如何畫產品架構圖?

0 評論 16539 瀏覽 180 收藏 12 分鐘

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

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

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

那么,規劃什么?討論什么?

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

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

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

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

一、什么是產品架構圖?

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,一定有一個數據流的方向性,或從下往上,或從左到右,或者從下往上中局部包含從左到右等。

(示例:源啟數字構建平臺)

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

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

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

本文由 @產品路上 原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自Unsplash,基于 CC0 協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!