需求繁多，頻繁迭代，管理困難？大廠產品學姐將在這篇文章為你介紹需求池的管理方法，包括需求收集、需求池填寫和維護等，幫你一招搞定需求管理。推薦對產品、產品運營、需求分析等感興趣的童鞋閱讀。

回想學姐十幾年前剛入職的那會兒，第一個月折騰了半天，才做了一個簡單的小需求，從需求的調研到最后上線，我基本就跟這么一個需求，其余的時間就打打雜咯，也不需要做什么“需求管理”～

隨著自己的快速成長，半年后我就獨立負責一個App了，對口研發也有好幾十號，這時候需求就日益增多，每個迭代（當時我們是兩周一迭代）都會有大大小小十多個新增的需求，加上還沒做完的需求，或者需要繼續優化的需求……

同時還要應付其他部門的同事、老板們甩各種需求過來，這時候沒有一個比較好的工具去管理，就有點手忙腳亂了。需求管理是每個產品、運營在職業生涯上必須要掌握的技能，經驗當然也很重要，不過一個好的工具，可以讓大家上手更快，這篇文章學姐就介紹一個比較好的需求管理工具——需求池。

01 什么叫需求池？

剛才學姐也說了，隨著需求的增多，我們需要用一個工具去管理它們，我們形象地管這個工具叫做——需求池，英語叫做backlog。學姐覺得這個翻譯還挺傳神，因為需求就像水一樣，在這個池子里進進出出～

需求池的形式一般是一個在線的表格，里面記錄著每個需求的內容和狀態，你和其他相關同事可以隨時編輯、查看各需求的情況。這個迭代（或者版本）進入尾聲的時候，我們可以打開這個這個表格，盤一盤下個迭代或者下個版本我們要上哪些需求，對它們進行細化；等到需求評審會的時候，我們又可以對著需求池，逐一講解我們的需求；啟動研發后，我們又可以通過需求池來追蹤每個需求的狀態。

除了以上這些場景，我們還可以把需求池分享給其他部門的同事查看，以便他們在對我們的工作、資源飽和度產生質疑的時候，把信息共享（甩）給他們。另外，在平時做周報、月報的時候，我們對需求池稍加美化（當然是指格式美化不是指粉飾太平），就可以把最近的工作貼進去啦～這樣可以避免很多重復的工作量。

02 收集需求

在講需求池怎么用之前，學姐先來簡單介紹下一般的需求是怎么產生的，畢竟要先有需求，我們才能去管理。需求一般有以下幾種來源：

• 調研分析：通過問卷、訪談、查閱行業報告等形式，總結歸納出用戶的痛點并解決；
• 體驗產品：在體驗現有產品的過程中，發現現有流程的問題并改善；
• 競品分析：通過體驗競品，發現自身產品的不足并優化；
• 業務方、合作部門：如運營、銷售、法務等基于他們對產品的理解，給出建議；
• 老板：這就不解釋了吧，懂得都懂……

總之只要有了idea，我們就可以把它列到我們的需求池了。

03 如何填寫需求池

有了想法之后，怎么樣結構化地去管理需求呢？學姐這就來分享一個比較好的模版～

需求池一般由兩部分組成，一是需求內容，包括名稱、價值、優先級、提出人、文檔等；二是需求狀態，包括迭代、進度、人員、發布時間等。下面詳細講解每一項該如何填寫。

1. 需求內容

名稱：

每個需求都要有一個清晰的名稱——雖然聽上去像是廢話，但是學姐在看簡歷的時候，經?？吹揭恍懙貌惶玫捻椖棵Q，看了半天也不知道到底在做了啥，導致學姐面試的時候經常熱衷于幫童鞋們改項目名字～

那么需求名稱要怎么寫得好呢？首先，在需求還不太明確、只有一個idea的時候，可以用需求的目的、需求的價值去代替，比如“搜索體驗優化”。隨著需求逐漸明朗，盡量用比較清晰、可以確切描述功能的名字，這樣不容易混淆，比如“搜索列表頁新增篩選器”就比“搜索列表頁優化”更明確。

