編輯導語：產(chǎn)品經(jīng)理的日常工作需要與很多人打交道，因此成為一名受歡迎、可信賴、懂技術(shù)的產(chǎn)品經(jīng)理是很重要的，對于工作的推進也有好處。那么，如何才能成為這樣的產(chǎn)品經(jīng)理呢？本文作者總結(jié)了四個層面，幫助你成為產(chǎn)品經(jīng)理中的萬人迷。

我們談產(chǎn)品架構(gòu)、畫圖示、寫文檔，歸根結(jié)底的價值，在于表達對“需求—>功能—>擴展”等方面的深度理解，并傳達其他人。

否則，一切只是流于形式。反過來，也不必拘泥于形式。本文將產(chǎn)品經(jīng)理工作過程進行拆解，洞悉“好的產(chǎn)品經(jīng)理”如何把工作落地。

01?產(chǎn)品經(jīng)理工作的四個層

問起產(chǎn)品體驗要素，很多人脫口而出：戰(zhàn)略層、范圍層、結(jié)構(gòu)層、框架層，表現(xiàn)層。

• 戰(zhàn)略層對應產(chǎn)品目標、用戶需求，是對目標，需求的商業(yè)化方案的歸納；
• 范圍層對應產(chǎn)品的信息和功能點，涉及到產(chǎn)品的側(cè)重點和取舍；
• 結(jié)構(gòu)層對應產(chǎn)品的實際落地，產(chǎn)品在這個層面開始具體化；
• 框架層對應產(chǎn)品具體內(nèi)容的呈現(xiàn)，產(chǎn)品進一步具體化，落實到界面；
• 表現(xiàn)層對應產(chǎn)品的視覺傳達，是產(chǎn)品的美化。

曾面試一個產(chǎn)品經(jīng)理：怎么理解“產(chǎn)品架構(gòu)”？

他回答的也是這五層，似乎Jesse James Garrett老爺子的這十個字就是產(chǎn)品經(jīng)理的B格句子。但是大家自問，這十個字離你自身的感受很近嗎？

很明顯，這個五層壓根沒跑出一個產(chǎn)品的設(shè)計范疇。而冰山80%的內(nèi)容是表現(xiàn)層看不到的。特別是后端產(chǎn)品經(jīng)理的思維格局核心，絕對不是在這五個層面。

如果我們也將產(chǎn)品經(jīng)理的工作重心分個層次，我認為產(chǎn)品經(jīng)理的工作（尤其是泛后臺、中臺、B端產(chǎn)品）是四層：

1. 業(yè)務層（抽象業(yè)務訴求）
2. 功能層（界定功能定義）
3. 數(shù)據(jù)層（設(shè)計數(shù)據(jù)結(jié)構(gòu)）
4. 實現(xiàn)層（探討實現(xiàn)機制）

這四項幾乎包含了整個產(chǎn)品方案誕生的全部，其中前兩項是產(chǎn)品經(jīng)理擔責任，后兩項技術(shù)人員擔責任。

• 重視第一層，是需求分析師；
• 重視第二層，是上文體驗五要素的踐行者；
• 做到后兩層，你就是別人眼中“懂技術(shù)”的產(chǎn)品經(jīng)理；
• 做到上述四層，你就是讓團隊舒服，讓運營省心的產(chǎn)品經(jīng)理。

作為團隊“布道者”和產(chǎn)品“owner”的產(chǎn)品經(jīng)理，要做好一個大系統(tǒng)，四項缺一不可。因為你真正掌握了業(yè)務足夠的素材，修復運營（或用戶）反饋的場景的閉環(huán)。

又洞察到如何調(diào)度內(nèi)部結(jié)構(gòu)和未來擴展，彌補著技術(shù)人員對需求洞察的邊界；勾勒了產(chǎn)品本來的樣子，確保事情超正確方向發(fā)展。

02?業(yè)務層-抽象業(yè)務訴求

