需求池是需求管理和項目管理的工具，是下版本迭代時不知道做什麼的依據，也是產品經理與領導、業務部門溝通最好的證據。
需求池：顧名思義“把即將要做或打算要做的內容放置到一個地方進行儲存”，也就是INBOX的概念，有一個區域去放置我們的Stuff，Stuff中可能會包含一系列內容：想法、任務、目標、靈感、idea……
一、需求來源
各種行業，各種類型的產品經理都會跟需求打交道，但是需求的來源卻不盡一致。可能對於做業務方向的產品經理，多數的需求是業務方給提出的；對於做2C方向的產品經理，多數的需求時自己通過調研或抽樣得出的…
目前筆者在做倉儲行業數據平台的產品經理，對於我來説可能需求最重要的兩個來源就是【業務方】和【老闆（總裁辦領導）】；為什麼我們的數據平台需求多集中於這兩方呢？因為源於數據平台的產品定位是：為企業高層領導決策提供方向，為業務方提供數據分析；
無論是老闆（總裁辦領導）方的需求還是業務方的需求，他們可能主動向你提出，但是如果在你的產品年度規劃中涉及到老闆和業務部門的話，就需要你主動出擊了。
二、為什麼創建需求池
剛入行產品的時候，最頭疼的兩件事情：下個版本該做誰的需求和下個版本要做什麼？
後來引入了需求池的概念，需求池兩大優勢治好了我的“頭疼病”：明確量化需求優先級和新版本規劃的依據。
2.1 明確量化需求優先級
做B端產品經理的時候，特別偏業務方向比較多的時候，會接到各式各樣各種領導的需求，其中往往很多的需求有一個共同的特點，比如：這個需求很緊急、這個需求下週要、這個需求馬上做……往往這時候我們會有一種感覺：資源是有限的，時間是有限的，需求是無限的；我們下個版本到底該先做誰的需求呢？
這個時候我們需要對需求優先級進行量化（評分），需要引入一個工具“需求池”，通過需求池能夠對需求進行集中管理，集中量化。
原先工作時的一個場景：需求池現在已經擺放了3個業務方的N個都非常緊急的業務型需求了。那麼如何去把看似優先級一致的需求量化呢？這是一個很現實的也很燒腦的問題，難在考慮讓參與需求量化評分的業務方的人都同意這個方案；
量化在於【量化模型】的搭建，量化需要考慮的有需求方（業務方）緊急程度、使用方緊急程度、開發設計資源三個；由此得出基礎量化模型：【評分=業務迫切度/總工作量】。總工作量無外乎：數據產品經理、數據分析師、數據開發、UI、測試的工作量之和；業務迫切度需要結合公司綜合考慮業務方、使用方的情況共同搭建出業務迫切度的模型，通過分析公司的整體情況，最終給定的業務迫切度由5部分構成：重要程度（5分制）、緊急程度（5分制）、使用人員崗位（5分制）、使用頻率（5分制）、是否年度里程碑（2分制）。
越上層的的領導可能決策性的數據需要更多一些，基於平台定位，所以我會讓這個點作為業務迫切度的重要因素；看板使用也是分頻率的，可能有的報表看板一天使用一次，有的一個月使用一次，那週期越長顯然分值越低；年度里程碑就屬於公司規劃內需要看重一些。
通過對上述量化模型的分子分母構成因素分析（分子屬於維度，進行乘積計算，分母進行加和計算），就得出了需求量化的公式：
評分=（重要度*緊急度*使用人員*使用頻率*年度里程碑）/Σ工作量（數據產品經理 UI設計師 數據分析師 數據開發 測試）
當然量化模型建立後，需要徵集大家意見，當大家同意後，統一召開需求方評審會議，順便叫開發設計人員共同參與，給出需求池中每個業務型需求量化評分，會議結束後，需求池中所有業務型需求均已被評分，從高到低優先級一目瞭然，需求方也沒有“怨言”了。
需求池是集中管理需求、量化需求優先級的好工具，可以將很多需求放入進去管理，使用同樣的量化標準（可以讓每個人都信服），讓每一個需求優先級的量化都有跡可循。通過量化，不僅能夠解決“下個版本要做誰的需求”，還能夠作為和領導溝通的“證據”。
2.2 新版本規劃的依據
現在我們迭代計劃為一週到兩週，有時候感覺月度的計劃是江郎才盡才湊的需求，只是為了項目經理管控的需求個數而建立的，自己並沒有真正的計劃下個版本要做什麼。
為什麼B端產品會出這種原因呢？有的可能因為公司業務比較少，有的可能剛入門沒有規劃，有的屬於來一個需求溝通完就完事了，不進行記錄…而我剛入行的時候屬於後者，俗話説：“好記性不如爛筆頭”，腦子再好用，也敵不過時間的殺傷力。每次當列下版本計劃的時候，總是感覺隱隱約約有個需求，但是就是想不起來的那種痛苦感，真想當時就記錄下來；這時需要一個需求池，對於需求進行及時記錄、及時整理並且集中管理。
通過“需求池”作為管理、溝通的依據，將溝通的需求行之有效的記錄下來；不僅能夠安慰需求提出者，讓需求者心裏有一個想法：需求被重視了；另一有價值的點就是能夠做到讓自己不慌，清晰的規劃處下個版本將要做的內容，作為新版本規劃的依據。
三、如何創建你的需求池？
“頭疼病”的良方叫做“需求池”，開篇也説過，需求池就是承載你的想法、任務、目標、靈感…的地方，但是該如何創建呢？下面與大家一起分享。
3.1 確定需求池基本字段
需求池最基本的字段（如3.1.1 圖所示）肯定是必須要有的，基本字段就是對於需求的基本描述以及下版本規劃溝通的依據；但是隻有基本字段基本是解決不了上述問題的，只是能夠緩解一部分的壓力，所以我們要綜合考慮如何去創建需求池。
圖3.1.1 需求池基本字段
3.2 確定需求池增值字段
上文也説到過創建需求池的原因是想要通過需求池來進行需求優先級的量化，所以我們首先引入評分的概念；想要通過一系列的算法去把需求池中內容進行評分，公平公正公開，邀請相關人員共同參與，最終得分情況一目瞭然且對比於其他業務部門的需求以及自己的需求有一個排級情況認知，作為大家均認可的量化評分。
公司裏面的年度里程碑計劃和非年度里程碑計劃會涉及到評分，所以是否年度里程碑會影響量化需求優先級，需求池中需要存在該字段；
同時我們會建立原始需求記錄的字段，因為若是業務方領導或總裁辦領導提的需求，總會有很多可挖掘的點，可能我們分析的產品需求只是一部分，原始需求存在，説不定可以剖析出其他的產品需求；
當然我們的優先級被量化之後，各個領導知道了我們對於需求池中需求的評分那麼就會給出一個期望上線的日期，所以我們需要記錄：期望上線日期；同時為了考量我們的產品規劃、設計、開發、測試的進度，會增加一個實際上線日期，用來比對進展情況，一般會在覆盤上一個版本使用
這樣就根據我們的實際場景構造了一個需求池（後續是否增加字段視具體場景而定），主要包含下列信息（分別用3.2.1腦圖和3.2.2 excel表進行展示）
3.2.1 需求池所有字段
圖3.2.2（1） BI系統需求池基本字段
圖3.2.2（2） BI系統需求池增值字段
Ps：因圖片太大，特意將需求池字段展開為“基本”和“增值”字段
總結
需求池的創建源於你的實際場景，具體場景具體分析，不拘泥於形式，以適合自己的方式做好項目管理和需求管理為主。
本文主要以筆者所在公司情況舉例，分別闡述了需求的來源，為什麼創建需求池以及如何創建你的需求池，希望能夠對大家有所幫助。
本文由 @Viper 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議