有效的需求管理對于產(chǎn)品來說十分有必要，需求管理分為四個(gè)階段：采集、處理、實(shí)現(xiàn)、反饋。

巧婦難為無米之炊。

對于產(chǎn)品經(jīng)理來說，需求就是用來煮飯的米。

但產(chǎn)品經(jīng)理的工作可比熬一鍋粥要復(fù)雜多了，不光要基于需求設(shè)計(jì)產(chǎn)品，需求的管理能力也極其重要。

很多時(shí)候，糟糕的需求管理，會使產(chǎn)品工作亂成一團(tuán)，甚至導(dǎo)致項(xiàng)目的失敗。

作為產(chǎn)品狗，需要經(jīng)常體驗(yàn)各種產(chǎn)品，也常遇到需求管理失敗的案例。

最近就有這么一次糟糕的體驗(yàn)：

一款定位小眾社交的App，名字就不說了。

產(chǎn)品邏輯是，通過心理測試，確定性格分型，匹配陌生人。

心理測試分為：初級、中級及高級等三個(gè)階段，每深入一級就更準(zhǔn)確。然而，問題就出在心理測試上。

我在完成了高級測試后，測試結(jié)果依舊是中級的結(jié)果，高級測試的狀態(tài)則是未完成。

我嘗試了重新答題、重新登陸、注冊新號、甚至卸載重裝，老樣子。

換臺iphone手機(jī)，問題依舊（android正常）。

于是，我在App內(nèi)的用戶反饋功能中，詳細(xì)描述了該問題。

一周后，App更新，Bug依舊。

接著，我在Appstore上面通過評價(jià)的方式，再次詳細(xì)描述了該問題。

半個(gè)月后，App更新，Bug依舊。

最后，我按照官方網(wǎng)站的郵箱，講問題描述再次反饋。

一周后，App更新，Bug迎風(fēng)招展。

在堅(jiān)持了一個(gè)多月之后，我默默的放棄了它。

如此糟糕的Bug管理，絕不是偶然。今天順眼看了下在Appstore，簡直就是車禍現(xiàn)場。

（如下信息，是我按照一星進(jìn)行的篩選，實(shí)際并非全部都是差評）

我如此執(zhí)著地反饋問題，卻毫無結(jié)果，我只能推測：要么他們看到了，卻沒有有效處理；要么就是他們連看都沒有看到。不管是哪種，都說明需求管理能力缺失。

需求管理的重要性

產(chǎn)品經(jīng)理工作的核心就是采集、加工和傳遞信息，而最重要的信息就是需求。就算idea再棒，就算開發(fā)效率再高，就算運(yùn)營團(tuán)隊(duì)推廣效果再好，需求管理不好，負(fù)面都會被不斷放大。

卸載前，我發(fā)了最后感悟：眼看他起朱樓，眼看他宴賓客，眼看他樓塌了。

你可能會有疑問，前面說的不是Bug么？

不論是反饋者，反饋渠道，或是反饋方式，Bug和需求都是共享的。

用戶訪談時(shí)，他會反饋需求，也會反饋Bug。

老板找你溝通時(shí)，會提想法，也會告訴你他看到的問題。

所以我更傾向于，將Bug作為（廣義上的）需求的一種。狹義需求當(dāng)作一種正向需求，而Bug則作為一種反向（優(yōu)先級更高）需求。

同時(shí)，把Bug作為需求，還有一個(gè)優(yōu)點(diǎn)。

像對待需求一樣，對Bug進(jìn)行分析，而不是原封不動的直接拋給開發(fā)。

經(jīng)過分析，你有可能發(fā)現(xiàn)它不是Bug，而是需要培訓(xùn)用戶，或是轉(zhuǎn)化為新需求。而確定是Bug的，經(jīng)過你的分析后再交給開發(fā)，本身已經(jīng)完成搜集、復(fù)現(xiàn)和定位等環(huán)節(jié)，修復(fù)速度也必然會快很多。

下文所說的需求和需求管理，都是廣義上（除非特指）的。即將狹義需求和Bug都作為廣義需求來統(tǒng)一說明。

需求的種類

