在B端產品的工作當中，常常要與不同的業務部門打交道，他們的角色眾多、訴求各有差異，造就了後臺業務產品的複雜性，下面介紹一下我在國內排名第一的房產中介公司工作以來總結的一套產品方法論。

需求梳理

我們常常收到來自使用者（業務部門）或老闆，以一句話高度概括提出的需求：“我需要對掛牌房源進行回訪，並進行判定”、“我需要一個對網站400來電錄音進行打分的平臺”……因此，需要一個框架有序、完整的與使用者一起梳理需求十分有必要。

需求梳理框架：使用者-場景-路徑

使用者

在B端產品中，使用者即業務部門或前線業務人員的角色。

在面對分工精細的企業內部，我們可以從“ 現在是怎樣的？” 去入手瞭解當前的部門架構、崗位分工。

因為所有業務線，無論它現在如何低效或我們看來是多餘的，但也是多年來一直優化，被證實有效的才得以保留和運作至今。所以即使新產品基於新流程、新技術，可以節省某些職能角色的參與，也只有從瞭解現有架構開始，理解現時為何這樣配置，每個崗位有何目的和作用，才不至於在產品上線後，才發現一些業務部門隱藏的需求。

這一步，我們的目標是瞭解有哪些人（角色），會參與到這個產品流程中。

場景

即：在什麼場景下，有什麼需求，要完成什麼目標。把每個角色的場景、需求、目標都一一列出來，然後把需求打碎、重組，即可定義出相關的功能。

這一步可以結合思維導圖，採用發散思維方式，與使用者一起完全窮盡各種可能發生的情況，再結合業務的考慮，提出對應的解決辦法，與使用者敲定。

如何窮盡所有可能？這裡有個小技巧： 把問題拆解為一個個小問題，對每個小問題追問下去，直至無解、清楚為止。

舉個例子：400來電錄音檢核平臺的需求：來電錄音採用輪循機制隨機分配給AE（Agent Energize，經紀賦能師）檢核，以提升經紀人接聽來電的服務水準和規範。

資料來源：

1. AE的職位架構取自哪裡？K3人事系統？雖然從常識可以知道人事資料來源於人事系統，但剛好本例是特例，由於歷史原因，受限於K3系統的限制，“AE”這個的職位資料來源二手業務系統。所以如果新接觸一個新角色，特別在歷史悠久的公司，最好先與開發溝通，確定資料的來源，甚至如果當前不存在此架構資料，如何進一步處理。
2. 錄音來自於哪裡？本例中，錄音來自於北京總部每天會發送前一條的錄音資料檔案給我們，我們作為分公司再進一步匯入處理。這裡涉及到兩地技術對接、協商處理。

邊界情況：

1. 已分配錄音後，AE離職，錄音無人檢核，是否需要重新分配？
2. 假如離職錄音重新分配，錄音是否有時效性，比如只分配當月未檢核的錄音？否則將會影響到報表週期的資料
3. 如果總部沒有按照約定，在特定試點發送前一天錄音給我們，後備方案怎麼處理？
4. ……

以上只是簡單舉例，實際情況要進行更多的考慮。

路徑

即：完成任務所需的流程，用流程把功能串聯起來。

這一步推薦使用泳道圖，清晰表達角色之間的任務流程，和相互的關聯。

如果專案比較複雜，可以用流程圖再進一步詳細描述各個子流程。

這裡稍微提升一下思維高度： 不論何種形式的圖表，目的是與業務部門和團隊成員溝通，所以選擇的圖表只要大家看得明白，實現高效溝通即可。

通過以上三個需求分析框架，我們已經能夠清晰與使用者溝通，瞭解使用者所需的需求，並通過進一步發掘、整合設想出產品的框架和主要功能。

確定系統資訊流、相關主體

系統資訊流

B端的業務系統，往往需要與很多其他基礎服務（OA辦公、人事、財務、通訊等）、不同業務系統間的對接。因為這些對接往往決定了新產品的資料來源、實現限制和介面規範，在動手寫需求文件之前，不妨先與開發交流一下各關聯絡統的對接要求，以便可以寫出更規範完整的需求文件。當然，一些基礎性服務，如果團隊間默契已經形成，可以節省這個步驟。

相關主體

