習慣養成記丨創建你的需求池

需求池是需求管理和項目管理的工具，是下版本迭代時不知道做什麼的依據，也是產品經理與領導、業務部門溝通最好的證據

前言

需求池：顧名思義“把即將要做或打算要做的內容放置到一個地方進行儲存”，也就是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：因圖片太大，特意將需求池字段展開為“基本”和“增值”字段

總結

需求池的創建源於你的實際場景，具體場景具體分析，不拘泥於形式，以適合自己的方式做好項目管理和需求管理為主；

本文主要以筆者所在公司情況舉例，分別闡述了需求的來源，為什麼創建需求池以及如何創建你的需求池，希望能夠對大家有所幫助。

後續定期更新《習慣養成記》系列文章，主要講述產品經理在實際工作中各個環節方法論的總結，同時也會新增其他系列類文章，可以關注作者或公眾號，不錯過任何一篇讓我們互相成長的新文章。

本文由作者@Dr.Z 韓 在PMCAFF社區發佈，轉載請註明作者及出處。