講需求管理之前，先對需求的種類做個(gè)全面認(rèn)識。全面認(rèn)識需求的種類（區(qū)分維度），有助于在管理需求時(shí)，做到兼顧所有情況。

需求的種類（區(qū)分維度）有：

• 來源（提出方）：用戶（客戶）、協(xié)作方（開發(fā)、運(yùn)營、銷售、項(xiàng)目等）、管理層（投資人、老板、上司）等；
• 渠道：訪談、問卷、內(nèi)部會議、內(nèi)部系統(tǒng)、IM、產(chǎn)品內(nèi)反饋、服務(wù)郵箱等；
• 形式：錄音、錄像、文檔、郵件、會議記錄、留言、聊天記錄等；
• 類型：就是前面說的，正向需求和反向需求（Bug）兩種；
• 場景：正式使用、體驗(yàn)產(chǎn)品、開發(fā)測試、產(chǎn)品演示等；
• 緊急重要度：有很多方法，建議使用四象限法（重要緊急、重要不緊急、緊急不重要及不緊急不重要），或直接用1、2、3、4級代替。

需求管理的四個(gè)階段

需求管理全過程可以分為四個(gè)階段：

• 需求的采集，維護(hù)高效穩(wěn)定的采集渠道和合理的記錄規(guī)范；
• 需求的處理，對采集到的需求進(jìn)行篩選和加工明確；
• 需求的實(shí)現(xiàn)，對加工明確后的需求進(jìn)行規(guī)劃和開發(fā)；
• 需求的反饋，反饋需求信息的處理給需求來源。

通過這四個(gè)步驟，做到對需求信息有效管理。

采集階段

采集階段，就是我們搜集并記錄需求信息的階段，是需求管理的起點(diǎn)。
首先，回憶一下：

• 你是如何采集需求的？
• 你日常獲得的需求中，有多少比例是提出者告知你的？
• 你是否經(jīng)常主動去獲取各類需求？
• 你有主動維護(hù)需求獲取渠道的習(xí)慣么？

如果，你可以做到主動獲取各類需求，甚至主動維護(hù)需求獲取渠道，那么你已經(jīng)超過90%的產(chǎn)品經(jīng)理。

而更常見的情況是，很多產(chǎn)品經(jīng)理只被動接受需求，也從不維護(hù)需求來源。

前面已經(jīng)講過，需求有多種來源、渠道和場景。

而每款產(chǎn)品，來源、渠道和場景之間的相關(guān)度也會不同。

比如，A產(chǎn)品的用戶更喜歡通過產(chǎn)品內(nèi)的用戶反饋和郵件來反饋需求，但是B產(chǎn)品的用戶，則可能更喜歡面對面反饋信息。

多關(guān)注日常獲取到的需求信息，努力尋找和明確你的產(chǎn)品中，各類人群（來源）喜歡通過什么途徑（渠道）反饋哪種類型（場景）的問題。

針對各類人群建立合適的反饋路徑，逐漸明白哪邊的需求多久采集一次，哪類人群需要采用什么方法促進(jìn)反饋。

慢慢你會發(fā)現(xiàn)，你能獲取到的信息會越來越全面，你離產(chǎn)品的真相也更進(jìn)一步。

采集階段，光做好采集還遠(yuǎn)遠(yuǎn)不夠。

正如我那次糟糕的經(jīng)歷，我相信，他們獲取到了我的反饋。

但也許很快，更多更雜的反饋出現(xiàn)，他們迷失其中……

沒有對信息的有效管理，信息就沒有任何價(jià)值。

做好了需求信息的開源，下一步就是做好需求信息的記錄。有效的記錄方法，不光可以讓需求變得有序，接下來的需求處理、需求實(shí)現(xiàn)、需求反饋，也依賴良好的記錄。

需求記錄，就是把一條條的需求記錄下來，同時(shí)補(bǔ)齊需求的種類等信息。

我習(xí)慣的做法是通過兩張表來管理所有的需求：

采集記錄表

所有采集的需求信息，均按照采集的順序編號記錄。

它是一張完整的需求表，事無巨細(xì)的記錄采集到的每一條需求（包括你覺得可笑的需求）。

