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

否則，一切只是流于形式。反過來，也不必拘泥于形式。

本文將產品經理工作過程進行拆解，洞悉“好的產品經理”如何把工作落地。

01

產品經理工作的四個層

問起產品體驗要素，很多人脫口而出：戰略層、范圍層、結構層、框架層，表現層。

• 戰略層對應產品目標、用戶需求。是對目標，需求的商業化方案的歸納。

• 范圍層對應產品的信息和功能點，涉及到產品的側重點和取舍。

• 結構層對應產品的實際落地，產品在這個層面開始具體化。

• 框架層對應產品具體內容的呈現，產品進一步具體化，落實到界面。

• 表現層對應產品的視覺傳達，是產品的美化。

曾面試一個產品經理：怎么理解“產品架構”？他回答的也是這五層。似乎Jesse James Garrett老爺子的這十個字就是產品經理的B格句子。

但是大家自問，這十個字離你自身的感受很近嗎？

很明顯，這個五層壓根沒跑出一個產品的設計范疇。而冰山80%的內容是表現層看不到的。特別是后端產品經理的思維格局核心，絕對不是在這五個層面。

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

• 業務層（抽象業務訴求）

• 功能層（界定功能定義）

• 數據層（設計數據結構）

• 實現層（探討實現機制）

這四項幾乎包含了整個產品方案誕生的全部。其中前兩項是產品經理擔責任，后兩項技術人員擔責任。

• 重視第一層，是需求分析師；

• 重視第二層，是上文體驗五要素的踐行者；

• 做到后兩層，你就是別人眼中“懂技術”的產品經理。

• 做到上述四層，你就是讓團隊舒服，讓運營省心的產品經理。

作為團隊“布道者”和產品“owner”的產品經理，要做好一個大系統，四項缺一不可。

因為你真正掌握了業務足夠的素材，修復運營（或用戶）反饋的場景的閉環；

又洞察到如何調度內部結構和未來擴展，彌補著技術人員對需求洞察的邊界；

勾勒了產品本來的樣子，確保事情超正確方向發展。

02

業務層-抽象業務訴求

“兵者，國之大事，死生之地，存亡之道，不可不察也?！?/p>

同理，調研需求，是獲得立題的基礎。分析需求，是脫胎出產品雛形的依據。

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

需求分析有三種方式：面向故事、面向對象、面向結構。

• 面向故事：是面向用戶場景，按照用戶與業務場景，定義需求。

• 面向對象：是面向用例圖，按照用戶與產品系統交互的場景，定義需求。

• 面向結構：指的是面向功能結構。以“輸入-計算-輸出”的模型，分析功能分支，并組建功能樹。

以面向故事為例:

用戶故事就是“誰，做啥，價值”，也就是“作為誰，我想做什么，以實現什么”。也就是角色的抽象、需求的抽象、目標的抽象。

在此基礎上結合場景，即在什么場景下，誰，做啥，實現啥價值。形成故事矩陣。

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

領域模型，是對領域內的概念類或現實世界中對象的可視化表示。是對業務角色和業務實體之間應該如何聯系和協作以執行業務的一種抽象。

領域模型設計的步驟為:

1. 從業務描述中提取名詞;

2. 從提取出來的名詞中總結業務實體，區分名詞中的屬性、角色、實體、實例，形成問題域中操作實體的集合;

3. 從業務實體集合中抽象業務模型，建立問題域的概念(例如，我們把容易變質的水果稱之為"短期保持水果");

4. 用UML提供的方法和圖例進行領域模型設計、確定模型之間的關系;

領域模型設計是需求分析的關鍵步驟。它幫助用戶及需求分析人員建立業務概念，確定用戶業務的問題域，系統涉及的業務范圍等等，為功能的脫胎提供依據支持。

03

功能層-功能定義

有了業務場景和訴求，就可以把這些訴求轉化為以產品為載體的功能。

也就是從用例模型，向功能模型的轉化。通過觸發，響應式實現目的，連接用戶層和功能層。

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

舉個例子：在O2O電商平臺，商戶有700家門店，每個門店1萬種商品。組合成700萬門店*商品的矩陣數據。

那么，批量上下架很難全部一次執行。就算執行完畢，也要預防用戶無意識地反復操作。這會給服務器帶來“潛在風險”。

