編輯導語：產品經理日常會接收到大量來自其他部門提出的需求，或者自身發現的需求點；但并非所有需求都要立馬實現，所以要創建一個需求池進行管理；本文作者分享了該如何創建需求池，我們一起來看一下。

作為產品經理，會收集到來自四面八方的需求，而將這些需求放進我們創建好的需求池中并進行有效管理是我們首要的任務，今天我就來講一下如何創建需求池。

一、沒有需求池的場景和問題

剛剛入行產品經理的時候經歷過這樣的問題——需求源源不斷。

有時候這個需求沒做完又會出現新的一堆需求，這些需求都來自客戶的、技術的、領導的、團隊討論的、運營反饋的、產品經理自己提出的、還有老板的靈感等等；這些需求來自四面八方。

下面我們來說一下，這種場景下沒有需求池，我們都會遇到哪些問題。

1. 信息分散、導致需求遺漏

如果沒有需求池統一管理需求，我們就會將隨時隨地來自四面八方的需求隨意的記到方便記錄的地方；勤快些的會記錄在電腦的各類記事本或寫在本子上，還有過于自信童鞋就直接記在腦子里。

舉個例子：

我最早留下的習慣是將隨時接收到的需求記錄在本子上，俗話說好記性不如爛筆頭嘛。

將小A提出的需求寫在本子的第17頁，過了幾天將小B提出需求寫在第36頁 …在過很久又將小C提出的需求寫在第N頁；等到有一天想做小B提出的需求時，發現在本子上找不到記錄在哪一頁了，只能苦命的從第一頁開找。

這種情況經常發生，有時候需求過多，每天可能會收到不同人提出的多條需求，有時候在本子上找不到還懷疑是不是記錄在了電腦記事本中？或者產生“是不是我沒記錄下來”的自我懷疑。

這些都是因為將零散的需求存儲到不同的地方所導致的，時間久了還會導致需求遺漏；各種需求提出人來問，之前提的需求為什么還沒有實現？然后產品經理壓根不記得或是找不到這個需求。

2. 沒有信息源頭追溯，傳遞需求時容易導致需求變形

假設我們有一天想實現一部分需求，這些需求包含自己收集的，也包含其他人收集到的需求經過幾手最后到你手上的；當我們在做產品設計的時候發現一些問題（這些問題會因為基于在某個成型產品做迭代而大幅度產生，有些是因為產品本身設計方式導致實現新需求而改動較大），或者對需求內容不理解，想找人確認時，這時想找需求提出人又想不起來或不知道是誰提出的。

那么就產生了沒有信息源頭追溯的問題，如果按照我們自己理解的方式去做，最后就會導致需求變形。

二、什么是需求池，創建需求池的目的

了解了沒有需求池會產生的問題，下面我們來說下什么是需求池。

需求的來源主要有用戶需求、老板需求、用戶調研等，如果沒有需求池，這些需求會散亂在各處；需求池首先解決的問題是將散亂在各個地方的需求匯總，我們可以將任何人，任何時間，任何方式產生的需求統一歸總到需求池中，避免丟失。

其次我們在收集需求的第一時間可以和需求提出人了解清楚需求的詳細信息，避免過很久后在追溯，找到需求提出人時不記得了，容易導致錯過好需求。

創建好需求池后，我們可以通過需求池中統計的信息去判斷需求和需求之間的關聯性，同時可以通過這些信息判斷并明確需求的優先級，從而做好產品的版本規劃；我們在日后工作過程中可以按照優先級隨用隨取，也可以按照制定好的版本按順序開發。

簡單理解，需求池是裝需求的池子——是需求管理和項目管理的依據；我們可以根據這些規則信息進行制定需求的版本規劃，同時通過需求的記錄可以追溯到需求提出人，后續有問題作為和領導、老板溝通的依據。

三、如何創建需求池

上面我們提到，創建需求池的目的是將散亂在各處的需求匯總，那么創建需求池首先要建立固定的格式。

為了日后溯源，還需要記錄需求來源信息；為了輔助我們對每條需求進行分析、歸類、建立版本規劃，還需要有優先級、需求場景等信息，下面我們來看下建立固定格式需要的字段信息都有哪些。

為了方便理解，我將這些字段分成基礎信息及擴展信息，基礎信息是創建需求池不可缺少的字段，擴展信息可以在基礎信息上靈活調整，不是必填信息。

1. 基礎信息

基礎信息主要包含的信息有：編號、模塊、功能點、需求描述、場景描述、需求層次、需求類型、優先級、商業價值、提出人、提出時間、狀態。

下面我來依次講解下這些信息都是什么：

1）編號：需求的唯一標識，可用序號羅列，也可以用日期+當天提交需求的序號統計；作用是作為每條需求的唯一編號和快速查詢需求。