僅供參考，可根據(jù)具體情況增減字段

處理跟蹤表
只記錄完成處理階段后，進(jìn)入實(shí)現(xiàn)階段的需求。
它是一張指導(dǎo)產(chǎn)品規(guī)劃和實(shí)現(xiàn)的跟蹤表，只包含最后進(jìn)入實(shí)際產(chǎn)品工作的需求。

僅供參考，可根據(jù)具體情況增減字段

為什么要分成兩張表？

我先說只有其中一張，會怎么樣。

如果只有「采集記錄表」：

每次使用這張表指導(dǎo)需求實(shí)現(xiàn)時(shí)，都會受到冗余無效需求（那些在處理環(huán)節(jié)被篩選掉的）的干擾。

同時(shí)，如果你想在這張表上體現(xiàn)，歸屬什么產(chǎn)品線、哪個(gè)版本實(shí)現(xiàn)、當(dāng)前實(shí)現(xiàn)進(jìn)度等，就必要增加字段。而這些多出來的字段，被篩選掉的需求卻并不需要。

最后，難道每次初步溝通需求時(shí)，都要讓老板、同事都面對這么一張龐大的信息表么？

如果只有「處理跟蹤表」：

也許你每次處理完需求，都把那些不做的需求給刪掉了……

但是，如果你發(fā)現(xiàn)一條需求有些熟悉，之前被你干掉過，那你還能記起你當(dāng)時(shí)處決它的理由么？

當(dāng)你要反饋結(jié)果給提出者時(shí)（包括不做的理由），信息都沒了，你還怎么反饋？

所以，我會把所有采集的需求記錄在「采集記錄表」，在處理階段繼續(xù)使用它。

處理過后的需求，保留的轉(zhuǎn)移到「處理跟蹤表」，在實(shí)現(xiàn)階段使用，同時(shí)定期更新回「采集記錄表」。否決的，直接在「采集記錄表」中記錄否決原因等信息。

反饋結(jié)果給需求提出者時(shí)，只看「采集記錄表」就好了。

處理階段

處理階段的工作有兩項(xiàng)：篩選需求和明確需求。

篩選需求

首先，對采集到的需求進(jìn)行初步判斷，要不要讓它進(jìn)入后續(xù)的實(shí)現(xiàn)階段。

要判斷正向需求（狹義需求）和反向需求（Bug）。

如果是Bug，判斷其是否真的是Bug。

如下情況，都不需要當(dāng)作Bug來修復(fù)。

• 用戶誤操作，導(dǎo)致出現(xiàn)問題。
  比如，企業(yè)管理員在中臺誤操作刪除了用戶權(quán)限，導(dǎo)致他們的員工打不開報(bào)表。
• 用戶不會使用功能。
  比如，管理員沒有將業(yè)務(wù)環(huán)節(jié)中必備的組織架構(gòu)配置好，導(dǎo)致員工無法正常使用。
• 功能不夠完善。
  比如，員工的填寫表單后，因?yàn)闆]有自動保存功能，經(jīng)常未保存退出，導(dǎo)致內(nèi)容丟失。
• 無法復(fù)現(xiàn)。
  比如，只有極少數(shù)情況下出現(xiàn)，反饋后在任何環(huán)境下，都無法再次出現(xiàn)的問題。

如上這些不需要修復(fù)的Bug，不代表就可以直接刪除了事。

需要針對具體情況，進(jìn)行處理。

誤操作和不會使用的情況，我們需要反思，對客戶的培訓(xùn)是否到位。

功能不夠完善的情況，我們可以轉(zhuǎn)化為新的狹義需求。

無法復(fù)現(xiàn)的情況，也要特別關(guān)注，如果再次出現(xiàn)，可以對比兩次情況，尋找可能性。

如果是（狹義的）需求，則判斷是否要去實(shí)現(xiàn)它。

狹義需求的取舍，主要依靠已經(jīng)確立的產(chǎn)品戰(zhàn)略。

可以參照我的原創(chuàng)文章《如何系統(tǒng)性思考產(chǎn)品需求-產(chǎn)品問答第一篇》
這里就不展開了。