在業務上，除了在產品內部的操作，還有很多是線下或對外部系統的操作。如何簡單表述出參與者完整的業務活動？這裡推薦使用——UML用例圖。

用例圖有助於討論和傳達以下內容：

1. 您的系統或應用程式與人、組織或外部系統進行互動的幾種方案。
2. 它幫助參與者實現的目標。
3. 系統的範圍。

舉個例子。網籤預約系統專案：接案專員在網籤預約系統（內部產品）收到經紀人的預約案件後，需要在房管局的“存量房預簽約系統”進行相關操作，把匯出的成交合同上傳到網籤預約系統（內部產品）以繼續後續的確認簽約流程。

這個案例涉及幾個主體：

1. 經紀人
2. 接案專員
3. 房管局的“存量房預簽約系統”
4. 本產品：網籤預約系統

使用用例圖即可清晰表達劃分以上主體及其主要功能（任務），最大好處是以最簡潔、高度概括的外部視角與使用者（業務部門）溝通確認需求，確保對複雜的業務過程理解一致。

專案範圍

我把專案範圍歸納為三種邊界：需求邊界、行業邊界、系統邊界。

需求邊界

需求理應沒有邊界，但如果要實現需求，則存在資源等各種客觀原因，使需求有了優先順序——即版本規劃。我們可以根據B端產品的特性，結合業務的迫切程度，劃定優先順序的判定標準，如果你的公司習慣專案時間由老闆拍板，我這裡建議其中一種辦法是：在產品初步策劃階段，拓寬思路，儘可能規劃完整的產品，向老闆、決策者展現完整的目標成果。然後，列出各種功能的建議優先順序和所耗資源，提請老闆根據時間期限決定實現的優先順序，定下此版本的專案範圍，即交給老闆做減法。

行業邊界

如果我們設計的是會計、人力資源等專有行業的系統，我們就不能天馬行空，系統的規則離不開行業的法律法規，比如會計就像一個正方形，法律法規已經設好邊界，我們所做的是在邊界內設計；人力資源的HRBP系統則像一個水桶，半開放式，有其自由性。所以我們設計產品的時候，第一是要深入發掘公司業務的需求，理解業務，通過產品、技術去提升公司效益；第二是熟悉行業相關法律法規，清晰產品的底線要求。為什麼自己也要了解？因為業務人員很可能會認為一件在TA看來不言而喻的事情，而你作為行業外的設計者，根本不知道，產生需求盲點，直至產品上線才發現問題。

系統邊界

一個產品，只應該為解決一個（類）問題而生。我們最常接觸的業務系統，雖然業務多變，形態千變萬化，每間公司有其特性，但只有找準主心骨，產品才可以有序健康地發展，我們可以用魚骨型去比喻它。沒有規劃的系統，將會越來越變得臃腫難用，或會有一天系統不足以支撐而崩潰。要避免這個問題，有幾點心得：

1. 用程式上解耦的思維 ，把業務按事件拆分成各自獨立的小產品，特別是把共性的基礎業務部分獨立出來，其他程式需要時其能力時呼叫介面即可。當一個業務變化時，不會令其他產品受到牽連，靈活性高。
2. 拒絕不合理需求 。雖然B端產品是很多是基於業務部門提出的“需求”，但使用者往往習慣以自己的見解提出他們認為合適的解決方案，我們作為專業的產品設計者，應該學會分辨是需求還是解決方案，發覺出使用者真正的需求，從全域性考慮，整合需求，提出更好的解決方案。
3. 一個產品，只應該為解決一個（類）問題而生。 如果一個產品放到了一個不合適的地方，將會為未來留下隱患。在面對各種各樣的需求時，我們應該清晰什麼需求應該在什麼地方（產品）解決。就像業務系統不應該存放人事資料一樣。

小結

最後，分享一下在實際工作中，產品上線真正的使用者和需求提出者很可能不是同一個人，需要我們想辦法接觸到實際操作同事，瞭解一下他們的想法，考慮到產品中去；需求溝通初步階段，也很可能沒有業務部門的主管（有決策權）或所有干係部門參與，所以當已有初步方案，一定要找所有與產品有干係的業務部門的主管落實方案，達成共識，避免上線後才發現溝通存在問題。