當(dāng)我們?nèi)ニ阉鳌凹軜?gòu)”，可以得到很多的架構(gòu)圖片，比如組織架構(gòu)、業(yè)務(wù)架構(gòu)、數(shù)據(jù)架構(gòu)、技術(shù)架構(gòu)、安全架構(gòu)、產(chǎn)品架構(gòu)、部署架構(gòu)等。

什么是架構(gòu)，通常大家說(shuō)架構(gòu)一般指軟件架構(gòu)，架構(gòu)是指軟件的基礎(chǔ)結(jié)構(gòu)，創(chuàng)造這些基礎(chǔ)結(jié)構(gòu)的準(zhǔn)則，以及對(duì)這些結(jié)構(gòu)的描述。在這個(gè)定義基礎(chǔ)上，我們可以簡(jiǎn)單理解為架構(gòu)往往是對(duì)事物主體的結(jié)構(gòu)性描述。

產(chǎn)品架構(gòu)是對(duì)產(chǎn)品的一種結(jié)構(gòu)性描述。一般可以包括前端系統(tǒng)、業(yè)務(wù)管理、運(yùn)營(yíng)管理、基礎(chǔ)支撐等子產(chǎn)品或子系統(tǒng)，并描述各個(gè)子產(chǎn)品或子系統(tǒng)之間的關(guān)聯(lián)關(guān)系。

在公司整體戰(zhàn)略之下，需要基于公司戰(zhàn)略等多種因素設(shè)計(jì)組織架構(gòu)，組織架構(gòu)影響業(yè)務(wù)架構(gòu)，業(yè)務(wù)架構(gòu)影響產(chǎn)品架構(gòu)，產(chǎn)品架構(gòu)影響技術(shù)架構(gòu)。

從這個(gè)鏈條可以看出產(chǎn)品架構(gòu)基于業(yè)務(wù)架構(gòu)。做產(chǎn)品架構(gòu)前，需要對(duì)業(yè)務(wù)架構(gòu)有清晰的了解。

一、業(yè)務(wù)架構(gòu)對(duì)產(chǎn)品設(shè)計(jì)的5個(gè)影響

業(yè)務(wù)架構(gòu)是基于組織架構(gòu)設(shè)計(jì)的，業(yè)務(wù)架構(gòu)是把企業(yè)的業(yè)務(wù)戰(zhàn)略轉(zhuǎn)化為日常運(yùn)作的渠道，業(yè)務(wù)戰(zhàn)略決定業(yè)務(wù)架構(gòu)，它包括業(yè)務(wù)的運(yùn)營(yíng)模式、流程體系、組織體系、資源分布等內(nèi)容。

業(yè)務(wù)架構(gòu)是一個(gè)比較專業(yè)的研究課題，技術(shù)人員一般對(duì)業(yè)務(wù)架構(gòu)的關(guān)注度相對(duì)較低，更重視產(chǎn)品架構(gòu)、技術(shù)架構(gòu)。這里我們簡(jiǎn)單示例什么是業(yè)務(wù)架構(gòu)，這些架構(gòu)事實(shí)上影響我們的產(chǎn)品架構(gòu)設(shè)計(jì)，如下圖5-1就是其中一個(gè)業(yè)務(wù)架構(gòu)設(shè)計(jì)的框架圖。

業(yè)務(wù)架構(gòu)圖

業(yè)務(wù)架構(gòu)對(duì)企業(yè)的收入模式、支出成本、客戶群體、客戶關(guān)系、需要的資源、關(guān)鍵活動(dòng)，以及合作伙伴等進(jìn)行設(shè)計(jì)說(shuō)明。

業(yè)務(wù)架構(gòu)對(duì)產(chǎn)品架構(gòu)的影響，主要體現(xiàn)在以下幾個(gè)方面：

1. 系統(tǒng)參與角色

