編輯導(dǎo)語：產(chǎn)品架構(gòu)是對業(yè)務(wù)的抽象，但架構(gòu)不是完美存在的結(jié)果，而是一個不斷改進(jìn)優(yōu)化的過程。本文以O(shè)2O平臺為例，將其簡化拆分為幾個部分，以此來講解產(chǎn)品架構(gòu)。推薦對產(chǎn)品架構(gòu)感興趣的用戶閱讀。

見過很多公司，產(chǎn)品都已經(jīng)上線了，卻找不到一份合適的文檔描述整個產(chǎn)品的框架，前端和后臺由哪些部分組成，各自之間有著怎么的關(guān)聯(lián)關(guān)系，各個模塊如何協(xié)同支撐整個業(yè)務(wù)的發(fā)展。

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

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

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

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

如下圖所示：

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

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

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

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

對這棟房子而言，支柱、承重墻是再裝修的時候都不能動，要動就得大動手術(shù)，甚至干脆推到重來。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“一個媽媽生一個孩子要10個月，10個媽媽生一個孩子只需要一個月”。

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

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

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

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

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

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

這兩種情況我都見過，帶來的后果除了平臺的效率低以外，也是資源的浪費，更是阻塞了團(tuán)隊的上升空間。——阻塞整個團(tuán)隊獲得成就的通道，也阻礙團(tuán)隊能力的提升。

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

相比較于“用戶層”，是所有人都直觀可見的是，所有人都知道有一個“數(shù)據(jù)庫”，甭管知不知道數(shù)據(jù)是什么，有哪些，要怎么用，它就相當(dāng)于我們的錢袋子，裝得有東西肯定就比沒東西更好。

再要怎么擺弄擺弄，無法是錢票子裝得多點，容易數(shù)一點的問題。

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

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

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

讓我們在回到案例中的O2O項目。

我們用一個“用戶故事”來描述當(dāng)時我們需要解決的用戶問題：

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

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

用戶信息：

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

業(yè)務(wù)信息：

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

數(shù)據(jù)信息：

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

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

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

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

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

三、抽象與解耦

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

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

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

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

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

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

這才是真正的產(chǎn)品價值，企業(yè)通過部署這一套平臺化系統(tǒng)，帶來了整個業(yè)務(wù)流程的優(yōu)化，提升了用戶的體驗。

對2B的產(chǎn)品來說，它需要的是系統(tǒng)性的提高整個組織的效率，提升整體的績效，這其中也必然包括可見的系統(tǒng)部署成本，維護(hù)成本，以及相應(yīng)的管理成本的優(yōu)化。

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

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

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

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

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

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

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

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

四、架構(gòu)，是一個漸進(jìn)的過程

架構(gòu)，是一個偏向宏觀的事情，而設(shè)計則是一個偏向細(xì)節(jié)的事情。

這里要區(qū)分的一件事就是技術(shù)架構(gòu)和產(chǎn)品架構(gòu)，技術(shù)架構(gòu)是將產(chǎn)品需求轉(zhuǎn)變?yōu)榧夹g(shù)實現(xiàn)的過程，產(chǎn)品架構(gòu)則是將用戶需求轉(zhuǎn)變?yōu)楫a(chǎn)品需求的過程。

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

所以，產(chǎn)品的架構(gòu)設(shè)計，最考驗PM的判斷力和設(shè)計能力——體驗是設(shè)計出來的，產(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è)計都可能不會考慮，而是隨著業(yè)務(wù)的發(fā)展而調(diào)整。所以，必須保證產(chǎn)品架構(gòu)具備一定的擴(kuò)展性和成長性。比如電商平臺的banner，隨著業(yè)務(wù)的發(fā)展，它能完全成長為一個獨立的強(qiáng)運營的業(yè)務(wù)模塊。

作者： 杜松；公眾號：產(chǎn)品微言

原文鏈接：https://mp.weixin.qq.com/s/Wicbv-zpgvZw6xkOfR2glg

本文由 @產(chǎn)品微言 授權(quán)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

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