產品架構是對業務的抽象，但架構不是完美存在的結果，而是一個不斷改進優化的過程。

此前我們聊過“業務架構、產品架構和信息架構的問題”在現實工作中我們 能見到一些公司，產品都已經上線了，卻找不到一份合適的文檔描述整個產品的框架，前端和后臺由哪些部分組成，各自之間有著怎么的關聯關系，各個模塊如何協同支撐整個業務的發展。

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

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

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

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

如下圖所示：

O2O產品架構示例

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

本文為你具體解析產品架構的設計過程。

01?產品架構是可視化工具

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

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

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

從房子的例子，我們可以得出一個結論：產品架構圖是一種產品經理用來抽象表達一款產品的服務和商業模式的可視化工具。

產品經理把產品所要實現的具象功能，抽象為一個一個彼此獨立又互為關聯的模塊（這種關聯性也是模塊的交互關系，包括信息和數據，通常以接口的方式實現），并把這些模塊根據一定的業務或數據邏輯進行分層組合，來傳遞產品的業務流程、商業模式和設計思路。

所以，在產品正式進入開發以前，繪制一個完整的產品架構圖就成為必然。

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

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

產品架構是團隊基于某一獨特市場和用戶痛點的統一溝通語言，也是在產品迭代過程中的業務邊界。

02 分層是產品架構設計的基本方法

如果你足夠細心的話，會發現本文的案例“O2O產品架構示例”中，右側有標記“接口層”、“服務平臺”、“終端用戶”等字眼，并做了一個標記，說明他們說代表的含義和使命，比如“響應終端的服務請求”，意味著這一層級的所有功能，都是為“用戶”服務的，是針對用戶行為的一個信息接受和反饋機制。

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

這就是一種響應機制，這一過程就是整個平臺的服務端開始處理用戶請求的起點，然后整個平臺基于這一個被“觸發”的機制，去調動整個平臺的資源，包括各項數據的查閱、各種資源的調動，來協同處理這一個業務請求的系列動作。

所以，整個產品的架構設計，也就是基于這一個連鎖反應進行的業務層和邏輯層的解耦分拆，系統性的規劃整個O2O平臺的前后端如何高效的協同。

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

由此可見，產品架構設計，首先就是一個分層設計的過程。

常來說，最容易實現的產品層級結構就是三層，即用戶層、功能層和數據層，這種層級關系即可完整的實現前、后臺關系的業務系統：

1. 統一的用戶感知層

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

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

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

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

2. 解耦的業務功能層

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

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

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

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

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

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

“業務功能”的解耦，本質是解決產品的核心功能的設計問題，包括如何高效的完成業務功能，如何與用戶層進行交互，如何與外部系統進行數據通信等一系列復雜的業務處理。

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

這是“重構”的原罪。

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

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

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

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

3. 集中的數據處理層

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

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

比如：今日頭條的推薦算法，就是根據用戶在使用（用戶層的行為）過程中產生的數據，來繪制這個用戶的習慣偏好，采用一種恰當的規則來推薦相關的內容，從而使得這個用戶更多的停留在產品上。

然后在此基礎上催生更多的商業可能性。

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

O2O產品架構示例
我們用一個“用戶故事”來描述當時我們需要解決的用戶問題：

“張三新買的冰箱出現了故障，他找到當時的回執單申報了一次售后服務，要求在周六上午處理完冰箱的故障”。

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

（1）用戶信息

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

（2）業務信息

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

（3）數據信息

上次的訂單是怎么找到的，這個用戶是不是在服務期內，是不是要額外收費，費用是多少。這次處理完的訂單怎么和上次的訂單相關聯等等。

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

當然，單憑這一個“用戶故事”就能繪制一個大概的業務輪廓。

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

下一步，則是針對具體的業務展開規劃。

03?抽象與解耦

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

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

這個問題的奧秘在于，產品架構解決的是業務問題，而非功能問題。意思就是，架構只框定這個產品要完成哪些業務，取得哪些成果以及相關的支撐數據，而不解決為了完成這些業務，所需要進行的每一項具體的功能操作。

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

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

通過這一層“抽象”以后，整個平臺的業務框架即可完整的呈現只紙面上，我們就能把用戶發起請求一直到后續的所有關聯性業務完整的進行串聯，也就能夠發現整個過程的不足和缺陷，去通過產品的優化來促進業務的優化。

這才是真正的產品價值，企業通過部署這一套平臺化系統，帶來了整個業務流程的優化，提升了用戶的體驗。對2B的產品來說，它需要的是系統性的提高整個組織的效率，提升整體的績效，這其中也必然包括可見的系統部署成本，維護成本，以及相應的管理成本的優化。

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

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

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

• 受理：坐席把用戶反饋的問題記錄在案，并形成一個單據
• 調度：坐席根據用戶信息，安排恰當的工程師
• 接單：工程師接受坐席安排的任務
• 履約：工程師上門處理用戶反饋的問題

我們可以把這種抽象后的關鍵節點稱之為“業務動作”，他們將像一棟房子的支柱和承重墻一樣，牢牢的支撐起整個平臺的運轉。

通過這種高度抽象后，整個系統非常簡潔而又完整，各個環節只需要通過一個訂單主線即可完成一系列的任務，不管這個過程將要發生多復雜的業務交互，都始終能夠圍繞用戶和訂單來進行溯源管理和任務處理。

這種抽象后的業務動作即可作為我們構建產品架構的核心信息，通過業務分層和邏輯分層，嚴謹進行分拆，形成最終的產品架構設計，并根據這一線索進行恰當的展開和引申，則整個平臺雛形便顯現在我們眼前。

回到問題的起點，假設我們沒有能夠進行這種抽象性的架構設計，我們將面臨怎樣的局面呢？

04?架構，是一個漸進的過程

架構，是一個偏向宏觀的事情，而設計則是一個偏向細節的事情。這里要區分的一件事就是技術架構和產品架構，技術架構是將產品需求轉變為技術實現的過程，產品架構則是將用戶需求轉變為產品需求的過程。

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

所以，產品的架構設計，最考驗PM的判斷力和設計能力——體驗是設計出來的，產品是規劃出來的，簡潔的架構決定產品的調性。

但是，與“房屋”的案例不同的是，產品的架構不只是“結果”，而是一種迭代的過程。它會隨著業務的發展而不斷優化和調整，對一款產品來說，不存在一種始終靜態的架構模式。

比如：電商平臺，在早期很多功能可能都不是關鍵性業務，在架構設計都可能不會考慮，而是隨著業務的發展而調整。所以，必須保證產品架構具備一定的擴展性和成長性。比如：電商平臺的banner，隨著業務的發展，它能完全成長為一個獨立的強運營的業務模塊。

<本文完>

#專欄作家#

杜松，公眾號：產品微言，人人都是產品經理專欄作家。專注于人工智能方向，擅長產品規劃和架構設計。

本文原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash ，基于 CC0 協議。