產(chǎn)品架構(gòu)是對業(yè)務(wù)的抽象，但架構(gòu)不是完美存在的結(jié)果，而是一個(gè)不斷改進(jìn)優(yōu)化的過程。

此前我們聊過“業(yè)務(wù)架構(gòu)、產(chǎn)品架構(gòu)和信息架構(gòu)的問題”在現(xiàn)實(shí)工作中我們 能見到一些公司，產(chǎn)品都已經(jīng)上線了，卻找不到一份合適的文檔描述整個(gè)產(chǎn)品的框架，前端和后臺由哪些部分組成，各自之間有著怎么的關(guān)聯(lián)關(guān)系，各個(gè)模塊如何協(xié)同支撐整個(gè)業(yè)務(wù)的發(fā)展。

更有甚者，甚至都找不到一份完整的文檔，來清晰的界定產(chǎn)品的邊界，完全是盲人摸象般的走到哪算哪。

我們還能見到不少掛著總監(jiān)，甚至VP頭銜的人，仍然講不清公司的產(chǎn)品的發(fā)展方向和未來規(guī)劃，因?yàn)樗麄儚膩頉]有真正的規(guī)劃過整個(gè)產(chǎn)品線的未來，慢慢的，整個(gè)公司只有各自一大堆的軟件，或者不同的功能模塊，有的是些微的改動(dòng)，有的是重復(fù)設(shè)計(jì)和開發(fā)。

我們的疑問是：為什么會出現(xiàn)這種情況？以及如何解決這個(gè)問題呢？

以本次復(fù)盤的O2O平臺為例，我們把整個(gè)平臺簡化分拆為用戶層、服務(wù)層和接口層（裁剪掉整個(gè)平臺中的多租戶等實(shí)際業(yè)務(wù)中的復(fù)雜應(yīng)用）。

如下圖所示：

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

現(xiàn)在的疑問是，為什么要這么分層，又是通過什么方式得出每一層要有這些功能模塊的設(shè)計(jì)呢？

本文為你具體解析產(chǎn)品架構(gòu)的設(shè)計(jì)過程。

01?產(chǎn)品架構(gòu)是可視化工具

在前文我們探討產(chǎn)品的信息架構(gòu)、產(chǎn)品架構(gòu)與業(yè)務(wù)架構(gòu)基本概念時(shí)，我用了一棟房子的例子來描述“產(chǎn)品架構(gòu)”的概念，“架構(gòu)”決定整棟方式的位置、朝向、樓層，決定了地下幾層，地面有幾層，有多少間房，層高多少米，這些東西是不管怎么裝修，都改變不了的事實(shí)。

對這棟房子而言，支柱、承重墻是再裝修的時(shí)候都不能動(dòng)，要?jiǎng)泳偷么髣?dòng)手術(shù)，甚至干脆推到重來。

“客廳”、“餐廳”、“主臥”這些功能區(qū)域，則是我們在使用某些某個(gè)產(chǎn)品的時(shí)候，所對應(yīng)的功能模塊。這個(gè)時(shí)候我們就發(fā)現(xiàn)，如果等房子建好了，再想把原來的一房一廳改成兩房一廳，就只能做隔斷，比如導(dǎo)致每個(gè)房間的面積變小，或者沒窗，或者采光不足等等。

從房子的例子，我們可以得出一個(gè)結(jié)論：產(chǎn)品架構(gòu)圖是一種產(chǎn)品經(jīng)理用來抽象表達(dá)一款產(chǎn)品的服務(wù)和商業(yè)模式的可視化工具。

產(chǎn)品經(jīng)理把產(chǎn)品所要實(shí)現(xiàn)的具象功能，抽象為一個(gè)一個(gè)彼此獨(dú)立又互為關(guān)聯(lián)的模塊（這種關(guān)聯(lián)性也是模塊的交互關(guān)系，包括信息和數(shù)據(jù)，通常以接口的方式實(shí)現(xiàn)），并把這些模塊根據(jù)一定的業(yè)務(wù)或數(shù)據(jù)邏輯進(jìn)行分層組合，來傳遞產(chǎn)品的業(yè)務(wù)流程、商業(yè)模式和設(shè)計(jì)思路。

