產(chǎn)品經(jīng)理關(guān)于「產(chǎn)品架構(gòu)設(shè)計(jì)」,我的實(shí)踐思考

1、本文中，筆者將結(jié)合自己參與產(chǎn)品重構(gòu)以及做SaaS產(chǎn)品的實(shí)踐，與大家分享一些關(guān)于產(chǎn)品架構(gòu)設(shè)計(jì)的思考，希望對(duì)你有所啟發(fā)。作為一名產(chǎn)品助理，入職后剛好趕上產(chǎn)品重構(gòu)，我也就 “趁機(jī) ”參與其中，主要負(fù)責(zé)將撰寫PRD,與設(shè)計(jì)和開發(fā)對(duì)接。那時(shí)的我對(duì)SaaS產(chǎn)品的理解很淺，甚至說對(duì)業(yè)務(wù)場(chǎng)景、產(chǎn)品定義、需求價(jià) 值，沒有一套判斷標(biāo)準(zhǔn)和行為準(zhǔn)則。但好在自己有一股沖勁，不停地做、不停 地問，也就這樣跌跌撞撞地熬過來(lái)了。隨后為了提升SaaS產(chǎn)品能力，系統(tǒng)地學(xué)習(xí)知識(shí)，并對(duì)以往的工作內(nèi)容做復(fù) 盤。一是反思當(dāng)時(shí)產(chǎn)品團(tuán)隊(duì)決策的正確性，二是希望自己能在接下來(lái)的工作中 做得更好。接下來(lái)，針對(duì)產(chǎn)品架構(gòu)設(shè)計(jì)的這個(gè)問題，與你分享我的思

2、考與方式，希望能與你交流。產(chǎn)品架構(gòu)設(shè)計(jì)的第一步，需要保證業(yè)務(wù)調(diào)研的結(jié)果，以及產(chǎn)品戰(zhàn)略上的定義是正確的。對(duì)此最直接的方法，就是畫業(yè)務(wù)流程圖。這不僅可以將你腦中抽象的業(yè)務(wù)具象化，而且你可以拿著它直接與客戶進(jìn)行溝通，明確你的理解是否存在偏 差。要知道SaaS產(chǎn)品的最大好處，就是需求一定存在于真實(shí)的業(yè)務(wù)中。因此，客戶能根據(jù)你的描述，判斷你的理解是否與他們真實(shí)的工作相符。不過這里也需要注意遺漏，畢竟一些頻率低的場(chǎng)景對(duì)方也是會(huì)遺漏的。接下來(lái)，以我負(fù)責(zé)的SaaS產(chǎn)品為例，來(lái)介紹一下當(dāng)時(shí)產(chǎn)品架構(gòu)設(shè)計(jì)的整體 過程。我負(fù)責(zé)的產(chǎn)品主要面向的餐飲加盟行業(yè)，是將實(shí)體門店巡檢線上化，實(shí)現(xiàn)信息化管理。總得來(lái)說是后端PC派發(fā)

3、任務(wù)，前端App執(zhí)行任務(wù)。此圖在細(xì)節(jié)上做過改動(dòng)，并不完全代表真實(shí)場(chǎng)景找出最全的業(yè)務(wù)鏈條，從產(chǎn)品定位、客戶角色、業(yè)務(wù)流程、階段分布等多個(gè)角度繪制業(yè)務(wù)流程圖。這樣做的好處是：大多數(shù)SaaS產(chǎn)品面向的不是單個(gè)的人，而是由一群具有通用特征的人群， 組成的一個(gè)組織。這類通用特征的人群，在現(xiàn)實(shí)中用崗位劃分，而對(duì)應(yīng)到系統(tǒng)中就會(huì)用角色來(lái)稱呼。其實(shí)本質(zhì)是一樣的。我們需要對(duì)業(yè)務(wù)調(diào)研結(jié)果進(jìn)行整理，明確角色的描述、種類、工作內(nèi)容、關(guān)注指標(biāo)、行為邊界等信息。這是因?yàn)橄到y(tǒng)早期沒有資源做權(quán)限模塊的設(shè)計(jì)，因此我們可以根據(jù)這些信息，在系統(tǒng)中預(yù)置這些角色的權(quán)限，在之后直接調(diào)用即可。但需要注意的是，我們不能僅局限于一家企業(yè)，需要調(diào)

4、研多家同類企業(yè)，做彼此間的交叉驗(yàn)證以及通用整合。最后將角色分為通用類和個(gè)性類兩種。我們需要將精力重點(diǎn)用在通用類角色身上，個(gè)性類角色不是重點(diǎn)，甚至可以考慮用通用類角色替代個(gè)性類角色。而具體在系統(tǒng)內(nèi)的承載方式，可以考慮在人員部分加一個(gè)崗位字段值，用于承載通用類角色的權(quán)限。一來(lái)用戶理解起來(lái)容易，二來(lái)在后面設(shè)計(jì)權(quán)限功能模塊的時(shí)候可以做到很好的替換。不得不說，即使作為產(chǎn)品助理，心里也得有一張路線圖，需要能夠看到產(chǎn)品的全貌，需要走一步看兩步。場(chǎng)景需求清單是對(duì)實(shí)際業(yè)務(wù)場(chǎng)景的描述，產(chǎn)品經(jīng)理需要將他們梳理分類，最后呈現(xiàn)出來(lái)。下面是梳理出的PC端核心業(yè)務(wù)場(chǎng)景需求清單，這里重點(diǎn)考驗(yàn)的是產(chǎn)品經(jīng) 理將需求翻譯成功能的能

