一個健康的需求池，能讓使用者直觀地看到各項需求的進度和接下來要推進哪項；也能幫助使用者診斷版本迭代中的問題；還能讓使用者看到每個需求的實現需要各崗位準備什么。

相信很多產品經理有這樣的痛苦：需求多且雜，需要對接的崗位很多，而且即使一個需求也往往涉及多個崗位。這時候我們需要一個好用的工具管理各項需求，這個工具就是需求池。需求池之于產品經理，就像甘特圖之于項目經理。

需求池不是需求的簡單羅列。一個健康的需求池，能讓使用者直觀地看到各項需求的進度和接下來要推進哪項；也能幫助使用者診斷版本迭代中的問題；還能讓使用者看到每個需求的實現需要各崗位準備什么。

什么是不健康的需求池？

• 沒有標注各項需求的優先級
• 不涉及各崗位如何配合，不能促進溝通
• 沒有厘清各個需求之間的前后續順序
• 沒有版本規劃
• 把BUG也進行排期，或者根本不記錄BUG
• 需求池很復雜，每天要花很多時間才能維護好
• ……

怎么維護健康的需求池？

1. 需求池的表頭

• 優先級：我的習慣是A+、A、B、Z。A+表示馬上就做，A/B是候選，等消化完A+就從AB里任命新的A+。Z表示暫緩，一時半會兒做不了。還有的需求不確定要不要做我直接不標注優先級。EXCEL的自定義排序功能可以很方便地實現按優先級排序。
• 需求模塊/關鍵詞：方便快速查找，也方便相關需求放到一起規劃。不過負責單一模塊的產品經理不需要這個字段。
• 需求詳細描述。
• 補充說明：記錄重要變化，如技術表示什么有難點、需求方需求有變化等。為了防止遺忘最好加上記錄時間，一般我的格式是：XXXXXX@181120。
• 進度：一個需求的生命線往往是這樣：提出并討論需求→分解需求（常形成流程圖）→溝通預估工期→排定優先級→具體規劃（常形成需求文檔）→排期并完成。在維護需求池時，我把需求分為需求調研、規劃中、方案已確認、技術對接中、開發中、已完成幾種狀態。而且會根據和技術溝通結果寫明預計什么時候達到什么階段。
• 產品負責人：記錄每個需求分給了誰，當然只用記錄自己的需求就不用這個字段了。

2. 怎么評估優先級

從3+1個維度評估：重要性、緊急程度、粗估工期、加一個BUG。

1. 重要性和緊急程度的確定也不是產品一個人說了算，需要和上級領導、需求方溝通確定；
2. 粗估工期需要請技術同事給出，很簡單的需求優先級提高。最好同時記錄開發給出的預估工期和實際完成工期，幫助了解自己團隊的需求消化能力；
3. BUG一定要記錄在需求中，但是不用排期，要第一時間解決，所以BUG永遠是優先級最高的。

在以上三個維度評估的基礎上，摘出下2個版本要做的事,在表中進行清楚的標注。

（PS：出于用戶體驗考慮，控制發版頻率，尤其當你的產品是APP時，每次大的版本都需要重新下載。即使是可以自動更新的迭代也要控制頻率。）

3. 為什么這樣的需求池是健康的

1. 對需求從整體上進行審視，提高迭代效率；每件事單獨看起來都是非常重要且緊急的級別，但是需求永遠會大于消化能力，本著要事優先的原則，必須通過共同的審視摘出最重要且緊急的代辦項目。從而讓迭代向著對整個項目最好的方向進行。
2. 對利益相關者廣播優先級和項目進度，提高團隊透明度，使大家互相理解，更少抱怨更高效率。

三、誰來維護需求池

維護者當然是產品經理，但是數據來源卻涉及開發同事和不同部門的需求方。這個時候大家坐下來快速高效地審視一邊需求，一定要有決定權的領導在場防止扯皮。

當著所有人的面（尤其領導的面）把每個需求再認真定義一遍也很重要，因為有的時候需求不是從產品整體考慮，會被老板砍掉。絕對不要讓自己的開發團隊陷入到沒有被認真審視過的需求里浪費時間。

產品經理的工作，尤其當到達一定級別開始帶團隊，需求池=TO DO LIST，最好每天都過一遍需求，不要讓他們在表中荒蕪。

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

題圖來自Unsplash，基于CC0協議