所有決定不實(shí)現(xiàn)的需求，都需要對提出者進(jìn)行有效反饋，留到反饋階段慢慢說。

明確需求

我們也需要對采集到的需求進(jìn)行明確。

首先，明確需求的類型，到底是Bug還是狹義需求。

然后，我們要對需求的信息進(jìn)行全面搜集。

1. 找需求來源進(jìn)一步溝通，獲取更多信息；

大部分人在溝通時(shí)，都會對信息進(jìn)行加工，這會產(chǎn)生信息缺失。

可能是覺得某些背景信息，大家都知道，不需要再說一遍；可能是覺得某些細(xì)節(jié)不是關(guān)鍵信息，所以故意略去；可能是完全沒有察覺某些相關(guān)信息。

信息的缺失，會讓需求變得難以理解或產(chǎn)生偏差。

找到需求的提出者進(jìn)行溝通，使用“5W1H”提問法，不斷循序漸進(jìn)的提問。

如果是Bug，要了解清楚它發(fā)生的具體場景，發(fā)生在什么情況下，什么機(jī)型，什么系統(tǒng)，使用的賬戶，前面做了什么操作等等；

如果是狹義需求，要了解提出它的背景，基于什么場景，希望達(dá)到什么目的，是否還有其他相關(guān)意愿，偶然提出還是長久期望等等。

2. 對需求進(jìn)行分析

獲取盡可能多關(guān)于需求的信息，對信息進(jìn)行分析，進(jìn)一步消化需求。

可以通過演繹法和歸納法，推斷出需求的規(guī)律和更深層次原因。

需求分析可參照《如何深入挖掘用戶需求-產(chǎn)品問答第二篇》，這里不再展開。

3. 假設(shè)初步實(shí)現(xiàn)方案

對需求進(jìn)行分析之后，在進(jìn)入實(shí)施環(huán)節(jié)之前，我們可以嘗試初步假設(shè)多個(gè)實(shí)現(xiàn)方案。
在實(shí)現(xiàn)階段前，初步假設(shè)實(shí)現(xiàn)方案的好處有很多：

a.可以檢驗(yàn)是否真的了解需求。

很多時(shí)候我們覺得已經(jīng)完全了解需求，但是進(jìn)行功能規(guī)劃時(shí)，才發(fā)覺還需要補(bǔ)充信息，又要找到提出者進(jìn)行溝通。

b. 可以快速獲取反饋者的驗(yàn)證。

具像化的方案，能讓提出者看到，他提出的需求是否得到理解，也讓他對產(chǎn)品產(chǎn)生期待。

c. 可以讓實(shí)現(xiàn)團(tuán)隊(duì)快速理解需求。

提出多個(gè)初步方案，可以幫助實(shí)現(xiàn)團(tuán)隊(duì)（產(chǎn)品和開發(fā)）快速理解需求，也可以讓他們更容易提出合理化建議，并為實(shí)現(xiàn)階段做好準(zhǔn)備。

完成篩選和明確后，保留下來的需求，我們要確定重要緊急度及在哪個(gè)版本去實(shí)現(xiàn)。

你應(yīng)該已經(jīng)發(fā)現(xiàn)，篩選和明確并不是完全獨(dú)立，一前一后的工作。而是互相滲透，互相支撐。

需求的處理階段，你需要明確需求才能更好的篩選需求，同時(shí)篩選后確定實(shí)現(xiàn)的，也正是你要花更多力氣去明確的需求。

處理階段的信息，是在「采集記錄表」中更新。

經(jīng)過處理階段，保留下來的需求，確定了實(shí)現(xiàn)版本和重要度，接著就進(jìn)入實(shí)現(xiàn)階段了。

實(shí)現(xiàn)階段

實(shí)現(xiàn)階段有兩項(xiàng)工作：功能規(guī)劃和功能開發(fā)。

功能規(guī)劃

從處理階段傳遞過來的需求，安排了具體的產(chǎn)品線及版本，明確了優(yōu)先級。

