如果給你做一個SaaS產(chǎn)品，如何從產(chǎn)品架構(gòu)層面去設(shè)計？

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

圖1 what

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

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

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

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

圖3 用戶前臺和用戶后臺

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

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

圖4 三種方法

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

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

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

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

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

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

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

現(xiàn)在想想，真的是太年輕啊，一點產(chǎn)品思維都沒有體現(xiàn)，一丟丟的邏輯性都沒有。

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

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

那么什么是架構(gòu)呢？百度詞條顯示：

架構(gòu)，又名軟件架構(gòu)。軟件架構(gòu)（software architecture）是一系列相關(guān)的抽象模式，用于指導(dǎo)大型軟件系統(tǒng)各個方面的設(shè)計。軟件架構(gòu)是一個系統(tǒng)的草圖，軟件架構(gòu)描述的對象是直接構(gòu)成系統(tǒng)的抽象組件，各個組件之間的連接則明確和相對細(xì)致地描述組件之間的通訊。在實現(xiàn)階段，這些抽象組件被細(xì)化為實際的組件，比如具體某個類或者對象。在面向?qū)ο箢I(lǐng)域中，組件之間的連接通常用接口(計算機(jī)科學(xué))來實現(xiàn)。

翻譯成一個詞就是高屋建瓴，大白話就是從整體上，將軟件高度抽象成組件，通過架構(gòu)圖直觀的去表達(dá)所規(guī)劃軟件的各個組件以及各個組件之間的關(guān)系，并傳達(dá)軟件的業(yè)務(wù)流程、數(shù)據(jù)流轉(zhuǎn)。在老王看來，從商業(yè)的角度來說，制定一個商業(yè)模式也算是一次架構(gòu)，從企業(yè)角度來說，部門的設(shè)立與調(diào)整也是一次架構(gòu)。

看一下老王虛構(gòu)的一個架構(gòu)圖，想來你能有一個較為清楚的認(rèn)知了。

圖7 三層架構(gòu)圖

那么產(chǎn)品架構(gòu)是什么呢？

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

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

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

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

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

以上其實就是一種產(chǎn)品架構(gòu)，這是從功能模塊來劃分的，當(dāng)業(yè)務(wù)進(jìn)一步做大的時候，技術(shù)得到了一定的發(fā)展，就需要從產(chǎn)品、服務(wù)和技術(shù)層面去規(guī)劃產(chǎn)品架構(gòu)，這個就類似于編程中的MVC框架，對應(yīng)的產(chǎn)品表現(xiàn)層、服務(wù)邏輯層、數(shù)據(jù)服務(wù)層。（這里大家的叫法和用法都有所區(qū)別，不過都是對應(yīng)MVC中的model-view-controller這種結(jié)構(gòu)）

至于劃分依據(jù)，有幾個方面：

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

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

建議你可以試著做一個產(chǎn)品架構(gòu)，不一定從無到有，也不一定要面面俱到，只要將現(xiàn)有的產(chǎn)品或者模塊遵照MVC的三層關(guān)系，去抽象并且清晰的表達(dá)你所做的產(chǎn)品與其他產(chǎn)品或模塊的對應(yīng)關(guān)系和一來關(guān)系，就可以了。

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

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

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

本文由 @老王指南 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash，基于CC0協(xié)議