傑夫貝佐斯曾經在一次演講中提到「人們經常問我：未來10年什麼會被改變？但從來沒有人問我：未來10年，什麼不會變？」。

在一款產品裡中，架構就是那個不容易變的東西

。

產品架構是產品經理發展到一定階段都需要具備的能力，只是多年來網際網路產品一直以來都處於捨命狂奔的狀態，這種情況下產品經理往往也沒有太多的機會去鍛鍊自己的架構能力，畢竟產品架構是個細活，不像功能體驗那麼能夠被直接感知到。埋了坑不一定自己填，功能沒上線肯定是要背鍋的。然而，近年來新的app越來越少，各巨頭們都在做深耕和提效，架構這件事情開始變得越來越受到重視了，從18年底-19年突然中臺建設成為IT圈的大熱點也充分體現了這一點。

產品架構是什麼，為什麼要做架構？

架構這個詞往往代表了骨架和脈絡，是抽象模型。

產品架構就是產品的骨架和模型

。假設人體是一個產品，那麼人這個產品最粗粒度的架構就有頭、四肢、軀幹，透過骨骼支撐起來。在這個架構之上附著了肌肉、器官和面板等，構成了整個人體。在日常工作中，我們常常會聽到好幾個架構，業務架構、資訊架構和技術架構，這些和產品架構是什麼關係呢？我的理解是這樣的：

業務架構往往是為了達到業務目標（通常是商業目標）所搭建的業務體系和商業模式，比如著名的亞馬遜飛輪效應和Google搜尋的印鈔機模式。

業務架構包括且不僅限於產品，產品架構是為了更好的支撐業務架構而構建的

。

資訊架構主要是產品在結構層的一部分，通常是在互動設計階段考慮的產品給使用者呈現的產品全貌，讓使用者可以清晰快速的找到功能的方法。有些說法會把產品架構和資訊架構當成一回事，在一些2C產品裡，從資訊架構裡就能看出產品架構，如新聞資訊類的app。但實際上

資訊架構只是產品架構的一種表現形式，並不能完全代表產品架構

。

技術架構是產品架構的實現

，

並還覆蓋有其他範疇，是個獨立的大話題

。在一些偏向技術型的產品裡，產品架構和技術架構很接近，比如雲計算產品，其使用者本身就是程式設計師，所以雲計算產品的產品架構和技術架構就非常接近了。

產品架構本身也有三個層次：

獨立可交付客戶價值的業務產品。

單一產品內的模組化。

單一個模組的抽象設計，也就是功能設計的架構。

整體的關係見下圖：

好的產品架構能夠帶來哪些價值呢？借鑑雲計算產品的說法，本文這裡也提出一個三高的說法：

高可用。在多業務產品組成的產品矩陣中，每個產品可獨立交付價值，也可組合成不同的解決方案。

高可靠。在單一產品內，基於解耦化和模組化的設計，對模組類邏輯的調整，其複雜邏輯所造成的影響往往控制在模組內，模組之間依然還是透過定義好的輸入輸出進行互動。

高可擴充套件。在單一產品內，基於模組化定義好的規則，不需要事無鉅細的瞭解整個產品的所有細節邏輯就可以快速擴充套件產品功能。

由此可見，

好的產品架構是相對穩定的，在業務方向本身不發生重大變化的情況下，是可以事半功倍的支援業務發展的

。

如何做產品架構？

從具象到抽象

目前各大廠商對網際網路產品經理的要求裡往往非常注重同理心和使用者體驗，這是一個具象化的過程，在一個具體的場景裡以使用者的視角來體驗和設計產品。而做產品架構則有了不同的要求，

產品經理需要基於使用者場景找出一類需求，並且還需要考慮到背後的需求，衍生的需求。對於這些需求進行抽象和建模，找出一些通用型的解放方案去滿足他們的需求

。並且，由於B端產品的價值流和功能邏輯相對於C端產品往往要複雜很多，對於B端產品經理而言，產品架構的要求往往更高。

各層次的產品架構搭建

前面已經介紹到產品架構有三個層次，接下來具體介紹三個層次是如何做產品架構的。

1。 可獨立交付價值的產品架構

可獨立交付價值的產品架構，這類架構往往和業務是強相關的，每個產品可以獨立使用交付客戶價值，形成採購，也可以針對客戶不同場景的需求進行組合，提供綜合解決方案。雲計算產品就是最典型的例子，使用者可以在雲計算廠商官網根據自己的需求勾選一些產品，然後獨立採購和使用。以影片雲涉及到的幾類常見產品：

物件儲存。主要進行非結構化資料（檔案）的儲存。

CDN。內容分發網路，主要解決跨地域的海量使用者資源訪問速度的問題。

點播。主要是指音影片的播放問題，音影片會被轉碼成標準編碼格式，並可透過指定播放器解碼和播放。

直播。主要是實時音影片的直播，主要包括普通推流直播和實時互動直播。

對於客戶而言：

如果只需儲存海量資料，就只需要購買物件儲存即可。

服務於不同地域的大量使用者訪問，就需要使用CDN。

類似於映客這樣的直播類產品，就購買直播+CDN+物件儲存。

像抖音、愛奇藝這種完整的影片類產品，就需要有直播+點播+CDN+物件儲存。

2。 產品內的模組化

使用者在一個較複雜產品裡進行操作，其需求被滿足的整個的流程會涉及到很多功能，其中這些功能可以進行分類，同一類功能組合成一個模組。