業(yè)務(wù)架構(gòu)一般會(huì)明確用戶范圍;營(yíng)銷端的參與人員，比如渠道商或代理商，大客戶銷售團(tuán)隊(duì)等;運(yùn)營(yíng)端的參與人員，如售后、客戶成功等團(tuán)隊(duì);合作伙伴的參與，如第三方合作平臺(tái)等。每類角色按需設(shè)計(jì)對(duì)應(yīng)的使用終端。

2. 系統(tǒng)運(yùn)營(yíng)流程

業(yè)務(wù)架構(gòu)對(duì)運(yùn)營(yíng)流程有較明確的定義，如開(kāi)戶、續(xù)費(fèi)、注銷、變更、售前售后工單處理、庫(kù)存入庫(kù)出庫(kù)處理、合同流程、發(fā)票流程等。這些構(gòu)成SaaS平臺(tái)的運(yùn)營(yíng)流程，是產(chǎn)品實(shí)現(xiàn)商業(yè)價(jià)值的重要手段，產(chǎn)品環(huán)節(jié)一般需要有相應(yīng)的處理。

3. 核心價(jià)值

業(yè)務(wù)架構(gòu)需要明確SaaS服務(wù)對(duì)客戶帶來(lái)的價(jià)值，這個(gè)價(jià)值往往需要通過(guò)產(chǎn)品端來(lái)呈現(xiàn)，業(yè)務(wù)架構(gòu)的價(jià)值描述，很大程度上就是我們產(chǎn)品建設(shè)的側(cè)重點(diǎn)。

4. 周邊系統(tǒng)

業(yè)務(wù)架構(gòu)中的合作伙伴、資源一定程度上體現(xiàn)出需要與產(chǎn)品交互的其他系統(tǒng)，這些“其他系統(tǒng)”可能是產(chǎn)品需要的一些基礎(chǔ)能力(如文字識(shí)別、計(jì)算能力等)、數(shù)據(jù)(權(quán)限數(shù)據(jù)、業(yè)務(wù)數(shù)據(jù))、流程(管理流程、運(yùn)營(yíng)流程)等 ，而這些能力需要合伙伙伴或者公司的現(xiàn)有資源中提供。這些周邊系統(tǒng)會(huì)以各種各樣的作用支撐著產(chǎn)品的運(yùn)轉(zhuǎn)。

5. 計(jì)費(fèi)模式

業(yè)務(wù)架構(gòu)一般會(huì)說(shuō)明收入和成本模型。收入的處理過(guò)程影響運(yùn)營(yíng)產(chǎn)品的設(shè)計(jì)，如公司在線下收款，可以產(chǎn)品只需要控制用戶賬號(hào)的可用狀態(tài)或有效期，如果是線上收款，就需要設(shè)計(jì)一套開(kāi)通、續(xù)費(fèi)的線上支付流程。有些SaaS產(chǎn)品還會(huì)涉及到收入和成本費(fèi)用的攤銷，以配合財(cái)務(wù)工作的處理，也可能需要在產(chǎn)品中完成此類計(jì)算。

假如所在公司沒(méi)有清晰的業(yè)務(wù)架構(gòu)，或者部分環(huán)節(jié)缺失怎么辦?如果可以引導(dǎo)，我們盡量引導(dǎo)業(yè)務(wù)部門完善相關(guān)的環(huán)節(jié)，但有些客觀情況是我們無(wú)法改變的，我們可以嘗試按照現(xiàn)有架構(gòu)，收集梳理信息，做好整體的結(jié)構(gòu)設(shè)計(jì)，確保具備可擴(kuò)充能力，能夠滿足后續(xù)需求，再根據(jù)業(yè)務(wù)各環(huán)節(jié)成熟度設(shè)計(jì)產(chǎn)品架構(gòu)，分階段去實(shí)現(xiàn)。

二、產(chǎn)品架構(gòu)

SaaS產(chǎn)品架構(gòu)的設(shè)計(jì)，可以考慮模塊化、漸進(jìn)式設(shè)計(jì)。

