如果給你做一個SaaS產品，如何從產品架構層面去設計？

老王前段時間去面試了一家做SaaS產品的公司，雖然后來沒什么消息，但是面試過程中面試官問的一個問題讓老王印象深刻，回來之后在網上也查了不少相關的內容，今天想試著總結并重新回答一下這個問題——“如果給你做一個SaaS產品，如何從產品架構層面去設計？”

圖1 what

當老王聽到這個問題的時候，腹誹了一下，確定這個問題的每個字我都認識，每個詞組單獨拉出來我也能清晰的理解，但是組合起來就有點費解了。所以老王委婉的說道：“不好意思，能再解釋一下嗎？”

面試官可能看出了我的疑惑，不知道要回答些什么，然后說，“就是讓你負責做一個SaaS你都會做些什么，比如有哪些模塊？”這么一說，老王就懂了，這里要注意，參加面試的朋友遇到開放式命題的時候，第一點要表述的一定是設定場景。

這里有兩個好處：第一是盡可能設定自己熟悉的場景，避免犯錯；第二是面試官如果覺得這個場景過于簡單，會給出他想要的場景，這樣就能更加清楚的了解面試官希望你回答的范疇在哪。

老王設定的場景是比如說我們做的是一個電商場景的SaaS，這個產品類似于有贊，那么經過了一系列需求收集分析后，針對電商場景，簡單的劃分為前臺用戶端，后臺商家端。（做電商的朋友不要噴我哈，我知道并不是這么簡單的兩個，里面涉及的非常多，包括倉儲、物流、支付、分單等等，但是面試嘛，說多錯多。）

圖3 用戶前臺和用戶后臺

用戶端的核心業務流程就是瀏覽商品>下單>支付>發貨>收貨>評價>訂單完成，商家端的核心業務流程有幾個，分別是用戶管理、商品管理、供應商管理、營銷活動、訂單、支付、快遞、財務、數據報表等等。

好嘛，面試官聽完之后又問道：“那你是依據什么構建的這個產品框架的呢？或者說基于什么原因這么劃分模塊？”，老王心想說憑借的是我多年的購物經驗啊，回歸到現實工作中，如何劃分這些模塊的依據或者來源大致可以分為：競品分析；需求分析；流程梳理。

圖4 三種方法

通過競品分析，我們能知道在一般情況下別人是怎么做的，我們不能說他都是對的，但是必定有其道理，如果只是去看別人有什么你就要有，那這是不可理喻的，要分析他為什么要這么做，找到一個根本原因或者依據，而不是一句“存在即合理”就解釋了。

在產品的實際工作中，很多產品經理要做的產品都已經珠玉在前了，重新制造一個輪子并不能說它一定是毫無意義，但是絕大多數企業確實是毫無意義甚至還不如前者。美其名曰借鑒，其實就是抄。當然抄也不是全都照搬，也會根據實際的業務情況、資源配置等等因素去權衡，優化或刪減，從而達到既符合企業定位、滿足市場需求的同時，又能為產品節省資源。

需求分析，這也是我們常說的，但是在需求分析的過程中我們可以做很多，其中用戶訪談，是我認為做SaaS或者做定制化產品很常見的。

比如在做財務系統時，與財務總監、會計、出納溝通，甚至還需要與CFO、法務溝通，在了解財務的工作內容的時候，就可以通過他們的一些工作習慣和認知，去定義或劃分功能模塊。這也與尼爾森的“一致性原則”中與用戶預期保持一致性相同，甚至也可以說這是與現實映照。

流程梳理，其實這也是需求分析中的一個必然步驟，之所以拉出來說，是因為在做SaaS的時候，有些業務的模式的創新性導致沒有一般等價物作為參照，我們需要根據實際商業模式去設計適合他的業務流程和規范，并且為之提供切實有效的系統作為商業開展的保障。在梳理整個業務流程的時候，有哪些場景、哪些角色、哪些流程對應的都需要什么，抽象出來，一目了然。

比如審核，一般SaaS產品都會有工作臺，有審核模塊，將用戶可見、參與的審核信息聚合統一處理，并且大一些的SaaS組合產品會將流程引擎與審核中心獨立成SaaS產品給各業務引用，這都是在流程梳理時，通過抽象聚合出來的。

當然，上述并不是我在面試的時候所敘述的，都是后來我回來琢磨的時候想到的，當時我說了一個非常糟糕，乃至于面試官都忍不住笑了，我說：“這都是順其自然的啊，通過需求分析挖掘出所需要的內容，自然而然就劃分了?！?/p>

現在想想，真的是太年輕啊，一點產品思維都沒有體現，一丟丟的邏輯性都沒有。

當然，我上面說的全是一家之言，完全是廢話，也是后話。讓我再次重申這個問題：“如果給你做一個SaaS產品，如何從產品架構層面去設計？”這里面有兩個名詞：SaaS產品，產品架構。不知道SaaS產品為何物的，請出門百度，或者以后老王再單獨總結歸納一下。

這個“產品架構”讓我費解了好一陣，并且網上查了好一陣也沒有得到一個清晰的界定，什么是產品架構？所以我們把這個詞拆分一下“產品”和“架構”。一般提到架構，相信你一定聽說過架構師，老王也有幸認識一位架構師，雖然接觸的時間不長。

