産品架構圖是每個産品線經理日常都需要畫的一張圖，屬于産品經理必學基本功。

今天重點和大家聊聊怎麼畫産品架構圖，以及為什麼産品架構圖畫的挺好，但是系統還是做的很爛的問題。

基本功這玩意，沒人會在意，除非是害怕跳槽，面試官問到這個知識點，才有人去學基本功。

沒辦法，大部分産品經理都是 to money 導向，什麼值錢咱學什麼。

最近發現有人不會畫産品架構圖，甚至連什麼時候畫産品架構圖還分不清。

比如看我的一位讀者朋友的回答怎麼做産品規劃：

"那我鬥膽給大佬補充一下規劃後執行的部分

1、産品架構出來後，還需要梳理一下業務流程

2、根據産品架構 業務流程，整理功能清單，用剝洋蔥理論，一層層細化功能點及相關的邏輯限制

3、梳理功能流程以及數據流向，相關産出文件為功能流程圖、時序圖

4、動手畫原型，寫需求文檔

6、進入研發（到項目管理階段），寫産品使用手冊/用戶手冊"

首先鼓勵他能夠有自己的思考,并且愛發言，但是他第一點其實描述是有問題的，正确的流程應該是先梳理業務流程，出業務架構圖，再畫産品架構圖。

最近還遇到一個問題，有些人産品架構圖和系統架構圖傻傻分不清的情況。

其實這也好區分隻要記住系統架構圖大多是研發參與畫的，系統架構圖是研發為了梳理好内部各個系統的關系。

如果産品經理要梳理好系統各個功能模塊之前的關系，本質都是各自崗位希望一張圖能把系統内部的層次和連接關系講清楚。

隻不過一個是産品角度，一個是技術角度。

當然很多産品經理也懶得畫産品架構圖，于是乎拿系統架構圖來當産品架構圖來用。

也有很多人的産品架構圖畫着畫着就變成了系統架構圖和産品架構圖的混血兒。

畫出來的圖也好像這麼回事，不細看你還真挑不出他們的毛病。

那麼産品架構圖具體要怎麼畫呢?

第一個是抽象思想，将業務流程圖中所有功能類似或者範圍有包含關系的機制/功能放在一起，以模塊化的形式形成一張簡單的矩陣圖。

第二是将明顯是同一個功能的模塊放在同一層級，得到一個基礎的産品框架。

第三是對産品架構進行分層，一般是分為用戶感知層、功能模塊層、數據層、基礎配置層

第四是明确各個功能模塊的邊界問題，比如信息傳遞相鄰的模塊直接可以放到一起。

最後是明确信息流的交互方式，比如最底層向上傳遞信息，最上層收集信息反饋到底層。

這樣一張産品架構圖就出來了。

網絡截圖

那麼有了産品架構圖，産品系統就能做的很牛皮嗎？

答案是否定的，特别是互聯網産品小步快跑的情況，初期系統都是非常簡單的，無非是增删改查的合集。

而不管是産品架構還是技術架構圖都隻是個大概意思，很多隻是一個樣子貨，與實際技術實現差異很大。

一來是因為整個軟件系統的關系特别複雜，很難展示很多細節，大部分是系統的簡化，同時在彙報和對外展示的時候，也需要簡潔，所以隻要畫的關系明白就可以。

于是乎變成了你畫你的，實際系統開發還是怎麼簡單怎麼來，所以疊代多了，屎上雕花成了必然現象。

除非業務穩定之後，那麼有機會對系統進行重構，那麼這時候的系統可以考慮好好設計一下産品架構。

現實情況是大部分互聯網公司是産品概念一出來，就開始發pr稿，系統要求一個月就開發好，其實很難有抽象的思想在裡面。

如果最開始就沒有做好分模塊去設計系統，最後的結局就是系統在最後冗餘字段非常多，後接手的産品經理看不懂前人做的系統。

當要做一個新功能的時候，由于不理解前人的業務，或者前人設計的系統沒有擴展性，最後是相似的業務，做了兩套不同的功能。

建議産品總監除了要做産品規劃，也要是一個合格的産品架構師，去整合不同産品經理的需求，以及不同業務的需求，對其進行抽象複用。

這樣才能談得上有産品架構。

具備産品架構師能力的人需要對整體業務非常了解，能夠把業務進行很好的抽象能力，這需要和細節以及業務不斷的死磕。

其實要做到也不難，為什麼沒人想去做呢？

現實生活中是大部分業務系統其實根本不care産品架構。

隻要系統能跑就行，大部分公司的業務指标考核大于系統指标。

所以規劃是一碼事，實際産品設計又是另外一碼事。

根本原因還是資源問題，資源決定了系統的好壞，資源好造汽車也能給你造車來。

作者：陳雪濤 分享産品技能和産品思維幹貨，廣交産品好友，促進産品經理文化普及。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!