需求分析可以說是產品從業人員的核心技能了，若分析不夠輕則需要反復調研，重則導致產品定位不清晰、不滿足需求，需要推倒重來。本文主要介紹本人在B端產品需求分析實踐過程中的思考和注意事項。

上篇文章《B端產品需求采集的實踐與思考》介紹了B端產品需求采集的方法和注意事項。我們將采集回來的需求稱為用戶需求，用戶需求轉換為產品需求需要經歷一個需求分析的過程。

一、概念解釋

在正式進入如何進行需求分析之前，我們先來理解下什么叫做需求。

《人人都是產品經理》一書作者蘇杰曾指出：“減少甚至消除理想與現實的差距的愿望，就產生了需求”。

本人認為這是從宏觀方向的解釋，若從軟件或互聯網產品這個微觀角度解釋的話：需求是在特定的角色特定的場景想要達成某種目的內心的渴望。也就是在研究需求的時候，不可將角色、場景和內心渴望分開來討論，否則就容易導致需求不滿足的情況。

具體案例下文將會有，這里不做太多贅述。

理清需求的概念后，需求分析過程本質上就是找出用戶在具體場景下內心的渴望，然后通過軟件的方式幫助實現這種渴望。但是并不是所有的渴望會被滿足或立即被滿足。

二、需求分析案例實踐

通過前期的需求采集大行動，我們的需求池里存儲了大量的需求。面對眾多未經過分析的需求，不禁反問自己：

• 這些紛繁雜亂的需求都應該被滿足嗎？
• 看似眾多的需求能夠滿足業務需求嗎？
• 如何篩選掉偽需求？
• 如何挖掘用戶的潛在需求？

帶著這些問題，我們一起探討下本人在需求分析實踐過程中的方法論。

1. PSP方法

• P：即Peson，角色
• S：即Scenes，場景
• P：即Paths，路徑

脫離角色談需求，適用用戶則不明確；脫離場景談需求，則需求適用業務范圍不明確；脫離路徑談需求，則業務流程不明確，因此PSP方法可以很好的幫助分析人員明確具體的需求。

案例實踐1：

下表為需求池當中的1條需求，其中需求描述為客戶提出的原始需求

在B端產品中，很多時候我們會拿到這種角色和場景不太明確的需求， 拿到這種需求之后，切忌直接動手開始設計，否則帶來的后果輕則后期改動所帶來的成本消耗，重則需要全部推倒重來，面向B端產品，常常涉及到多角色，因此在思考任何一個需求的時候，一定要加入角色，通俗的講就是思考什么類型的用戶在什么樣的場景下想要做什么事，等到我們理清了這些思考，需求將會變得越來越明確和合理，下表即本人在針對上表需求的PSP方法過程，內容僅供大家參考，重在幫助理解該方法。

可以看到將不明確的需求依據角色、場景和路徑進行劃分可以得到一個個明確的需求。

2. 需求三法（加法、減法、挖掘）

1）需求減法

需求采集回來的林林總總的需求，要學會做減法，目的是保證產品定位更清晰，用戶體驗更好，以下為本人總結需求做減法的情況：

• 影響產品定位，每個產品為了適應市場的競爭會形成自己的差異性定位，若是需求會影響到產品的定位，一定要非常的謹慎，否則會導致產品臃腫、定位不清晰，影響會很大。在B端項目中采集回來的需求，需求若合理但不符合產品定位的情況，可放到項目中實現，但不應在產品中實現。
• 影響用戶體驗，當我們的用戶經常抱怨產品界面充斥著很多無用功能、界面重點信息不突出，用戶上手困難，學習成本高的時候，可能需要對需求做減法了，很多需求是產品人員不考慮用戶的實際情況自己構造出來，若是不符合用戶需求，應該果斷砍掉。
• 暫時不實現，需求合理，但現階段因各種因素不能滿足實現的情況下，可安排到以后的版本，待時機成熟時再實現。

2）需求加法

很多時候滿足了用戶提出的合理需求，依然不能很好地滿足實際的應用，或者產品無亮點，不能形成自己的優勢，這個時候我們需要頭腦風暴，對需求做加法，然后進行驗證，進而強化產品的功能、定位和用戶體驗，

案例實踐2：

科室人員制定需求計劃的時候，可以手動選擇物料填寫采購數量。這樣做存在的問題是：科室人員必須非常清楚需要什么物料，且每個物料需要手動選擇，工作量大；另外填寫采購數量受主觀因素影響，未必合理。

