上一篇我們討論了需求分析，主要從需求的對象、需求的意圖、需求的成本三個維度去探討，接下來我們講一講需求池。

需求池對于圈內(nèi)產(chǎn)品人來說是想當(dāng)然的存在，因為幾乎每天都會面對，但你可曾認真想過為什么會有需求池？

在時間上，需求的收集可能比較分散，但也可能蜂擁而來，將需求傳達給設(shè)計、研發(fā)還需要進一步評估、轉(zhuǎn)化，這需要花費不少的時間。這時候需求池提供了一個緩沖空間，平衡了需求的供給，同時需求池也是調(diào)控項目周期的重要工具，有規(guī)劃版本作用。

需求池看似簡單，想做好卻也不容易，我們再來了解下管理需求池有哪幾個重要環(huán)節(jié)？

如果把需求池形象化，那么蓄水池再合適不過。

蓄水池是一個蓄水設(shè)施，想要蓄水自然需要有水的流入，蓄水的目的是為了平衡水的流出。如果想蓄水池發(fā)揮更高級作用，那么在蓄水的同時通過濾懸浮顆粒、去除有機污染物、處理可溶無機物等工序凈化水質(zhì)，使其流進來的是污水，流出去的是凈化水。

如同蓄水池一般，管理需求池可分為三個重要環(huán)節(jié)：需求輸入、需求轉(zhuǎn)化、需求輸出。

下面我們針對這三個環(huán)節(jié)逐一討論。

一、輸入：需求錄入

經(jīng)歷了前面用戶需求分析，我們已經(jīng)得到需求的大致樣貌。需求池作為一個緩沖區(qū)，需要把需求基本信息清晰地記錄起來，既要把原始需求描述清楚，也要把分析后的場景、服務(wù)對象記錄好，等下一次再看時，能夠還原需求本質(zhì)而不產(chǎn)生歧義。

儲蓄字段

需求池記錄方式不限制，可以簡單地用表格文檔，也可以用項目協(xié)作工具，只要能把需求描述清即可。一個合格的需求池里應(yīng)該有以下幾個字段：

• 需求來源：記錄需求從那個渠道獲取，方便后期跟蹤核對。
• 需求描述：記錄第一手需求描述，方便后期跟蹤核對。
• 需求場景：場景化是需求推演的重要依賴。
• 服務(wù)對象：需要仔細甄別，提出者與需求受益者并不一致。
• 本質(zhì)意圖：有別于需求描述，記錄經(jīng)過分析后的需求目標。
• 提出時間：有些需求存放過于長久的時需要重新取舍或再分析。
• 優(yōu)先級：是輸出版本規(guī)劃的重要依據(jù)。

上面提到只是基本字段，需要根據(jù)產(chǎn)品性質(zhì)、公司流程酌情增加。

諸如需求場景、服務(wù)對象、本質(zhì)意圖等在第一階段的需求分析已經(jīng)有了答案，現(xiàn)在只是組織言語依次填入。

比較特殊的是歸類，大部分的需求池都會有。但實際上有不少的歸類僅僅是為了存在而存在，對于需求的描述并沒有多大幫助，有的甚至造成誤導(dǎo)。這個需要本身工作流已經(jīng)形成清晰的需求分類才考慮，這是需要注意的細節(jié)。

優(yōu)先級排序

關(guān)于優(yōu)先級，也有不少人總結(jié)出一套完整的流程，大致是通過KANO模型對用戶滿意度的分析，根據(jù)基本需求、期望需求、興奮需求、無差異需求、方向需求五個特征給需求打分，再綜合緊急程度、開發(fā)成本、研發(fā)周期等最終評定出優(yōu)先級。

看起來很棒，這種精細分析針對于某個大需求或整個產(chǎn)品去做調(diào)研，分析效果不錯，但大量運用于每個需求幾乎是不可能的。

首先，需求的滿意度從何談起？

必須通過用戶調(diào)研或數(shù)據(jù)分析才能建立模型，這樣做需要花費大量的人力與時間，顯然不適合應(yīng)用在每個需求上。但如果不這么做，那么這個模型就只能依賴產(chǎn)品經(jīng)理的主觀經(jīng)驗去判定，然后打分。

那何必繞一個大圈子來掩飾自己的主觀意識呢？亂了思緒也亂了工作流程，因此我并不推薦。

工具方法是好，但不應(yīng)該亂用，老老實實結(jié)合當(dāng)前產(chǎn)品周期，給需求定一個需要完成的時間，通過這個時間排個序。

后期根據(jù)研發(fā)排期也可靈活調(diào)整優(yōu)先級，坦白承認這確實依賴工作經(jīng)驗，但隨著實踐次數(shù)的增多，判斷會越來越準確。

二、轉(zhuǎn)化：需求轉(zhuǎn)述