那么什么是架構呢？百度詞條顯示：

架構，又名軟件架構。軟件架構（software architecture）是一系列相關的抽象模式，用于指導大型軟件系統各個方面的設計。軟件架構是一個系統的草圖，軟件架構描述的對象是直接構成系統的抽象組件，各個組件之間的連接則明確和相對細致地描述組件之間的通訊。在實現階段，這些抽象組件被細化為實際的組件，比如具體某個類或者對象。在面向對象領域中，組件之間的連接通常用接口(計算機科學)來實現。

翻譯成一個詞就是高屋建瓴，大白話就是從整體上，將軟件高度抽象成組件，通過架構圖直觀的去表達所規劃軟件的各個組件以及各個組件之間的關系，并傳達軟件的業務流程、數據流轉。在老王看來，從商業的角度來說，制定一個商業模式也算是一次架構，從企業角度來說，部門的設立與調整也是一次架構。

看一下老王虛構的一個架構圖，想來你能有一個較為清楚的認知了。

圖7 三層架構圖

那么產品架構是什么呢？

這里我們只討論互聯網以及軟件產品經理的思考，斯以為，從整體上規劃產品，將具象化的產品功能或業務高度抽象并清晰的表達，從產品設計上高度契合軟件架構所要達到的效果。軟件架構的非功能性特征包括：可靠性；易用性；可擴展性；強壯性；靈活性；性能等等。那么，在做產品規劃與設計時，也必須時刻關注這些非功能性特征。

在我們了解了這些之后，再來看這道題就變成了：從整體上規劃、設計一個SaaS產品，將具象化的產品功能或業務高度抽象并清晰的表達。雖然分析到這個地步了，但是貌似也沒有拿出一個實際有效的答案，屬實有點尷尬。在老王看來，這個時候畫一個產品架構圖來就最好了，但是面試嘛，更多的是口頭表述，那老王就拋磚引玉一下吧。

尊敬的XXX公司面試官您好，針對這個問題，我想首先擬定一個場景，我們假定要做一個電商SaaS產品，那么作為SaaS產品，一般是要具有一些行業通用性，假設我們已經做過了用戶調研、競品分析、需求分析，得出了以下幾個需求：1.用戶購買商品；2.商家管理商品并且需要給用戶發貨；3.用戶收到貨物會評價等等。

那么，在經過上述分析之后，我們可以得到一些內容：這個產品至少有三個角色，用戶，商戶，公司，也就至少有三個終端，我們分為用戶前臺、商戶后臺、公司運營平臺。那么前臺都需要些什么呢，需要商品展示、支付、訂單查詢、評價，甚至是商品的分類和搜索，未來可能還有會員體系等等。

商戶后臺，根據需求，需要用戶管理、商品管理、訂單管理、評價管理、供應商管理，未來還會有營銷、財務、數據、倉儲、物流等等等等，這些模塊或者系統來支撐商戶后臺。公司運營平臺也會有客戶管理、訂單管理、財務管理等等一系列模塊或系統。

以上其實就是一種產品架構，這是從功能模塊來劃分的，當業務進一步做大的時候，技術得到了一定的發展，就需要從產品、服務和技術層面去規劃產品架構，這個就類似于編程中的MVC框架，對應的產品表現層、服務邏輯層、數據服務層。（這里大家的叫法和用法都有所區別，不過都是對應MVC中的model-view-controller這種結構）

至于劃分依據，有幾個方面：

1. 競品分析，根據該領域頭部玩家的經驗，在其基礎上去優化沉淀自有品牌的優勢；
2. 需求分析，在于客戶或行業資深專家的溝通中，不難發現一些行業規律，依照行業規律劃分也是符合用戶行為習慣的；
3. 流程梳理，在梳理的過程中根據流程的必要性，以降低耦合為目的去劃分和提煉必要的模塊和功能。

相信大部分產品經理其實很少正經做產品架構，日常的工作更多的是接到需求，分析需求，然后設計產品。但殊不知又時刻與產品架構保持聯系，因為你的每一次新增、改動都會影響整個產品的架構。

建議你可以試著做一個產品架構，不一定從無到有，也不一定要面面俱到，只要將現有的產品或者模塊遵照MVC的三層關系，去抽象并且清晰的表達你所做的產品與其他產品或模塊的對應關系和一來關系，就可以了。

老王在一份短暫的工作經驗有幸接觸了產品架構，其目的是要求產品經理必須清楚自己所做的產品在事業部所有產品的架構中所處的位置，以及與各個產品的依賴關系、數據流轉。產品架構圖不僅僅是這些作用，對于產品經理來說，還可以讓你從宏觀的視角看清楚模塊與模塊之間、產品與產品之間、系統與系統之間的關系，更可以讓你的領導以及運營和市場的同事清晰的知道你的產品規劃。

綜上就是老王因為這個面試問題而去了解的產品架構的相關內容，寫這篇文章的主要目的是為了自省，如果對你有所幫助，那是在是意外之喜。

作者：老王，一個不愿意透露體重的90后產品經理，公眾號“老王修煉指南”唯一作者。

本文由 @老王指南 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash，基于CC0協議