編輯導(dǎo)語：產(chǎn)品經(jīng)理日常會接收到大量來自其他部門提出的需求，或者自身發(fā)現(xiàn)的需求點(diǎn)；但并非所有需求都要立馬實(shí)現(xiàn)，所以要?jiǎng)?chuàng)建一個(gè)需求池進(jìn)行管理；本文作者分享了該如何創(chuàng)建需求池，我們一起來看一下。

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

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

剛剛?cè)胄挟a(chǎn)品經(jīng)理的時(shí)候經(jīng)歷過這樣的問題——需求源源不斷。

有時(shí)候這個(gè)需求沒做完又會出現(xiàn)新的一堆需求，這些需求都來自客戶的、技術(shù)的、領(lǐng)導(dǎo)的、團(tuán)隊(duì)討論的、運(yùn)營反饋的、產(chǎn)品經(jīng)理自己提出的、還有老板的靈感等等；這些需求來自四面八方。

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

1. 信息分散、導(dǎo)致需求遺漏

如果沒有需求池統(tǒng)一管理需求，我們就會將隨時(shí)隨地來自四面八方的需求隨意的記到方便記錄的地方；勤快些的會記錄在電腦的各類記事本或?qū)懺诒咀由?，還有過于自信童鞋就直接記在腦子里。

舉個(gè)例子：

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

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

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

這些都是因?yàn)閷⒘闵⒌男枨蟠鎯Φ讲煌牡胤剿鶎?dǎo)致的，時(shí)間久了還會導(dǎo)致需求遺漏；各種需求提出人來問，之前提的需求為什么還沒有實(shí)現(xiàn)？然后產(chǎn)品經(jīng)理壓根不記得或是找不到這個(gè)需求。

2. 沒有信息源頭追溯，傳遞需求時(shí)容易導(dǎo)致需求變形

假設(shè)我們有一天想實(shí)現(xiàn)一部分需求，這些需求包含自己收集的，也包含其他人收集到的需求經(jīng)過幾手最后到你手上的；當(dāng)我們在做產(chǎn)品設(shè)計(jì)的時(shí)候發(fā)現(xiàn)一些問題（這些問題會因?yàn)榛谠谀硞€(gè)成型產(chǎn)品做迭代而大幅度產(chǎn)生，有些是因?yàn)楫a(chǎn)品本身設(shè)計(jì)方式導(dǎo)致實(shí)現(xiàn)新需求而改動(dòng)較大），或者對需求內(nèi)容不理解，想找人確認(rèn)時(shí)，這時(shí)想找需求提出人又想不起來或不知道是誰提出的。

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

二、什么是需求池，創(chuàng)建需求池的目的

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

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

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

創(chuàng)建好需求池后，我們可以通過需求池中統(tǒng)計(jì)的信息去判斷需求和需求之間的關(guān)聯(lián)性，同時(shí)可以通過這些信息判斷并明確需求的優(yōu)先級，從而做好產(chǎn)品的版本規(guī)劃；我們在日后工作過程中可以按照優(yōu)先級隨用隨取，也可以按照制定好的版本按順序開發(fā)。

簡單理解，需求池是裝需求的池子——是需求管理和項(xiàng)目管理的依據(jù)；我們可以根據(jù)這些規(guī)則信息進(jìn)行制定需求的版本規(guī)劃，同時(shí)通過需求的記錄可以追溯到需求提出人，后續(xù)有問題作為和領(lǐng)導(dǎo)、老板溝通的依據(jù)。

三、如何創(chuàng)建需求池

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

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

為了方便理解，我將這些字段分成基礎(chǔ)信息及擴(kuò)展信息，基礎(chǔ)信息是創(chuàng)建需求池不可缺少的字段，擴(kuò)展信息可以在基礎(chǔ)信息上靈活調(diào)整，不是必填信息。

1. 基礎(chǔ)信息

基礎(chǔ)信息主要包含的信息有：編號、模塊、功能點(diǎn)、需求描述、場景描述、需求層次、需求類型、優(yōu)先級、商業(yè)價(jià)值、提出人、提出時(shí)間、狀態(tài)。

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

1）編號：需求的唯一標(biāo)識，可用序號羅列，也可以用日期+當(dāng)天提交需求的序號統(tǒng)計(jì)；作用是作為每條需求的唯一編號和快速查詢需求。