所以，在產(chǎn)品正式進(jìn)入開發(fā)以前，繪制一個(gè)完整的產(chǎn)品架構(gòu)圖就成為必然。

架構(gòu)的根本目的就是為了梳理產(chǎn)品思路，從整體上把握產(chǎn)品的發(fā)展方向，把控產(chǎn)品的功能重點(diǎn)（賣點(diǎn)），它決定了產(chǎn)品必須要實(shí)現(xiàn)的功能，以及什么時(shí)候必須完成的功能，也就是產(chǎn)品的架構(gòu)決定了產(chǎn)品的發(fā)展路徑。

同時(shí)，為了滿足我們所設(shè)定的“架構(gòu)”構(gòu)想，還必須配備相關(guān)的產(chǎn)品研發(fā)和市場運(yùn)營資源以及具體的落地計(jì)劃，包括技術(shù)選型和技術(shù)路徑，市場營銷規(guī)劃等一系列的策略和措施。

產(chǎn)品架構(gòu)是團(tuán)隊(duì)基于某一獨(dú)特市場和用戶痛點(diǎn)的統(tǒng)一溝通語言，也是在產(chǎn)品迭代過程中的業(yè)務(wù)邊界。

02 分層是產(chǎn)品架構(gòu)設(shè)計(jì)的基本方法

如果你足夠細(xì)心的話，會發(fā)現(xiàn)本文的案例“O2O產(chǎn)品架構(gòu)示例”中，右側(cè)有標(biāo)記“接口層”、“服務(wù)平臺”、“終端用戶”等字眼，并做了一個(gè)標(biāo)記，說明他們說代表的含義和使命，比如“響應(yīng)終端的服務(wù)請求”，意味著這一層級的所有功能，都是為“用戶”服務(wù)的，是針對用戶行為的一個(gè)信息接受和反饋機(jī)制。

比如：在O2O的服務(wù)過程中，用戶有一個(gè)設(shè)備的維修請求，他通過“用戶界面”向平臺發(fā)送一個(gè)狀態(tài)信息和請求信息，平臺端通過一個(gè)有效的機(jī)制，及時(shí)的接受這一信息，并讓用戶理解到，“我已經(jīng)知道你這邊除了狀態(tài)，我正在安排人采用一些措施來協(xié)助你解決問題”。

這就是一種響應(yīng)機(jī)制，這一過程就是整個(gè)平臺的服務(wù)端開始處理用戶請求的起點(diǎn)，然后整個(gè)平臺基于這一個(gè)被“觸發(fā)”的機(jī)制，去調(diào)動(dòng)整個(gè)平臺的資源，包括各項(xiàng)數(shù)據(jù)的查閱、各種資源的調(diào)動(dòng)，來協(xié)同處理這一個(gè)業(yè)務(wù)請求的系列動(dòng)作。

所以，整個(gè)產(chǎn)品的架構(gòu)設(shè)計(jì)，也就是基于這一個(gè)連鎖反應(yīng)進(jìn)行的業(yè)務(wù)層和邏輯層的解耦分拆，系統(tǒng)性的規(guī)劃整個(gè)O2O平臺的前后端如何高效的協(xié)同。

同時(shí)，基于這一個(gè)基本規(guī)則，我們再考慮平臺的未來業(yè)務(wù)發(fā)展，甚至我們還需要考慮到未來三五年的業(yè)務(wù)容量會達(dá)到什么量級，由此需要采用怎樣的技術(shù)設(shè)計(jì)和資源配置（云端服務(wù)資源）。

由此可見，產(chǎn)品架構(gòu)設(shè)計(jì)，首先就是一個(gè)分層設(shè)計(jì)的過程。

