巧婦難爲無米之炊。
對於產品經理來說，需求就是用來煮飯的米。
但產品經理的工作可比熬一鍋粥要複雜多了，不光要基於需求設計產品，需求的管理能力也極其重要。
很多時候，糟糕的需求管理，會使產品工作亂成一團，甚至導致項目的失敗。
作爲產品狗，需要經常體驗各種產品，也常遇到需求管理失敗的案例。
最近就有這麼一次糟糕的體驗：
一款定位小衆社交的App，名字就不說了。
產品邏輯是，通過心理測試，確定性格分型，匹配陌生人。
心理測試分爲：初級、中級及高級等三個階段，每深入一級就更準確。
然而，問題就出在心理測試上。
我在完成了高級測試後，測試結果依舊是中級的結果，高級測試的狀態則是未完成。
我嘗試了重新答題、重新登陸、註冊新號、甚至卸載重裝，老樣子。
換臺iphone手機，問題依舊（android正常）。
於是，我在App內的用戶反饋功能中，詳細描述了該問題。
一週後，App更新，Bug依舊。
接着，我在Appstore上面通過評價的方式，再次詳細描述了該問題。
半個月後，App更新，Bug依舊。
最後，我按照官方網站的郵箱，講問題描述再次反饋。
一週後，App更新，Bug迎風招展。
在堅持了一個多月之後，我默默的放棄了它。
如此糟糕的Bug管理，絕不是偶然。今天順眼看了下在Appstore，簡直就是車禍現場。
（如下信息，是我按照一星進行的篩選，實際並非全部都是差評）
我如此執着地反饋問題，卻毫無結果，我只能推測：
要麼他們看到了，卻沒有有效處理；
要麼就是他們連看都沒有看到。
不管是哪種，都說明需求管理能力缺失。
需求管理的重要性
產品經理工作的核心就是採集、加工和傳遞信息，而最重要的信息就是需求。就算idea再棒，就算開發效率再高，就算運營團隊推廣效果再好，需求管理不好，負面都會被不斷放大。
卸載前，我發了最後感悟：
「眼看他起朱樓，眼看他宴賓客，眼看他樓塌了」
你可能會有疑問，前面說的不是Bug麼？
不論是反饋者，反饋渠道，或是反饋方式，Bug和需求都是共享的。
用戶訪談時，他會反饋需求，也會反饋Bug。
老闆找你溝通時，會提想法，也會告訴你他看到的問題。
所以我更傾向於，將Bug作爲（廣義上的）需求的一種。狹義需求當作一種正向需求，而Bug則作爲一種反向（優先級更高）需求。
同時，把Bug作爲需求，還有一個優點。
像對待需求一樣，對Bug進行分析，而不是原封不動的直接拋給開發。
經過分析，你有可能發現它不是Bug，而是需要培訓用戶，或是轉化爲新需求。而確定是Bug的，經過你的分析後再交給開發，本身已經完成蒐集、復現和定位等環節，修復速度也必然會快很多。
下文所說的需求和需求管理，都是廣義上（除非特指）的。即將狹義需求和Bug都作爲廣義需求來統一說明。
需求的種類
講需求管理之前，先對需求的種類做個全面認識。全面認識需求的種類（區分維度），有助於在管理需求時，做到兼顧所有情況。
需求的種類（區分維度）有：
- 來源（提出方）：用戶（客戶）、協作方（開發、運營、銷售、項目等）、管理層（投資人、老闆、上司）等；
- 渠道：訪談、問卷、內部會議、內部系統、IM、產品內反饋、服務郵箱等；
- 形式：錄音、錄像、文檔、郵件、會議記錄、留言、聊天記錄等；
- 類型：就是前面說的，正向需求和反向需求（Bug）兩種；
- 場景：正式使用、體驗產品、開發測試、產品演示等；
- 緊急重要度：有很多方法，建議使用四象限法（重要緊急、重要不緊急、緊急不重要及不緊急不重要），或直接用1、2、3、4級代替。
需求管理的四個階段
需求管理全過程可以分爲四個階段：
- 需求的採集，維護高效穩定的採集渠道和合理的記錄規範；
- 需求的處理，對採集到的需求進行篩選和加工明確；
- 需求的實現，對加工明確後的需求進行規劃和開發；
- 需求的反饋，反饋需求信息的處理給需求來源。
通過這四個步驟，做到對需求信息有效管理。
採集階段
採集階段，就是我們蒐集並記錄需求信息的階段，是需求管理的起點。
首先，回憶一下：
你是如何採集需求的？
你日常獲得的需求中，有多少比例是提出者告知你的？
你是否經常主動去獲取各類需求？
你有主動維護需求獲取渠道的習慣麼？
如果，你可以做到主動獲取各類需求，甚至主動維護需求獲取渠道，那麼你已經超過90%的產品經理。
而更常見的情況是，很多產品經理只被動接受需求，也從不維護需求來源。
前面已經講過，需求有多種來源、渠道和場景。
而每款產品，來源、渠道和場景之間的相關度也會不同。
比如，A產品的用戶更喜歡通過產品內的用戶反饋和郵件來反饋需求，但是B產品的用戶，則可能更喜歡面對面反饋信息。
多關注日常獲取到的需求信息，努力尋找和明確你的產品中，各類人羣（來源）喜歡通過什麼途徑（渠道）反饋哪種類型（場景）的問題。
針對各類人羣建立合適的反饋路徑，逐漸明白哪邊的需求多久採集一次，哪類人羣需要採用什麼方法促進反饋。
慢慢你會發現，你能獲取到的信息會越來越全面，你離產品的真相也更進一步。
採集階段，光做好採集還遠遠不夠。
正如我那次糟糕的經歷，我相信，他們獲取到了我的反饋。
但也許很快，更多更雜的反饋出現，他們迷失其中……
沒有對信息的有效管理，信息就沒有任何價值。
做好了需求信息的開源，下一步就是做好需求信息的記錄。有效的記錄方法，不光可以讓需求變得有序，接下來的需求處理、需求實現、需求反饋，也依賴良好的記錄。
需求記錄，就是把一條條的需求記錄下來，同時補齊需求的種類等信息。
我習慣的做法是通過兩張表來管理所有的需求：
- 採集記錄表
所有采集的需求信息，均按照採集的順序編號記錄。
它是一張完整的需求表，事無鉅細的記錄採集到的每一條需求（包括你覺得可笑的需求）。
- 處理跟蹤表
只記錄完成處理階段後，進入實現階段的需求。
它是一張指導產品規劃和實現的跟蹤表，只包含最後進入實際產品工作的需求。
爲什麼要分成兩張表？
我先說只有其中一張，會怎麼樣。
-
如果只有「採集記錄表」
每次使用這張表指導需求實現時，都會受到冗餘無效需求（那些在處理環節被篩選掉的）的干擾。
同時，如果你想在這張表上體現，歸屬什麼產品線、哪個版本實現、當前實現進度等，就必要增加字段。而這些多出來的字段，被篩選掉的需求卻並不需要。
最後，難道每次初步溝通需求時，都要讓老闆、同事都面對這麼一張龐大的信息表麼？ -
如果只有「處理跟蹤表」
也許你每次處理完需求，都把那些不做的需求給刪掉了……
但是，如果你發現一條需求有些熟悉，之前被你幹掉過，那你還能記起你當時處決它的理由麼？
當你要反饋結果給提出者時（包括不做的理由），信息都沒了，你還怎麼反饋？
所以，我會把所有采集的需求記錄在「採集記錄表」，在處理階段繼續使用它。
處理過後的需求，保留的轉移到「處理跟蹤表」，在實現階段使用，同時定期更新回「採集記錄表」。否決的，直接在「採集記錄表」中記錄否決原因等信息。
反饋結果給需求提出者時，只看「採集記錄表」就好了。
處理階段
處理階段的工作有兩項：篩選需求和明確需求
篩選需求
首先，對採集到的需求進行初步判斷，要不要讓它進入後續的實現階段。
要判斷正向需求（狹義需求）和反向需求（Bug）。
如果是Bug，判斷其是否真的是Bug。
如下情況，都不需要當作Bug來修復 。
- 用戶誤操作，導致出現問題。
比如，企業管理員在中臺誤操作刪除了用戶權限，導致他們的員工打不開報表。 - 用戶不會使用功能。
比如，管理員沒有將業務環節中必備的組織架構配置好，導致員工無法正常使用。 - 功能不夠完善。
比如，員工的填寫表單後，因爲沒有自動保存功能，經常未保存退出，導致內容丟失。 - 無法復現。
比如，只有極少數情況下出現，反饋後在任何環境下，都無法再次出現的問題。
如上這些不需要修復的Bug，不代表就可以直接刪除了事。
需要針對具體情況，進行處理。
誤操作和不會使用的情況，我們需要反思，對客戶的培訓是否到位。
功能不夠完善的情況，我們可以轉化爲新的狹義需求。
無法復現的情況，也要特別關注，如果再次出現，可以對比兩次情況，尋找可能性。
如果是（狹義的）需求，則判斷是否要去實現它。
狹義需求的取捨，主要依靠已經確立的產品戰略。
可以參照我的原創文章《如何系統性思考產品需求-產品問答第一篇》
這裏就不展開了。
所有決定不實現的需求，都需要對提出者進行有效反饋，留到反饋階段慢慢說。
明確需求
我們也需要對採集到的需求進行明確。
首先，明確需求的類型，到底是Bug還是狹義需求。
然後，我們要對需求的信息進行全面蒐集。
找需求來源進一步溝通，獲取更多信息
大部分人在溝通時，都會對信息進行加工，這會產生信息缺失。
可能是覺得某些背景信息，大家都知道，不需要再說一遍；可能是覺得某些細節不是關鍵信息，所以故意略去；可能是完全沒有察覺某些相關信息。
信息的缺失，會讓需求變得難以理解或產生偏差。
找到需求的提出者進行溝通，使用“5W1H”提問法，不斷循序漸進的提問。
如果是Bug，要了解清楚它發生的具體場景，發生在什麼情況下，什麼機型，什麼系統，使用的賬戶，前面做了什麼操作等等；
如果是狹義需求，要了解提出它的背景，基於什麼場景，希望達到什麼目的，是否還有其他相關意願，偶然提出還是長久期望等等。對需求進行分析
獲取儘可能多關於需求的信息，對信息進行分析，進一步消化需求。
可以通過演繹法和歸納法，推斷出需求的規律和更深層次原因。
需求分析可參照《如何深入挖掘用戶需求-產品問答第二篇》，這裏不再展開。假設初步實現方案
對需求進行分析之後，在進入實施環節之前，我們可以嘗試初步假設多個實現方案。
在實現階段前，初步假設實現方案的好處有很多：
a.可以檢驗是否真的瞭解需求。
很多時候我們覺得已經完全瞭解需求，但是進行功能規劃時，才發覺還需要補充信息，又要找到提出者進行溝通。
b. 可以快速獲取反饋者的驗證。
具像化的方案，能讓提出者看到，他提出的需求是否得到理解，也讓他對產品產生期待。
c. 可以讓實現團隊快速理解需求
提出多個初步方案，可以幫助實現團隊（產品和開發）快速理解需求，也可以讓他們更容易提出合理化建議，併爲實現階段做好準備。
完成篩選和明確後，保留下來的需求，我們要確定重要緊急度及在哪個版本去實現。
你應該已經發現，篩選和明確並不是完全獨立，一前一後的工作。而是互相滲透，互相支撐。
需求的處理階段，你需要明確需求才能更好的篩選需求，同時篩選後確定實現的，也正是你要花更多力氣去明確的需求。
處理階段的信息，是在「採集記錄表」中更新。
經過處理階段，保留下來的需求，確定了實現版本和重要度，接着就進入實現階段了。
實現階段
實現階段有兩項工作：功能規劃和功能開發
功能規劃
從處理階段傳遞過來的需求，安排了具體的產品線及版本，明確了優先級。
我們要做的就是把它們規劃成一個個的功能，並通過產品規劃交付物的方式來輸出給相關團隊。
這部分工作，是產品經理日常工作中，所佔比重最大的。
正因如此，很多產品經理沉溺其中，逐漸變成一個“畫原型的”或“寫文檔的”。這是很危險的！通過前面兩個階段介紹，你可以發現：做不好需求採集和處理，直接進行需求實現是多麼可怕。
具體的功能規劃，涉及到的方法論和工具，有許多書籍和文章都在講，我就不再贅述。
我要強調的唯一一點就是，提高對產品規劃交付物的標準。不要讓自己的原型和文檔，成爲阻礙開發的障礙。有興趣可以看我這篇《提崗管理後的團隊管理及項目管理-產品問答第三篇》
功能開發
功能進行開發階段，產品經理的注意點就轉化爲項目管理。
項目管理不僅僅要管理項目的進度，還要管理項目的質量。
同樣在《提崗管理後的團隊管理及項目管理-產品問答第三篇》這篇文章中，我有詳細講。
實現階段的需求信息，要及時更新到「跟蹤記錄表」中。
反饋階段
需求不光要採集、處理和實現，還要不斷讓信息迴流，反饋給需求的源頭-提出者，讓需求管理成爲閉環。
需求的反饋，不是等前三個階段完成後，再去獨立進行的。
在採集、處理和實現階段，要一直保持反饋的習慣。
- 在採集階和處理階段，我們可能會不斷找反饋者溝通，以獲取更加全面的信息；
- 在處理階段，我們反饋信息給提出者：需求是否要實現及何時實現，或是爲什麼不實現；
- 在處理階段，我們還要反饋初步方案，讓提出者確信併產生期待；
-
在實現階段，我們要有節奏的反饋實現進展，並在實現時儘可能的告知提出者，甚至準備好相關培訓。
![]()
良好的需求反饋習慣，可以讓需求管理的可信度更高，而不是將功能規劃和開發變成“閉門造車”。
反饋階段主要維護「採集記錄表」，但需要及時將「跟蹤記錄表」的信息同步進去。
最後強調，需求管理的四個階段，也不是互相獨立，互分先後的。
實際的需求管理工作，可能會有多個階段的工作在同步進行。需求管理，需要你努力練習，完成技能內化，最終成爲你的核心武器。
千萬別當一隻日夜操勞的工蜂！一個需求的搬運工，不是合格的產品人。