2.1 模塊化設(shè)計(jì)

所謂模塊化是指降低業(yè)務(wù)間的耦合。低耦合、高內(nèi)聚是技術(shù)架構(gòu)的重要設(shè)計(jì)原則，在產(chǎn)品端也非常值得借鑒。

模塊式化設(shè)計(jì)對(duì)于系統(tǒng)建模、技術(shù)實(shí)現(xiàn)、升級(jí)迭代、業(yè)務(wù)推廣都有很多幫助。模塊化設(shè)計(jì)也是對(duì)最小化場(chǎng)景(MVP)的一種有效支撐。

SaaS產(chǎn)品隨著公司的發(fā)展，業(yè)務(wù)范圍、功能都會(huì)越來(lái)越大，而客戶可能僅需要部分能力，如果功能間耦合太多，對(duì)客戶的功能選擇會(huì)增加限制;銷售政策制定起也會(huì)受到掣肘，無(wú)法靈活組合產(chǎn)品進(jìn)行銷售，對(duì)業(yè)務(wù)推廣產(chǎn)生一定影響。

如何做好模塊化設(shè)計(jì)?

模塊化設(shè)計(jì)針對(duì)有獨(dú)立性、可復(fù)用的業(yè)務(wù)或功能進(jìn)行抽取，包裝功能集合構(gòu)成產(chǎn)品進(jìn)行推廣使用，方便客戶根據(jù)需要進(jìn)行產(chǎn)品組合，模塊化設(shè)計(jì)在傳統(tǒng)軟件中也非常重要。

(1)歸類與抽象

需要對(duì)相似的功能或者場(chǎng)景進(jìn)行歸類然后抽象出來(lái)進(jìn)行設(shè)計(jì)。在軟件設(shè)計(jì)領(lǐng)域，越是底層的東西越容易復(fù)用，越是偏向應(yīng)用端的東西，越難以復(fù)用。比如構(gòu)成一套軟件服務(wù)，可以有服務(wù)器硬件、應(yīng)用服務(wù)中間件(比如數(shù)據(jù)庫(kù)等)、各種微服務(wù)、業(yè)務(wù)流程、外部入口等，這套軟件架構(gòu)中，服務(wù)器硬件是處于架構(gòu)底層，比較基礎(chǔ)且通用性很強(qiáng);應(yīng)用入口處于架構(gòu)高層級(jí)，形式相對(duì)靈活，復(fù)用性較低。在產(chǎn)品端也是同理，基礎(chǔ)信息如人員、機(jī)構(gòu)等屬于基礎(chǔ)信息，同一組織在不同系統(tǒng)中的結(jié)構(gòu)大體一樣，復(fù)用性強(qiáng)，其次是各類業(yè)務(wù)流程，再其次是業(yè)務(wù)表單。

我們要做的產(chǎn)品模塊化設(shè)計(jì)，是針對(duì)不同用戶的需求，將完成某項(xiàng)業(yè)務(wù)的場(chǎng)景進(jìn)行分析、歸類、抽象，抽取共性部分，做成可實(shí)現(xiàn)多種組合的產(chǎn)品形態(tài)。

(2)數(shù)據(jù)接口

系統(tǒng)一般由邏輯(算法)和信息兩部分構(gòu)成，信息又分為內(nèi)容和數(shù)據(jù);邏輯是構(gòu)建軟件功能的骨架，內(nèi)容和數(shù)據(jù)是血肉，其中以數(shù)據(jù)尤為重要。

假如要實(shí)現(xiàn)軟件模塊化且模塊之間相互獨(dú)立，必須要先拋棄邏輯(實(shí)現(xiàn)方法)，因?yàn)橛羞壿嬀痛磉@兩個(gè)模塊誰(shuí)也離不開(kāi)誰(shuí)，就不能稱之為獨(dú)立。