常來說，最容易實(shí)現(xiàn)的產(chǎn)品層級結(jié)構(gòu)就是三層，即用戶層、功能層和數(shù)據(jù)層，這種層級關(guān)系即可完整的實(shí)現(xiàn)前、后臺關(guān)系的業(yè)務(wù)系統(tǒng)：

1. 統(tǒng)一的用戶感知層

解決的是用戶觸達(dá)的問題，考慮在何種場景下通過何種方式觸達(dá)用戶，最表層的業(yè)務(wù)體驗(yàn)，也就是我們常說的“用戶體驗(yàn)”，包括界面，布局，配色等直觀可見的每一個(gè)產(chǎn)品頁面。

在這個(gè)層面，我們考慮的是如何更好的表達(dá)我們想要表達(dá)的業(yè)務(wù)元素，如何能夠更吸引用戶的注意力和停留決策，它在一定程度上決定了用戶是否會立即卸載，或者是帶著好奇之心在有效的引導(dǎo)下探索產(chǎn)品。

這是產(chǎn)品經(jīng)理的必修課，因?yàn)樗苤庇^的讓人直接評斷產(chǎn)品，最常見的說辭就是“丑爆了”，而且是任何一個(gè)產(chǎn)品都會遭受到這一批評，哪怕你是微信也毫不例外。

但真正決定體驗(yàn)的，并不是這一層，但又無可奈何必須面對的現(xiàn)實(shí)。所謂人靠衣裝吧，一個(gè)打扮時(shí)髦的美女你甚至都會覺得她特別讓你感覺親密，甚至你會直覺認(rèn)為她根本就是一個(gè)好人，一個(gè)讓你喜歡的人。

2. 解耦的業(yè)務(wù)功能層

多少產(chǎn)品經(jīng)理實(shí)際在這個(gè)層級就開始陷入迷糊狀態(tài)，根本不知道甚至沒有意識到“功能”的分解和層次設(shè)計(jì)，在他們眼里，任何產(chǎn)品都只需要一個(gè)界面+一個(gè)數(shù)據(jù)庫，即可愉快的完成所有業(yè)務(wù)。

也是因?yàn)檫@種主觀的判斷，讓多少人總是認(rèn)為這個(gè)東西很簡單，那個(gè)東西很容易，別人都可以做出來，你為什么明天還不能上線，以及誰誰誰又做了這么一個(gè)功能，我們明天也要做一個(gè)。

諸如此類的根本原因就是只見樹木不見森林。

這一種粗淺的認(rèn)識，也帶來大量的產(chǎn)品被粗制濫造，胡亂承諾，最后不得不草草收場，因?yàn)檫@些產(chǎn)品從一個(gè)開始就沒有被真正的理解和設(shè)計(jì)，而是想當(dāng)然的認(rèn)為“我們只差一個(gè)程序員，明天就可以上線”。

對這一層級的認(rèn)知不足，會讓我們陷入一種奇怪的局面。

一個(gè)媽媽生一個(gè)孩子要10個(gè)月，10個(gè)媽媽生一個(gè)孩子只需要一個(gè)月。

“業(yè)務(wù)功能”的解耦，本質(zhì)是解決產(chǎn)品的核心功能的設(shè)計(jì)問題，包括如何高效的完成業(yè)務(wù)功能，如何與用戶層進(jìn)行交互，如何與外部系統(tǒng)進(jìn)行數(shù)據(jù)通信等一系列復(fù)雜的業(yè)務(wù)處理。

很多人無法理解，某個(gè)功能為什么要這么設(shè)計(jì)，為什么不能那樣設(shè)計(jì)，就是無法真正理解這一層的設(shè)計(jì)，從而加劇整個(gè)產(chǎn)品在最開始階段就限定了它的可能性。

這是“重構(gòu)”的原罪。

這里再次用了解耦這個(gè)詞，為什么會反復(fù)用到它，根本性原因就是考慮業(yè)務(wù)的擴(kuò)展性，也是考慮整個(gè)平臺的伸縮性。不要把各個(gè)功能模塊過于緊密的耦合，導(dǎo)致任何些微的改動(dòng)，都必須大動(dòng)干戈。