“兵者，國之大事，死生之地，存亡之道，不可不察也?！蓖?，調(diào)研需求，是獲得立題的基礎(chǔ)。分析需求，是脫胎出產(chǎn)品雛形的依據(jù)。

因為我們看到的用戶行為是雜亂的，用戶的需求也是無序的。這時候進行歸類和窮舉，再提煉并抽象出用戶的需求模型。

需求分析有三種方式：面向故事、面向?qū)ο?、面向結(jié)構(gòu)：

• 面向故事：是面向用戶場景，按照用戶與業(yè)務場景，定義需求。
• 面向?qū)ο螅菏敲嫦蛴美龍D，按照用戶與產(chǎn)品系統(tǒng)交互的場景，定義需求。
• 面向結(jié)構(gòu)：指的是面向功能結(jié)構(gòu)。以“輸入-計算-輸出”的模型，分析功能分支，并組建功能樹。

以面向故事為例：用戶故事就是“誰，做啥，價值”，也就是“作為誰，我想做什么，以實現(xiàn)什么”。也就是角色的抽象、需求的抽象、目標的抽象。

在此基礎(chǔ)上結(jié)合場景，即在什么場景下，誰，做啥，實現(xiàn)啥價值。形成故事矩陣。

故事矩陣的窮舉，把用戶故事組織成用戶故事地圖，并輸出技術(shù)場景下的需求定義：領(lǐng)域模型。

領(lǐng)域模型，是對領(lǐng)域內(nèi)的概念類或現(xiàn)實世界中對象的可視化表示。是對業(yè)務角色和業(yè)務實體之間應該如何聯(lián)系和協(xié)作以執(zhí)行業(yè)務的一種抽象。

領(lǐng)域模型設(shè)計的步驟為：

1. 從業(yè)務描述中提取名詞；
2. 從提取出來的名詞中總結(jié)業(yè)務實體，區(qū)分名詞中的屬性、角色、實體、實例，形成問題域中操作實體的集合；
3. 從業(yè)務實體集合中抽象業(yè)務模型，建立問題域的概念（例如，我們把容易變質(zhì)的水果稱之為“短期保持水果”）；
4. 用UML提供的方法和圖例進行領(lǐng)域模型設(shè)計、確定模型之間的關(guān)系。

領(lǐng)域模型設(shè)計是需求分析的關(guān)鍵步驟。它幫助用戶及需求分析人員建立業(yè)務概念，確定用戶業(yè)務的問題域，系統(tǒng)涉及的業(yè)務范圍等等，為功能的脫胎提供依據(jù)支持。

03?功能層-功能定義

有了業(yè)務場景和訴求，就可以把這些訴求轉(zhuǎn)化為以產(chǎn)品為載體的功能。也就是從用例模型，向功能模型的轉(zhuǎn)化。通過觸發(fā)，響應式實現(xiàn)目的，連接用戶層和功能層。

需求是靶點，功能是箭。有時候需求范圍很大，就很難命中痛點。同樣，功能常常也有局限性。

舉個例子：在O2O電商平臺，商戶有700家門店，每個門店1萬種商品。組合成700萬門店*商品的矩陣數(shù)據(jù)。那么，批量上下架很難全部一次執(zhí)行。就算執(zhí)行完畢，也要預防用戶無意識地反復操作——這會給服務器帶來“潛在風險”。

怎么辦呢？

在后端產(chǎn)品設(shè)計中，有一句話：“不能讓用戶用著太舒服”。是不是與“別讓我想、別讓我等、別讓我煩”相悖呢？其實都是相對的。

過于舒服的操作，用戶感受不到背后的復雜邏輯。輕輕點擊一個按鈕，服務器要承載多大的壓力，后端產(chǎn)品數(shù)據(jù)量可能瞬間暴增到極點。

基于這種思維，對于案例中的功能，通常有四種方案：功能替代、交互補償、組合功能、降維處理。