如果這兩個(gè)模塊必須要關(guān)聯(lián)在一起，但又不允許它們?cè)谶壿嬌匣ハ喔缮?，那么最好的辦法就是為它們內(nèi)部包含的數(shù)據(jù)進(jìn)行抽象化，形成標(biāo)準(zhǔn)化接口，以數(shù)據(jù)調(diào)用的形式實(shí)現(xiàn)兩個(gè)模塊間的互相協(xié)作。

模塊化的一個(gè)特征是復(fù)用，在產(chǎn)品設(shè)計(jì)上復(fù)用意味著需要多種場(chǎng)景的結(jié)合，如果只有一個(gè)場(chǎng)景，就不是復(fù)用，在多個(gè)場(chǎng)景都需要使用的情況下，會(huì)有數(shù)據(jù)交互的需要，模塊化設(shè)計(jì)就是要把共性的東西抽取出來(lái)后，提供標(biāo)準(zhǔn)接口，進(jìn)行數(shù)據(jù)交互，這個(gè)共性的東西，可以是字段，也可以是規(guī)則。

大家通常理解的SDK，也是模塊化設(shè)計(jì)的一種體現(xiàn)。模塊化的產(chǎn)品可以是一個(gè)界面、也可以是一個(gè)功能，還可以是一個(gè)子系統(tǒng)。

2.2 漸進(jìn)式設(shè)計(jì)

SaaS產(chǎn)品是逐步迭代的，產(chǎn)品設(shè)計(jì)也不是一蹴而就的，需要有一個(gè)不斷前進(jìn)的過(guò)程，漸進(jìn)式設(shè)計(jì)非常契合SaaS產(chǎn)品。比如我們公司的產(chǎn)品，有企業(yè)客戶、集團(tuán)客戶、代理商、平臺(tái)運(yùn)營(yíng)人員、售后人員等參與，在設(shè)計(jì)系統(tǒng)的過(guò)程中，并不是一上來(lái)就把所有的工作全部做完， 這樣周期太長(zhǎng)，也不利于快速驗(yàn)證產(chǎn)品和市場(chǎng)的匹配，所以產(chǎn)品架構(gòu)自然而然也變成了一種漸進(jìn)的設(shè)計(jì)過(guò)程。

漸進(jìn)式設(shè)計(jì)需要盡量考慮未來(lái)產(chǎn)品的全局，以滿足后續(xù)產(chǎn)品擴(kuò)展需要。

以我曾經(jīng)做過(guò)的一個(gè)產(chǎn)品舉例，產(chǎn)品的用戶可以分為三大類，關(guān)系如下圖：

產(chǎn)品關(guān)系示例

在產(chǎn)品架構(gòu)的搭建過(guò)程中，我們?cè)谇宄羞@些基礎(chǔ)結(jié)構(gòu)以后，按照優(yōu)先級(jí)順序，逐步發(fā)展產(chǎn)品。如圖：

產(chǎn)品架構(gòu)示例圖

首先搭建了企業(yè)版產(chǎn)品和簡(jiǎn)單的運(yùn)營(yíng)管理系統(tǒng)，讓用戶能夠使用起來(lái)。后來(lái)隨著代理商力量的不斷計(jì)入，需要為代理商設(shè)計(jì)一套管理系統(tǒng)，代理商系統(tǒng)需要依賴于公司運(yùn)營(yíng)管理系統(tǒng)(公司運(yùn)營(yíng)早期就已經(jīng)有了代理商加入，運(yùn)營(yíng)管理平臺(tái)只有最簡(jiǎn)單的代理商管理功能，能夠標(biāo)記客戶所屬代理商，但并沒(méi)有去開(kāi)發(fā)一套代理商管理系統(tǒng)，只是預(yù)留了擴(kuò)展能力)。

隨著平臺(tái)的發(fā)展，用戶群體不斷擴(kuò)大，集團(tuán)客戶也在不斷增加，公司又基于企業(yè)版產(chǎn)品開(kāi)發(fā)了集團(tuán)版產(chǎn)品，滿足集團(tuán)企業(yè)客戶的需要。

