說起產品架構，有些人或許會覺得陌生，但說起“技術架構”就會比較熟悉，產品架構，本質上與技術架構類似，是站在使用者的角度完成對業務需求的解讀。本文總結了產品架構圖如何畫的方法，一起來看看吧。

有沒有遇到過這樣的場景：

老板：我們最近打算要上一個**產品，你先規劃規劃，回頭我們一起討論一下？

那么，規劃什么？討論什么？

這就是我們今天一起去討論的話題：產品架構圖。

說起產品架構，有些人可能會覺得陌生，但說起另外一個詞“技術架構”大多數人都會感覺熟悉。

技術架構，從技術角度完成了對線上業務的解讀，將企業的業務需求轉化為可實現的技術方案，既需掌控整體又需兼顧局部。

那么產品架構，本質上與技術架構類似，是站在使用者的角度完成對業務需求的解讀。借助技術架構中流行的一句話：一切脫離業務的架構都是耍流氓，產品架構亦是如此。

一、什么是產品架構圖？

1. 產品架構圖的定義

產品架構圖，是產品經理站在使用角度對業務需求的解讀，是產品經理表達其對產品整體設計和規劃的可視化圖形。產品經理根據產品的戰略定位，將產品功能信息化、模塊化、層次化的呈現，并展現出不同層級的交互關系、功能模塊的組合關系及數據和信息的流轉關系，以此傳遞產品的戰略定位、商業模式、業務流程，甚至是發展規劃。

2. 產品架構圖的作用

從產品架構圖的定義就不難看出，產品架構圖圖的主要作用有以下幾點：

a、根據產品戰略定位，確定產品的用戶角色和需求；

b、根據用戶需求，推導出產品功能；

c、對產品功能進行統籌和規劃；

d、對技術&運營等環節的輸出形成支撐，為其他人的輸出節奏提供依據。

二、如何畫好產品架構圖？

要畫好產品架構圖，需要既有全局思維，又有考慮細節。這個過程不會一蹴而就，多嘗試積累，總會有進步。這里總結了畫好產品架構圖的六大步驟：

1. 確定產品戰略定位

在畫產品架構圖之前，先要確定產品的戰略定位。這個戰略定位，有可能是老板直接給你的，也有可能是你根據公司的產品組合確認的，還有可能是你通過競品分析得來的。

無論哪種方式，你都先確認好產品的戰略定位，它幫助我們：

a、確保產品與企業戰略一致；

b、確認產品的目標人群；

c、確認產品與其他產品或平臺的系統邊界和組合關系；

d、確認產品的市場定位目標；

2. 根據產品戰略定位，確定產品的用戶角色及需求

有了戰略戰略定位，就能確定產品的目標用戶是誰，這些用戶是否又有細分，他們的需求又是什么？舉個例子來解釋一下：

比如：To C類產品，購物網站，用戶大致分為3大類：購物物品的消費者、發布商品的商家、維護網站運行的平臺運營者，這3類用戶，他們的角色不一樣，在網站上的訴求也不一樣。消費者需要搜索到產品，需要查看商品詳情，需要完成產品購買，需要對訂單（購買）進行管理；商家需要發布商品、需要對店鋪進行線上裝修、需求咨詢答疑、需要訂單（售賣）進行管理等；平臺運營者的需求又不一樣。

再比如：To B類產品，某銀行的零售營銷平臺，分為：營銷策劃人員、營銷主管、渠道管理人員、系統管理人員等，他們的角色和需要亦不一樣。營銷策劃人員需完成客戶分析、客群探索、活動創建、活動評估等；營銷主管需對活動進行審批、活動執行情況查看等。

（示例：營銷平臺功能和角色對照表，部分）

3. 根據用戶角色和需求，梳理業務流程

確定了用戶角色和需求，其對應的業務流程亦出來了。每個角色，要完成什么工作，涉及到哪些功能，就很好梳理了。

比如ToB營銷平臺的案例，其活動流程涉及2個角色：營銷策劃人員和營銷主管。

（整體活動流程）

在整體流程下，有時又可能按場景再細分，同一個功能，在不同角色下，需求也不一樣，如審批功能：

（營銷策劃人員）

（營銷主管）

這些業務流程的梳理，串聯起整個業務線的架構。

業務流程的推導，常用的有以下幾種方式：

A、根據業務邊界來推導，即某個業務具有相對獨立性，比如購物網站中的物品搜索業務和物品下單業務；

B、根據業務場景來推導，如上文所示，這種推導方式，對業務沉淀要求較高，容易覆蓋不到所有場景，但有助于多角色和多功能間的邏輯關系梳理；

C、根據角色的職責邊界來推導，即當一個角色完成一件事后，由另一個角色開始履行職責，如公司內部常見的請假流程、報銷流程等。

4. 根據業務流程，推演出相關功能

當每個角色的所涉及到的業務流程梳理清楚后，我們就需要推演每個業務流程所涉及的各個業務點上，用戶需要完成什么工作，輸入輸出是什么，會遇到什么樣的問題，我們需要用什么樣的功能、頁面或處理機制，才能支持用戶目標的達成？

如此這樣，依次推演出所有業務流程所需功能。

5. 將功能進行聚合，區分出模塊和層次

根據業務流程完成功能推演之后，還不夠，還需對功能進行聚合，這種聚合可分為2個方面：

A、對功能進行模塊聚合

按模塊進行聚合，可以是同一功能的不同面進行組合，如：審批功能（審批者的審批功能和提交審批者的撤回審批功能）；亦可以是不同功能，按業務場景或業務定義和理解放到一起的功能組合，如：營銷中的“客群”生成，可以由多種功能完成（名單上傳、標簽圈選、預測模型生成、外系統接入等），這些功能組合成“客群”模塊。

B、對模塊進行層級劃分

當功能模塊化后，我們就需要按照一定的規則對模塊進行劃分。這種劃分規則，沒有固定的標準，常見的有：數據層、功能層、應用層、用戶/終端等。

（示例：源啟指標管理平臺）

實際操作時，建議可以從以下幾點進行考慮：

A、明確架構分層（需同時注意橫向和縱向）；

B、處理不同信息層級的邊界；

C、處理同一級內子模塊的邊界；

D、明確產品間的邊界（組合產品形成產品矩陣時）；

6. 加入信息流轉機制

信息流轉機制，是產品架構圖的最后一步，也是最容易被忽略的一步。產品架構圖除了對核心功能的表達外，還應體現信息流轉的路徑：當前層級或模塊的數據，產生新的數據，新的數據又推動下一層級或模塊數據的產生。

這種信息流轉機制，通常用箭頭表示，但對比較明顯的層級關系，也有不少隱藏箭頭的?？偟膩碚f，一定有一個數據流的方向性，或從下往上，或從左到右，或者從下往上中局部包含從左到右等。

（示例：源啟數字構建平臺）

至此，產品架構圖就完成了從想法到落地的，從業務需求到功能實現的轉化，將不可能變成可能。

文末再提一點，現今單獨一個產品完成所有業務需求的可能性越來越小，隨著對行業的深耕，更多的時候是以產品組合或產品矩陣的方式存在，形成整體解決方案，為客戶提供全方位服務。

所以，我們作為產品經理，在進行產品架構圖的設計時，系統邊界、與外系統的上下文交互、合力形成整體產品賣點等，也是我們需要重點考慮的。