當(dāng)我們接了許多活忙得昏天暗地時，我們肯定很想找人分擔(dān)下，把一堆的需求鍋丟給設(shè)計師、程序猿，給他們制造點“麻煩”，想想就是興奮。但一股腦直接丟過去估計是要打架的，互聯(lián)網(wǎng)八卦咱們?nèi)套〔徽?，記得別這么干就是了。

轉(zhuǎn)化產(chǎn)品需求描述

盡管在這之前我們已經(jīng)確定了需求背后的意義與其基本的可操作性，從開發(fā)的角度而言，這個叫做用戶需求，是關(guān)于用戶意圖的實際描述。然而具體怎么做，設(shè)計師、程序猿們不一定能很好的理解。

打個比方，用戶的問題是“某一個頁面的按鈕很被難點到”。

從產(chǎn)品的角度看，放大按鈕、調(diào)整位置，似乎都有助于改善用戶體驗，改哪一個？一起改？這個問題的解決方法是模糊的。

實際上還有一種可能，并是不按鈕太小跟位置問題，而是點擊按鈕時都會有短暫時間的無響應(yīng)。這在用戶看來就是沒點著，如此一來，無論在視覺交互上怎么修改，都解決不了問題。

所以，產(chǎn)品經(jīng)理作為用戶與團隊對接第一人，需要拆解問題、分析功能，將用戶需求定到位，最終轉(zhuǎn)義形成適合于產(chǎn)品開發(fā)的功能描述與產(chǎn)品目標，再一并傳達給研發(fā)團隊。

與團隊先切磋

產(chǎn)品經(jīng)理既然承載了用戶與團隊的溝通橋梁，多溝通是關(guān)鍵，避免梳理出一大堆研發(fā)團隊看不懂的文檔。

想在溝通層面做好，首先要善于分享，這需要苦口婆心多次重復(fù)，越是重要的事越需要被重復(fù)提及才能被理解、被記住，有能力的管理者通過溝通將產(chǎn)品的核心理念清晰的往外傳達。

其次，要不恥下問，在溝通中保持開放，產(chǎn)品經(jīng)理干得活不少，會面臨到許多方面的問題。有些問題需要留給垂直能力突出的專業(yè)人士來處理，我們需要做的只是拋磚引玉。

也只有研發(fā)團隊了解產(chǎn)品的核心理念，再通過他們進一步轉(zhuǎn)化相關(guān)的需求描述。這樣，需求描述是建立在大家共同的認知上，能為后期避免很多因歧義產(chǎn)生的爭論。

三、輸出：版本規(guī)劃

關(guān)于輸出，主要是決定當(dāng)前需要實現(xiàn)哪些需求，既是為下一步的需求評審確定好內(nèi)容，也是對產(chǎn)品的版本規(guī)劃。

頂住外界壓力

當(dāng)我們在確定當(dāng)前要實現(xiàn)哪些需求時，幾乎每一個部門都認為他們的需求才是最重要的，包括老板，有木有？

切莫被各個部門牽著鼻子走，記住我們才是專業(yè)的；老子說了算，要有霸氣，要有骨氣。

當(dāng)然，適當(dāng)調(diào)整需求的優(yōu)先級也是可以的。

需求關(guān)聯(lián)

版本規(guī)劃不應(yīng)該著眼一個需求，應(yīng)該站在全局的角度去思考，在需求功能上下鉆挖掘，在需求模塊上橫向聯(lián)系。在理清楚需求之間存在的關(guān)聯(lián)后，將有聯(lián)系的需求規(guī)劃在同一個版本輸出。

從長期來看，關(guān)聯(lián)嚴謹?shù)男枨蠹嫌兄陧椖康目焖偻七M。

簡易文檔

如果前面的工作都做好了 ，那么文檔的輸出就是水到渠成的事。這里需要形成的是簡易文檔或原型，后期再逐步深入。

這里是啟動階段，主要以磋商為主，文檔也是以交流為主。

當(dāng)我們做到這里，需求池管理的基本工作已經(jīng)結(jié)束了，下面總結(jié)一下流程。

1. 首先，整理需求錄入排好優(yōu)先級；
2. 其次，與團隊積極溝通形成產(chǎn)品需求描述；
3. 最后，聯(lián)動需求規(guī)劃好版本輸出溝通文檔。

以上就是本期內(nèi)容，每個人都有屬于自己的工作方式，找到合適自己的才是最重要。小龍只是拋磚引玉，希望對你能有所啟發(fā)。

下一期需求評審，咋們不見不散。

#相關(guān)閱讀#

《想做好需求分析？這3個問題你需要解答》

作者：小龍的執(zhí)著；公眾號：小龍的執(zhí)著（ID：york_wu1219_office）

本文由 @小龍 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。