編輯導讀：產品經理每天都在和需求打交道，每天都會遇到瑣碎卻又不得不解決的問題。例如，需求如何尋找，如何進行判斷需求的優先順序，如何落地等等。本文作者以B端產品為例，分析如何做好需求管理，希望對你有幫助。

作為一個產品經理，從開始接手產品工作的那一刻起，就在和各種各樣的需求打交道。

打交道的過程中會遇到如下各種問題：

• 需求應該要從哪里去收集？
• 各種渠道，各個相關角色會反饋給你一堆需求，這時應該如何去落地？
• 當需求越來越多時，需要一個需求庫來進行相關需求的管理，這時需求庫如何做，需求庫里應該要包含哪些要素會比較好？
• 接到的需求到底該不該做，什么時間做，應該如何去判斷？
• 等等。

這一系列的問題，通過做好需求管理的一套方法，將會一一得到解決。

這一套方法是什么？

我將從以下3點展開來講：

1. 需求全生命周期管理；
2. 需求庫管理；
3. 需求取舍、優先級判斷原則。

01?需求全生命周期管理

關于“需求”相關的問題，我們首先要建立一個基本的認知，那就是：需求全生命周期管理。

需求不是一個零碎、單一環節的存在，它有相應的一套完整管理過程。

這一套完整的全生命周期管理，大概可以分為以下6個關鍵點：

1. 需求收集；
2. 需求分析；
3. 需求確定；
4. 需求評審；
5. 需求推進；
6. 需求變更。

以上6個關鍵點，這里我將一一拆開來詳細講講。

第一個關鍵點，需求收集。

需求管理的第一步就是收集需求，沒有收集到需求，何來后面的全生命周期管理。

收集需求的方法有很多，比如：

1. 可以通過用戶訪談的形式收集需求；
2. 可以通過用戶調查的方式收集需求；
3. 可以通過深入一線，觀察、學習的方式收集需求；
4. 可以通過會議溝通的方式來收集需求；
5. 可以通過競品分析的方式來收集需求；
6. 等等。

關于收集需求具體更詳細的理解，可以參考我之前的一篇文章：《Ｂ端產品需求的3個層次，你都了解嗎？》。

第二個關鍵點，需求分析。

通過第一階段收集到的需求，可能會來自于不同部門、不同角色、不同顆粒度且零散的需求。這時就需要對需求進行分析。

需求分析的目的就是業務分析，也就是：

選擇一種以業務為導向的方式將零散的、不同顆粒度的需求串起來，形成一個完整的、內容清晰的框架，指導后續相關的產品設計 、產品開發工作。

做需求分析時，我們可以用業務流程圖，業務場景，領域建模，狀態圖等思考模型來進行需求分析。

具體如何用這些模型來做需求分析，可以參考我之前寫過的兩篇文章：《Ｂ端產品如何進行業務流程的梳理與繪制？》；《Ｂ端產品如何進行業務全場景的需求梳理？》。

第三個關鍵點，需求確定。

對分析完成的需求，接下來就要和需求發起者進行確定，這是不是他們想要的需求。

第四個關鍵點，需求評審。

需求確定以后，接下來需要與技術團隊評審需求，需要開發的周期、投入的人力需要多少進行溝通。

第五個關鍵點，需求推進。

對已經完成確定、完成評審的需求，需要進一步往下進行原型設計、UI設計、技術開發等工作的推進。

如何推進？

需求推進的過程中有哪些關鍵點需要注意，可以參考我之前的一篇文章：《B端產品如何做好項目管理？》。

第六個關鍵點，需求變更。

已評審完成的需求，在往后推進落地的過程中，可能會遇到需求變化的情況。

可能是業務方提出的需求變化，也可能是技術在開發過程中遇到了技術挑戰，提出了需求變更的請求。

這時通過再次溝通、評估新的產品方案、評估新的技術方案，選擇合適方案，往下進行需求落地的推進。

從需求收集到需求變更是一個完整、閉環的需求管理過程。

只有認清需求管理的全生命周期，才能管理好全生命周期中動態的變化，管理好每一個“需求管理”的節點。

02?需求庫管理

一家初創的企業級Saas公司，或者是一家傳統企業開始開發軟件來解決企業數字化轉型問題的公司，剛開始需求沒有多少，收集到的需求可能找個文檔簡單記錄一下需求就可以。

隨著業務的發展，需求越來越多，面對龐大的需求，這時就需要找一個合適的工具來進行需求管理。

這個工具叫做“需求庫”，也有人把它稱為“需求池”。

通過需求庫的使用，可以把需求按照標準的方式匯集在一起，方便后面對需求的統一管理（可以在需求庫里增加需求、修改需求、查看需求，對需求進行歸類、優先級排序等等）。

需求庫里包含的要素主要有5大類：

1.需求，包括

需求描述，提出人，提出職級，提出時間。

2.優先級

P0,P1,P2。

3.評估

產品可行性、技術可行性、投入資源、開發周期預估。

4.狀態

需求確認、需求評審、產品設計、技術設計、技術開發、測試、部署上線。