整個(gè)代理商管理系統(tǒng)和公司運(yùn)營(yíng)管理系統(tǒng)也跟隨迭代，從最初的企業(yè)注冊(cè)審核，到用戶工單管理、結(jié)算續(xù)費(fèi)管理、再到增加集團(tuán)版的開(kāi)通管理流程及結(jié)算流程，歷時(shí)用了幾年時(shí)間。產(chǎn)品整體架構(gòu)經(jīng)歷了多個(gè)版本的迭代，才逐步變成現(xiàn)在的體系，并且還在持續(xù)完善中。

產(chǎn)品架構(gòu)的漸進(jìn)式設(shè)計(jì)和最小化可用產(chǎn)品(MVP)并不是一回事，產(chǎn)品架構(gòu)漸進(jìn)式設(shè)計(jì)是為了產(chǎn)品穩(wěn)步推進(jìn)并可擴(kuò)展，先集中精力解決當(dāng)前的重要需求和問(wèn)題，所積累的產(chǎn)品成果，會(huì)成為將來(lái)產(chǎn)品發(fā)展的基礎(chǔ)，而不是MVP中表示的每一個(gè)過(guò)程都可能要重構(gòu)。

MVP有一個(gè)非常生動(dòng)的例子，用戶需求是一輛車，那么車的MVP及產(chǎn)品演進(jìn)過(guò)程應(yīng)該如下圖5-5的第二部分所示：

MVP的演進(jìn)

產(chǎn)品架構(gòu)的漸進(jìn)式設(shè)計(jì)和產(chǎn)品的MVP有什么關(guān)系，其實(shí)是兩個(gè)維度的事情，產(chǎn)品架構(gòu)漸進(jìn)式設(shè)計(jì)是對(duì)現(xiàn)在業(yè)務(wù)的快速響應(yīng)，以及對(duì)未來(lái)業(yè)務(wù)擴(kuò)張的支撐。

MVP是在產(chǎn)品迭代過(guò)程中，在不同的階段，可能需要進(jìn)行重構(gòu)，上圖的例子，在一些產(chǎn)品論壇上都有闡述，這對(duì)MVP的解釋是很準(zhǔn)確的，最小化可行產(chǎn)品需要做到每次迭代都是完整可用的，可用場(chǎng)景閉環(huán)是MVP的核心指標(biāo)，這是產(chǎn)品從0到1的一種有效驗(yàn)證方式，但我認(rèn)為這種重構(gòu)并不一定是必須的.

很多軟件產(chǎn)品在迭代的過(guò)程中，都是在原有基礎(chǔ)上的擴(kuò)展，實(shí)際上產(chǎn)品架構(gòu)具備彈性和擴(kuò)展性，這是一名優(yōu)秀產(chǎn)品經(jīng)理需要具備的能力，畢竟任何歷史投入都是有成本的，優(yōu)秀的設(shè)計(jì)應(yīng)該是在原有基礎(chǔ)上的擴(kuò)展，而不是推倒重來(lái)。

B端產(chǎn)品在發(fā)展過(guò)程中，也比較注重產(chǎn)品和服務(wù)的結(jié)合，這個(gè)服務(wù)并不是指產(chǎn)品即服務(wù)，而是在早期產(chǎn)品不夠完善的情況下，部分環(huán)節(jié)通過(guò)線下服務(wù)來(lái)補(bǔ)充，這也是SaaS產(chǎn)品發(fā)展的一種形式。

產(chǎn)品架構(gòu)大體能夠說(shuō)清楚了系統(tǒng)間的關(guān)系，但對(duì)于具體的產(chǎn)品流程，產(chǎn)品架構(gòu)圖是無(wú)法表達(dá)清楚的，還需要輔助系統(tǒng)流程圖進(jìn)行說(shuō)明。