起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識規劃：TO B產品架構圖，用這6步搞定，錯過就要再等（1）
導語：軟件工程是一項復雜的項目工程，架構設計的好壞往往決定著項目的成功或失敗。To B的產品人在設計一款產品時，學會搭建產品架構是一項必備的能力。這里我們來聊聊To B的產品架構如何去搭建，能讓你的產品生命周期更長，更穩定。
“產品架構猶如房屋地基、人體骨骼、車輛核心部件?！?/p>
“架構”一詞最早來源于建筑，其核心是通過一系列構件的組合來承載上層傳遞的壓力。經過漫長的演變，架構設計的理念已經深入多個行業和場景，成為了必不可少的活動。
01 架構認知
1. 架構的含義
架構一詞，從韋伯詞典中定義為“一種意識過程結果的形態或框架；一種統一或有條理的形式或結構”。這里的關鍵部分是具有特定結構的，有條理的，這個定義很抽象，很不好理解，說人話核心我們要把握住“框架”、“結構”、“有條理”這幾個關鍵詞就好了。
我們來看一個例子：
車的骨架由車身、車架、發動機、制動設備、輪胎和電器設備等構成，這些組件構成了一款完整的車，提供駕駛服務，這些組件的好壞決定著車的使用壽命和服務體驗；組件數量的多少決定著車所能提供的服務邊界在哪，不是越多功能越多好，也不是只有一個車身就行，組件的最低數量是起碼保證一款車能夠正常使用。
同理，軟件產品是不是也需要具備同樣的邏輯，保證一款軟件產品能夠正常使用，滿足用戶訴求，解決用戶的問題。
我們有一個不容忽視的問題，軟件領域發展到今天，延伸出了企業架構、業務架構、應用架構、數據架構、產品架構、技術架構等一堆的名詞。是不是有點暈了，這些架構都是用來干什么，它們之間有什么區別？不搞清楚它們之間的關系，產品架構從何談起。
2. 架構之間的區別和聯系
這么多名詞，它們是如何定義的？相互之間如何區分和聯系？這里做一些簡單的說明，詳細的解釋和案例還望各位童鞋翻閱架構相關書籍。我們來看下面這張圖。
1）業務架構
業務架構是指企業通過分析自身所處的外界環境，自身面臨的機遇和挑戰，同時剖析自身的結構特點和資源情況，明確自身優劣勢，從而選擇和制定企業發展目標，制定具體的實施方案和計劃。
核心要素主要包括業務目標、資源能力、業務流程和組織結構；放在企業層面是企業業務目標，放在部門層面是部門業務目標。
對業務架構我們要思考一下的問題：
- 達成的目標是什么；
- 做什么業務；
- 資源和能力在哪里；
- 什么樣方式在什么樣的組織里做；
舉例來說：企業采購業務的業務架構
- 業務目標：合理、合規、高效、節約的方式為集團各部門提供尋源、合同簽訂、訂單執行等服務，保障和保本各運營業務線的運行。
- 資源能力：品類豐富、規模優勢、采購模式多樣，具備一定的市場話語權。
- 業務流程：以集團統管的方式，實現供應商交付，需求部門驗收的上下游流程一體化的格局。
- 組織結構：建立集采、分采等采購團隊，集中管控+授權自購的組織體系。
2）數據架構
數據架構是基于數據管理領域知識經驗的總結，提煉指導未來數據管理的過程。
主要包括數據治理和數據管理，數據治理包括數據管理政策，原則，規范和標準等；數據管理包括數據總體視圖和數據結構，數據庫設計等。
下圖是一張總體視圖：
3）技術架構
技術架構是將數據架構和應用架構落實下去，通過技術的手段實現出來。主要包括架構規劃和技術選型等事項。架構規劃包括網絡、平臺、語言、中臺、微服務等概念規劃；技術選型主要是具體到某個產品時技術方案的選型，包括開源框架、語言、架構風格、數據庫、中間件等。
我們來參考一個單個產品的技術架構方案，如下圖：
圖片來源：百度圖片
4）應用架構
應用架構是描述一個企業各個相互獨立的應用系統的部署以及核心業務流程之間的關系，目的是建立業務架構與數據架構和其他架構之間的關聯；它能連接業務架構的流程，功能，人員，也能夠連接數據架構中的數據管理和使用，還能提出對技術架構的要求。主要分為表現層、應用層和數據層來表示
產品架構是產品的結構，是對某一塊具體業務的進行抽象，并用可視化的方式呈現出來，它劃分了功能模塊、數據流向，包括現有的，以及未來規劃的。其目的不僅是為了架構設計的簡潔性，更是為了整個業務的完整性，把離散的業務過程場景化。
產品架構和應用架構的關系？
產品架構是應用架構的一部分，當應用架構只有一個產品時，也就是產品架構。多個產品組合一起形成了企業應用架構全景圖。
這里主要闡述如何規劃產品架構圖。
02 為什么產品架構圖
畫產品架構圖目的是為了將業務架構拆解并梳理出產品思路，整體上把握產品的發展方向，把控產品的核心功能，決定了產品功能的實現路徑和大體規劃。當然，架構本身也是需要隨業務的發展逐步的演進，具備一定的擴展性。這里闡述幾條做架構的好處：
1）梳理產品方向和規劃路徑
這種圖本身就體現了整個產品的結構，包括已實現的和未實現的，為產品的迭代指明方向，判斷產品之間的依賴和關系。
2）為團隊提供明確的目標
團隊成員，包括，研發、測試、運營、市場和銷售，能夠根據這張圖了解產品的規劃，相應的團隊可采取對應的策略。比如，研發可思考技術方案，市場和銷售可制定產品的推銷策略等。
3）建立業務全景圖
產品規劃是從業務架構中抽象出來的，反過來，可以幫助業務部門完善業務制度、和管理標準化，實現整個鏈條上的閉環。
03 構建產品架構圖
構建產品架構圖是需要產品人具備較高的綜合能力，包括不限于：
- 相關的業務知識；
- 對相關成熟的商業產品了如指掌；
- 一定的技術知識儲備；
- 產品戰略和規劃的能力；
- 抽象、歸納和結構化思維能力；
這里提供一個方法：6步構建To B產品架構圖
1. 梳理用戶故事，全面認識業務需求，形成業務閉環
不管是從0到1構建一款產品，還是1到N迭代一款產品，當新的業務場景進來時，我們先要進行用戶分析和需求調研，全面的認識需求，從組織級，用戶級，開發級三個層面考慮不同類型的功能需求、質量需求和約束條件。比如，我們看一個企業采購需求到合同簽訂的場景。
這里用戶提交需求，中間經過招投標，最后才簽訂合同，涉及多個角色，多個業務場景，我們在分析的時候，就要全面的調研整個業務環節的用戶，并記錄其相應的業務訴求和現狀。
2. 識別業務鏈條的業務領域以及問題域
用戶的需求陳述可能是模糊，可能是清晰的，我們在獲取用戶需求后，先要判斷業務領域，再識別該領域內的問題。
1）業務領域，是一個組織所做的事情以及其中所包含的一切。狹義上，如采購領域、生產領域、銷售領域等。這里領域是采購領域，子領域是采購里的細分領域。
我們將上面的例子進行領域劃分后，分為需求領域、招投標領域和合同領域，如下：
2）問題域，是指產品能夠解決的所有問題的集合。架構設計是沒有時間對所有需求進行深入分析，也沒必要對所有的需求進行深入分析，只要抓住關鍵需求即可。
關鍵需求決定架構，將核心需求當前要解決的，以及未來要解決的問題歸集起來，作為問題域。
比如，上面的例子包括不限于以下問題：
- 怎么識別該需求需要招投標；
- 招投標需求是否需要策略；
- 招投標如何制定比價模板；
- 招投標如何進行比價；
- 招投標如何進行定標；
- 合同簽訂有多方嗎；
建立問題域是需要產品人具備一定的業務知識和結構化思維，可閱讀相關業務書籍，比如采購，財務書籍等，提問過程可基于實際業務操作流來積累每個環節可能會出現的問題。
3. 畫出業務閉環流程圖，并拆分出初步的解決方案域
通過前面的調研和領域劃分，基本上能夠確定業務場景現有的或將來的業務流程圖。業務流程圖的畫法，可參考相應的書籍或后續文章會單獨進行分享如何畫好業務流程圖。
基于業務流程圖和需求，我們需要抽象和歸納同類型事物，用更高層次來表達；比如，蘋果和梨子都是水果。
上述案例我們基本可以得出整個流程上的初步解決方案功能。
4. 明確產品定位，劃分好范圍
回到定位，不要走錯了路?？蓞⒖迹骸?a href="http://www.aharts.cn/operate/4757426.html" target="_blank" rel="noopener">戰略（4）：TO B產品定位，千萬不要忽略這兩層！》。
梳理完需求和業務流程以及初步的解決方案域，我們能夠評估那些是當前產品或待規劃產品的范圍，不是當前產品定位內的需求，要果斷的讓另一個產品承接；比如，審批流的需求，當前產品內只能是部門內審批，涉及到外部門的審批，審批流的功能必須放在企業OA系統完成。
5. 架構分層
清晰的產品架構圖至少包括這三層：
- 表現層：用戶接觸產品的途徑；產品展示給用戶的界面、風格；
- 應用層：產品的功能模塊劃分、數據流向、接口集成；
- 數據層：產品的數據存儲方式；
在進行產品架構分層時，我們可以采用自上而下的方法分別對展示層、業務邏輯層和數據層進行信息分類和排版。在信息分類時可以使用金字塔原理將每層核心信息盡量完全窮盡，相互獨立。
分層之前需注意以下幾項：
- 明確不同信息層級的邊界：架構的層級表達有一定的信息流轉邏輯，同一層級的上下信息流轉要一致
- 明確同一層級的子模塊邊界：同一層級不同模塊的邊界要清晰，模塊之間要做到可獨立開發和部署
- 明確產品邊界：產品邊界要清晰，明確區分不同產品的顏色
1）表現層
主要是用戶的接觸渠道，用戶通過這個登錄使用產品功能，獲取相應的服務，一般可分為PC端和APP端。
2）應用層
這個層將具體的功能進行分類組合成模塊單元，先將大的模塊填充，再將大模塊下的功能點填充。
模塊和功能的顆粒度如何界定？
- 模塊的劃分顆粒度可參照業務領域模型來劃分，比如招投標領域的業務功能點歸類到招投標模塊，合同領域的功能點歸類到合同模塊；
- 功能點劃分顆粒度可采用面向對象方法的實體顆粒度或者按完成某一項業務工作事項，比如，立項這個功能點，就是按采購員要完成發標前立項要做的工作任務來劃分。
顆粒度大小沒有明確標準，只要能表述一項工作任務即可。
另外，一些主數據，用戶，組織架構，消息組件，日志管理、接口服務等服務能力可單獨放在支撐層或者作為應用層的一些基礎數據也是可以。
3）數據層
這里主要是描述產品主要的數據存儲數據庫和存儲方式。比如，涉及到結構化數據一般存儲在Mysql，sql server等關系型數據庫；涉及到文件，可能一般存儲在對象存儲。
圖中的1、2、3對應的是表現層，應用層和數據層的功能和邏輯劃分，大家可以參考；這里就沒有把技術架構相關的內容放上來了，特別是涉及到中臺、微服務劃分，均沒有體現，比如，IAAS層，PASS層，SaaS層等。
5. 信息流轉和產品規劃
產品架構圖除了表達核心功能之外，還需將信息流轉的路徑標識清楚，比如圖中的標識4；
另外，我們需將產品功能的實現情況通過不同顏色標識出來，比如，綠色代表功能已上線，黃色代表功能需優化，灰色代表功能是規劃中。
如果你的產品是0到1，那么也可以標識出1.0版本做那些功能，2.0版本做那些功能，3.0版本做那些功能，有一個相對清晰的展示，這才是最終的產品架構圖。
如下圖：
最后，構建產品架構圖是產品經理一項必備的能力，To B的產品結構相對較為復雜，除了考慮產品本身功能場景外，還需考慮集成系統之間的數據交互和接口交互。
這里給大家分享了架構是什么，為什么要做產品架構，以及6步法構建一款B端產品架構圖，接下來我們就是要找機會去練習，去感悟。
知道的是知識，做到的是能力，能夠構建自己的體系才是大咖！
你認為好的產品架構圖是什么樣的？
作者：Robin；公眾號：PM雜貨鋪
本文由 @Robin 原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自 Unsplash，基于CC0協議
請問有推薦的書籍嗎？
終于看到個能把這個事兒說清楚的老師了，請問下有推薦的畫產品架構圖的軟件么？
可以使用億圖圖示
感謝
思路清晰