每個項目都會有一個需求池，你的項目應該也不例外吧。技術開發的速度，感覺總趕不上需求池增長的速度，身有體會吧。做不完的需求，清不空的需求池。每次版本迭代的源頭，也許不是來自需求池；可是消化不了的需求，總是倒入了需求池。別再讓你的需求池成為需求的垃圾堆，說說需求池的那些事兒。

一、需求池的定義

需求池：不在本次開發版本范圍內的所有需求。嚴格來說，即使是下一個開發版本的需求，也可以算作是需求池的范圍。需求池中的需求，有些可能只是一個想法，有些還需要調研，有些還需要討論，總之，需求池中的需求和實際交付給開發的需求還是有一定距離。

二、需求池的由來

“好記性不如爛筆頭”，一句話而概之，需求池的由來。你還記得上個月第二周的產品討論會上xxx提出的想法嗎？趕緊打開需求池看看吧。別讓你的好想法就這樣溜走，快點記下來吧。

三、需求池的作用

1. 記錄暫時無法消化的需求；
2. 頭腦風暴的源頭；
3. 版本規劃的源頭。

當你沒有產品靈感的時候，需求池很可能會幫你一把。

四、需求池的優先級

需求有優先級，需求池自然也有優先級。優先級是個很難劃定的東西，經常被人提到的“四象限法”：對需求進行歸類，重大問題修復、重要體驗優化、重要的新功能…這種比較主觀的歸類，每個版本都需要進行一次主觀的優先級判斷，相對來說太消耗時間了。有些需求或優化由于影響了正常的使用和核心功能，這樣的需求優先級高，大家很容易達成共識。對于一些新功能和產品規劃的方向性問題上，優先級的確定很可能會演變成一聲拉距戰，最后就是誰的級別高聽誰的。

是否還有更優的確定優先級方法呢？當然有。優先級最好能夠量化，減少主觀判斷，形成一個可視化的數學計算方法，而且讓大家達成共識，也很重要。

試試從這幾個緯度去考慮優先級

1. 階段性目標是什么？
2. 需求服務的用戶數量是多少？
3. 投入產出比是否合適？

加入這幾個緯度的考慮，很容易過濾掉一大半的需求，抓住重點，讓大家共識重點?？此坪唵蔚臇|西，可是當時為了優先級爭得面紅耳赤的時候，誰還會記得它呢？基于這幾個緯度，可以進一步對需求進行緯度細分和權重細分，討論出一個優先級計算公式。以后優先級的討論只要套用這個公式就行，一勞永逸。

五、需求池的細分項有哪些？

需求標題、需求描述、產品線、提交人、提交時間、功能模塊、優先級、需求狀態等，便于需求的追述、調研、細化，最終快速形成可以交付給開發的需求。無法滿足這些選項的需求，也就沒有必要進入需求池了，對待需求也需要一個嚴謹的態度。不是你的隨便一個想法都能進入需求池的，這個idea滿足了我們用戶的什么需求？如果提交人回答不知道，我想就沒有必要進入需求池了吧。需求池的細分項，讓需求更立體化，更清晰，過濾那些想都沒有想清楚的需求吧。

小結

是時候該優化一下你的需求池了，清理那些沒有價值和無法細化的需求，制定好大家認可的優先級公式，讓重要的需求池動起來吧。

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