最蹩腳的設(shè)計(jì)，就是所有功能只看到一個(gè)業(yè)務(wù)線，所有人都在忙活，但沒有人搞得清楚邊界。

還有一種糟糕的局面就是，完全的各自為政，沒有協(xié)同，沒有次序

這兩種情況我都見過，帶來的后果除了平臺的效率低以外，也是資源的浪費(fèi)，更是阻塞了團(tuán)隊(duì)的上升空間?！枞麄€(gè)團(tuán)隊(duì)獲得成就的通道，也阻礙團(tuán)隊(duì)能力的提升。

3. 集中的數(shù)據(jù)處理層

相比較于“用戶層”，是所有人都直觀可見的是，所有人都知道有一個(gè)“數(shù)據(jù)庫”，甭管知不知道數(shù)據(jù)是什么，有哪些，要怎么用，它就相當(dāng)于我們的錢袋子，裝得有東西肯定就比沒東西更好。再要怎么擺弄擺弄，無法是錢票子裝得多點(diǎn)，容易數(shù)一點(diǎn)的問題。

所以，這一層處理的問題就是，產(chǎn)品的數(shù)據(jù)從哪里，沉淀到哪里去。實(shí)際上，稍微深入一點(diǎn)的問題就是數(shù)據(jù)如何高效的存儲，如何快速的被調(diào)用。

比如：今日頭條的推薦算法，就是根據(jù)用戶在使用（用戶層的行為）過程中產(chǎn)生的數(shù)據(jù)，來繪制這個(gè)用戶的習(xí)慣偏好，采用一種恰當(dāng)?shù)囊?guī)則來推薦相關(guān)的內(nèi)容，從而使得這個(gè)用戶更多的停留在產(chǎn)品上。

然后在此基礎(chǔ)上催生更多的商業(yè)可能性。

讓我們在回到案例中的O2O項(xiàng)目。

O2O產(chǎn)品架構(gòu)示例
我們用一個(gè)“用戶故事”來描述當(dāng)時(shí)我們需要解決的用戶問題：

“張三新買的冰箱出現(xiàn)了故障，他找到當(dāng)時(shí)的回執(zhí)單申報(bào)了一次售后服務(wù)，要求在周六上午處理完冰箱的故障”。

從這個(gè)描述過程中，我們就能知道3個(gè)關(guān)鍵信息：

（1）用戶信息

要有一個(gè)方便的界面協(xié)助用戶申報(bào)服務(wù)，怎么能讓用戶在申報(bào)服務(wù)的時(shí)候把資料問題錄入正確，有沒有辦法在用戶打開這個(gè)界面就直接解決問題，有沒有一個(gè)FAQ供用戶查閱。

（2）業(yè)務(wù)信息

后臺要處理用戶的服務(wù)請求（申報(bào)的售后服務(wù)），要安排一個(gè)擅長處理這個(gè)故障的工程師上門服務(wù)（業(yè)務(wù)技能要匹配，不能派一個(gè)不懂冰箱的工程師處理這個(gè)問題），時(shí)間是周六（資源要調(diào)配，距離太遠(yuǎn)不合適，時(shí)間沖突不合適等）。

（3）數(shù)據(jù)信息

上次的訂單是怎么找到的，這個(gè)用戶是不是在服務(wù)期內(nèi)，是不是要額外收費(fèi)，費(fèi)用是多少。這次處理完的訂單怎么和上次的訂單相關(guān)聯(lián)等等。

按照這種邏輯，就能清晰的勾勒出，在處理用戶的服務(wù)請求所需要完成的系列動(dòng)作，整個(gè)平臺的數(shù)據(jù)和信息是如何進(jìn)行流轉(zhuǎn)，以及為了支持整個(gè)平臺需要開發(fā)的產(chǎn)品功能有哪些。

當(dāng)然，單憑這一個(gè)“用戶故事”就能繪制一個(gè)大概的業(yè)務(wù)輪廓。