2）模塊：根據產品模塊去劃分，例如“個人中心”作用是將需求統一歸類到某個模塊下，在進行版本規劃時，可以優先從某個模塊中篩選，同時便于根據模塊查詢。

3）功能點：簡單描述需求的功能，也就是要做什么；這樣我們快速查看某個需求時，能一眼看明白這個需求是要新增或修改哪個功能。

4）需求描述：需要描述清楚需求的完整性、一致性，需要精準的描述；如果產品經理在后續想不清楚這個需求到底要做什么，可以通過需求詳細描述來回想或了解。

5）場景描述：了解用戶在什么場景下產生的需求，便于我們分析需求背后的價值，在給開發轉述為什么要增加這個需求時，可以清晰的說明是因為哪些原因，更能說服開發愿意做這個需求。

6）需求層次：分為基礎需求、增值需求、擴展需求；便于產品經理了解需求屬于哪個層級，可根據需求類型、需求價值、優先級、需求層級等結合考慮版本規劃。

7）需求類型主要包含：

• 新增功能：目前平臺沒有實現的功能；
• 功能改進：對目前平臺已實現的功能進行優化；
• bug修復：系統功能使用出現問題，與正確的設計邏輯不一致；
• 用戶體驗：例如頁面按鈕擺放的問題，發送消息時發送按鈕放在右側，可以按照用戶的使 ??用習慣設計；
• UI優化：頁面體現內容，如按鈕顏色；
• 內部需求：公司內部產生的需求，如開發一個內部OA系統；
• 刪除需求：對平臺已有的功能進行簡化；
• 接口需求：使用對方提供的接口，或給對方提供接口。

產品經理可以根據這些類型區分，在產品開發階段根據需求類型考慮先實現哪些，例如：在時間緊急的情況下，有新增功能和bug修復的情況下，我們會優先解決bug修復這類型的問題，先保證項目不會出現問題。

優先級：P0緊急重要?→?P1緊急不重要?→?P2不緊急重要?→?P3不緊急不重要；可根據實際情況根據商業價值、需求類型、需求層次等信息綜合判定優先級，按照四象限法則將需求分別放進這四象限中，最后按照順序一一完成；可以幫助產品經理有條不紊的完成工作，也可基于優先級這幾個分類考慮到版本規劃中。

商業價值：可以按照0-10標注，不需要考慮實現難度，在需求討論時團隊討論決策即可；提前分析好商業價值能幫助我們了解清楚當前需求是否值得做，做完后能帶來什么價值；不做的話會有什么損失。

開發量：需求的開發工作量，可以通過這個信息規劃開發每個版本的工作內容，也方便我們了解每個需求的開發難度。

提出人：原需求的提出人，便于日后有疑問可追溯。

提出時間：需求的提出時間，方便我們了解是什么時間提出的需求，同時可以利用提出時間來規劃需求的緊急程度。

狀態：需求的生命周期，待討論、暫緩（標注原因）、拒絕、需求中、開發中、已發布；主要作用是可以對需求的流轉狀態進行跟蹤，可以了解需求在不同階段的狀態，發現問題及時調整。

2. 擴展信息

擴展信息包含：

• 原始需求：即需求提出人的原描述內容，主要目的為了保留提出人的表述，過后對需求理解有誤或跟需求人對接時方便提出人回憶需求內容。
• 價值描述：需求的價值分析，需求的價值可能會根據時間變化而改變，根據團隊討論好的價值分析，將分析原因簡明概要的寫在上面，日后回溯時可以迅速了解到當時是出于哪些思考確定的價值分析。
• 錄入人：需求是誰錄入的，日后也可根據此信息找到錄入人了解需求詳細情況。
• 負責PD：狀態進入到“需求中”時確定；目的是記錄，需求完成后或出現什么問題可以找到該負責人。
• 設計負責人：狀態進入到“開發中”時補充；目的是記錄，需求完成后或出現什么問題可以找到該負責人。
• 開發負責人：狀態進入到“開發中”時確定；目的是記錄，需求完成后或出現什么問題可以找到該負責人。
• 測試負責人：狀態進入到“開發中”時確定，或者開發結束后補充；目的是記錄，需求完成后或出現什么問題可以找到該負責人。
• 期望上線時間：需求提出人期望該需求的上線時間，可以通過此時間來考慮需求實現的優先級。
• 最終上線時間：記錄最終上線時間。
• 備注：對該需求的備注信息。

最終需求池的模版（基礎信息）：

最終需求池的模版（擴展信息）：

四、總結

需求池是產品經理不可缺少的工具，本文中主要根據沒有需求池容易產生的問題介紹了什么是需求池、創建需求池的目的及創建需求池所需要的字段信息。

最終的模板字段需要按照公司實際業務靈活變動，文中提供的字段信息僅為參考，主要目的是為了幫助產品經理創建并管理自己的需求池。

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

題圖來自 unsplash，基于CC0協議