為了解決上述問題，我們給需求做了一個加法：依據歷史消耗量自動生成采購數量，其功能取名為輔助決策，就是自動帶出該科室歷史周期消耗量作為采購數量；支持編輯，該功能可以大幅提升錄入效率，這樣就能很好的滿足自動選擇或者自動生成的實際應用場景了。

3）需求挖掘

需求的挖掘是建立對用戶的了解和業務經驗基礎之上為了更好的滿足產品的需要而進行的行動。

案例實踐3：

實際的倉庫業務中，安全庫存和最小庫存是庫房人員一直關注的重點。若當前庫存小于這兩個值，會影響到庫存的周轉甚至經營，因此隱含的需求就是及時地補充安全庫存和最小庫存量。

經過挖掘，明確了安全補倉這個需求；然后與用戶進行了驗證，用戶驚喜地確認了需求。因此建立在對用戶和業務了解上，不斷地深入場景進行分析，挖掘出讓用戶驚喜的需求。

3. 做一次需求評估

通過上面的方法找出了用戶真實的需求。但能否轉換產品需求還需要一個過程那就是需求評估，需求評估的過程其實是對對需求的商業價值、迫切程度、實現難度、性價比評估的一個過程。

案例實踐4：

下表內容為本人評估輔助決策的過程，僅供大家參考

其中：

• 強度為對該需求的渴望程度；
• 頻率為該需求會出現的次數；
• 持續時間為該需求出現的時間范圍；
• 實現難度也就是我們常說的開發量；

性價比=商業價值/實現難度

優先級是建立在前面的分析的基礎上評估的開發順序，也就是四象限法則。

四象限法則提倡優先處理重要而不緊急的事情，當然突發的重要且緊急的事情也應該優先處理。不過該類情況的發生通常是因重要且不緊急的事情規劃不當引起的，因此應該根據實際情況進行優先級的處理。

關于四限法則具體的理論和解釋大家可自行了解，本文就不做過多的贅述了。

三、B端產品需求分析容易碰到的坑

1. 業務經驗不足

B端產品因涉及到具體的行業和業務知識，如金融后臺、ERP、CRM等系統，因此要求產品人員具備較深的業務背景知識。

剛入行的產品新人，往往會因業務經驗不足導致需求分析無從下手；首先不要灰心，成長需要一個過程，可以先嘗試不涉及太多行業知識的需求進行入手，然后要做的是多請教、多學習、多跑系統積累行業經驗。

2. 思維邏輯不夠嚴謹

思維邏輯不夠嚴謹主要體現在需求的分析和撰寫上，這種情況通常是考慮不到位或者不夠全面造成的。

其實產品人員很難保證說自己做的需求分析是絕對嚴謹的，但是我們能做的是盡量的嚴謹，注重細節多思考、多總結各種可能性，逐漸提升自己的思維嚴謹度。

3. 眉毛胡子一把抓

出現這樣情況往往是沒有做深入的需求分析和評估引起的，分析不夠則判斷需求是否合理困難，不會做減法；缺少需求評估則缺少實現合理需求的優先級排序。

避免該類的情況發生的方法是可按照上文的方法做深入的需求分析和需求評估。

4. 不加思考，全盤接受領導安排需求

領導提出的需求不一定全是合理的，產品人員要把控好每個需求，面對不合理的需求，要敢于提出來，多思考為什么會提出這樣需求，這樣才能在共同理解的基礎上進行溝通。

5. 不加思考，完全照搬需求

很多時候，從競品照搬需求貌似是一個省心省力的工作，但是若是不加思考的完全照搬則是一個不明智的做法，照搬的需求可能不一定適合產品的定位或者不是在本版本實現，這里本人想提的是一定要有獨立思考的能力，過手的每個需求都是經過深度思考的。

6. 產品人員自己創造需求，卻不驗證

很多時候，產品人員會頭腦風暴產生需求，很多令用戶眼前的一亮的功能就是來源此，但是該類需求一定要做可用性測試快速驗證是否合理，避免出現閉門造成的情況。

四、總結

以上就是本人對B端產品需求分析的實踐和思考，重點闡述了需求分析中PSP、需求三法、做一次需求評估的理解和運用。

另外為了避免再次入坑，總結了本人在B端產品需求分析中容易碰到的坑。當然由于行業和經驗的差異，以上所述可能并不通用，僅供大家參考。

感謝大家的閱讀，另外預告下篇文章內容主題—如何進行B端產品的設計。

作者：張磊（個人公眾號：lightinglei）互聯網醫療B端產品策劃者，音樂愛好者，籃球愛好者，攝影愛好者

本文由 @張磊 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash ，基于 CC0 協議