5、力。但實(shí)際上，從客戶那里得到的業(yè)務(wù)場(chǎng)景遠(yuǎn)比這個(gè)多，但對(duì)于公司來(lái)說不可能一上來(lái)就全部滿足。因此SaaS產(chǎn)品最初的設(shè)計(jì)同樣遵循 MVP （最小可行化）原則，即完成核 心業(yè)務(wù)場(chǎng)景的閉環(huán)。在此基礎(chǔ)上先能讓客戶用起來(lái)，在這個(gè)過程中不斷的累加功能、完善服務(wù)。況且客戶在系統(tǒng)上產(chǎn)生數(shù)據(jù)，實(shí)際上就是產(chǎn)生依賴，隨之用戶的替換成本也會(huì)一點(diǎn)點(diǎn)的提高。通用架構(gòu)有兩種 管理通用架構(gòu)和商業(yè)通用架構(gòu)。而我負(fù)責(zé)的產(chǎn)品顯然屬于管理類，因此這里我會(huì)先找出符合通用模塊的功能，進(jìn)行歸類整合，避免重復(fù)造輪子。由于剛開始的業(yè)務(wù)比較簡(jiǎn)單，因此符合度很高，并沒有做過多的拆分。不過相信你也發(fā)現(xiàn)了一個(gè)問題，就是數(shù)據(jù)管理中的這個(gè)簽到數(shù)據(jù)，它是從哪來(lái)

6、的？先介紹一下這個(gè)業(yè)務(wù)背景：某企業(yè)的每個(gè)督導(dǎo)負(fù)責(zé)10 家左右的門店，每天根據(jù)任務(wù)巡檢門店，除此之外還要處理一些門店的瑣事。這就會(huì)導(dǎo)致督導(dǎo)在當(dāng)天沒有完成對(duì)應(yīng)門店的巡檢，而上級(jí)需要知道他們的行蹤。對(duì)方目前的解決方案，是通過釘釘?shù)暮灥絹?lái)完成。而對(duì)方希望能逐步使用我們的系統(tǒng)完成，同時(shí)在一些個(gè)性化需求上，比如數(shù)據(jù)導(dǎo)出方面能夠滿足他們的訴求。在考慮產(chǎn)品定位、需求ROI 等信息后，最終選擇開發(fā)這個(gè)簽到功能，并將數(shù)據(jù)導(dǎo)出部分放在了數(shù)據(jù)管理里面。話說回來(lái)，SaaS產(chǎn)品的每一個(gè)功能，都是在明確解決一個(gè)具體的業(yè)務(wù)問題。因此在設(shè)計(jì)架構(gòu)的時(shí)候，我們要注意功能模塊的包容性，而不是單純的累加。當(dāng)然還有一種情況，接下來(lái)隨著業(yè)

7、務(wù)的發(fā)展，一定會(huì)出現(xiàn)不符合通用模塊的功能。到那時(shí)，我會(huì)根據(jù)業(yè)務(wù)重要程度和復(fù)雜性單獨(dú)進(jìn)行整合，例如任務(wù)管理模塊，目前在App端允許執(zhí)行人將任務(wù)移交給他他人，但目前PC端并沒有記錄。因此隨著后續(xù)的業(yè)務(wù)發(fā)展，會(huì)結(jié)合整改業(yè)務(wù)的部分，將任務(wù)管理整個(gè)抽離出來(lái)單獨(dú)形成一個(gè)模塊做設(shè)計(jì)。當(dāng)然這就是后話了，但我們要知道架構(gòu)不會(huì)一成不變，它會(huì)隨著業(yè)務(wù)復(fù)雜程度的提高，慢慢地拓展成長(zhǎng)。要知道業(yè)務(wù)是一個(gè)鏈條，上下游的銜接一定會(huì)產(chǎn)生數(shù)據(jù)。因此我們可以將模塊分為兩類，一是存在基礎(chǔ)信息，但不產(chǎn)生數(shù)據(jù)流的靜態(tài)模塊，二是產(chǎn)生數(shù)據(jù)流通的動(dòng)態(tài)模塊。對(duì)于上面我提到的模塊，品牌管理、任務(wù)管理屬于靜態(tài)模塊，數(shù)據(jù)管理、數(shù)據(jù)看板屬于動(dòng)態(tài)模塊。數(shù)據(jù)從哪來(lái)到哪去，會(huì)在哪些節(jié)點(diǎn)發(fā)生變化，這些產(chǎn)品經(jīng)理也需要做到心中有數(shù)。到此，就是我目前產(chǎn)品的架構(gòu)形態(tài)。這次產(chǎn)品設(shè)計(jì)的過程雖然存在很多問題，