結構化思維，是産品架構設計的底層驅動力。

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

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

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

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

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

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

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

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

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

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

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

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

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

1、回歸業務場景，找準産品定位。

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

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

産品定位清楚後，才會有具象化的北極星目标，才可被拆解量化出詳細的需求任務。

要想搞清楚産品定位，可以從業務場景和功能定義來着手。

比如，我們這個“客戶檔案”這個業務場景：

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

其次，我們剛好沉澱的有客戶數據和安全數據，完成這個需求之後，用戶就可以通過該“客戶檔案”功能查看，可以查詢某個企業的基本信息，尤其是安全信息。

比如，保險機構在推安責險前就需要了解企業的安全管理水平，安全管理水平高保費就可以低一些，反之就高一些，他就可以通過“客戶檔案”功能查詢。

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

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

通過業務場景和功能定義基本确定了産品的定位，接下來最重要的其實就需要提煉本質需求，拆解出來核心的需求要點。

這個階段需要完成先從具象到抽象，再從抽象到具象的兩輪轉變。

還以“客戶檔案”為例：

①從具象到抽象

根據業務場景和功能定義，我們對客戶檔案已經有了初步具象化的認知，那麼下一步就是要将需求抽象提煉，客戶檔案本質上是什麼呢？

重新審視需求：基于現有的客戶系統和安全平台各個系統的基礎數據，目的是為了向用戶提供企業的基本信息查詢服務，進而設計付費查詢等增值服務。

顯然，該需求是一個數據應用服務。

②從抽象到具象

明确了這是一個數據應用服務，接下來就需要結合業務場景，向下拆解，再次具象化産品需求，拆解出高層級的核心功能點。

比如，數據來源設計、數據查詢設計、增值服務設計（套餐配置、線上支付、訂單管理等等），這些都屬于核心的功能要點。

需要說明的是，在這個階段隻需梳理出核心的功能要點，不需要太深入到細節裡面，隻需要高層級的核心功能就行，這樣更利于全局把控或敏捷調整設計方向。

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

首先，數據應用類需求有哪些需求方法論呢？

嚴格來說，這依賴于你的産品知識積累，當然你也可以邊學邊應用，比如，我們就可以參考“數字化轉型”，一般來說，數據應用服務都需要經曆數據收集、數據治理、數據分析、數據融合幾個階段。

事實上，數據應用類的産品設計絕非一朝一夕，它在客觀上需要長期的數據沉澱，可能是數年甚至數十年，并且經過數月的打磨和馴化，再通過數小時的數據準備，最後實現秒級的數據結果。

對用戶而言，他們看到的結果往往都是可視化的統計數據，這些易讀性和便捷的交互設計，都是為了能幫用戶最大限度地提高決策效率，這背後其實是一系列的數據處理邏輯。

上周我去北京參加了IBM的産品交流會，中間也有提到數字化轉型，我當時也在峽谷微信群裡分享了一些現場圖片，其中就有關于數據應用的方法模型。

其次，找到了方法論，就要場景化詳細需求，我們還以“客戶檔案”這個需求為例：

第一，數據收集：

數據收集也就意味着要确定數據來源，客戶檔案我們初步設定有三個數據來源：①客戶系統的企業數據；②對接企查查的基礎數據；③我們其他安全系統的企業安全數據。

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

第二，數據治理：

數據治理意味着設置适用于收集、存儲、處理和處置數據的内部标準，即數據策略，它規定了誰可以訪問哪些數據以及哪些數據應受治理。

數據治理其實很重要，比如，有些數據是沒有價值或者價值很低的，這些數據就不必要展示；有些數據涉及隐私或安全，不能夠展示；

這就對我們提出了要求，我們一定要對數據進行篩選和過濾，剔除無意義的數據，保留最有價值的高效數據。

事實上，我們這個産品同學在最初設計時，直接展示了企業的生産數據，諸如“風險四色圖”、“隐患排查”的現場數據，這些數據均沒有經過治理，都是最初的原材料堆砌。

所以我說，他的第一次産品設計豐富度很高，但設計的深度很淺，更多是被動的羅列數據，并沒有對數據進行充分治理，産品自主思考與設計不足。

第三，數據分析

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

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

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

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

第四，數據融合

在我看來，數據融合應該圍繞着産品價值來實現。

比如，增值服務應該包括付費查詢、報告下載、導出文件、在線支付等等，這些都是具體的功能點；

再比如，針對體驗性或口碑的提升，通過“客戶檔案”來提高數據變現能力，進一步提升公司的品牌影響力。

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

4、梳理成思維導圖

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

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

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

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

5、産品架構設計

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

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

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

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

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

作者 | 東瓶西鏡 七年産品總監。

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