不知道大家有沒(méi)有一個(gè)感受，就是雖然產(chǎn)品在不斷的更新迭代，但是需求還是會(huì)源源不斷的增加，感覺(jué)怎么也不會(huì)減少。這時(shí)候就需要用需求池這個(gè)工具，來(lái)管理這些源源不斷的需求了。

一、需求池是什么？

需求池主要產(chǎn)品汪用來(lái)收集和管理各方來(lái)源的各類(lèi)需求，這里不僅僅是簡(jiǎn)單記錄需求是什么，還會(huì)記錄這個(gè)需求相關(guān)的一些關(guān)鍵要素。另外初次進(jìn)入需求池的需求是通過(guò)簡(jiǎn)單篩選和評(píng)估的?？偟膩?lái)說(shuō)，需求池管理有兩個(gè)原則：有進(jìn)有出、寬進(jìn)嚴(yán)出。

二、需求池有哪些要素？

編號(hào)

編號(hào)就是需求列表的順序號(hào)，主要是作為當(dāng)前需求的唯一性標(biāo)識(shí)。

功能模塊

根據(jù)現(xiàn)有的產(chǎn)品模塊進(jìn)行分類(lèi)，初步判定此需求屬于哪個(gè)功能模塊的類(lèi)別，若是新增業(yè)務(wù)功能，則此項(xiàng)可以待定不填寫(xiě)。

需求描述

如果是比較簡(jiǎn)單、不復(fù)雜的小需求，直接描述要解決什么問(wèn)題。如果不是小需求，則不僅需要描述要解決什么問(wèn)題，還要把為什么要解決問(wèn)題的原因一并記錄下來(lái)。（解決問(wèn)題的原因，多數(shù)情況下需要產(chǎn)品汪刨根問(wèn)底的去問(wèn)，去了解實(shí)際上用戶(hù)的需求到底是什么和想解決怎樣的用戶(hù)需求）

需求來(lái)源

直白的理解就是此需求從哪里來(lái)，是誰(shuí)提了這個(gè)需求。

以產(chǎn)品汪作為需求主要提出人來(lái)分類(lèi)的話，可分成如下兩類(lèi)：

被動(dòng)告知需求：

1. 主要業(yè)務(wù)部門(mén)，包括市場(chǎng)部、運(yùn)營(yíng)部、財(cái)務(wù)部、管理層等主要業(yè)務(wù)部門(mén)，需求目的是為了上線某一個(gè)新業(yè)務(wù)或者是新活動(dòng)，這時(shí)候產(chǎn)品要做的是了解新業(yè)務(wù)或者新活動(dòng)的內(nèi)容，梳理出業(yè)務(wù)流程，整理涉及到的邏輯出demo等等；
2. 客服，需求目的是解決某一類(lèi)用戶(hù)問(wèn)題，當(dāng)存在一類(lèi)用戶(hù)頻繁咨詢(xún)或投訴這類(lèi)問(wèn)題，客服是會(huì)把這類(lèi)用戶(hù)問(wèn)題提交給產(chǎn)品組，產(chǎn)品來(lái)評(píng)估從業(yè)務(wù)和產(chǎn)品角度怎么進(jìn)行優(yōu)化此類(lèi)問(wèn)題；
3. QA，針對(duì)于視覺(jué)或者交互的細(xì)節(jié)QA在測(cè)試過(guò)程中，會(huì)遇到一些細(xì)節(jié)的小問(wèn)題（主要是歷史遺留），這時(shí)候會(huì)提交給產(chǎn)品，一般此類(lèi)需求等級(jí)較低；
4. 用戶(hù)意見(jiàn)反饋，每月收集整理用戶(hù)提交的意見(jiàn)反饋（吐槽或建議），分析用戶(hù)吐槽的問(wèn)題是否具有普遍性還是個(gè)例，用戶(hù)的建議是否能實(shí)現(xiàn)，背后想解決什么樣的問(wèn)題；

主動(dòng)收集或挖掘需求：

1. 競(jìng)品分析，主要是在研究競(jìng)品或者同類(lèi)型產(chǎn)品中，發(fā)掘比較好的功能且適用于自己產(chǎn)品（能解決一部分用戶(hù)的需求或者能為企業(yè)帶了一定的收入）
2. 用戶(hù)研究，自己在論壇、貼吧、微博等內(nèi)容社區(qū)，了解社區(qū)里那些屬于自己產(chǎn)品的目標(biāo)用戶(hù)或潛在用戶(hù)都在吐槽或者期待產(chǎn)品的哪些內(nèi)容，產(chǎn)品要做的是了解這些問(wèn)題背后的原因是什么，其次是怎么能解決這些吐槽或者滿(mǎn)足用戶(hù)需求。

需求類(lèi)型

需求類(lèi)型主要是記錄此類(lèi)需求屬于哪一個(gè)類(lèi)別的，前期需要定義好需求類(lèi)型有哪些？主要需求類(lèi)型有：

