參與到項目中，經(jīng)常發(fā)現(xiàn)項目的需求源源不斷，剛做完一堆需求，馬上又有新的需求要做，感覺總是做不完，就像一個“無底洞”。實際上，這里涉及到一個需求管理的概念。項目中哪些該做，哪些不該做，做到什么程度，都是由需求管理的過程來決定的。而需求管理可以通過需求池進行維護跟蹤。
參與到項目中，經(jīng)常發(fā)現(xiàn)項目的需求源源不斷，剛做完一堆需求，馬上又有新的需求要做，感覺總是做不完，就像一個“無底洞”。實際上，這里涉及到一個需求管理的概念。項目中哪些該做，哪些不該做，做到什么程度，都是由需求管理的過程來決定的。而需求管理可以通過需求池進行維護跟蹤。
需求池概念 1. 使用場景
在項目工作中，經(jīng)常會碰到客戶說我之前給你們提了一個某某需求，怎么還沒有上線。然后產(chǎn)品經(jīng)理根本就沒有找到該需求的任何記錄。客戶的忘性很大，很多時候都不記得曾經(jīng)說過什么。這個時候就需要有一個通過信息記錄，幫助客戶找回需求記憶。
在實際工作中，產(chǎn)品經(jīng)理每天都會面臨各種各樣的需求，如果僅憑大腦記憶而沒有及時記錄下來，就容易產(chǎn)生需求信息丟失。此時需求池就是一個很好的工具，產(chǎn)品經(jīng)理可以隨時記錄各個來源傳遞過來的需求，以防需求或者關(guān)鍵信息遺漏。
需求池作為需求管理的一個容器，相當(dāng)于需求的數(shù)據(jù)庫，為需求分析提供數(shù)據(jù)來源。需求池一般采用最簡單的Excel，原因是簡單、易管理。這里不僅僅是簡單記錄需求是什么，還會記錄這個需求相關(guān)的一些關(guān)鍵要素。比如用戶（who）在什么模塊（where）遇到什么問題（what），希望達到什么效果（how）。
需求池的維護原則是寬進嚴(yán)出，“寬進”主要是因為需求池面對的產(chǎn)品經(jīng)理或者產(chǎn)品部門，是需求的備忘錄，所以需要把所有的需求都應(yīng)該放到池子里。而“嚴(yán)出”則是需求池的需求需要經(jīng)過篩選、分析、規(guī)劃之后，才正式從需求池進行到后續(xù)的需求文檔中安排開發(fā)。
2. 需求池屬性
需求池的模板參考上圖，需求池的關(guān)鍵屬性說明如下：
（1）編號
編號就是需求池的順序號，主要是需求的唯一性標(biāo)識。通常情況下，項目中會有多個業(yè)務(wù)系統(tǒng)，每個系統(tǒng)單獨維護一個需求跟蹤表，需求編號的命名規(guī)則即為：系統(tǒng)英文簡稱_OR（原始需求縮寫）_順序號。
（2）功能模塊
把需求劃分到系統(tǒng)的某個功能模塊，由于需求池的需求還未經(jīng)過進一步的分析，一般只需要劃分到系統(tǒng)的一級菜單。
（3）需求類型
需求類型一般包括：新增功能、功能改進、需求變更、界面優(yōu)化、Bug修復(fù)、刪除功能、接口需求等。
- 新增功能：已發(fā)布版本中尚未包含的功能。
- 功能改進：對已發(fā)布功能做可用性、易用性的改進，比如性能優(yōu)化、架構(gòu)優(yōu)化等。
- 需求變更：相對新增需求而言，提出方的需求發(fā)生改變，原來的需求變更為“刪除需求”狀態(tài)，并記錄關(guān)聯(lián)關(guān)系。
- 界面優(yōu)化：UI層面的改動，如按鈕顏色。
- BUG修復(fù)：系統(tǒng)上線之后，反饋回來的Bug視為需求統(tǒng)一管理。
- 刪除功能：去除已發(fā)布的功能。
- 接口需求：我方是數(shù)據(jù)使用方，使用對方提供的接口，和我方是數(shù)據(jù)提供方，提供接口供對方使用。
（4）需求名稱
用簡潔的短提煉出用戶的訴求。比如：文本框搜索框支持點擊鍵盤Enter鍵觸發(fā)查詢功能。
（5）用戶故事
我們要明確用戶是在什么場景下，為了完成什么目標(biāo)而需要做什么任務(wù)。即要從場景、目標(biāo)和任務(wù)這三方面去具象化需求。
比如場景：針對查詢申請單，查詢專員發(fā)現(xiàn)運營商反饋的文件不對；任務(wù)：支持在原來的查詢單上重新發(fā)起查詢請求，以便運營商接收到新的指令，可以再次反饋文件；目標(biāo)：運營商根據(jù)查詢申請單反饋正確的文件。
（6）優(yōu)先級
需求的優(yōu)先級可以根據(jù)需求重要性：核心需求、基本需求、建議需求和需求的緊迫性：非常緊迫、一般緊迫、無緊迫性這兩個方便來定義出三個等級：高、中、低。
（7）提出人
需求的提出者，有疑惑時便于追溯，負(fù)責(zé)解釋需求。
（8）提出時間
原始需求的提出時間，輔助信息。
（9）關(guān)聯(lián)需求
該需求和需求池中哪些需求有關(guān)聯(lián)，一般在需求分析的時候需要參考的相關(guān)信息。
比如：同一個需求，但是不同從不同用戶采集的信息不一致，或者多個用戶對同一個需求信息的表達觀點矛盾，那么這個就要用到關(guān)聯(lián)性編號。比如A用戶希望登錄的時候，需要選擇當(dāng)前用戶的所屬機構(gòu)，用戶名和密碼。B用戶建議登錄的時候，直接通過用戶名和密碼即可。這2個需求，就是關(guān)聯(lián)需求。
（10）需求來源
需求的來源主要包括：用戶調(diào)研、競品分析、運營反饋、領(lǐng)導(dǎo)意見等。
- 用戶調(diào)研：通過用戶訪談收集需求，可以是面對面溝通，也可以通過微信、QQ、電話等方式獲取信息。
- 競品分析：通過在市面上找到同類競爭產(chǎn)品，深入體驗競品功能，為產(chǎn)品設(shè)計及需求收集尋求思路。
- 運營反饋：產(chǎn)品上線后，運營同學(xué)會把用戶在使用過程中會發(fā)出反饋的吐槽的或者建議的信息，反饋給產(chǎn)品經(jīng)理。
- 領(lǐng)導(dǎo)意見：實際工作中經(jīng)常會遇到老板一句話的需求，這些需求往往來自于老板身處的高度和豐富的工作經(jīng)驗。
（11）需求狀態(tài)
隨著產(chǎn)品的進展，需求的生命周期會以不同的狀態(tài)標(biāo)識，比如：待討論、需求中、開發(fā)中、已發(fā)布、暫緩、取消。
- 待討論：剛剛提出或尚未討論或技術(shù)尚未確認(rèn)的需求。
- 需求中：已完成排期的需求。
- 開發(fā)中：已經(jīng)進入開發(fā)或尚未發(fā)布的需求。
- 已發(fā)布：已經(jīng)發(fā)布的需求。
- 暫緩：討論完成尚未排期的需求。
- 取消：無效需求。
（12）開發(fā)版本
在經(jīng)過后續(xù)的需求排期之后，記錄原始需求是在哪個版本開始實現(xiàn)的。
（13）備注
其它任何信息，如：
- 被拒絕的理由；
- 被暫緩的理由和重啟條件；
- 其它相關(guān)文檔。
在產(chǎn)品經(jīng)理的日常工作中，我們來看一個需求采集的場景。
當(dāng)產(chǎn)品正在畫原型的時候，發(fā)現(xiàn)電腦右下角的QQ圖像閃爍，打開對話框，看到運營同學(xué)發(fā)過來的消息，進行如下對話。
需求溝通之后，產(chǎn)品經(jīng)理需要及時把信息記錄到需求池中，以防需求信息的遺漏。而且在需求記錄的過程中，還能再次梳理需求，進一步挖掘需求信息，為后面做需求分析和設(shè)計提供重要依據(jù)。
通過維護一個健康的需求池，我們給需求提出者一種信息反饋，就是他們的需求我們都重視了，已經(jīng)放到了需求池當(dāng)中，但是是否安排給開發(fā)需要根據(jù)所有需求進行“輕重緩急”的權(quán)重比較才能決定。這樣可以及時給相關(guān)人員反饋需求排期和進度。
總結(jié)
需求池其實就是信息傳遞的載體，還可以為后續(xù)需求變更提供信息依據(jù)，也便于領(lǐng)導(dǎo)或者相關(guān)人及時了解需求狀態(tài)，了解產(chǎn)品的整體情況，了解每個迭代版本完成了哪些需求，便于產(chǎn)品進行進度把控和需求驗收。
由于市場環(huán)境，用戶行為都有可能發(fā)生變化，這個時間段的需求有可能過一段時間就失去意義了；或者之前暫緩的需求，在目前的市場環(huán)境和產(chǎn)品情況下，該需求的緊迫優(yōu)先級變高了，需要納入到下一版本的需求排期。故需求池需要產(chǎn)品經(jīng)理定期梳理，每次安排產(chǎn)品版本計劃的時候都要重新審視一遍需求，對所有的需求再次進行分析和篩選，進行需求優(yōu)先級的定義。
本文由 @瓜子 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。
題圖來自Unsplash，基于CC0協(xié)議。