因此一個複雜產品內部可以劃分出多個模組，每個模組負責業務流中相似的一類功能

。以淘寶為例，商家在淘寶上開店併發布商品，使用者到淘寶上搜索到商品，下單購買。這一套業務流程裡在淘寶這個超級app裡，除了人機互動的那層殼以外，產品被劃分成了以下模組。

其中每個模組雖不能單獨滿足使用者想要的商品購買的完整體驗，但可以專注的解決購買過程中一類問題。而當這些模組抽象到能夠服務淘寶以外其他的產品時，這就是中臺了。關於中臺我之前也有過分享，我的教育中臺一年實戰錄。

3。 單個模組的架構

即使是隻滿足一類需求的單模組，其在設計時也需要做好其架構。以線上考試模組為例，如果你對線上考試流程有一定的瞭解，就會大概想到整個過程。使用者進入考試、完成題目並提交，系統判分，低於60分就未透過，超過80分就是優秀。如果僅僅只是做一個滿足這個需求的線上考試系統，把細節再補充下，就可以直接出互動了。但前面我們也提到過了，產品經理在面對需求時要進行抽象，考慮到未來拓展的需求。那麼我們就需要對此模組做架構設計和抽象拆解。首先，考試的核心價值是對透過一些設計好的題目去檢驗學生對知識點的理解情況，檢驗學生的最小的功能單元並不是試卷，而是題目。一道題目就完成了知識點的考核，和使用者進行了價值交換。所以題目應該被抽象出來成為一個獨立的子模組。通常一道題目會包括了題幹、答案輸入、標準答案、判題輸出（對/錯，答案解析）等部分，而從需求擴充套件的角度來看，在不同的年齡層次以及不同的學科裡會有很多不同型別的題目，比如：

客觀題：單選、多選、判斷、填空等等

主觀題，無標準答案，一般是大題，輸入方式也有多種，有文字錄入、畫圖、拍照錄題等等

所以把題目這個結構抽象出來，有利於後期各種題型的拓展。試卷是整個系統性知識點檢驗的模組，是多個題目的組合。在題目的基礎上，試卷還需要具備一些其他的能力，包括：

組卷規則，比如隨機組卷，AB卷的能力

一些時間限制，開始作答、提交截止、答案公佈等等

並且其實試卷只是一個抽象的概念，實際上試卷可以具象化成課後作業、小測驗、考試等等多種使用形式交付給使用者。

把題目和試卷拆開成兩個模組，有利於維護和拓展。那麼這樣是否就已經拆解得足夠好了呢？實際上線上考試系統裡，題目的自動化批改是一個很重要的部分。因為題型的不同，批改的方式也有很多種：

簡單的標準答案比對

人工批改

AI自動批改，拍照上傳

接入第三方批改系統，比如一些線上程式設計的判題系統

我們也可以把批改系統抽離出來，一道題可以使用多個批改系統，一張試卷裡的每道題都可能用不同的批改系統，這樣的拓展性會更好。當然，一個好的線上考試系統實際還會有很多其他的能力拓展，如題庫、知識點標籤等等，這裡就不做過多展開了。

進行抽象建模

產品架構設計核心的抽象建模，主要涉及到：

歸納法。歸納法是在大量經驗的基礎上進行抽絲剝繭，總結到其內在規律的。

演繹法。在歸納法的基礎上基於演繹法去推測系統如何去支援可能延伸的需求，可用來驗證當前的架構設計是否合理。

UML是一個表述產品架構的好工具，上面畫考試系統架構時就是一個很簡化的UML圖，相關的文章和書籍有很多。通常來說，研發人員會比較擅長做架構設計。因為計算機專業學生在學校就必須學習設計模式和麵向物件的程式設計，其中類和物件的概念本身就是在建模和做架構。這也是我為什麼會認為好的產品經理需要懂一些技術的原因。對於產品經理而言，技術實現的細節不是重點，而以下幾點是需要著重注意的：

產品在做模組化設計時使用起來容易變得「技術化」，使用者體驗不那麼好。如何做到使用者在使用產品時的體驗是簡單且流暢的，但產品內部其實是模組化的設計，這是要在互動設計上下功夫的。

歸納法很怕遇到黑天鵝事件，所以再歸納的時候要儘量整合儘可能全的場景，特別是要做中臺產品時，難度是很高的。

所以在進行產品架構設計前，一定要儘可能全面的去了解各類典型的場景，和有經驗的人多交流。

不要做過度抽象，抽象得沒有了業務特性，就好像要解微積分時，1+1=2這個公式是不解決問題的。

在產品架構之下

產品大神俞軍負責過百度貼吧、滴滴等很多知名的軟體產品，而在他的「俞軍產品方法論」一書裡最開始對產品下了一個抽象的定義，

是企業以產品為媒介跟使用者進行價值交換

。這是一個在產品更底層邏輯裡的定義，不那麼容易懂，但卻體現了這本書裡所描述的產品方法的層次。產品這個詞在網際網路行業往往等同於軟體，在傳統行業是實體，在教培行業是課程內容，而這些都符合俞軍對產品的定義，並且書裡大量的經濟學介紹，產品方法早就已經超越了軟體了。本文簡述了產品的架構，而在產品架構之下還有很多更穩定和基礎的原理和模型。因此，一名優秀的產品經理，在自己負責的產品功能之下，還需要不斷的去深挖掘商業、產品的底層邏輯，才能不斷提升對產品的認知，構建個人更高的競爭力壁壘。

感謝看完，歡迎關注「何必多想」