5.變更情況

變更提出人、是否有技術瓶頸、產品方案是否變更，技術方案是否變更。

知道需求庫里需要哪些要素之后，接下來，就要進行需求庫的繪制，

需求庫的繪制，可以使用Excel表格或者石墨文檔來完成。

03?需求取舍、優先級判斷原則

文章一開始，我就提到，日常工作中，各種渠道，各個相關角色會反饋給產品經理一堆需求。

面對一堆需求，需求該不該做，需求的優先級該怎么去排列，這時，就我們就需要有一些方法或者是原則來支撐我們對需求取舍、需求優先級判斷。

先聊第一個問題，需求取舍。

需求到底該不該做？

根據我的經驗來看，可以有幾個標準來綜合判斷：

1.戰略方針

也可以叫產品的價值主張，知道了產品的價值主張，就能大概的知道產品的邊界在哪？

屬于價值主張范圍內的需求，可以考慮做；不屬于價值主張范圍內的需求，則不應該做。

2.用戶價值、商業價值組合思考

如果需求對用戶價值，對公司也有商業價值，那就該做；

如果對用戶有價值，對公司沒有商業價值，那也可以考慮做，可能需求優先級就要排在后面；

如果對用戶沒有價值，不管對公司是否有商業價值，都不應該做。

3.若無必要，則不需要過度設計

我們開發軟件是為了支持業務的需要，支持業務需要時可以是線上+線下來完成，如果是及其低頻、線下處理比線上處理還要方便的業務需求，這時可以化繁為簡，沒必要線上來做。

接著聊第二個問題，需求優先級排序。

首先，對需求類型進行分類，我對所有的Ｂ端需求分為3大類:

1. 業務閉環型需求；
2. 便利性需求；
3. 個性化需求。

這3類需求，

第一個最重要，排第一；

第二個，第二重要，排第二；

第三個，第三重要，排第三。

我之前在哈佛商業評論期刊上看到一篇文章，具體文章標題我已經忘了，文章中給出了Ｂ端企業顧客需求的幾個維度，如下圖：

這張圖里面的基本價值和功能價值就是我說的業務閉環型需求；便利價值就是我說的便利性需求；個性價值和理想性價值就是我說的個性化需求。

這里我舉個實際的例子。

比如，小明是某個給景區提供營銷推廣、SCRM的Saas服務商的一個產品經理，這家公司是一家初創企業，在做門票系統時，有以下幾個需求：

1. 添加門票
2. 編輯門票
3. 查看門票
4. 刪除門票
5. 分組批量管理門票
6. 面向用戶的詳情頁，需要有多種樣式可以選擇

這6個需求中的1、2、3、4對應著我上面講的閉環型需求，優先級是排第一的；

第5個需求對應著我上面提出的便利性需求，優先級排第二；

第6個需求對應著我上面提出的個性化需求，優先級排第三。

這三類需求中，不同類別中，也會存在很多需求，如何進行前后排列？

可以從以下幾個維度來綜合考慮：

1. 需求強烈程度；
2. 功能的使用頻次；
3. 實現成本；
4. 團隊情況；
5. 企業生命周期階段。

這里還是接著舉例。

比如，文章中提到的，給景區提供營銷推廣、SCRM的Saas系統，其中有一個需求是：

掃碼授權系統可以和景區服務號綁定，這個需求首先肯定屬于閉環型需求，排在第一位的，沒有這個需求功能，產品閉環不了。

在第一個類別中，這個需求優先級應該如何排列呢？

我們來綜合考慮一下：

1. 需求強烈程度，程度是比較高的；
2. 功能的使用頻次，頻次是比較低的，一次授權，終身使用；
3. 實現成本，產品設計、技術開發上比較耗時；
4. 團隊情況，初創團隊，產品、技術人員較少；
5. 企業生命周期階段，屬于初期，主要要進行產品價值的驗證階段。

綜合評估完，短期來講，每增加一個景區，技術手動操作，授權服務號綁定系統（這個比較簡單，耗時較?。?，只要能解決系統綁定服務號問題就行，不一定要完整的解決方案。

完整的解決方案排在后期再去做，因此這個需求的優先級是排在后面的。

以上講了一些方法來支撐我們對需求取舍、需求優先級判斷，

不過老實來講，需求優先級判斷這事其實是沒有標準答案的，

沒有一種方法可以將需求劃分到足夠小的顆粒度來進行需求優先級判斷，只要能夠大概的區分出來就好。

最后，關于Ｂ端產品如何做好需求管理的問題就講到這里了。

愿你有所收獲，知道如何動態、系統的管理需求。

#專欄作家#

豐憲飛，微信公眾號：小飛哥筆記，個人微信：f1506620495。人人都是產品經理專欄作家。某互聯網創業公司合伙人兼產品總監，多個項目“從0到1”項目負責人，擅長戰略、運營、產品的整體規劃及落地執行。

本文原創發布于人人都是產品經理，未經允許，禁止轉載。

題圖來自Unsplash, 基于CC0協議。