產(chǎn)品架構是對業(yè)務的抽象，但架構不是完美存在的結果，而是一個不斷改進優(yōu)化的過程彰阴。
文??|? ?杜松，公眾號??|? ?產(chǎn)品微言
見過很多公司拍冠，產(chǎn)品都已經(jīng)上線了尿这，卻找不到一份合適的文檔描述整個產(chǎn)品的框架，前端和后臺由哪些部分組成庆杜，各自之間有著怎么的關聯(lián)關系射众，各個模塊如何協(xié)同支撐整個業(yè)務的發(fā)展。
更有甚者晃财，甚至都找不到一份完整的文檔叨橱，來清晰的界定產(chǎn)品的邊界，完全是盲人摸象般的走到哪算哪断盛。
我們還能見到不少掛著總監(jiān)罗洗，甚至VP頭銜的人，仍然講不清公司的產(chǎn)品的發(fā)展方向和未來規(guī)劃钢猛，因為他們從來沒有真正的規(guī)劃過整個產(chǎn)品線的未來栖博，慢慢的，整個公司只有各自一大堆的軟件厢洞，或者不同的功能模塊仇让，有的是些微的改動，有的是重復設計和開發(fā)躺翻。
我們的疑問是：為什么會出現(xiàn)這種情況丧叽？以及如何解決這個問題呢？
以本次復盤的O2O平臺為例公你，我們把整個平臺簡化分拆為用戶層踊淳、服務層和接口層（裁剪掉整個平臺中的多租戶等實際業(yè)務中的復雜應用）。
如下圖所示：
現(xiàn)在的疑問是，為什么要這么分層迂尝，又是通過什么方式得出每一層要有這些功能模塊的設計呢脱茉？
本文為你具體解析?產(chǎn)品架構?的設計過程。
01垄开、產(chǎn)品架構是可視化工具
在前文我們探討?產(chǎn)品的信息架構琴许、產(chǎn)品架構與業(yè)務架構?基本概念時，我用了一棟房子的例子來描述“產(chǎn)品架構”的概念溉躲，“架構”決定整棟方式的位置榜田、朝向、樓層锻梳，決定了地下幾層箭券，地面有幾層，有多少間房疑枯，層高多少米辩块，這些東西是不管怎么裝修，都改變不了的事實荆永。
對這棟房子而言废亭，支柱、承重墻是再裝修的時候都不能動屁魏，要動就得大動手術滔以，甚至干脆推到重來捉腥。
“客廳”氓拼、“餐廳”、“主臥”這些功能區(qū)域抵碟，則是我們在使用某些某個產(chǎn)品的時候桃漾，所對應的功能模塊。這個時候我們就發(fā)現(xiàn)拟逮，如果等房子建好了撬统，再想把原來的一房一廳改成兩房一廳，就只能做隔斷敦迄，比如導致每個房間的面積變小恋追，或者沒窗，或者采光不足等等罚屋。
從房子的例子苦囱，我們可以得出一個結論：
“? ?產(chǎn)品架構圖是一種產(chǎn)品經(jīng)理用來抽象表達以一款產(chǎn)品的服務和商業(yè)模式的可視化工具。
產(chǎn)品經(jīng)理把產(chǎn)品所要實現(xiàn)的具象功能脾猛，抽象為一個一個彼此獨立又互為關聯(lián)的模塊（這種關聯(lián)性也是模塊的交互關系撕彤，包括信息和數(shù)據(jù)，通常以接口的方式實現(xiàn)）猛拴，并把這些模塊根據(jù)一定的業(yè)務或數(shù)據(jù)邏輯進行分層組合羹铅，來傳遞產(chǎn)品的業(yè)務流程蚀狰、商業(yè)模式和設計思路。
所以职员，在產(chǎn)品正式進入開發(fā)以前麻蹋，繪制一個完整的產(chǎn)品架構圖就成為必然：
架構的根本目的就是為了梳理產(chǎn)品思路，從整體上把握產(chǎn)品的發(fā)展方向廉邑，把控產(chǎn)品的功能重點（賣點）哥蔚，它決定了產(chǎn)品必須要實現(xiàn)的功能，以及什么時候必須完成的功能蛛蒙，也就是產(chǎn)品的架構決定了產(chǎn)品的發(fā)展路徑糙箍。
同時，為了滿足我們所設定的“架構”構想牵祟，還必須配備相關的產(chǎn)品研發(fā)和市場運營資源以及具體的落地計劃深夯，包括技術選型和技術路徑，市場營銷規(guī)劃等一系列的策略和措施诺苹。
產(chǎn)品架構是團隊基于某一獨特市場和用戶痛點的統(tǒng)一溝通語言咕晋，也是在產(chǎn)品迭代過程中的業(yè)務邊界。
02收奔、分層是產(chǎn)品架構設計的基本方法
如果你足夠細心的話掌呜，會發(fā)現(xiàn)本文的案例“O2O產(chǎn)品架構示例”中，右側有標記“接口層”坪哄、“服務平臺”质蕉、”終端用戶“等字眼，并做了一個標記翩肌，說明他們說代表的含義和使命模暗，比如”響應終端的服務請求“，意味著這一層級的所有功能念祭，都是為”用戶“服務的兑宇，是針對用戶行為的一個信息接受和反饋機制。
比如粱坤，在O2O的服務過程中隶糕，用戶有一個設備的維修請求，他通過“用戶界面”向平臺發(fā)送一個狀態(tài)信息和請求信息站玄，平臺端通過一個有效的機制枚驻，及時的接受這一信息，并讓用戶理解到蜒什，“我已經(jīng)知道你這邊除了狀態(tài)测秸，我正在安排人采用一些措施來協(xié)助你解決問題”。
這就是一種響應機制，這一過程就是整個平臺的服務端開始處理用戶請求的起點霎冯，然后整個平臺基于這一個被“觸發(fā)”的機制铃拇，去調動整個平臺的資源，包括各項數(shù)據(jù)的查閱沈撞、各種資源的調動慷荔，來協(xié)同處理這一個業(yè)務請求的系列動作。
所以缠俺，整個產(chǎn)品的架構設計显晶，也就是基于這一個連鎖反應進行的業(yè)務層和邏輯層的解耦分拆，系統(tǒng)性的規(guī)劃整個O2O平臺的前后端如何高效的協(xié)同壹士。
同時磷雇，基于這一個基本規(guī)則，我們再考慮平臺的未來業(yè)務發(fā)展躏救，甚至我們還需要考慮到未來三五年的業(yè)務容量會達到什么量級唯笙，由此需要采用怎樣的技術設計和資源配置（云端服務資源）。
由此可見盒使，產(chǎn)品架構設計崩掘，首先就是一個分層設計的過程。
常來說少办，最容易實現(xiàn)的產(chǎn)品層級結構就是三層苞慢，即用戶層、功能層和數(shù)據(jù)層英妓，這種層級關系即可完整的實現(xiàn)前挽放、后臺關系的業(yè)務系統(tǒng)：
1、統(tǒng)一的用戶感知層
解決的是用戶觸達的問題鞋拟，考慮在何種場景下通過何種方式觸達用戶骂维，最表層的業(yè)務體驗惹资，也就是我們常說的“用戶體驗”贺纲，包括界面，布局褪测，配色等直觀可見的每一個產(chǎn)品頁面猴誊。
在這個層面，我們考慮的是如何更好的表達我們想要表達的業(yè)務元素侮措，如何能夠更吸引用戶的注意力和停留決策懈叹，它在一定程度上決定了用戶是否會立即卸載，或者是帶著好奇之心在有效的引導下探索產(chǎn)品分扎。
這是產(chǎn)品經(jīng)理的必修課澄成，因為它能直觀的讓人直接評斷產(chǎn)品，最常見的說辭就是“丑爆了”，而且是任何一個產(chǎn)品都會遭受到這一批評墨状，哪怕你是微信也毫不例外卫漫。
但真正決定體驗的，并不是這一層肾砂，但又無可奈何必須面對的現(xiàn)實列赎。所謂人靠衣裝吧，一個打扮時髦的美女你甚至都會覺得她特別讓你感覺親密镐确，甚至你會直覺認為她根本就是一個好人包吝，一個讓你喜歡的人。
2源葫、解耦的業(yè)務功能層
多少產(chǎn)品經(jīng)理實際在這個層級就開始陷入迷糊狀態(tài)诗越，根本不知道甚至沒有意識到“功能”的分解和層次設計，在他們眼里息堂，任何產(chǎn)品都只需要一個界面+一個數(shù)據(jù)庫掺喻，即可愉快的完成所有業(yè)務。
也是因為這種主觀的判斷储矩，讓多少人總是認為這個東西很簡單感耙，那個東西很容易，別人都可以做出來持隧，你為什么明天還不能上線即硼，以及誰誰誰又做了這么一個功能，我們明天也要做一個屡拨。
諸如此類的根本原因就是只見樹木不見森林只酥。
這一種粗淺的認識，也帶來大量的產(chǎn)品被粗制濫造呀狼，胡亂承諾裂允，最后不得不草草收場，因為這些產(chǎn)品從一個開始就沒有被真正的理解和設計哥艇，而是想當然的認為“我們只差一個程序員绝编，明天就可以上線”。
對這一層級的認知不足貌踏，會讓我們陷入一種奇怪的局面十饥。
““一個媽媽生一個孩子要10個月，10個媽媽生一個孩子只需要一個月”祖乳。
“業(yè)務功能”的解耦逗堵，本質是解決產(chǎn)品的核心功能的設計問題，包括如何高效的完成業(yè)務功能眷昆，如何與用戶層進行交互蜒秤，如何與外部系統(tǒng)進行數(shù)據(jù)通信等一系列復雜的業(yè)務處理汁咏。
很多人無法理解，某個功能為什么要這么設計作媚，為什么不能那樣設計梆暖，就是無法真正理解這一層的設計，從而加劇整個產(chǎn)品在最開始階段就限定了它的可能性掂骏。
這是“重構”的原罪轰驳。
這里再次用了解耦這個詞，為什么會反復用到它弟灼，根本性原因就是考慮業(yè)務的擴展性级解，也是考慮整個平臺的伸縮性。不要把各個功能模塊過于緊密的耦合田绑，導致任何些微的改動勤哗，都必須大動干戈。
最蹩腳的設計掩驱，就是所有功能只看到一個業(yè)務線芒划，所有人都在忙活，但沒有人搞得清楚邊界欧穴。
還有一種糟糕的局面就是民逼，完全的各自為政，沒有協(xié)同涮帘，沒有次序
這兩種情況我都見過拼苍，帶來的后果除了平臺的效率低以外，也是資源的浪費调缨，更是阻塞了團隊的上升空間疮鲫。——阻塞整個團隊獲得成就的通道弦叶，也阻礙團隊能力的提升俊犯。
3、集中的數(shù)據(jù)處理層
相比較于“用戶層”伤哺，是所有人都直觀可見的是燕侠，所有人都知道有一個“數(shù)據(jù)庫”，甭管知不知道數(shù)據(jù)是什么默责，有哪些贬循，要怎么用咸包，它就相當于我們的錢袋子桃序，裝得有東西肯定就比沒東西更好。
再要怎么擺弄擺弄烂瘫，無法是錢票子裝得多點媒熊，容易數(shù)一點的問題奇适。
所以，這一層處理的問題就是芦鳍，產(chǎn)品的數(shù)據(jù)從哪里嚷往，沉淀到哪里去。實際上柠衅，稍微深入一點的問題就是數(shù)據(jù)如何高效的存儲皮仁，如何快速的被調用。
比如今日頭條的推薦算法菲宴，就是根據(jù)用戶在使用（用戶層的行為）過程中產(chǎn)生的數(shù)據(jù)贷祈，來繪制這個用戶的習慣偏好，采用一種恰當?shù)囊?guī)則來推薦相關的內容喝峦，從而使得這個用戶更多的停留在產(chǎn)品上势誊。
然后在此基礎上催生更多的商業(yè)可能性。
讓我們在回到案例中的O2O項目俱济。
我們用一個“用戶故事”來描述當時我們需要解決的用戶問題：
“張三新買的冰箱出現(xiàn)了故障胰挑，他找到當時的回執(zhí)單申報了一次售后服務渣慕，要求在周六上午處理完冰箱的故障”。
從這個描述過程中挤忙，我們就能知道3個關鍵信息：
用戶信息
要有一個方便的界面協(xié)助用戶申報服務，怎么能讓用戶在申報服務的時候把資料問題錄入正確谈喳，有沒有辦法在用戶打開這個界面就直接解決問題饭玲，有沒有一個FAQ供用戶查閱；
業(yè)務信息
后臺要處理用戶的服務請求（申報的售后服務）叁执，要安排一個擅長處理這個故障的工程師上門服務（業(yè)務技能要匹配茄厘，不能派一個不懂冰箱的工程師處理這個問題），時間是周六（資源要調配谈宛，距離太遠不合適次哈，時間沖突不合適等）；
數(shù)據(jù)信息
上次的訂單是怎么找到的吆录，這個用戶是不是在服務期內窑滞，是不是要額外收費，費用是多少恢筝。這次處理完的訂單怎么和上次的訂單相關聯(lián)等等哀卫。
按照這種邏輯，就能清晰的勾勒出撬槽，在處理用戶的服務請求所需要完成的系列動作此改，整個平臺的數(shù)據(jù)和信息是如何進行流轉，以及為了支持整個平臺需要開發(fā)的產(chǎn)品功能有哪些侄柔。
當然共啃，單憑這一個“用戶故事”就能繪制一個大概的業(yè)務輪廓占调。
這是一種最簡單的分層機制，我們可以快速的得到一個初步的產(chǎn)品框架移剪，當然一定存在不少邊界不清晰究珊，分層不明確的問題，我們還需要根據(jù)不同信息層級的邊界纵苛、同一層級內模塊和模塊的邊界剿涮。
下一步，則是針對具體的業(yè)務展開規(guī)劃攻人。
03幔虏、抽象與解耦
在前述的”分層“邏輯中，在各個業(yè)務層級中贝椿，我用了很多“小豆腐塊”表示具體的功能想括。我想你現(xiàn)在的疑問應該是，這些小豆腐塊是如何被界定烙博，它們的依據(jù)又是什么呢瑟蜈？
比如架構中有“接單”、“履約”渣窜、“回單”铺根、“訂單列表”，為什么沒有登錄乔宿，修改密碼這些基礎功能位迂，是因為這個產(chǎn)品不需要這些功能嗎？
這個問題的奧秘在于详瑞，產(chǎn)品架構解決的是業(yè)務問題掂林，而非功能問題。意思就是坝橡，架構只框定這個產(chǎn)品要完成哪些業(yè)務泻帮，取得哪些成果以及相關的支撐數(shù)據(jù)，而不解決為了完成這些業(yè)務计寇，所需要進行的每一項具體的功能操作锣杂。
所以，在整個設計中番宁，我們只看到一些簡潔的元莫、概括性的詞匯，而沒有任何的實際功能蝶押，而且這些詞匯甚至可能本身就是整個平臺中的一個模塊或者一個小產(chǎn)品踱蠢，也可能其中的詞匯永遠不會在產(chǎn)品中表現(xiàn)為具體的功能，比如“履約”播聪，它代表的就是完成服務的一系列過程朽基。
這種設計思路布隔，就是抽象化离陶，把具象的業(yè)務抽象為一種概念性的詞匯稼虎，其目的不僅是為了架構設計的簡潔性，更是為了整個平臺業(yè)務的完整性招刨，并把離散的業(yè)務過程場景化霎俩。
通過這一層“抽象”以后，整個平臺的業(yè)務框架即可完整的呈現(xiàn)只紙面上沉眶，我們就能把用戶發(fā)起請求一直到后續(xù)的所有關聯(lián)性業(yè)務完整的進行串聯(lián)打却，也就能夠發(fā)現(xiàn)整個過程的不足和缺陷，去通過產(chǎn)品的優(yōu)化來促進業(yè)務的優(yōu)化谎倔。
這才是真正的產(chǎn)品價值柳击，企業(yè)通過部署這一套平臺化系統(tǒng)，帶來了整個業(yè)務流程的優(yōu)化片习，提升了用戶的體驗捌肴。對2B的產(chǎn)品來說，它需要的是系統(tǒng)性的提高整個組織的效率藕咏，提升整體的績效状知，這其中也必然包括可見的系統(tǒng)部署成本，維護成本孽查，以及相應的管理成本的優(yōu)化饥悴。
對用戶來說，也只有這種全鏈路的觸點優(yōu)化盲再，才是真正的用戶體驗西设。
我們再次回到O2O平臺的一個“用戶故事”來反推如何進行業(yè)務的抽象化：“坐席接到用戶王五反饋的問題，安排李四上門服務解決用戶的冰箱故障”答朋。
在這個描述中實際包括的關鍵信息有：記錄問題济榨，安排資源，工程師接受任務绿映，上門服務擒滑。所以這個過程經(jīng)過抽象處理后就變成如下形式：
受理：坐席把用戶反饋的問題記錄在案，并形成一個單據(jù)
調度：坐席根據(jù)用戶信息叉弦，安排恰當?shù)墓こ處?/p>
接單：工程師接受坐席安排的任務
履約：工程師上門處理用戶反饋的問題
我們可以把這種抽象后的關鍵節(jié)點稱之為“業(yè)務動作”丐一，他們將像一棟房子的支柱和承重墻一樣，牢牢的支撐起整個平臺的運轉淹冰。
通過這種高度抽象后库车，整個系統(tǒng)非常簡潔而又完整，各個環(huán)節(jié)只需要通過一個訂單主線即可完成一系列的任務樱拴，不管這個過程將要發(fā)生多復雜的業(yè)務交互都始終能夠圍繞用戶和訂單來進行溯源管理和任務處理柠衍。
這種抽象后的業(yè)務動作即可作為我們構建產(chǎn)品架構的核心信息洋满，通過業(yè)務分層和邏輯分層，嚴謹進行分拆珍坊，形成最終的產(chǎn)品架構設計牺勾，并根據(jù)這一線索進行恰當?shù)恼归_和引申，則整個平臺雛形便顯現(xiàn)在我們眼前阵漏。
回到問題的起點驻民，假設我們沒有能夠進行這種抽象性的架構設計，我們將面臨怎樣的局面呢履怯？
04回还、架構，是一個漸進的過程
架構叹洲，是一個偏向宏觀的事情柠硕，而設計則是一個偏向細節(jié)的事情。
這里要區(qū)分的一件事就是技術架構和產(chǎn)品架構运提，技術架構是將產(chǎn)品需求轉變?yōu)榧夹g實現(xiàn)的過程蝗柔，產(chǎn)品架構則是將用戶需求轉變?yōu)楫a(chǎn)品需求的過程。
我們可以想象一棟樓的地基問題所帶來的影響糙捺，對任何產(chǎn)品而言诫咱，一旦架構定錯，輕則樓蓋不高洪灯，重則根本改不起樓坎缭。
所以，產(chǎn)品的架構設計签钩，最考驗PM的判斷力和設計能力——體驗是設計出來的掏呼，產(chǎn)品是規(guī)劃出來的。簡潔的架構決定產(chǎn)品的調性铅檩。
但是憎夷，與“房屋”的案例不同的是，產(chǎn)品的架構不只是“結果”昧旨，而是一種迭代的過程拾给。它會隨著業(yè)務的發(fā)展而不斷優(yōu)化和調整，對一款產(chǎn)品來說兔沃，不存在一種始終靜態(tài)的架構模式蒋得。
比如電商平臺，在早期很多功能可能都不是關鍵性業(yè)務乒疏，在架構設計都可能不會考慮额衙，而是隨著業(yè)務的發(fā)展而調整。所以，必須保證產(chǎn)品架構具備一定的擴展性和成長性窍侧。比如電商平臺的banner县踢，隨著業(yè)務的發(fā)展，它能完全成長為一個獨立的強運營的業(yè)務模塊伟件。
<本文完>
關注公眾號：產(chǎn)品微言硼啤，回復“從0到1”，即可下載完整? PPT? ?
我將通過17篇文章锋爪，解密推動產(chǎn)品落地的全過程丙曙，包括產(chǎn)品的定義和設計爸业、開發(fā)過程的管理其骄，以及由此引發(fā)的系列問題，更包括在此過程中我所學到的寶貴經(jīng)驗和深刻教訓扯旷。
歡迎交流拯爽，下輯預告：
2B產(chǎn)品的架構設計實戰(zhàn)：O2O平臺的多租戶模型設計
