編輯導語：作為產品經理，掌握結構化思維有利于后續職場工作的展開，也是產品架構設計的底層驅動力。關于產品架構設計不是一朝一夕就能夠學會的，需要積累經驗，并不斷實踐，反復練習。作者分享了產品架構設計的方法，幫助你更快達到目標。

結構化思維，是產品架構設計的底層驅動力。上篇文章講了一個觀點：產品同學職場發展的關鍵在于戰略性的制造不平衡，文章中分享了一個關于“架構設計”的案例，不少產品同學看后在微信群內反饋，說很想系統學習下架構設計。

坦白說，產品架構設計需要很多的經驗積累，尤其依賴對業務場景的深度理解、體系化的產品思維、較強的抽象能力等等，偏向于水到渠成，很難讀完一篇文章就能學會，但掌握了設計方法，再通過反復練習就能逐漸掌握。

因此，鏡同學想通過本文系統性的分享下產品架構設計的入門方法，我會通過一個產品案例幫你更好的理解產品架構設計。

當然，能力有限，本文并非適合每個產品同學，歡迎批評指正，主要是想幫助入行不久的產品同學建立對架構設計的一些認知，重點是分享一些方法論。

等你看完，你一定會有這個認知：

產品架構設計對外集中體現的是你的專家效應，尤其是對你的產品視野和格局都有很大的提升，而這對你的職場發展也極為重要，絕不是撐面子的花架子。

你知道的，在“產品大峽谷中”，鏡同學一貫愿意并擅長做這樣的輔助。

↑- 敏捷版的產品架構圖示例

先介紹下該產品案例的背景：

我們團隊目前主要在做HSE安全信息化平臺，該平臺的產品矩陣主要解決企業安全生產管理的需求，諸如“雙重預防機制”等等，目前平臺積累了近十萬企業用戶。

同時，為了提高集團各事業部的業務推進效率，我們同時也在做CRM系統，上周我們設計了一個“客戶檔案”的產品需求。

這個需求屬于客戶關系管理系統中的一個一級功能，主要是把CRM系統收集到的客戶信息，尤其是安全信息平臺所擁有的該企業的安全信息進行集中展示，用戶可以免費或付費查詢，多少有點類似于“企查查”。

這個需求是讓一個產品經理負責設計的，評審時我發現他對產品設計的深度還遠不夠，只是被動的羅列企業的信息，缺少深入的產品設計思考。

歸根結底，主要在于沒有產品架構的意識，因此，借這個案例，分享一些經驗，希望能給你帶來一些啟發。

一、回歸業務場景，找準產品定位

不僅僅是產品架構設計，任何產品設計都應該圍繞業務場景所展開，讓需求深度契合業務場景是最基礎的產品能力。

很多產品初學者，最容易犯的錯誤往往就是忽略了業務場景，反而在乎某個功能的界面交互、用戶體驗等，這是本末倒置。

產品定位清楚后，才會有具象化的北極星目標，才可被拆解量化出詳細的需求任務。要想搞清楚產品定位，可以從業務場景和功能定義來著手。比如，我們這個“客戶檔案”這個業務場景：

首先，安全行業的上下游企業在開展業務時，很多時候客戶都需要掌握某個企業的基本信息，尤其是關于安全管理的相關信息，借以評估該企業的安全管理水平如何等等。

其次，我們剛好沉淀的有客戶數據和安全數據，完成這個需求之后，用戶就可以通過該“客戶檔案”功能查看，可以查詢某個企業的基本信息，尤其是安全信息。比如，保險機構在推安責險前就需要了解企業的安全管理水平，安全管理水平高保費就可以低一些，反之就高一些，他就可以通過“客戶檔案”功能查詢。

因此，客戶檔案的功能定義便是如此：為安全行業的上下游企業，提供以安全數據為核心的一站式查詢服務，助力其業務高效發展。

二、提煉本質需求，拆解核心要點

通過業務場景和功能定義基本確定了產品的定位，接下來最重要的其實就需要提煉本質需求，拆解出來核心的需求要點。這個階段需要完成先從具象到抽象，再從抽象到具象的兩輪轉變。還以“客戶檔案”為例：

①從具象到抽象根據業務場景和功能定義，我們對客戶檔案已經有了初步具象化的認知，那么下一步就是要將需求抽象提煉，客戶檔案本質上是什么呢？重新審視需求：基于現有的客戶系統和安全平臺各個系統的基礎數據，目的是為了向用戶提供企業的基本信息查詢服務，進而設計付費查詢等增值服務。顯然，該需求是一個數據應用服務。

②從抽象到具象明確了這是一個數據應用服務，接下來就需要結合業務場景，向下拆解，再次具象化產品需求，拆解出高層級的核心功能點。比如，數據來源設計、數據查詢設計、增值服務設計（套餐配置、線上支付、訂單管理等等），這些都屬于核心的功能要點。需要說明的是，在這個階段只需梳理出核心的功能要點，不需要太深入到細節里面，只需要高層級的核心功能就行，這樣更利于全局把控或敏捷調整設計方向。

三、對照需求方法論，場景化詳細需求

首先，數據應用類需求有哪些需求方法論呢？嚴格來說，這依賴于你的產品知識積累，當然你也可以邊學邊應用，比如，我們就可以參考“數字化轉型”，一般來說，數據應用服務都需要經歷數據收集、數據治理、數據分析、數據融合幾個階段。