2）模塊：根據(jù)產(chǎn)品模塊去劃分，例如“個(gè)人中心”作用是將需求統(tǒng)一歸類到某個(gè)模塊下，在進(jìn)行版本規(guī)劃時(shí)，可以優(yōu)先從某個(gè)模塊中篩選，同時(shí)便于根據(jù)模塊查詢。

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

4）需求描述：需要描述清楚需求的完整性、一致性，需要精準(zhǔn)的描述；如果產(chǎn)品經(jīng)理在后續(xù)想不清楚這個(gè)需求到底要做什么，可以通過需求詳細(xì)描述來回想或了解。

5）場景描述：了解用戶在什么場景下產(chǎn)生的需求，便于我們分析需求背后的價(jià)值，在給開發(fā)轉(zhuǎn)述為什么要增加這個(gè)需求時(shí)，可以清晰的說明是因?yàn)槟男┰?，更能說服開發(fā)愿意做這個(gè)需求。

6）需求層次：分為基礎(chǔ)需求、增值需求、擴(kuò)展需求；便于產(chǎn)品經(jīng)理了解需求屬于哪個(gè)層級，可根據(jù)需求類型、需求價(jià)值、優(yōu)先級、需求層級等結(jié)合考慮版本規(guī)劃。

7）需求類型主要包含：

• 新增功能：目前平臺沒有實(shí)現(xiàn)的功能；
• 功能改進(jìn)：對目前平臺已實(shí)現(xiàn)的功能進(jìn)行優(yōu)化；
• bug修復(fù)：系統(tǒng)功能使用出現(xiàn)問題，與正確的設(shè)計(jì)邏輯不一致；
• 用戶體驗(yàn)：例如頁面按鈕擺放的問題，發(fā)送消息時(shí)發(fā)送按鈕放在右側(cè)，可以按照用戶的使 ??用習(xí)慣設(shè)計(jì)；
• UI優(yōu)化：頁面體現(xiàn)內(nèi)容，如按鈕顏色；
• 內(nèi)部需求：公司內(nèi)部產(chǎn)生的需求，如開發(fā)一個(gè)內(nèi)部OA系統(tǒng)；
• 刪除需求：對平臺已有的功能進(jìn)行簡化；
• 接口需求：使用對方提供的接口，或給對方提供接口。

產(chǎn)品經(jīng)理可以根據(jù)這些類型區(qū)分，在產(chǎn)品開發(fā)階段根據(jù)需求類型考慮先實(shí)現(xiàn)哪些，例如：在時(shí)間緊急的情況下，有新增功能和bug修復(fù)的情況下，我們會優(yōu)先解決bug修復(fù)這類型的問題，先保證項(xiàng)目不會出現(xiàn)問題。

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

商業(yè)價(jià)值：可以按照0-10標(biāo)注，不需要考慮實(shí)現(xiàn)難度，在需求討論時(shí)團(tuán)隊(duì)討論決策即可；提前分析好商業(yè)價(jià)值能幫助我們了解清楚當(dāng)前需求是否值得做，做完后能帶來什么價(jià)值；不做的話會有什么損失。

開發(fā)量：需求的開發(fā)工作量，可以通過這個(gè)信息規(guī)劃開發(fā)每個(gè)版本的工作內(nèi)容，也方便我們了解每個(gè)需求的開發(fā)難度。

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

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

狀態(tài)：需求的生命周期，待討論、暫緩（標(biāo)注原因）、拒絕、需求中、開發(fā)中、已發(fā)布；主要作用是可以對需求的流轉(zhuǎn)狀態(tài)進(jìn)行跟蹤，可以了解需求在不同階段的狀態(tài)，發(fā)現(xiàn)問題及時(shí)調(diào)整。

2. 擴(kuò)展信息

擴(kuò)展信息包含：

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

最終需求池的模版（基礎(chǔ)信息）：

最終需求池的模版（擴(kuò)展信息）：

四、總結(jié)

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

最終的模板字段需要按照公司實(shí)際業(yè)務(wù)靈活變動(dòng)，文中提供的字段信息僅為參考，主要目的是為了幫助產(chǎn)品經(jīng)理創(chuàng)建并管理自己的需求池。

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

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