編輯導語：B端產品具有非常強的業務屬性，如果缺乏框架性思考，不僅單點設計功能將會讓你精疲力盡，還可能會導致比較嚴重的問題。本文作者基於以往的經驗，為我們梳理了符合業務的框架，希望能帶給大家一些幫助。
缺乏框架性思考可能導致比較嚴重的問題：
- 對內：不斷的堆砌功能，開發成本會越來越高。
- 對外：用户看到的信息繁雜，無法高效完成任務。
設計功能應前先釐清業務架構，以一種抽象的框架視角來全局思考。
一、業務架構業務架構是一套將功能依據業務進行分類，整合形成的抽象化的業務模型。業務架構可以幫你釐清每個業務模塊/功能間的邊界，以及它們之間的關係。
先梳理架構，可以理解業務模塊的邊界，面對多個類似的需求時就可以基於場景迅速定位對應的模塊；然後再設計功能，解決用户的需求。
架構有助於梳理一套標準化業務模型，搭建框架，讓後端標準化，前端個性化，最終為了高效滿足用户的不同需求。
我們要用發展的眼光看待架構，B端產品從大的層面分為四個階段：
- 基礎產品完善期：這個階段需要滿足核心場景的需求。這個階段要不斷增加功能、穩定系統、完善服務；
- 行業產品深入期：這一階段需要滿足重點行業的個性化需求，要有更深度的行業解決方案，更多的客户成功案例，更完善的客户服務體系；
- 生態建設期：這個階段要滿足大多數的個性化需求，要有個性化定製，開放平台和開放的服務生態；
- 再創新：讓產品邁向更高階段，探索新的賣點，挖掘用户的痛點，尋找市場的空白點。
業務架構也會隨着產品的成長而成長。
二、通用架構以B端SaaS軟件舉例子， SaaS不同的業務細分類型，存在一些通用的架構。
- 商品管理：讓商品有更好的賣相，同時高效管理商品；
- 訂單管理：瞭解商品的銷售情況，讓自己產生最大化創收；
- 客户管理：讓熟客產生更高的復購和推薦，同時高效管理他。
管理活動主要是幫助企業把人和事（項目）梳理清楚。分解一下管理就是：
基於不同的管理對象，管理活動架構存在較大的區別。人是管理活動的基石，所以管理活動主要講述人的管理。
三、梳理業務架構三步走- 將場景需求清單拆解到功能，每一個功能需明確解決一個具體的業務問題，如何將需求翻譯為功能，極其考驗對於業務的理解；
- 將功能按不同的維度進行分類整合，分類整合需要先考慮符合通用模塊的功能，切忌重複造輪子；功能對應的複雜程度越高、業務越重要，越值得被拿出來單獨做一個模塊；
- 梳理模塊之間的邏輯關係。
以HRM軟件舉例説明：
小盧是一個創業公司的HR，隨着公司不斷髮展，小盧也在不斷調整關注點：
1.第一階段：員工管理由於公司人數很少，小盧每天最頭疼的都是如何招聘到合適的人才，並且對員工信息進行初步的管理。
每天小盧花時間在各種渠道發佈招聘需求，跟人口頭約定工資，在招聘到人之後，簡單記錄一下員工的信息到花名冊並分配到對應的崗位，就能基本符合企業的管理訴求了。
員工管理模塊的主要業務：
隨着公司人數不斷變多，漸漸地，管理成了難題，老闆讓小盧想辦法用制度約束。
於是小盧開始潛心研究考勤制度，並制定了一些複雜的考勤規則並執行下去，當員工考勤不符合規定時，就會扣工資，這也讓老闆感到滿意。
考勤管理模塊的主要任務：
公司在持續發展壯大，小盧發現，負向激勵無法讓真正的人才留下，於是小盧開始設計一個更高效的薪酬體系，希望能夠用正向激勵的方式讓員工更好地為公司創造價值，當員工為公司創造的價值越多，自然也會得到更多收入。
薪酬管理模塊的主要任務：
員工管理模塊基於考勤制度與薪酬制度產生活動數據，並最終通過工資反饋。這也是HRM軟件的核心。
通過上述業務可以梳理對應的功能，先按照通用架構梳理。
通過分析，招聘業務相對複雜，同時價值比較高，可以考慮單獨抽離出來。
申請審批比較通用，適合各個模塊，為了避免各個模塊重複造輪子，該模塊也可以抽離出來。最終可以改成如下架構。
我們在做「完美工事」這款HRM產品時，從一開始就制定架構並雖然產品迭代而完善。
如上圖，藉助 Xmind 思維導圖工具可以標識每個模塊完成進度，添加優先級標籤，更方便產品跟進業務模塊，面對新的需求時也方便進行框架性思考。
一點經驗分享給大家，歡迎關注交流。
作者：老於；公眾號：老於的筆記
本文由 @老於 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自 Unsplash，基於CC0協議