事實上，數據應用類的產品設計絕非一朝一夕，它在客觀上需要長期的數據沉淀，可能是數年甚至數十年，并且經過數月的打磨和馴化，再通過數小時的數據準備，最后實現秒級的數據結果。對用戶而言，他們看到的結果往往都是可視化的統計數據，這些易讀性和便捷的交互設計，都是為了能幫用戶最大限度地提高決策效率，這背后其實是一系列的數據處理邏輯。

上周我去北京參加了IBM的產品交流會，中間也有提到數字化轉型，我當時也在峽谷微信群里分享了一些現場圖片，其中就有關于數據應用的方法模型。其次，找到了方法論，就要場景化詳細需求，我們還以“客戶檔案”這個需求為例：

第一，數據收集：數據收集也就意味著要確定數據來源，客戶檔案我們初步設定有三個數據來源：

①客戶系統的企業數據；

②對接企查查的基礎數據；

③我們其他安全系統的企業安全數據。

在這里，鏡同學還特別想說一句，產品經理要牢記“數據來源”這四個字，在產品設計時反復詢問自己，這對業務邏輯的充分理解很有幫助。

第二，數據治理：數據治理意味著設置適用于收集、存儲、處理和處置數據的內部標準，即數據策略，它規定了誰可以訪問哪些數據以及哪些數據應受治理。數據治理其實很重要，比如，有些數據是沒有價值或者價值很低的，這些數據就不必要展示；有些數據涉及隱私或安全，不能夠展示；這就對我們提出了要求，我們一定要對數據進行篩選和過濾，剔除無意義的數據，保留最有價值的高效數據。

事實上，我們這個產品同學在最初設計時，直接展示了企業的生產數據，諸如“風險四色圖”、“隱患排查”的現場數據，這些數據均沒有經過治理，都是最初的原材料堆砌。所以我說，他的第一次產品設計豐富度很高，但設計的深度很淺，更多是被動的羅列數據，并沒有對數據進行充分治理，產品自主思考與設計不足。

第三，數據分析在數據治理之后要進行數據分析，這些分析要立足于當下的業務場景，說白了，治理后的生產數據是原料，是最初的生產資料，我們要想辦法加工成半成品。

那么，這個案例中“客戶檔案”的企業安全數據，我們應該如何有效分析呢？

我們首先要進行分維度的權重設計，其次要進行統計分析，諸如，哪些數據是對業務需求意義大，應該分配什么樣的權重；這些一定不是單純的羅列原始數據，因為你展示的是依托數據的客戶檔案，應該是報告性的、統計性的，一定要讓用戶最直觀的看到你的數據分析結果。

比如，通過數據分析，產品應該可以告訴用戶某個企業的安全評分是90分，統計數據大概有哪些，等等，均是直觀表達，而不應該是眾多的列表、詳情，等待用戶自己再去計算分析。

第四，數據融合。

在我看來，數據融合應該圍繞著產品價值來實現。比如，增值服務應該包括付費查詢、報告下載、導出文件、在線支付等等，這些都是具體的功能點；再比如，針對體驗性或口碑的提升，通過“客戶檔案”來提高數據變現能力，進一步提升公司的品牌影響力。

當然，鏡同學這里只是提供一個產品思路供你參考，所以也只是一部分細化的需求，像數據查詢、付費查看等等需求功能，都可以對照產品方法論，依托業務場景，從底層去構建基礎的需求功能點。

四、梳理成思維導圖

通過以上的功能梳理，我們對于需求功能點應該拆解的比較清晰了，那么下一步我們應該就是著手畫產品架構圖了。

不過，我還是建議你先梳理成思維導圖，這樣結構化更加清晰，也方便查漏補缺，這對于接下來的產品架構設計更能具象化，理解起來也更加高效。

這里思維導圖的關鍵在于結構化的拆解，要通過需求方法論、場景化的需求分類，將該產品設計分解成對應的結構層次中，這些維度是架構圖的關鍵。

比如，客戶檔案需求設計時，我們就可以把需求方法論“數據收集”、“數據治理”、“數據分析”、“數據融合”作為設計底座，從這些維度方向去進行功能詳細設計，細化成哪些功能點，這就自然而然形成了產品架構。

五、產品架構設計

接下來就要畫產品架構圖了，這里對照“思維導圖”即可快速梳理，當然，如果你可以使用VISIO、PPT或者Axure等工具設計。

最后，我覺得產品架構的顆粒度應該大一些，重點在于方向把控和核心功能點的設計，是核心業務邏輯的集中表現，不必過于細化。

而架構設計的前提在于高度契合產品定位，設計的核心在于多維度的結構化分層，從不同的維度去拆解原始需求，不斷修正，反復訓練，熟能生巧。

比如，客戶檔案的產品定位一定不是做企查查，而是依賴業務系統的差異性數據，提供垂直領域的數據服務，隨之帶來的數據權重將會在架構設計上充分體現，這也是架構設計的核心理念。

當然，本文只是一個小的產品案例拆解，方法也未必適合每個產品同學，只是希望這些敏捷的設計方法能帶給你啟發，尤其是能對初學者對產品架構的認知能提供一些淺薄的經驗參考。

最后，真的希望對你有產品啟發。

#專欄作家#

產品大峽谷，公眾號：產品大峽谷，人人都是產品經理專欄作家。七年B端產品經理，供應鏈物流與金融領域，擅長需求設計、業務指導、商業觀察等。

本文由@公眾號：產品大峽谷 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議。