怎么辦呢？

在后端產品設計中，有一句話：“不能讓用戶用著太舒服”。

是不是與“別讓我想、別讓我等、別讓我煩”相悖呢？其實都是相對的。

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

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

1）功能替代：就是換一種方式，比如頁面勾選操作，一次只能選擇100條，那么我們可以改為批量導入后異步執行；

2）交互補償：就是通過交互，制造障礙或者制造便利，“強制”教化用戶。

3）組合功能：就是通過多個功能配合完成。以上述例子來說，可以通過單門店全量操作+復制門店上下架關系實現。

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

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

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

我們發現在定義功能之前往往是多套功能方案，篩選比對后的取舍結果。

需要注意的是，功能模型需要結合到產品模型中去。也就是盡量做成通用的輪子。將弱邏輯并入到強邏輯中，盡量不要為弱邏輯關系制造岔路。

隨后，進一步是將產品或功能落地為DEMO，這個是我們最熟悉的畫原型，這個環節對應的是框架層和表現層。

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

04

數據結構的梳理

當有個功能，自然想到功能中的數據。

數據就像血液，我們要搭建起來血管系統，定義出數據運行的秩序，也就是數據關系結構。

需要說明，到這里不是產品經理負責的，我們只是從業務層面，將實體映射為數據結構。為開發提供清晰的表達。

1、數據結構中包含哪些信息

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

我們只需要知道第一范式，就可以從業務角度界定出需要多少數據表。具體可以參考書籍《后端產品經理寶典》。

之所以要參與數據，是因為我們發現，當開發人員面對功能的時候，常常是不見森林的，他們要把許多功能碎片串聯起來，才能構建一個完整的數據體系。

而反過來，產品經理在搭建產品模型的時候，就同時在考慮數據的復用、數據的流轉、數據唯一性等。

當我們列出數據清單的時候，對開發不僅是提示，更是一種檢查清單，同時也是一種數據結構式的需求傳達方式。

舉例：下圖左側向下，是正常的流程圖；右側是用到的數據的結構。配合使用就能很清楚看到數據的流向、使用邏輯。

2、數據的維度是怎么樣的

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

又比如疾病和藥品和癥狀之間的關系：

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

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

3、字段的約束

這一點就簡單了，比如：人的年齡是數字，范圍不會超過200；

員工是否在職是布爾型的，不可能出現空，只會是是或否。

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

05

功能的實現機制

對一個功能來說，你看得到的靜態頁面，實現機制變數不大。

能做的無非是想法減少HTTP請求數、壓縮網頁元素、樣式表放在網頁head部分、JS文件放到網頁底部等。這些看前端的水準了。

功能實現機制更多的心思是后端方案。而后端方案最終是考慮數據的運行。

把數據比作為血管，那么實現機制就考慮如何觸發心臟跳動勃血等。

這時候考慮數據變更的觸發因素、數據的流轉機制、過濾機制、異常機制、復用性等。

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

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

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

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

再看一個例子：

想象一個對碼功能：檢測平臺銷售的商品編碼，在ERP能查到，查到即為對碼成功。以確保能正常發貨。

觸發條件：創建平臺后臺的商品的時候、手動點擊對碼的時候、從平臺下載商品的時候，挺多的。

那么就可以把這個對碼服務做成通用的插件，供多處調用。

這些可以被共同調用的，可視為中間件，將其用模型化的通用的輪子。當技術架構是這種架構的時候，就可算微服務架構。

在微服務架構中，每個服務都是自我包含的，并且實現了單一的業務功能。

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

我們也只需知道技術的原理即可。

產品經理能整理出檢查清單，并輔助開發人員同步跟進，會讓開發輕松，整個項目的質量會得到很大提升。

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

總結：作為產品經理，是否全棧、是否或切圖等都是次要的，首要是作為布道者把事情理清楚，以產品思維，做產品經理的本質工作，確保產品環節的質量落地到實處。

↘好文推薦：

字節跳動的產品經理是怎么工作的？

產品經理跳槽面試大揭秘……

B端產品如何進行業務全場景的需求梳理？

點個“在看”吧

總結

以上是生活随笔為你收集整理的从四个层面落地，成为受欢迎、可信赖、懂技术的产品经理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。