價值：

這個也是學姐的老生常談啦，之前寫文章介紹過，這里就不詳細張開了，我們需要用一兩句話來描述需求的價值。我們可以用“用戶痛點+論據+解決方案”的句式，也可以用“幫助用戶+論據+解決方案”的句式，下面是兩個例子：

• 目前的商品詳情頁相比競品，展示的信息少，用戶做購買決策難（用戶痛點），轉化率僅40%，遠低于競品（論據），因此需要對商品詳情頁進行改版（解決方案）。
• 調研顯示50%的客戶有在平臺投放廣告的需求（論據），為了幫助這些客戶獲取更多目標用戶（幫助用戶），我們會通過算法匹配在合適的列表頁展示廣告位（解決方案）。

優先級：

我們要根據需求的價值，得出需求的優先級。優先級怎么排，學姐之前也講過一個簡單的公式：核心用戶的核心需求&核心用戶的非核心需求&非核心用戶的核心需求；：

需求的優先級我們一般用P00、P01、P1、P2表示，這樣比較有層次，數字越小優先級越高。核心用戶的核心需求一般是P00或者P01，核心用戶的非核心需求是P1，非核心用戶的核心需求是P2。當然，具體的數字其實不重要，重要的是要在某個迭代里，所有的需求一定要有相對的優先級排序。

提出人：

在需求收集這一部分學姐也提到了不同的需求來源，如果需求的提出人是其他部門的，我們應該把TA的名字填入，這樣需求有任何進展，我們可以及時告知。

文檔、交互、視覺等：

這就不贅述了，需求文檔怎么寫之前學姐也教過，大家貼上鏈接就行了。在需求進入評審之前，如果還沒有完整的文檔，至少也要有需求描述+交互設計稿，在需求開發之前，文檔、交互和視覺缺一不可。

2. 需求狀態

迭代：

對于已經明確有排期的需求，我們把迭代號填寫進去，這樣我們只要篩選一下就可以看到每個迭代中有哪些需求了，如果有些童鞋走的不是敏捷開發，那么填寫版本號也是一樣的。

進度：

排入迭代的需求，我們需要對其標注研發的進度，用未開始、已開始（未完成）、已完成來表示，如果有必要的也可以把開發了百分之多少填寫進去～

人員：

一旦需求開始研發，我們就可以把相關人員給填上了，比如研發寫一欄、測試寫一欄，有必要的也可以把視覺、交互設計師也單獨寫上，這樣做視覺還原的時候方便找人。

發布時間/版本：

在需求進入迭代之后就應該填寫，這樣方便追蹤需求的進度。

04 如何維護需求池

首先，我們要明確需求池應該由哪些角色來維護。需求內容（需求名稱、價值、提出人、優先級、文檔、交互&視覺）這一部分，由產品經理本人填寫；需求狀態（迭代、進度、人員、發布時間）這一部分，一般由項目管理或者研發負責人填寫，當然如果是比較小的團隊，也可以產品經理自己填寫。

其次，我們需要及時更新需求池。除了把新增的需求填入之外，當需求有進展的時，我們要及時更新需求池。比如在需求逐漸明朗，有了需求文檔、設計稿的時候我們要及時更新鏈接；比如需求排入了某個迭代，開始開發的時要及時更新需求狀態和上線時間；比如需求的優先級產生變化，我們也要及時調整，甚至刪除一些分析下來覺得不靠譜的需求。

最后，我們要時不時看一下需求池，畢竟這是記錄我們靈感的地方?？匆幌伦约哼€有哪些idea沒有被實現，趕緊把需求文檔補起來；也可以回首一下自己這個月完成了多少個需求，獲得滿滿的成就感～當然，隨著互聯網行業的發展，現在市面上有很多完善的需求管理工具，比如Ones、Jira、TAPD等等。