我們要做的就是把它們規(guī)劃成一個(gè)個(gè)的功能，并通過產(chǎn)品規(guī)劃交付物的方式來輸出給相關(guān)團(tuán)隊(duì)。

這部分工作，是產(chǎn)品經(jīng)理日常工作中，所占比重最大的。

正因如此，很多產(chǎn)品經(jīng)理沉溺其中，逐漸變成一個(gè)“畫原型的”或“寫文檔的”。這是很危險(xiǎn)的！通過前面兩個(gè)階段介紹，你可以發(fā)現(xiàn)：做不好需求采集和處理，直接進(jìn)行需求實(shí)現(xiàn)是多么可怕。

具體的功能規(guī)劃，涉及到的方法論和工具，有許多書籍和文章都在講，我就不再贅述。

我要強(qiáng)調(diào)的唯一一點(diǎn)就是，提高對產(chǎn)品規(guī)劃交付物的標(biāo)準(zhǔn)。不要讓自己的原型和文檔，成為阻礙開發(fā)的障礙。有興趣可以看我這篇《產(chǎn)品問答 | 提崗管理后，如何進(jìn)行團(tuán)隊(duì)管理及項(xiàng)目管理？》。

功能開發(fā)

功能進(jìn)行開發(fā)階段，產(chǎn)品經(jīng)理的注意點(diǎn)就轉(zhuǎn)化為項(xiàng)目管理。
項(xiàng)目管理不僅僅要管理項(xiàng)目的進(jìn)度，還要管理項(xiàng)目的質(zhì)量。
同樣在《產(chǎn)品問答 | 提崗管理后，如何進(jìn)行團(tuán)隊(duì)管理及項(xiàng)目管理？》這篇文章中，我有詳細(xì)講。

實(shí)現(xiàn)階段的需求信息，要及時(shí)更新到「跟蹤記錄表」中。

反饋階段

需求不光要采集、處理和實(shí)現(xiàn)，還要不斷讓信息回流，反饋給需求的源頭-提出者，讓需求管理成為閉環(huán)。

需求的反饋，不是等前三個(gè)階段完成后，再去獨(dú)立進(jìn)行的。

在采集、處理和實(shí)現(xiàn)階段，要一直保持反饋的習(xí)慣。

• 在采集階和處理階段，我們可能會不斷找反饋者溝通，以獲取更加全面的信息；
• 在處理階段，我們反饋信息給提出者：需求是否要實(shí)現(xiàn)及何時(shí)實(shí)現(xiàn)，或是為什么不實(shí)現(xiàn)；
• 在處理階段，我們還要反饋初步方案，讓提出者確信并產(chǎn)生期待；
• 在實(shí)現(xiàn)階段，我們要有節(jié)奏的反饋實(shí)現(xiàn)進(jìn)展，并在實(shí)現(xiàn)時(shí)盡可能的告知提出者，甚至準(zhǔn)備好相關(guān)培訓(xùn)。

良好的需求反饋習(xí)慣，可以讓需求管理的可信度更高，而不是將功能規(guī)劃和開發(fā)變成“閉門造車”。

反饋階段主要維護(hù)「采集記錄表」，但需要及時(shí)將「跟蹤記錄表」的信息同步進(jìn)去。

最后強(qiáng)調(diào)，需求管理的四個(gè)階段，也不是互相獨(dú)立，互分先后的。

實(shí)際的需求管理工作，可能會有多個(gè)階段的工作在同步進(jìn)行。需求管理，需要你努力練習(xí)，完成技能內(nèi)化，最終成為你的核心武器。

千萬別當(dāng)一只日夜操勞的工蜂！一個(gè)需求的搬運(yùn)工，不是合格的產(chǎn)品人。

#專欄作家#

十八子殺，微信公眾號：產(chǎn)品狗的思考（ID：PM-Doggy）。人人都是產(chǎn)品經(jīng)理專欄作家。10年產(chǎn)品人，擅長基于業(yè)務(wù)尋找問題領(lǐng)域，然后抽象業(yè)務(wù)需求，搭建靈活度較高的業(yè)務(wù)系統(tǒng)。

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

題圖來自@Unsplash, 基于CC0協(xié)議