這是一種最簡單的分層機(jī)制，我們可以快速的得到一個(gè)初步的產(chǎn)品框架，當(dāng)然一定存在不少邊界不清晰，分層不明確的問題，我們還需要根據(jù)不同信息層級的邊界、同一層級內(nèi)模塊和模塊的邊界。

下一步，則是針對具體的業(yè)務(wù)展開規(guī)劃。

03?抽象與解耦

在前述的”分層“邏輯中，在各個(gè)業(yè)務(wù)層級中，我用了很多“小豆腐塊”表示具體的功能。我想你現(xiàn)在的疑問應(yīng)該是，這些小豆腐塊是如何被界定，它們的依據(jù)又是什么呢？

比如：架構(gòu)中有“接單”、“履約”、“回單”、“訂單列表”，為什么沒有登錄，修改密碼這些基礎(chǔ)功能，是因?yàn)檫@個(gè)產(chǎn)品不需要這些功能嗎？

這個(gè)問題的奧秘在于，產(chǎn)品架構(gòu)解決的是業(yè)務(wù)問題，而非功能問題。意思就是，架構(gòu)只框定這個(gè)產(chǎn)品要完成哪些業(yè)務(wù)，取得哪些成果以及相關(guān)的支撐數(shù)據(jù)，而不解決為了完成這些業(yè)務(wù)，所需要進(jìn)行的每一項(xiàng)具體的功能操作。

所以，在整個(gè)設(shè)計(jì)中，我們只看到一些簡潔的、概括性的詞匯，而沒有任何的實(shí)際功能，而且這些詞匯甚至可能本身就是整個(gè)平臺中的一個(gè)模塊或者一個(gè)小產(chǎn)品，也可能其中的詞匯永遠(yuǎn)不會在產(chǎn)品中表現(xiàn)為具體的功能，比如：“履約”，它代表的就是完成服務(wù)的一系列過程。

這種設(shè)計(jì)思路，就是抽象化，把具象的業(yè)務(wù)抽象為一種概念性的詞匯，其目的不僅是為了架構(gòu)設(shè)計(jì)的簡潔性，更是為了整個(gè)平臺業(yè)務(wù)的完整性，并把離散的業(yè)務(wù)過程場景化。

通過這一層“抽象”以后，整個(gè)平臺的業(yè)務(wù)框架即可完整的呈現(xiàn)只紙面上，我們就能把用戶發(fā)起請求一直到后續(xù)的所有關(guān)聯(lián)性業(yè)務(wù)完整的進(jìn)行串聯(lián)，也就能夠發(fā)現(xiàn)整個(gè)過程的不足和缺陷，去通過產(chǎn)品的優(yōu)化來促進(jìn)業(yè)務(wù)的優(yōu)化。

這才是真正的產(chǎn)品價(jià)值，企業(yè)通過部署這一套平臺化系統(tǒng)，帶來了整個(gè)業(yè)務(wù)流程的優(yōu)化，提升了用戶的體驗(yàn)。對2B的產(chǎn)品來說，它需要的是系統(tǒng)性的提高整個(gè)組織的效率，提升整體的績效，這其中也必然包括可見的系統(tǒng)部署成本，維護(hù)成本，以及相應(yīng)的管理成本的優(yōu)化。

對用戶來說，也只有這種全鏈路的觸點(diǎn)優(yōu)化，才是真正的用戶體驗(yàn)。

我們再次回到O2O平臺的一個(gè)“用戶故事”來反推如何進(jìn)行業(yè)務(wù)的抽象化：“坐席接到用戶王五反饋的問題，安排李四上門服務(wù)解決用戶的冰箱故障”。

在這個(gè)描述中實(shí)際包括的關(guān)鍵信息有：記錄問題，安排資源，工程師接受任務(wù)，上門服務(wù)。所以這個(gè)過程經(jīng)過抽象處理后就變成如下形式：

