昨天的推文裡面有分享王師母的“幕後產品”，其中師母有講到產品資訊一章。

原文提到

“資訊架構是最前端的表現層架構，產品架構是連線業務和使用者的產品功能，業務架構是包含商業邏輯的架構。

思考的時候依次從業務架構到產品架構到資訊架構思考。”

今天發到產品遇上運營群裡，鵬哥提出了不同的意見，我覺得很有探討意義，包括我自己，過去對資訊架構、產品架構、業務架構的關係都傻傻分不清楚。

鵬哥的觀點是：

“最底層的是業務架構，中層的是產品架構，上層的是資訊架構，底層到中層我同意，因為這就是推演承接關係。

資訊架構本身是產品的一個區域性，前臺產品的展現層。它可以單獨分出章節來論述。”

鵬哥的認為資訊架構和產品架構不是並行的，資訊架構應該是產品架構的一個區域性。

由於這方面的產品資料很少，我看過關於產品分層比較經典的書是《使用者體驗五要素》，書中把產品分為五層：

分別是 表現層→框架層→結構層→範圍層→戰略層。

受到這本書的影響，我個人傾向與把業務架構、產品架構、資訊架構做並行處理，並且依次分解。

這樣分層最核心是好記！

我認為表現層、框架層、結構層統一歸類為資訊架構，範圍層對應產品架構，業務架構對應戰略層。

對於B端負責產品，從業務架構到產品架構到資訊架構，依次怎麼推演，其實楊老師有張圖最好能說明

我個人認為B端產品在抽象、複用上有天然的基因，但是C端產品，如何從業務架構、到產品架構到資訊架構推演出來，其實我是蒙逼的。

呱哥自己沒有做過C端產品，所以關於C端產品資訊架構如何做得簡潔，讓使用者感覺簡單，而且還好用，也沒有相關思路，如果你知道請留言。

B端產品如果按照上面的流程進行規劃，能提高複雜業務系統的架構能力和擴充套件性，但是這只是如果罷了。

有個讀者朋友提到

“之前出現過產品功能堆砌，然後程式碼變成屎上雕花的情況。分析了下原因，主要有兩塊：

初期業務調研不充分，業務認知不全面，導致業務建模過程中有遺漏，主要其中於業務用例層面有疏漏；

業務建模搭建的時候，沒有從頂層設計，而是從業務用例層面逐漸堆砌的，這樣也會導致後面很難擼程式碼。”

呱哥聽到屎上雕花這個四個字是又好氣又好學，特別共鳴！

呱哥之前在創業公司就是這樣，小公司對產品的考核第一要務是“快”，要什麼產品質量和架構，功能只要最快速度的能上線就行，上線改bug這才是基操。

呱哥之前按業務架構到產品架構梳理的思路做了一套系統，但是業務部門覺得太麻煩了，並且因為歷史資料問題，2個月搭建的系統說扔就扔，最後嘴碎的人還說系統不好。

沒辦法！最後用低程式碼平臺給他們做了一套表單系統，大概是帶流程的excel系統，業務部門到是欣然接受。

大部分做複雜業務系統的產品經理都是在填坑中度過，無非是前人挖了一大堆坑，或者是核心人換了又換，系統一點點改，越改到後面越沒有什麼追求了。

直到有一天來了新的高層，生怕老系統直接塌了，於是組織人力來了一次重構，並且也是一次投名狀。

可是當業務繼續發展下去，匆匆忙忙重構的系統又變成老系統，如此反覆下去。

呱哥之前做過乙方專案，當年我們就是每隔幾年要求客戶換系統，一來是為了創收，二來也是老系統實在不想改下去了，這樣人也留不住啊，工程師內心還是覺得新專案有價值。

一次標準的業務架構、產品架構、資訊架構梳理，前期還是比較費時費力，而且研發成本初期也會比較高。

但研發費錢，如果你所在的團隊拮据，還是老老實實堆功能吧，如果你恰好趕上一個大專案，那恭喜你，好好梳理清楚，別丟產品人的臉~

萬字長文，解讀“幕後產品”的核心觀點

張小龍微信十年，21個精華觀點和解讀

低程式碼，不要以比“中臺”還快的速度臭大街