SaaS 平臺產品架構設計
當我們去搜索 “架構”，可以得到很多的架構圖片，比如組織架構、業務架構、數據架構、技術架構、安全架構、產品架構、部署架構等。
什麼是架構，通常大家說架構一般指軟件架構，架構是指軟件的基礎結構，創造這些基礎結構的準則，以及對這些結構的描述。在這個定義基礎上，我們可以簡單理解爲架構往往是對事物主體的結構性描述。
產品架構是對產品的一種結構性描述。一般可以包括前端系統、業務管理、運營管理、基礎支撐等子產品或子系統，並描述各個子產品或子系統之間的關聯關係。
在公司整體戰略之下，需要基於公司戰略等多種因素設計組織架構，組織架構影響業務架構，業務架構影響產品架構，產品架構影響技術架構。
從這個鏈條可以看出產品架構基於業務架構。做產品架構前，需要對業務架構有清晰的瞭解。
一、業務架構對產品設計的 5 個影響
業務架構是基於組織架構設計的，業務架構是把企業的業務戰略轉化爲日常運作的渠道，業務戰略決定業務架構，它包括業務的運營模式、流程體系、組織體系、資源分佈等內容。
業務架構是一個比較專業的研究課題，技術人員一般對業務架構的關注度相對較低，更重視產品架構、技術架構。這裏我們簡單示例什麼是業務架構，這些架構事實上影響我們的產品架構設計，如下圖 5-1 就是其中一個業務架構設計的框架圖。
業務架構圖
業務架構對企業的收入模式、支出成本、客戶羣體、客戶關係、需要的資源、關鍵活動，以及合作伙伴等進行設計說明。
業務架構對產品架構的影響，主要體現在以下幾個方面：
- 系統參與角色
業務架構一般會明確用戶範圍；營銷端的參與人員，比如渠道商或代理商，大客戶銷售團隊等；運營端的參與人員，如售後、客戶成功等團隊；合作伙伴的參與，如第三方合作平臺等。每類角色按需設計對應的使用終端。
- 系統運營流程
業務架構對運營流程有較明確的定義，如開戶、續費、註銷、變更、售前售後工單處理、庫存入庫出庫處理、合同流程、發票流程等。這些構成 SaaS 平臺的運營流程，是產品實現商業價值的重要手段，產品環節一般需要有相應的處理。
- 核心價值
業務架構需要明確 SaaS 服務對客戶帶來的價值，這個價值往往需要通過產品端來呈現，業務架構的價值描述，很大程度上就是我們產品建設的側重點。
- 周邊系統
業務架構中的合作伙伴、資源一定程度上體現出需要與產品交互的其他系統，這些 “其他系統” 可能是產品需要的一些基礎能力（如文字識別、計算能力等）、數據（權限數據、業務數據）、流程（管理流程、運營流程）等 ，而這些能力需要合夥夥伴或者公司的現有資源中提供。這些周邊系統會以各種各樣的作用支撐着產品的運轉。
- 計費模式
業務架構一般會說明收入和成本模型。收入的處理過程影響運營產品的設計，如公司在線下收款，可以產品只需要控制用戶賬號的可用狀態或有效期，如果是線上收款，就需要設計一套開通、續費的線上支付流程。有些 SaaS 產品還會涉及到收入和成本費用的攤銷，以配合財務工作的處理，也可能需要在產品中完成此類計算。
假如所在公司沒有清晰的業務架構，或者部分環節缺失怎麼辦？如果可以引導，我們儘量引導業務部門完善相關的環節，但有些客觀情況是我們無法改變的，我們可以嘗試按照現有架構，收集梳理信息，做好整體的結構設計，確保具備可擴充能力，能夠滿足後續需求，再根據業務各環節成熟度設計產品架構，分階段去實現。
二、產品架構
SaaS 產品架構的設計，可以考慮模塊化、漸進式設計。
- 模塊化設計
所謂模塊化是指降低業務間的耦合。低耦合、高內聚是技術架構的重要設計原則，在產品端也非常值得借鑑。
模塊式化設計對於系統建模、技術實現、升級迭代、業務推廣都有很多幫助。模塊化設計也是對最小化場景（MVP）的一種有效支撐。
SaaS 產品隨着公司的發展，業務範圍、功能都會越來越大，而客戶可能僅需要部分能力，如果功能間耦合太多，對客戶的功能選擇會增加限制；銷售政策制定起也會受到掣肘，無法靈活組合產品進行銷售，對業務推廣產生一定影響。
如何做好模塊化設計？
模塊化設計針對有獨立性、可複用的業務或功能進行抽取，包裝功能集合構成產品進行推廣使用，方便客戶根據需要進行產品組合，模塊化設計在傳統軟件中也非常重要。
（1）歸類與抽象
需要對相似的功能或者場景進行歸類然後抽象出來進行設計。在軟件設計領域，越是底層的東西越容易複用，越是偏向應用端的東西，越難以複用。比如構成一套軟件服務，可以有服務器硬件、應用服務中間件（比如數據庫等）、各種微服務、業務流程、外部入口等，這套軟件架構中，服務器硬件是處於架構底層，比較基礎且通用性很強；應用入口處於架構高層級，形式相對靈活，複用性較低。在產品端也是同理，基礎信息如人員、機構等屬於基礎信息，同一組織在不同系統中的結構大體一樣，複用性強，其次是各類業務流程，再其次是業務表單。
我們要做的產品模塊化設計，是針對不同用戶的需求，將完成某項業務的場景進行分析、歸類、抽象，抽取共性部分，做成可實現多種組合的產品形態。
（2）數據接口
系統一般由邏輯（算法）和信息兩部分構成，信息又分爲內容和數據；邏輯是構建軟件功能的骨架，內容和數據是血肉，其中以數據尤爲重要。
假如要實現軟件模塊化且模塊之間相互獨立，必須要先拋棄邏輯（實現方法），因爲有邏輯就代表這兩個模塊誰也離不開誰，就不能稱之爲獨立。
如果這兩個模塊必須要關聯在一起，但又不允許它們在邏輯上互相干涉，那麼最好的辦法就是爲它們內部包含的數據進行抽象化，形成標準化接口，以數據調用的形式實現兩個模塊間的互相協作。
模塊化的一個特徵是複用，在產品設計上覆用意味着需要多種場景的結合，如果只有一個場景，就不是複用，在多個場景都需要使用的情況下，會有數據交互的需要，模塊化設計就是要把共性的東西抽取出來後，提供標準接口，進行數據交互，這個共性的東西，可以是字段，也可以是規則。
大家通常理解的 SDK，也是模塊化設計的一種體現。模塊化的產品可以是一個界面、也可以是一個功能，還可以是一個子系統。
- 漸進式設計
SaaS 產品是逐步迭代的，產品設計也不是一蹴而就的，需要有一個不斷前進的過程，漸進式設計非常契合 SaaS 產品。比如我們公司的產品，有企業客戶、集團客戶、代理商、平臺運營人員、售後人員等參與，在設計系統的過程中，並不是一上來就把所有的工作全部做完， 這樣週期太長，也不利於快速驗證產品和市場的匹配，所以產品架構自然而然也變成了一種漸進的設計過程。
漸進式設計需要儘量考慮未來產品的全局，以滿足後續產品擴展需要。
以我曾經做過的一個產品舉例，產品的用戶可以分爲三大類，關係如下圖：
產品關係示例
在產品架構的搭建過程中，我們在清楚有這些基礎結構以後，按照優先級順序，逐步發展產品。如圖：
產品架構示例圖
首先搭建了企業版產品和簡單的運營管理系統，讓用戶能夠使用起來。後來隨着代理商力量的不斷計入，需要爲代理商設計一套管理系統，代理商系統需要依賴於公司運營管理系統（公司運營早期就已經有了代理商加入，運營管理平臺只有最簡單的代理商管理功能，能夠標記客戶所屬代理商，但並沒有去開發一套代理商管理系統，只是預留了擴展能力）。
隨着平臺的發展，用戶羣體不斷擴大，集團客戶也在不斷增加，公司又基於企業版產品開發了集團版產品，滿足集團企業客戶的需要。
整個代理商管理系統和公司運營管理系統也跟隨迭代，從最初的企業註冊審覈，到用戶工單管理、結算續費管理、再到增加集團版的開通管理流程及結算流程，歷時用了幾年時間。產品整體架構經歷了多個版本的迭代，才逐步變成現在的體系，並且還在持續完善中。
產品架構的漸進式設計和最小化可用產品（MVP）並不是一回事，產品架構漸進式設計是爲了產品穩步推進並可擴展，先集中精力解決當前的重要需求和問題，所積累的產品成果，會成爲將來產品發展的基礎，而不是 MVP 中表示的每一個過程都可能要重構。
MVP 有一個非常生動的例子，用戶需求是一輛車，那麼車的 MVP 及產品演進過程應該如下圖 5-5 的第二部分所示：
MVP 的演進
產品架構的漸進式設計和產品的 MVP 有什麼關係，其實是兩個維度的事情，產品架構漸進式設計是對現在業務的快速響應，以及對未來業務擴張的支撐。
MVP 是在產品迭代過程中，在不同的階段，可能需要進行重構，上圖的例子，在一些產品論壇上都有闡述，這對 MVP 的解釋是很準確的，最小化可行產品需要做到每次迭代都是完整可用的，可用場景閉環是 MVP 的核心指標，這是產品從 0 到 1 的一種有效驗證方式，但我認爲這種重構並不一定是必須的.
很多軟件產品在迭代的過程中，都是在原有基礎上的擴展，實際上產品架構具備彈性和擴展性，這是一名優秀產品經理需要具備的能力，畢竟任何歷史投入都是有成本的，優秀的設計應該是在原有基礎上的擴展，而不是推倒重來。
B 端產品在發展過程中，也比較注重產品和服務的結合，這個服務並不是指產品即服務，而是在早期產品不夠完善的情況下，部分環節通過線下服務來補充，這也是 SaaS 產品發展的一種形式。
產品架構大體能夠說清楚了系統間的關係，但對於具體的產品流程，產品架構圖是無法表達清楚的，還需要輔助系統流程圖進行說明。
出處：
https://mbd.baidu.com/newspage/data/landingsuper?pageType=1&context=%7B%22nid%22%3A%22news_9715390798765381787%22,%22ssid%22%3A%22d45aad39%22%7D
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Xv2sa9_UvmBmupH4SN7M4A