在工作中，我們經常會遇到兩類性格特點比較突出的產品經理：

一類是偏業務型的，他們長期深入業務一線，有極強的業務理解能力，對業務的思考和價值預判都非常深入，但在做需求時，很容易和研發產生沖突，因為他們總是站在業務視角，無視系統的實現和擴展。

還有一類是偏系統型的，比如很多做saas和中臺的產品，他們有極強的邏輯思維和系統設計能力，但是太偏系統能力建設，離業務較遠，設計出來的產品總是不能很好的滿足業務訴求，導致業務投訴說系統不好用。

很明顯，這兩類都很難稱得上合格的產品經理，在木筆看來，優秀的產品經理一定是軟硬技能兼修的，硬技能包含業務能力和系統能力，軟技能包含溝通能力、協調能力、傾聽能力、同理心等，我們要不斷的學習和修煉，在任何一個方面都不能有太明顯的短板，否則，總有一天，我們會在自己最短板的地方掉進坑里。

▲優秀的產品經理技能

無論是擅長業務理解和運營能力的業務能力，還是擅長需求分析和系統設計的系統能力，就像天平的兩端，都是產品經理必備的硬技能，特別在B端領域，越往高處走，這兩項能力越缺一不可。理解業務，才能夠更好的支持業務，創造價值，熟悉系統，才能夠知道哪些可為，哪些不可為，兩項能力結合起來，才能夠實現整體最優，走的更遠。

本篇文章，我們重點聊一聊系統設計能力里的產品架構。很多朋友聽到“架構”這個詞，都感覺特別虛無縹緲，這種感覺是正常的，因為它看不見摸不著，更多傳遞的是一種產品設計思想，但這項思想卻非常重要，它能夠讓我們在業務支持和系統擴展這兩個不同的方向上找到平衡點，讓我們既能夠很好的支持業務，也能夠保證系統的完整性。

要理解產品架構，我們從一個經典的童話故事開始說起：《三只小豬的故事》…...

01 三只小豬的故事

森林里住著三只小豬，它們都想為自己蓋一間漂亮的房子。

豬大哥比較懶，從地里找來了很多茅草，為自己鋪了一間茅草房，兩天就完工了。

豬二哥將門前的樹砍下，用木頭隨便搭了一間木頭房子，一個星期也完工了。

只有豬小弟耐心的從山腳下搬來很多磚，然后開始挖地基、建地平、砌墻，然后精心布置，足足花了三個月，才為自己蓋起了一間漂亮的磚房子。

這一天，豬小弟正在睡覺，突然聽到豬大哥和豬二哥在門外急匆匆的敲門。原來，森林里來了一只大灰狼，想要找食物吃，它先找到了豬大哥的茅草房子，輕輕一吹，房子就倒了。之后它又找到豬二哥的木頭房子，使勁一撞，房子也倒了，兩只小豬只好逃到豬小弟的磚房子里求救。

大灰狼也跟著來了，在門外使勁撞豬小弟的磚房子，把頭上都撞的滿頭是包，房子卻紋絲不動。大灰狼想從煙囪里鉆進去，結果掉進了三只小豬燒滿開水的鍋里，只好灰溜溜的逃走了。

豬大哥和豬二哥這回終于知道不能偷工減料了。

后來，在豬小弟的邀請下，三只小豬把屋頂稍加改造，在上面加蓋了兩層，變成了三層小樓，從此愉快的生活在了一起…...

02 什么是產品架構？

故事講完了，咱們不是為了講童話，故事的寓意就不說了，重點聊聊為什么豬大哥和豬二哥的房子這么不結實，而豬小弟的磚房子卻堅如磐石，還能改造成三層小樓呢？

答案就在房子的結構上，豬大哥和豬二哥的房子雖然建的很快，但基本就是把茅草和木頭堆砌一下，就蓋成了，這樣的房子沒有鞏固的框架結構，稍微遇到大風和大力就倒塌了。而豬小弟的房子在地平下有很厚的地基，地面還有平穩的地平和能承重的主體結構，這樣的結構足夠牢固，任憑大灰狼撞破了頭，也穩如磐石。

同時，豬小弟的房子稍加改造就從一層變成了三層小樓，也是源自其牢固的基礎和堅實的主體結構，做擴展并不動根基，所以才能輕松的完成改造，收留兩位哥哥。

▲豬小弟的房子結構

