需求梳理
————————
我們常常收到來自用戶（業務部門）或老板，以一句話高度概括提出的需求：“我需要對掛牌房源進行回訪，并進行判定”、“我需要一個對網站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.一個產品，只應該為解決一個（類）問題而生。如果一個產品放到了一個不合適的地方，將會為未來留下隱患。在面對各種各樣的需求時，我們應該清晰什么需求應該在什么地方（產品）解決。就像業務系統不應該存放人事數據一樣。
小結
————————
最后，分享一下在實際工作中，產品上線真正的使用者和需求提出者很可能不是同一個人，需要我們想辦法接觸到實際操作同事，了解一下他們的想法，考慮到產品中去；需求溝通初步階段，也很可能沒有業務部門的主管（有決策權）或所有干系部門參與，所以當已有初步方案，一定要找所有與產品有干系的業務部門的主管落實方案，達成共識，避免上線后才發現溝通存在問題。