新增功能、功能改進(jìn)、體驗(yàn)提升、BUG修復(fù)、內(nèi)部需求等。

（我們公司主要是按需求來(lái)源劃分的需求類(lèi)型，業(yè)務(wù)需求、UI優(yōu)化、QA優(yōu)化、技術(shù)優(yōu)化、產(chǎn)品優(yōu)化、用戶(hù)建議，和需求來(lái)源整合在一起，屬于需求來(lái)源的一部分）

需求添加時(shí)間

此需求添加到需求池的時(shí)間，而不是需求提出人初次提出的時(shí)間。目的統(tǒng)計(jì)需求明確到需求上線的周期。

優(yōu)先級(jí)

需求池中的需求優(yōu)先級(jí)可以用高、中、低來(lái)初步進(jìn)行確定哪個(gè)需求的優(yōu)先級(jí)更高。通過(guò)需求評(píng)審后的需求，優(yōu)先級(jí)更應(yīng)該按照1、2、3、4的順序進(jìn)行排列。假設(shè)用高、中、低來(lái)確認(rèn)需求優(yōu)先級(jí)，會(huì)存在什么問(wèn)題呢？當(dāng)確定下個(gè)版本上線5個(gè)功能點(diǎn)（其中2個(gè)高、2個(gè)中、1個(gè)低），由于開(kāi)發(fā)進(jìn)度和開(kāi)發(fā)資源的問(wèn)題，5個(gè)功能點(diǎn)中只能如期上線3個(gè)功能點(diǎn)，那么就需要考慮在2個(gè)中的需求中先上線哪個(gè)？這樣的話，前期按照高、中、低來(lái)評(píng)審需求優(yōu)先級(jí)就存在不嚴(yán)謹(jǐn)性。

優(yōu)先級(jí)判斷原則：（四象限法則和kano模型結(jié)合）

• 重要且緊急（基本型需求） —— 必須g抓緊時(shí)間做。比如會(huì)影響到用戶(hù)主流程使用的功能。（高）
• 緊急但不重要（魅力型需求） —— 只有在優(yōu)先考慮了重要的事情后，再來(lái)考慮這類(lèi)事。（中）
• 重要但不緊急（期望型需求） —— 只要是沒(méi)有前一類(lèi)事的壓力，應(yīng)該當(dāng)成緊急的事去做，而不是拖延。比如節(jié)日優(yōu)惠相關(guān)的需求，但是現(xiàn)在距離下一個(gè)節(jié)日還有3個(gè)月。（中）
• 既不緊急也不重要（無(wú)差異型需求） —— 有時(shí)間再處理，比如IOS和安卓視覺(jué)個(gè)別小按鈕視覺(jué)不太一致。（低）

狀態(tài)

待討論、暫緩、拒絕、已明確。已明確的需求基本上下一步就是進(jìn)行版本規(guī)劃了，這時(shí)候需要重新評(píng)估需求優(yōu)先級(jí)（用1、2、3、4數(shù)字標(biāo)識(shí)），定哪個(gè)版本上線、版本啥時(shí)候發(fā)布。

備注

其他任何信息，如：需求期望完成時(shí)間、被拒絕原因、暫緩原因。

三、需求池有什么作用

需求容器

直白的來(lái)說(shuō)，需求池就是個(gè)需求容器，不同來(lái)源的各種需求都可以進(jìn)入（簡(jiǎn)單評(píng)審），進(jìn)來(lái)之后的需求進(jìn)行再次的評(píng)審，最終決定這個(gè)需求的去留。

緩沖地帶

一段時(shí)間內(nèi)來(lái)了較多的需求，而自己沒(méi)法第一時(shí)間進(jìn)行評(píng)估需求的合理性，這時(shí)候可以將需求先放進(jìn)需求池內(nèi)，后期自己再慢慢消化，再?lài)?yán)格的評(píng)估需求的合理性。

版本規(guī)劃

經(jīng)過(guò)再次評(píng)審后留下來(lái)的需求，可作為下個(gè)版本發(fā)布的內(nèi)容或下幾個(gè)版本迭代的內(nèi)容，目的是確保在做版本規(guī)劃時(shí)有足夠的素材來(lái)源，而不僅僅的靠自己盲目的規(guī)劃。

四、總結(jié)

以上是自己在整理需求池相關(guān)內(nèi)容的一些想法，主要是結(jié)合自己工作整理的，由于是自己公司內(nèi)部使用的，所以可能存在一定的局限性。歡迎大家多交流學(xué)習(xí)。

#專(zhuān)欄作家#

董小白，人人都是產(chǎn)品經(jīng)理專(zhuān)欄作家。喜歡研究各類(lèi)好玩好用的APP，關(guān)注出行、電商等領(lǐng)域；擅長(zhǎng)整理和分析APP亮點(diǎn)功能設(shè)計(jì)。

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

題圖來(lái)自 unsplash