• 受理：坐席把用戶反饋的問題記錄在案，并形成一個(gè)單據(jù)
• 調(diào)度：坐席根據(jù)用戶信息，安排恰當(dāng)?shù)墓こ處?/li>
• 接單：工程師接受坐席安排的任務(wù)
• 履約：工程師上門處理用戶反饋的問題

我們可以把這種抽象后的關(guān)鍵節(jié)點(diǎn)稱之為“業(yè)務(wù)動(dòng)作”，他們將像一棟房子的支柱和承重墻一樣，牢牢的支撐起整個(gè)平臺的運(yùn)轉(zhuǎn)。

通過這種高度抽象后，整個(gè)系統(tǒng)非常簡潔而又完整，各個(gè)環(huán)節(jié)只需要通過一個(gè)訂單主線即可完成一系列的任務(wù)，不管這個(gè)過程將要發(fā)生多復(fù)雜的業(yè)務(wù)交互，都始終能夠圍繞用戶和訂單來進(jìn)行溯源管理和任務(wù)處理。

這種抽象后的業(yè)務(wù)動(dòng)作即可作為我們構(gòu)建產(chǎn)品架構(gòu)的核心信息，通過業(yè)務(wù)分層和邏輯分層，嚴(yán)謹(jǐn)進(jìn)行分拆，形成最終的產(chǎn)品架構(gòu)設(shè)計(jì)，并根據(jù)這一線索進(jìn)行恰當(dāng)?shù)恼归_和引申，則整個(gè)平臺雛形便顯現(xiàn)在我們眼前。

回到問題的起點(diǎn)，假設(shè)我們沒有能夠進(jìn)行這種抽象性的架構(gòu)設(shè)計(jì)，我們將面臨怎樣的局面呢？

04?架構(gòu)，是一個(gè)漸進(jìn)的過程

架構(gòu)，是一個(gè)偏向宏觀的事情，而設(shè)計(jì)則是一個(gè)偏向細(xì)節(jié)的事情。這里要區(qū)分的一件事就是技術(shù)架構(gòu)和產(chǎn)品架構(gòu)，技術(shù)架構(gòu)是將產(chǎn)品需求轉(zhuǎn)變?yōu)榧夹g(shù)實(shí)現(xiàn)的過程，產(chǎn)品架構(gòu)則是將用戶需求轉(zhuǎn)變?yōu)楫a(chǎn)品需求的過程。

我們可以想象一棟樓的地基問題所帶來的影響，對任何產(chǎn)品而言，一旦架構(gòu)定錯(cuò)，輕則樓蓋不高，重則根本改不起樓。

所以，產(chǎn)品的架構(gòu)設(shè)計(jì)，最考驗(yàn)PM的判斷力和設(shè)計(jì)能力——體驗(yàn)是設(shè)計(jì)出來的，產(chǎn)品是規(guī)劃出來的，簡潔的架構(gòu)決定產(chǎn)品的調(diào)性。

但是，與“房屋”的案例不同的是，產(chǎn)品的架構(gòu)不只是“結(jié)果”，而是一種迭代的過程。它會隨著業(yè)務(wù)的發(fā)展而不斷優(yōu)化和調(diào)整，對一款產(chǎn)品來說，不存在一種始終靜態(tài)的架構(gòu)模式。

比如：電商平臺，在早期很多功能可能都不是關(guān)鍵性業(yè)務(wù)，在架構(gòu)設(shè)計(jì)都可能不會考慮，而是隨著業(yè)務(wù)的發(fā)展而調(diào)整。所以，必須保證產(chǎn)品架構(gòu)具備一定的擴(kuò)展性和成長性。比如：電商平臺的banner，隨著業(yè)務(wù)的發(fā)展，它能完全成長為一個(gè)獨(dú)立的強(qiáng)運(yùn)營的業(yè)務(wù)模塊。

<本文完>

#專欄作家#

杜松，公眾號：產(chǎn)品微言，人人都是產(chǎn)品經(jīng)理專欄作家。專注于人工智能方向，擅長產(chǎn)品規(guī)劃和架構(gòu)設(shè)計(jì)。

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

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