說起産品架構，有些人或許會覺得陌生，但說起“技術架構”就會比較熟悉，産品架構，本質上與技術架構類似，是站在使用者的角度完成對業務需求的解讀。本文總結了産品架構圖如何畫的方法，一起來看看吧。
有沒有遇到過這樣的場景：
老闆：我們最近打算要上一個**産品，你先規劃規劃，回頭我們一起讨論一下？
那麼，規劃什麼？讨論什麼？
這就是我們今天一起去讨論的話題：産品架構圖。
說起産品架構，有些人可能會覺得陌生，但說起另外一個詞“技術架構”大多數人都會感覺熟悉。
技術架構，從技術角度完成了對線上業務的解讀，将企業的業務需求轉化為可實作的技術方案，既需掌控整體又需兼顧局部。
那麼産品架構，本質上與技術架構類似，是站在使用者的角度完成對業務需求的解讀。借助技術架構中流行的一句話：一切脫離業務的架構都是耍流氓，産品架構亦是如此。
一、什麼是産品架構圖？
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. 加入資訊流轉機制
資訊流轉機制，是産品架構圖的最後一步，也是最容易被忽略的一步。産品架構圖除了對核心功能的表達外，還應展現資訊流轉的路徑：目前層級或子產品的資料，産生新的資料，新的資料又推動下一層級或子產品資料的産生。
這種資訊流轉機制，通常用箭頭表示，但對比較明顯的層級關系，也有不少隐藏箭頭的。總的來說，一定有一個資料流的方向性，或從下往上，或從左到右，或者從下往上中局部包含從左到右等。
（示例：源啟數字建構平台）
至此，産品架構圖就完成了從想法到落地的，從業務需求到功能實作的轉化，将不可能變成可能。
文末再提一點，現今單獨一個産品完成所有業務需求的可能性越來越小，随着對行業的深耕，更多的時候是以産品組合或産品矩陣的方式存在，形成整體解決方案，為客戶提供全方位服務。
是以，我們作為産品經理，在進行産品架構圖的設計時，系統邊界、與外系統的上下文互動、合力形成整體産品賣點等，也是我們需要重點考慮的。
本文由 @産品路上 原創釋出于人人都是産品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于 CC0 協定
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。