從定義來看，需求分析階段包括：找到用戶-採集用戶需求-深入分析需求-需求工程化表達。我們以B端產品的CRM系統為例，在需求分析階段，產品經理的工作主要包括哪些？
B端產品種類繁多，大體分為對外標準型產品（如釘釘、標準雲服務、身份認證接口服務等）和半（全）定製化開髮型產品（如ERP、CRM、進銷存等協助企業進行人、財、物管理的系統），兩者從工作流程、產品設計方面有較大差異，為避免歧義，本文所述的B端產品主要指後者。
消費級產品普遍是先有產品，才會吸引用戶，帶來收入。因此C端產品經理在開發一款產品前，要考慮清楚產品的商業模式，包括產品的目標用戶的需求及使用場景，推廣模式及產品的盈利模式，調研市場空間及競品情況，避免開發出沒有市場的產品。
而B端產品與消費級產品不同，B端產品會基於一些通用的組件，根據客戶特有的需求再定製化開發一部分功能，此類產品一般是先簽署了訂單合同，再進行產品設計。產品經理此時可以不用考慮產品的商業模式，包括推廣模式、盈利模式、市場空間等因素，可以直接進入具體的項目執行狀態。
因此，在商業模式分析方面，B端C端就已經有所不同，C端產品商業模式分析是重要一環，決定產品成敗，而B端卻無需執行商業模式分析步驟，直接進入需求分析階段。
需求分析百科定義：是開發人員經過深入細緻的調研和分析，準確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉化為完整的需求定義，從而確定系統必須做什麼的過程。
從定義來看，需求分析階段包括：找到用戶-採集用戶需求-深入分析需求-需求工程化表達。我們以B端產品的CRM系統為例，在需求分析階段，產品經理的工作主要包括：
- 明確干係人；
- 需求採集；
- 深入分析需求；
- 需求整理；
- 軟件設計。
一、明確干係人
C端產品經理經常談及明確目標用戶、用戶細分、用戶畫像等詞彙，在B端產品中，明確干係人工作與C端產品的用戶細分工作相似，但在B端產品中干係人又不僅是系統的用戶。
1. 干係人種類
干係人主要包括：出資者、使用者、評價者。
出資者通常不是產品經理來搞定，由銷售人員或企業高管來直接對接，出資者在實際執行中不會直接向產品經理提需求，而是經由銷售人員或企業高管來轉達需求。通常出資者如果有需求的話，也都是定性需求，如系統可以提升業務效率、系統安全性應該有保障等，很少會出現具體的、定量的需求。
使用者同C端產品的用戶類似，是未來會直接、間接使用系統的人，此處採用的描述是系統而不是軟件，因為如果產品採用私有化部署的方式，干係人中不僅會包含軟件的使用者，還會包含系統的運維人員，運維人員會提出一些系統的部署、維護方面需求。
評價者主要指會提出一些驗收標準但又不使用系統的人，如法務、採購、財務等部門人員，有時他們還會具有一票否決權。
2. 干係人細分
對上述三類干係人，進行干係人細分，細分的方式通常不像C端那樣花俏，通過需求、用戶行為、態度、價值觀等角度進行用戶細分，B端的干係人細分方式一般是通過崗位來細分，如使用者中，銷售經理、銷售主管、運維人員等。
二、需求採集
C端產品的需求大部分來源於如下途徑：競品分析、用戶訪談、用戶行為觀察、問券調查、用戶反饋、可用性測試、數據分析，其中一些需求採集途徑和B端產品是通用的，如用戶訪談、問券調查，但也存在不適宜用到B端產品中的需求採集途徑。
例如C端產品利用數據分析來進行用戶的需求採集，在B端產品中，軟件開發公司有時是拿不到數據的（如私有化部署的系統），沒有辦法去進行數據層面的剖析。另外更重要的原因是數據分析花費的人力、時間成本較高，多數情況下，系統驗收完畢之後，首款已到賬，此時已沒有動力去幫客戶進行高成本的數據分析，只有客戶提出系統更改需求後才會去進行版本迭代。
再例如競品分析，B端產品的競品輕易情況下是試用不到的，即使通過某種途徑試用了競品，不同客戶之間的需求也存在差異，B端產品中，通過模仿競品來設計產品是輕易走不通的。
B端需求採集途徑
B端產品的需求採集途徑主要包括：干係人訪談、問券調查、業務體驗、原型演示、中期演示等。
干係人訪談配以問券調查是需求採集的主要途徑，可以是一對一的聊，有時也會採用需求調研會的方式來進行。
業務體驗是高時間成本的方法，但也是最好的方法，如果可以把產品經理置於業務人員的角度去體驗一段時間，一個優秀的產品經理是完全可以培養出業務人員的用戶視角，否則單靠想象讓產品經理具備B端業務人員的用戶思維，是一個高難度的事情。
原型演示不容忽略，設計好原型後讓干係人進行確定，避免開發出的產品與干係人設想的不符。如果有條件可以採用高保真原型，高保真原型可以讓干係人進行可用性測試，若只採用線框圖就讓干係人來體驗，在心理層面上，體驗時的重視程度會有所降低。
很多項目在開發完成之前是有中期演示的，中期演示一來可以讓干係人確保開發進度是如期進行中，二來也對產品功能的偏差可以做出及時調整。中期演示後需要做需求變更是一件高概率事件，干係人在項目開始時往往想不全的全部的需求點，在經歷時間的發酵後，在中期演示後會進行添補。
三、深入分析需求
深入分析需求是對干係人的意圖不斷揭示和判斷的過程，雖然是B端產品，但干係人也是真實的實體個人，此時和做C端產品的需求分析類似，用戶在需求採集階段只會告訴你what（即表達他的需求是什麼），有時還會告訴你他所設想的how（即設計方案或解決方案），而不會主動告訴你why（即需求的產生原因是什麼）。
產品經理的本能就是在需求採集和產品設計時，獲得what後可以繼續深挖why，進而得出how。在此C端產品的需求分析方法論在B端產品中是可以直接借鑒的，如可以運用蘇傑的“Y模型”，“5W2H分析法”等需求分析方法論，即如何通過what導出how。
由於B端行業差異很大，每個行業、崗位的用戶思維都不是輕易具備的，很難站在干係人的角度思考，所以對於B端產品經理來說，學習對方工作領域的知識，理解業務極其重要，需要具備將對方的語言工程化，將抽象的需求具體化的能力。這一點說起容易，做到還是有一定難度的，可能某個B端5年的產品經理，跨行業後都沒有該行業內1年的產品助理更加懂行，所以通用的需求分析方法論很重要，深入行業也很重要。
控制需求
C端產品講究按需求的優先級排列，排列方式如KANO模型的基本型、期望型、興奮型、無差異型、反向型需求，或四象限法則的緊急重要、緊急不重要、不緊急重要、不緊急不重要。到了B端就沒那麼多排列方式了，只有一期，二期，三期可以進行爭取，和客戶去提什麼是MVP原則，通通不起作用，想把客戶的需求安排滯後，銷售經理都不會同意。
B端產品在需求控制方面，需要做到識別錯誤需求和識別超出範圍需求。錯誤的需求包括技術上無法實現的、邏輯不符的、無實際意義的需求內容，避免被干係人的天方夜譚帶跑偏。在判斷需求是否超出範圍，需要先嚴格執行合同或者標書中的標準，但有時合同簽署的會比較空泛，就需要在需求採集階段先同客戶共同明確項目目標，以目標為基準判斷需求邊界，在客戶提出跨越邊界的需求時及時指明。
四、需求整理
需求整理需要對每一類細分的干係人，找出一個（覺得有必要可以找多個）最具代表性的人選，進行干係人畫像。例如我們採訪了3個銷售經理，選擇了一個最具代表的銷售經理，將所有銷售經理的需求內容都整理到該干係人畫像表格內。畫像信息可以包括基本信息、干係人關註信息、其他信息。
（1）基本信息：主要包括崗位、代表、角色、崗位職責、系統使用頻率、影響程度（對項目的影響程度）、聯繫方式等。
（2）關註信息：主要包括需求點（可以標註需求實際來源）、阻力點（例如領導的需求，加入監管功能，對員工來說就是負需求；業務部門的易用性需求，對安全部門可能就是負需求）、重要程度。
（3）其他信息：包括便於站在干係人角度思考的信息，如教育背景、所學專業、對信息化的理解程度等。
示例：
崗位（銷售經理）、代表（銷售經理A王某）、角色（使用者）、崗位職責（市場拓展、客戶關係管理）、系統使用頻率（高）、影響程度（高）、聯繫方式（13988888888）。
需求點1（新增客戶關係），重要程度（高）。需求點2（避免同一客戶被多個銷售同時聯繫，該需求來源於銷售經理B李某），重要程度（中）。
教育背景（大學），所學專業（通信工程），對信息化的理解程度（理解程度較高）。
五、軟件設計
在軟件設計方面，B端產品和C端產品的差異性就相對較大了，B端產品不會像C端產品一樣，設計時講究簡約設計，讓用戶“不等不想不煩不學”，花大力氣請UI同事進行頁面美化。
B端產品經理在經歷了和干係人的若干次“美好”溝通之後，交互上能把尼爾森十大可用性原則都遵循了，就算是有良心的產品經理或UE設計師了。界面美化方面，B端產品多數情況下都是在套用模板，很少會動用UI設計師來定製化界面風格。
B端的軟件功能設計，本質上就是對數據的輸入、加工和輸出的過程，操作上通常是在圍繞數據的“增刪改查”來進行，再配以相應的規則和約束條件。在軟件需求說明書中，產品經理會以模塊用例和原型的方式進行表達。
模塊用例一般包括背景描述、用戶、前置條件、後置條件、主場景、擴展場景、規則等內容。
5.1 背景描述
背景描述是不用多說的內容了，無論B端產品還是C端產品，為什麼要增加一個功能，即使是拍腦袋想出來也需要給出一個合理的解釋。可採用“用戶-需求-收益”的模板來描述背景，例如作為銷售主管，希望添加銷售機會管理模塊，這樣就可以動態分配銷售機會給有具備優勢的銷售經理。
5.2 用戶
用戶是指具有操作特定模塊權限的人員，一般會用有UML的用例圖來表達。例如：CRM系統中，銷售主管具有銷售機會管理權限，而銷售經理沒有該權限。
5.3 前置條件
前置條件指需要滿足什麼條件下，用例才可以被執行。
例如，銷售主管分配銷售機會的前置條件為“存在未分配銷售機會的客戶”，如果添加這個前置條件，就表明系統對“已分配銷售機會的客戶”，銷售主管不可以再進行分配銷售機會操作；如果不添加這個前置條件，就表明銷售主管可以對所有客戶分配銷售機會。不添加這個前置條件的不好之處在於，如果銷售主管已分配某客戶給銷售經理A，幾天后又重新分配給銷售經理B，若銷售經理A未及時查看系統，會存在兩個銷售經理同時在聯繫同一客戶的情況。
若一個系統為不可採用游客方式訪問的系統，只有登錄後才可以進行所有的操作，那麼“已登錄”可以不用寫到前置條件中。
5.4 後置條件
後置條件是指用例執行結束後的系統狀態，系統會有哪些變化。例如，銷售主管在完成指定客戶分配後，該客戶狀態需要從未分配變更到已分配，對應的銷售經理賬號下，跟蹤客戶的數量需要相應增加。
5.5 主場景
主場景是軟件的主要執行流程，也見稱為“基本路徑”。根據二八法則，主場景數量雖然會少於擴展場景的數量，但主場景的使用率一般會占到80%以上。例如新增客戶關係中，主場景就是按照規則將客戶關係輸入完整，點擊保存按鈕。其中客戶關係輸入的內容可以採用原型展示，也可以在“5.7規則”中描述。
5.6 擴展場景
擴展場景是主場景之外的分支，也見稱為“擴展路徑”。例如在用戶登錄中，主場景是用戶輸入用戶名、密碼，點擊登錄，驗證成功，進入系統。擴展場景是如果用戶密碼輸入錯誤，或者用戶忘記密碼的處理流程。
5.7 規則
規則是指用例用到的業務規則、邏輯算法等，例如在搜索查找客戶時，模糊查找的規則是什麼。
5.8 非功能性需求
非功能性需求是指產品為了滿足用戶的業務需求而必須具備的除功能之外的特性，其和功能性需求是相輔相成的。非功能性需求是軟件產品的必備部分，但非功能性需求卻常常被忽視。
有些非功能性需求產品經理和開發人員會達成一種默契，即使不提明確的需求內容，也會按照大家的共識來開發交付。但如果客戶有特別強調或產品經理認為有必要特別提出的非功能性需求，需要定量、詳細地描述出來，不可出現理解偏差或模糊性描述。
非功能需求中，常見的錯誤就是模塊性描述，例如採用定性描述，寫高易用性、高安全性類似的描述。其二常見的錯誤是無根據定量，拍腦袋寫標準，例如所有查詢請求需要在3秒內響應完成。
在定義非功能需求時，可以套用SMART原則，即有具體明確的指標（Specific），指標是可測試，可證明，可以衡量的（Measurable），目標是可以達到的（Attainable），與功能性需求具有一定的相關性，可以說明問什麼會存在這個非功能性需求(Relevant)，明確的截止期限（Time-bound）。
按照卡爾·魏格斯在《軟件需求》中的定義和劃分方式，非功能性需求分為外部質量需求和內部屬性需求，具體描述如下：
（1）外部質量
- 易用性：當在某時某地需要系統服務時，系統服務能夠被有效訪問的程度；用戶對系統的學習、記憶和使用的難易程度；
- 可安裝性：正確安裝、卸載和更新安裝應用的難易程度；
- 完整性：防止系統數據錯誤以及數據丟失的程度；
- 互操作性：系統與其他系統或者其他組件互聯或者交互數據的難易程度；
- 性能：系統響應用戶輸入或者其他事件的快慢程度以及可預見性；
- 可靠性：在故障發生之前，系統正常運行時間；
- 健壯性：系統如何應對非預期的操作；
- 安全性：如何防止系統被破壞性損壞；
- 防護性：系統如何阻止對應用及其數據的未授權訪問。
（2）內部屬性
有效性：系統使用計算機資源的效率；
可修改性：維護、修改、改進以及重構系統的難易程度；
可移植性：使系統能夠在其他操作環境中運行的難易程度；
可重用性：在多大程度上能夠把組件使用在其他系統中；
可擴展性：隨著用戶數量、事務、服務器或者其他擴展，系統能夠隨之適應的難易程度；
可驗證性：開發和測試能夠對軟件進行驗證以查看軟件是否已正確實現的便利程度。
寫在最後
關於需求文檔的編寫，在實際工作中，不同團隊會有適合自身的特定模板，有的團隊要求細節描述詳細，有的項目團隊可能要求描述簡單即可。其實文檔的內容和模板都不是主要的，表達清晰、無模糊性、可做出來才是項目的首要任務。每種編寫規則都無所謂對與錯，適合團隊的方式才是最好的。
本文由 @產品工具箱 原創發佈於人人都是產品經理，未經許可，禁止轉載。
題圖來自 Unsplash，基於CC0協議