參與到項目中，經常發現項目的需求源源不斷，剛做完一堆需求，馬上又有新的需求要做，感覺總是做不完，就像一個“無底洞”。實際上，這里涉及到一個需求管理的概念。項目中哪些該做，哪些不該做，做到什么程度，都是由需求管理的過程來決定的。而需求管理可以通過需求池進行維護跟蹤。

需求池概念

1. 使用場景

在項目工作中，經常會碰到客戶說我之前給你們提了一個某某需求，怎么還沒有上線。然后產品經理根本就沒有找到該需求的任何記錄。客戶的忘性很大，很多時候都不記得曾經說過什么。這個時候就需要有一個通過信息記錄，幫助客戶找回需求記憶。

在實際工作中，產品經理每天都會面臨各種各樣的需求，如果僅憑大腦記憶而沒有及時記錄下來，就容易產生需求信息丟失。此時需求池就是一個很好的工具，產品經理可以隨時記錄各個來源傳遞過來的需求，以防需求或者關鍵信息遺漏。

需求池作為需求管理的一個容器，相當于需求的數據庫，為需求分析提供數據來源。需求池一般采用最簡單的Excel，原因是簡單、易管理。這里不僅僅是簡單記錄需求是什么，還會記錄這個需求相關的一些關鍵要素。比如用戶（who）在什么模塊（where）遇到什么問題（what），希望達到什么效果（how）。

需求池的維護原則是寬進嚴出，“寬進”主要是因為需求池面對的產品經理或者產品部門，是需求的備忘錄，所以需要把所有的需求都應該放到池子里。而“嚴出”則是需求池的需求需要經過篩選、分析、規劃之后，才正式從需求池進行到后續的需求文檔中安排開發。

2. 需求池屬性

需求池的模板參考上圖，需求池的關鍵屬性說明如下：

（1）編號

編號就是需求池的順序號，主要是需求的唯一性標識。通常情況下，項目中會有多個業務系統，每個系統單獨維護一個需求跟蹤表，需求編號的命名規則即為：系統英文簡稱_OR（原始需求縮寫）_順序號。

（2）功能模塊

把需求劃分到系統的某個功能模塊，由于需求池的需求還未經過進一步的分析，一般只需要劃分到系統的一級菜單。

（3）需求類型

需求類型一般包括：新增功能、功能改進、需求變更、界面優化、Bug修復、刪除功能、接口需求等。

• 新增功能：已發布版本中尚未包含的功能。

• 功能改進：對已發布功能做可用性、易用性的改進，比如性能優化、架構優化等。

• 需求變更：相對新增需求而言，提出方的需求發生改變，原來的需求變更為“刪除需求”狀態，并記錄關聯關系。

• 界面優化：UI層面的改動，如按鈕顏色。

• BUG修復：系統上線之后，反饋回來的Bug視為需求統一管理。

• 刪除功能：去除已發布的功能。

• 接口需求：我方是數據使用方，使用對方提供的接口，和我方是數據提供方，提供接口供對方使用。

（4）需求名稱

用簡潔的短提煉出用戶的訴求。比如：文本框搜索框支持點擊鍵盤Enter鍵觸發查詢功能。

（5）用戶故事

我們要明確用戶是在什么場景下，為了完成什么目標而需要做什么任務。即要從場景、目標和任務這三方面去具象化需求。

比如場景：針對查詢申請單，查詢專員發現運營商反饋的文件不對；任務：支持在原來的查詢單上重新發起查詢請求，以便運營商接收到新的指令，可以再次反饋文件；目標：運營商根據查詢申請單反饋正確的文件。

（6）優先級

需求的優先級可以根據需求重要性：核心需求、基本需求、建議需求和需求的緊迫性：非常緊迫、一般緊迫、無緊迫性這兩個方便來定義出三個等級：高、中、低。

（7）提出人

需求的提出者，有疑惑時便于追溯，負責解釋需求。

（8）提出時間

原始需求的提出時間，輔助信息。

（9）關聯需求

該需求和需求池中哪些需求有關聯，一般在需求分析的時候需要參考的相關信息。

比如：同一個需求，但是不同從不同用戶采集的信息不一致，或者多個用戶對同一個需求信息的表達觀點矛盾，那么這個就要用到關聯性編號。比如A用戶希望登錄的時候，需要選擇當前用戶的所屬機構，用戶名和密碼。B用戶建議登錄的時候，直接通過用戶名和密碼即可。這2個需求，就是關聯需求。

（10）需求來源

需求的來源主要包括：用戶調研、競品分析、運營反饋、領導意見等。

• 用戶調研：通過用戶訪談收集需求，可以是面對面溝通，也可以通過微信、QQ、電話等方式獲取信息。

• 競品分析：通過在市面上找到同類競爭產品，深入體驗競品功能，為產品設計及需求收集尋求思路。

• 運營反饋：產品上線后，運營同學會把用戶在使用過程中會發出反饋的吐槽的或者建議的信息，反饋給產品經理。

• 領導意見：實際工作中經常會遇到老板一句話的需求，這些需求往往來自于老板身處的高度和豐富的工作經驗。

（11）需求狀態

隨著產品的進展，需求的生命周期會以不同的狀態標識，比如：待討論、需求中、開發中、已發布、暫緩、取消。

• 待討論：剛剛提出或尚未討論或技術尚未確認的需求。

• 需求中：已完成排期的需求。

• 開發中：已經進入開發或尚未發布的需求。

• 已發布：已經發布的需求。

• 暫緩：討論完成尚未排期的需求。

• 取消：無效需求。

（12）開發版本

在經過后續的需求排期之后，記錄原始需求是在哪個版本開始實現的。

（13）備注

其它任何信息，如：

1. 被拒絕的理由；

2. 被暫緩的理由和重啟條件；

3. 其它相關文檔。

3. 如何正確記錄一個需求

在產品經理的日常工作中，我們來看一個需求采集的場景。

當產品正在畫原型的時候，發現電腦右下角的QQ圖像閃爍，打開對話框，看到運營同學發過來的消息，進行如下對話。

需求溝通之后，產品經理需要及時把信息記錄到需求池中，以防需求信息的遺漏。而且在需求記錄的過程中，還能再次梳理需求，進一步挖掘需求信息，為后面做需求分析和設計提供重要依據。

通過維護一個健康的需求池，我們給需求提出者一種信息反饋，就是他們的需求我們都重視了，已經放到了需求池當中，但是是否安排給開發需要根據所有需求進行“輕重緩急”的權重比較才能決定。這樣可以及時給相關人員反饋需求排期和進度。

總結

需求池其實就是信息傳遞的載體，還可以為后續需求變更提供信息依據，也便于領導或者相關人及時了解需求狀態，了解產品的整體情況，了解每個迭代版本完成了哪些需求，便于產品進行進度把控和需求驗收。

由于市場環境，用戶行為都有可能發生變化，這個時間段的需求有可能過一段時間就失去意義了；或者之前暫緩的需求，在目前的市場環境和產品情況下，該需求的緊迫優先級變高了，需要納入到下一版本的需求排期。故需求池需要產品經理定期梳理，每次安排產品版本計劃的時候都要重新審視一遍需求，對所有的需求再次進行分析和篩選，進行需求優先級的定義。