• 功能替代，就是換一種方式，比如頁面勾選操作，一次只能選擇100條，那么我們可以改為批量導入后異步執(zhí)行；
• 交互補償，就是通過交互，制造障礙或者制造便利，“強制”教化用戶；
• 組合功能：就是通過多個功能配合完成。以上述例子來說，可以通過單門店全量操作+復制門店上下架關(guān)系實現(xiàn)。

即：全量商品上下架時，系統(tǒng)要求必須是單門店。等做好一個門店的時候，其余門店可以復制這個門店的商品的上下架狀態(tài)。

這個方案從后臺處理量來說，和直接支持全門店全商品差不多，但是操作的“復雜”，會減少用戶頻次，起到一定避災作用。

• 降維處理，就是考慮線下其他方式解決用戶目的。比如《后端產(chǎn)品經(jīng)理寶典》一書中一個案例：做一個防止客對訂單做手腳謀取私利的功能，不如不做功能，而是改用加強團隊培訓和監(jiān)管的方式。

我們發(fā)現(xiàn)在定義功能之前往往是多套功能方案，篩選比對后的取舍結(jié)果。需要注意的是，功能模型需要結(jié)合到產(chǎn)品模型中去。也就是盡量做成通用的輪子。將弱邏輯并入到強邏輯中，盡量不要為弱邏輯關(guān)系制造岔路。

隨后，進一步是將產(chǎn)品或功能落地為DEMO，這個是我們最熟悉的畫原型，這個環(huán)節(jié)對應的是框架層和表現(xiàn)層。

同時要明確，功能是有邊界的。避免墜入需求蔓延或鍍金之路。

04?數(shù)據(jù)結(jié)構(gòu)的梳理

當有個功能，自然想到功能中的數(shù)據(jù)。數(shù)據(jù)就像血液，我們要搭建起來血管系統(tǒng)，定義出數(shù)據(jù)運行的秩序，也就是數(shù)據(jù)關(guān)系結(jié)構(gòu)。

需要說明，到這里不是產(chǎn)品經(jīng)理負責的，我們只是從業(yè)務層面，將實體映射為數(shù)據(jù)結(jié)構(gòu)，為開發(fā)提供清晰的表達。

1. 數(shù)據(jù)結(jié)構(gòu)中包含哪些信息

我們把功能中的名詞拿出來，也就是事物實體，根據(jù)該事物可能用到的屬性，構(gòu)建E-R模型。

我們只需要知道第一范式，就可以從業(yè)務角度界定出需要多少數(shù)據(jù)表。之所以要參與數(shù)據(jù)，是因為我們發(fā)現(xiàn)，當開發(fā)人員面對功能的時候，常常是不見森林的，他們要把許多功能碎片串聯(lián)起來，才能構(gòu)建一個完整的數(shù)據(jù)體系。

而反過來，產(chǎn)品經(jīng)理在搭建產(chǎn)品模型的時候，就同時在考慮數(shù)據(jù)的復用、數(shù)據(jù)的流轉(zhuǎn)、數(shù)據(jù)唯一性等。當我們列出數(shù)據(jù)清單的時候，對開發(fā)不僅是提示，更是一種檢查清單，同時也是一種數(shù)據(jù)結(jié)構(gòu)式的需求傳達方式。

舉例：下圖左側(cè)向下，是正常的流程圖；右側(cè)是用到的數(shù)據(jù)的結(jié)構(gòu)，配合使用就能很清楚看到數(shù)據(jù)的流向、使用邏輯。

2. 數(shù)據(jù)的維度是怎么樣的

我們需要知道數(shù)據(jù)表的維度。比如發(fā)貨這件事，以訂單維度最合適。但是存在一個訂單多個商品，多個包裹的情況。

又比如疾病和藥品和癥狀之間的關(guān)系：

與此同時，唯一鍵就出現(xiàn)了。他是為了標示數(shù)據(jù)的唯一性：在業(yè)務中，遇到重復的，可以進行一些處理措施。

在定義類似場景的時候，一定要定義出什么算是“重復數(shù)據(jù)”，比如這樣：

3. 字段的約束