了解完房子的結構，我們回到系統架構的問題上來，系統架構和蓋房子的原理也是一樣的，系統架構就是系統的脈絡和結構，架構設計就是梳理出系統的地基(底層核心邏輯）和主體結構（系統主體結構），并在此基礎上設計和裝修（搭建業務需要的功能和流程）。

好的系統架構就像豬小弟的房子一樣，結構清晰、穩定牢固，支持在主體結構上靈活擴展（一層改三層），不好的架構就像豬大哥和豬二哥的房子一樣，只是功能的堆砌，看起來能滿足當前的訴求，但不成體系，稍微有點外部變化影響，就會崩塌，只能重建，更不要說擴展性了。

根據設計分工的不同，系統架構又分為產品架構和技術架構，通常產品經理負責產品架構，技術架構師負責技術架構，二者的關系如下圖所示：

▲產品架構與技術架構

產品架構是在做產品方案設計的過程中產生的，主要是對系統進行合理的模塊劃分，包含系統主要分哪幾大模塊，哪些是底層支撐，哪些是上層建設，哪些是主干，哪些是分支，軟硬件如何交互等。

技術架構則是在架構師接到系統需求以后，對系統的實現進行技術選型和設計，包含如何進行庫表設計、使用什么技術框架和協議、如何劃分技術域等。

產品架構的產生過程是產品經理在接到業務需求以后，對需求進行分析，設計出系統的核心功能，然后再對這些功能進行抽象、分組，從而歸納出系統的架構，是一個先具象再抽象的過程。而技術架構是在接到產品需求以后會先開始設計架構方案，然后根據架構方案進入代碼開發階段，最終實現系統功能，是先抽象再具象的過程。

03 壞產品架構與好產品架構

好的架構堅韌靈活，擴展性好，壞的架構脆弱雜亂，問題不斷。很多系統的設計，金玉其外，從頁面和功能等外表看不出來好壞，但在實際業務運轉過程中，會隨著業務量級和復雜性的增加就慢慢體現出來優劣了。

在缺乏架構的系統設計中，通常表現為功能羅列、沒有主次、相互耦合：

一）功能羅列：系統功能完全是為了應付業務需求而拼湊到一起的，沒有規劃，沒有層級。

二）沒有主次：區分不出來核心邏輯和非核心邏輯，只為一味的滿足業務，而忽略了系統內部的升級成本。

三）相互耦合：不該耦合到一起的功能相互交織，揉到一起，相互約束，牽一發而動全身。

講個小A的故事來一起感受一下架構的魔力。

在倉儲系統中，入庫、出庫和庫內作業是倉儲的三大類業務，每個業務都要處理自己的業務邏輯和加減庫存，產品經理小A在設計系統時，將入庫、出庫和庫內模塊分開設計，各自處理自己的業務和庫存。但由于庫存是一個整體，三大業務之間在加減庫存時總是相互沖突，導致系統上線后庫存一直不平。

同時，小A將入庫、出庫和庫內的作業指令設計到了一個功能里，這樣帶來的問題是一個系統功能里要兼容不同業務下的不同邏輯，邏輯復雜不說，耦合性還高，經常因為A業務的調整導致B業務也出問題。另外，在部分頁面上，負責入庫、出庫和庫內的倉庫人員要在一個頁面過濾自己負責的單據，再進行操作，經常把其它業務的單據給誤操作了，現場痛苦不已，小A更加痛不欲生。

▲沒有架構的系統設計

而在一個好的產品架構里，系統是分層而立的，哪些功能是核心主體，哪些功能是外圍分支，一目了然。以木筆的經驗，產品架構從里往外，可分成底層邏輯、核心業務邏輯和非核心邏輯三部分：

一）底層邏輯：這是系統的最底層的地基建設，承接的是很多業務都公用的底層邏輯，一旦調整，影響面較廣，所以應該從場景中剝離出來，不過多的參與業務邏輯處理，保證它的穩定性。比如倉的庫存處理、中央庫存的分倉、售后的賠付退款、促銷系統的發券等；

二）核心業務邏輯：依附在底層邏輯之上，處理與業務相關的主干流程及流程涉及的單據、狀態變更等，調整后會對當前業務產生較大的影響，但不會影響其它業務，在設計系統時，核心業務要盡量保持獨立性，避免和其它業務交織到一起，以免相互影響，同時，也要盡量保證主干流程的穩定性，不要輕易調整。比如入庫流程、出庫流程、售后退款、維修流程等；

三）非核心邏輯：其它不對業務主干產生影響的非核心邏輯、輔助流程、工具等，在核心業務邏輯的基礎上，可根據業務需求靈活調整。如增加設備、自動化執行、批量操作、記錄日志等。

需要強調一點的是，核心業務并不等于核心邏輯，很多功能對業務很核心很重要，但在架構里，只是一個非核心的邏輯，二者是兩個維度的劃分，并不矛盾。

▲分層設計的產品架構

繼續小A的故事。

正在小A痛不欲生的時候，救星老L入職了，經過一番調研和分析后，老L開始對倉儲系統的架構進行梳理，只做了兩件事，所有的問題就迎刃而解了：

一是將庫存的處理獨立出來作為底層邏輯，并抽象出加庫存和減庫存兩個服務，這兩個服務只做庫存的加減和事務處理，不涉及任何業務，所有庫存變動的場景都必須調用庫存服務，通過庫存事務處理來保證庫存的準確性；

二是把入庫、出庫和庫內業務按照場景拆分為不同的模塊，并設計成不同的菜單，各業務之間相互獨立，互不干擾。如此一來，現場再也沒有出現過誤操作的情況了，而且當某個業務接到新需求需要升級時，也不會影響其它業務。

經過1個多月的調整，倉儲系統終于穩定下來，再也沒有出現過大問題了，這就是產品架構的魔力。

04 產品架構設計9字心法

通過前面的故事，相信沒人會懷疑產品架構的重要性了，產品架構設計的目標有兩個：結構清晰、通用擴展。

結構清晰：將復雜的業務進行分類，并區分出主次，讓系統的結構更加清晰。

通用擴展：將重要的核心邏輯設計的盡量通用，減少業務邏輯的干擾，以便保證其穩定性，后續也能接入更多的業務場景。

如何設計產品架構呢？木筆總結了一個9字心法：列場景、提主干、附功能。

（一）列場景。在需求調研和分析的過程中，盡可能全的將所有業務場景都羅列出來，比如倉庫系統包含入庫、出庫、庫內流程，入庫流程又包含收貨—驗收—上架幾個環節，在上架環節需要加庫存，這些都是場景。

（二）提主干。把場景進行分類，找到各個場景都公用的邏輯，抽象成公共模塊，并剝離出業務特色，變成底層邏輯；然后對每個業務進行設計，剝離出業務的核心流程和非核心邏輯。這樣一來，系統就被分成了底層邏輯、業務核心邏輯和非核心邏輯三層了。

比如在倉儲系統中，商品、貨位基礎數據，以及庫存處理是所有業務都公用的，這些功能就是系統的底層邏輯；入庫、出庫、庫內這幾大流程又各自都有自己的單據、節點和狀態，這是每個業務的核心邏輯。底層邏輯和業務核心邏輯就像房子的主體結構和承重墻，也像樹干和樹枝一樣，構成了系統的主干結構。

（三）附功能。按照梳理出的系統結構對場景和功能進行劃分，將業務核心邏輯附到底層邏輯上，再將非核心邏輯附到業務核心邏輯上，就像拼積木一樣，便能按照產品架構實現所有系統功能。

比如在梳理出倉儲的基礎數據和庫存處理等核心邏輯后，將入庫業務嫁接到基礎數據和庫存處理上，然后在入庫業務基礎之上衍生的其它功能如收貨信息錄入、上架操作等，便是非核心邏輯了，這些功能雖然是業務最常用的，但因為不涉及核心邏輯，所以可以跟隨業務需求隨意調整，就算推倒重來也影響不大。

▲如何設計產品架構

以下是按照9字心法設計的倉儲系統產品架構：最底層是所有業務公用的基礎數據，第二層是在基礎數據之上設立的庫存處理和策略配置，第三層是在庫存和策略之上開展的入庫、出庫、庫內業務和異常處理功能，最上層是輔助進銷存業務開展而設立的人工作業模式和設備作業模式。

▲倉儲系統產品架構

如何驗證一個產品架構是不是好的產品架構呢？木筆給幾個評判標準供參考：

（一）主次分明。好的架構有很清晰的結構，底層邏輯、核心邏輯和非核心邏輯有很好的定位，不是混在一起的。

  (二）邏輯通暢。好的架構要支持業務流程連貫，除了一些必要的強校驗外，應極少出現分支和卡頓。對于那些影響主流程通暢的子流程，應該剝離出去。

（三）邊界清晰。不同業務模塊之間相互獨立，保證模塊內高內聚，模塊間低耦合。

（四）擴展性好。好的架構一定是面向未來的，在保證主體結構穩定的前提下，能夠兼容更多業務場景以較小的成本接入。

（五）持續迭代。好的架構不是一成不變的，而是可以隨著業務的迭代節奏不斷進化的，時刻保持與業務的同步性。

做系統設計時，業務理解固然很重要，但架構設計也同樣不可或缺，業務理解幫我們貼合業務創造價值，架構設計幫我們分清主次走得更遠。當我們從功能實現轉為梳理產品架構的時候，就是產品能力躍遷的時候了，一起加油吧。