這一點就簡單了，比如：人的年齡是數(shù)字，范圍不會超過200；員工是否在職是布爾型的，不可能出現(xiàn)空，只會是是或否。

需注意：數(shù)據(jù)表重點約束與前端的約束可以不同。也就是數(shù)據(jù)庫可能支持很多個字，但是前端為了保證整齊度，只讓輸入4個字等。

05?功能的實現(xiàn)機制

對一個功能來說，你看得到的靜態(tài)頁面，實現(xiàn)機制變數(shù)不大。能做的無非是想法減少HTTP請求數(shù)、壓縮網(wǎng)頁元素、樣式表放在網(wǎng)頁head部分、JS文件放到網(wǎng)頁底部等。這些看前端的水準了。

功能實現(xiàn)機制更多的心思是后端方案，而后端方案最終是考慮數(shù)據(jù)的運行。把數(shù)據(jù)比作為血管，那么實現(xiàn)機制就考慮如何觸發(fā)心臟跳動勃血等。

這時候考慮數(shù)據(jù)變更的觸發(fā)因素、數(shù)據(jù)的流轉(zhuǎn)機制、過濾機制、異常機制、復用性等。

有時候觸發(fā)的機制是雙向的。比如，在B2C業(yè)務中，每次有倉庫庫存變化，都要查詢發(fā)貨倉庫配置關(guān)系，然后計算出各倉可供應的匯總庫存。

同時，我們應該想到，若發(fā)貨倉庫配置關(guān)系變更，也應該通知重新計算庫存（因為總庫存是要展示在商城端的）。

那么這樣就要做兩套接口，一套是：商品庫存后臺，請求倉庫，一套是倉庫請求商品庫存后臺。

但實際還可以有一種方案，只做一個公共的觸發(fā)重新計算庫存的服務，配置接口，倉庫和商品中心滿足觸發(fā)條件的情況下，各自調(diào)用。

再看一個例子：

想象一個對碼功能：檢測平臺銷售的商品編碼，在ERP能查到，查到即為對碼成功，以確保能正常發(fā)貨；觸發(fā)條件：創(chuàng)建平臺后臺的商品的時候、手動點擊對碼的時候、從平臺下載商品的時候，挺多的。

那么就可以把這個對碼服務做成通用的插件，供多處調(diào)用。這些可以被共同調(diào)用的，可視為中間件，將其用模型化的通用的輪子。當技術(shù)架構(gòu)是這種架構(gòu)的時候，就可算微服務架構(gòu)。

在微服務架構(gòu)中，每個服務都是自我包含的，并且實現(xiàn)了單一的業(yè)務功能。

到這里需要明確，我們不是指導開發(fā)寫代碼建數(shù)據(jù)表，甚至也不是干涉。而是基于業(yè)務提出的業(yè)務視角的技術(shù)設(shè)計建議。最終以開發(fā)的為準。

我們也只需知道技術(shù)的原理即可，產(chǎn)品經(jīng)理能整理出檢查清單，并輔助開發(fā)人員同步跟進，會讓開發(fā)輕松，整個項目的質(zhì)量會得到很大提升。

不會導致產(chǎn)品經(jīng)理像聽天書一樣陪襯，同時也會增強自己在團隊的信任度。

總結(jié)：作為產(chǎn)品經(jīng)理，是否全棧、是否或切圖等都是次要的，首要是作為布道者把事情理清楚，以產(chǎn)品思維，做產(chǎn)品經(jīng)理的本質(zhì)工作，確保產(chǎn)品環(huán)節(jié)的質(zhì)量落地到實處。

#專欄作家#

唧唧歪歪PM，公眾號：唧唧歪歪PM（ID：jjyypm），人人都是產(chǎn)品經(jīng)理專欄作家，2019年年度作者?！逗蠖水a(chǎn)品經(jīng)理寶典》作者，藥學碩士轉(zhuǎn)行互聯(lián)網(wǎng)產(chǎn)品多年；熟悉跨境電商業(yè)務，醫(yī)藥領(lǐng)域；擅長大型后臺體系，社交APP。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議