系統學習過專案管理(無論是PMP還是資訊系統專案管理師)的同學應該都有感觸，很多專案失敗的重要原因是需求管理做的不夠好。
這些專案往往在開始的時候就已經註定了失敗，無論專案組後面再怎麼努力再怎麼加班，都很難力挽狂瀾把專案救活。
很多產品經理認為需求管理這是PMO和專案經理的事情，自己只需要做好需求分析，需求(原型)設計，需求評審和需求跟進即可。殊不知專案經理和產品經理是需求的第一道防線，需求如果一開始沒管理好，那後續的專案推進會特別難。
01 需求是什麼
關於需求最著名的就是馬斯洛的“需求金字塔”，馬斯洛把需求分成了5個層次：生理需求、安全需求、社會需求、尊重需求、自我實現需求。
圖.馬斯洛的需求金字塔
但上面這個需求的定義太泛泛了，在產品經理的語言體系裡面，需求就是可以解決內外部客戶具體問題而提出，當前尚未滿足的要求。
以我們經常使用的微信朋友圈舉例說明。
我準備五一小長假去成都繞城綠道騎行打卡，但小紅書攻略太多找了半天都沒找到合適的，DeepSeek給的建議不夠全面，然後我猛然想起好友張三去年五一去綠道騎行打過卡並且還在朋友圈分享了詳細的攻略。
於是我就去翻張三的朋友圈，雖然張三朋友圈的內容全部可見，但張三本人酷愛分享，平均每天能發2-3條朋友圈，要想翻到1年前的內容就有點費勁了。
於是我就有了個需求：檢視朋友圈內容時能不能按年份和月份篩選？這就是上文說的解決客戶(也就是我)具體問題(快速查詢定位)而提出的，當前尚未滿足的需求。
有人說你可以用微信的(朋友圈)搜尋功能，這裡還可以選擇朋友和釋出時間，但問題是這種搜尋的前提是朋友圈內容有文字才會有效，純圖片或者純影片的搜不出來。
還有種情況就是搜尋關鍵字和好友朋友圈的文案內容可能不匹配。例如上圖我搜索的是年夜飯，好友發的文案裡面都是新年祝福語，根本沒有年夜飯這個關鍵字。
上面那個翻好友朋友圈歷史記錄的事情，我遇到過，我周圍的朋友同事也遇到過，在不願意打擾好友且不知道內容關鍵字的前提下，只有不停地向前翻找檢視。
好友的朋友圈無法按年份月份篩選，但我自己的朋友圈內容卻可以按年月來快速查詢(如下圖所示)，讀者們可以想想看微信為何會差別對待呢？
上面朋友圈的那個算是正常的需求，知乎上有人跟帖分享過各類奇葩的需求，比如：10多人的小公司老闆要求員工寫一款Java這樣的程式語言，2000塊錢做個淘寶，3000塊錢做個百度等等。
02 需求的來源
需求按照不同的維度可以有多種劃分方式，如下就是比較常見的需求型別分類方法。
那麼需求又是從哪裡來呢？常見的典型途徑有下面這些。
公司戰略：這個相對比較好理解，產品為了獲得更多的使用者和市場份額，公司為了打造自己的核心競爭力，提高准入門檻或壁壘，就需要有一些差異化的功能來實現。或者公司為了開闢新業務，就會有新需求。
例如海底撈麵向直營門店的內部訂貨平臺要打造為開放性的訂貨平臺，這就會有供應商入駐，供應商稽核、商品釋出、訂單支付、供應商管理端、清分結算等一系列的需求誕生。
使用者反饋：使用者可能會在產品內的建議反饋模組給產品提需求，也可能在微博、小紅書、百度貼吧、微信群和知乎等渠道吐槽提意見。為什麼要覆蓋這麼多的渠道呢？
因為我們的使用者也是這些平臺的使用者，他們習慣於在自己熟悉或喜歡的平臺去發聲，而每個渠道的使用者特點也有所不同。
-
產品內得到的反饋多來自重度使用者，畢竟這個反饋入口不好找。 -
微博的使用者喜歡發表觀點，有時會出現挺有啟發性的需求。 -
小紅書的使用者喜歡分享和發起話題。 -
百度貼吧的使用者年齡相對偏低，或者是老網民。 -
微信群內的反饋簡單直接，用著不爽就開始懟或者吐槽。 -
知乎會出現一些深度解析，應該是眾多渠道中反饋最認真的。
以下是知乎上的一個帖子，2421個使用者給微信提意見反饋。難怪張小龍2019年某次分享上調侃每天有1億人教他做產品。
產品資料：如果說前面2個渠道收集到的是定性的描述性需求，那麼產品資料則是定量性需求，例如註冊頁面的跳出率太高，下單到支付的轉化率較低等等，這就需要去最佳化，就會有最佳化類需求。
運營市場：在大部分公司內，運營、市場和銷售的同事都會背很多量化的KPI指標的，比如年度銷售額或利潤或註冊使用者數或付費使用者數達到XXX或者增長XXX，而要完成這些業績任務，除了前端產品需要增加功能外，還需要管理後臺提供工具支撐。
舉例說明。某消費金融公司運營部門的任務是年度完成2000萬新增註冊使用者，500萬授信使用者，運營部門就提出前端產品要有MGM分銷裂變的活動來做老帶新，管理後臺要能快速配置各種MGM活動並且做全流程的資料追蹤和統計分析，這些就是運營市場提的需求。
腦洞：上述需求都來自於產品部之外，產品內部有時也需要搞一些頭腦風暴來想一些產品的亮點或者特色出來，要不季度和年度的彙報PPT怎麼寫？要不怎麼去向上面要資源要HC？
當然需求的來源渠道不止上述這些，還有行業調研，使用者訪談、行業變化等。
行業(需求)調研：目前市面上大部分的產品，都可以在行業內和行業外找到競品。產品經理在打磨自家產品的同時，還得經常性的看行業、看標杆。
比如京東商城的產品經理，就要時刻關注淘寶和拼多多這2款產品，要時刻留心他們出了哪些功能，哪些值得京東跟進並做微創新，哪些暫時不需要跟但需要長期關注。
除了淘寶和拼多多之外，京東的產品經理還需要定期(比如每個季度)把市面上使用者基數大或者交易體量大的電商類APP挨個做一次摸排調研，找找他們的新功能或者亮點特色，再納入到京東APP的需求池內。
當然，京東如果要做某個新功能比如PDD的僅退款時，可能也得做一次深入全面的行業調研。
行業(需求)調研的方式多樣，產品階段不同、產品所屬行業不同，可供選擇的調研方式也會有很大的區別。
使用者訪談：主要有電話訪談、線上訪談和麵談3種，這個對產品團隊的要求會比較高，這個高主要體現在3個方面。
-
問卷要求高：既然是訪談就得有提綱，這個問卷提綱和內容怎麼設計？太短則收集到的反饋不夠全面，太長則對被訪談者不友好。 -
篩選門檻高：怎麼篩選出具有代表性的客戶？人數太少則樣本數量不夠，資料參考意義打折扣，太多訪談起來會耗時耗錢，那麼多少位比較合適？ -
費用預算高：委託外部機構做需要預算，自己團隊做則需要給被訪談者發放酬勞或禮品，這也需要費用，團隊耗費的時間也算人力成本。
綜上：使用者訪談這個對小公司不太友好，中大型公司會相對比較適用些。
特別需要注意的是，產品經理不要拒絕任何渠道任何人的需求。不管這個人是使用者、同事、老闆或陌生網友。
在收集需求的時候，產品經理要將需求與提交者的身份、地位、利益和動機等全部摒除，即原原本本的記錄每一項需求，不能在記錄時憑個人喜好或者主觀經驗刪掉自己認為不合理、不靠譜的需求。
需求收集的過程與頭腦風暴差不多，以獲取需求的數量為唯一目標，而不用考慮其他因素，例如需求是否與現階段的業務目標匹配、需求實現複雜度、投入產出比ROI等。
這些我們需要在分析/篩選需求的時候再去綜合考慮。
03 建立需求池
收集需求之後，我們就需要記錄需求，建立需求池。
由於需求提交人和接收人在工作資歷、理解能力、表達能力、身份背景和崗位職級等各方面存在差異，會導致需求在傳遞、表述和記錄的過程中出現需求失真，即提交者想要表達的資訊和接收人收到的資訊會有差異，這種差異可能很小，可能很大。
所以我們在需求收集、整理和記錄的時候要儘可能的規範，儘可能的詳細，這樣才能在後面做需求重要度(優先順序)分析的時候相對容易一些。
圖.需求池的相關要素
日期：除了可以按時間維度來查詢需求，也可以按時間維度來統計需求，例如2025年4月接收了需求X條。除此之外日期還是我們評估需求的重要依據，有些需求幾個月或者幾年前記錄時會覺得離譜或實現不了，但當前來看可能恰如其分，比如淘寶生態的應用中使用者希望支援微信支付，幾年前根本不可能，現在剛剛好。
來源：這個來源包括人的維度，當有些需求存在不確定性或需要了解更多需求背景或出發點時，可以透過需求來源找到提出者做進一步溝通。來源還包括地點(場景)的維度，即我們記錄需求時還需要記錄場景和背景。
舉個例子。老闆在某事業部的某次月會中提到我們訂貨平臺的體驗不好，我真的以為是UI/UE方面做的不好，但我後面找參會的幾位同事求證，事實並非如此。
老闆會上講到其它訂貨平臺的商品詳情頁有影片和精美的圖文介紹，我們平臺影片欠缺，圖文不全且沒有購買慾，這是老闆眼中的體驗不好，而並非是真的UI/UE不好。
需求描述：本小節開頭的時候說過，需求從提出人到記錄人再到接收人流轉的過程中存在需求失真的情況，比如前面那個“體驗不好”的需求。那怎樣才能做好需求描述減少失真呢？
有2個切實可行的方法，條件允許的情況下優先方法1，不允許的情況下用方法2。
方法1：記錄人和接收人變成同一個人，還是上面這個體驗不好的例子，如果產品經理親臨現場而不是由別人記錄並轉達，就可以如實的記錄下“需求”背景和需求內容。
方法2：利用飛書的會議錄製功能，會議開始到結束全程進行錄音，再將會議內容轉成文字，飛書可以識別出不同的發言人，這樣方便產品經理快速定位並甄別內容。
04 判定需求的優先順序
這個環節很考驗產品經理功力。面對各種渠道收集到的上百個需求，怎麼排出優先順序？有沒有好的模型或思路？答案是有的，這裡推薦3種。
4.1 影響複雜緊急度
排需求優先順序的時候，我們可以透過影響面、複雜度和緊急度3個維度來進行綜合評估。為便於記憶，我將其簡化為7字箴言：影響複雜緊急度。
為了讓優先順序排名可量化，可以採用評分制，再給每個維度賦予不同的權重，最後加權得出每個需求最終的分數，按分值高低排定優先順序。
影響面：即該需求能夠影響的使用者範圍，對使用者影響範圍越大，優先順序越高，反之越低。分值可以為1-5分，5代表影響範圍最大，1代表影響範圍最小。
複雜度：同理，如果該需求複雜度越高實現就越困難，反之越容易，開發測試需要的時間或人力成本就越大，複雜度同樣也可以用分值來表示。
緊急度：可以根據需求對於業務的緊急或重要程度來判斷。不做該需求會導致APP下架或使用者無法完成支付，這個緊急程度最高。如果只是無法批次審批，無法線上預覽這種問題，其緊急程度就低了很多很多，其同樣也可以用分值來表示。
但這個方法有侷限性，即權重和分值不太好賦分。假定複雜度如果用1-5分來賦分的話，那最優計算這個需求的複雜度肯定是5分，註冊頁面手機號段的正則表示式只能是1分。
前者複雜度可能有1萬需要300個小時完成，後者複雜度頂多10，1小時就能完成開發測試發版。兩者複雜度差了1000倍工作量差了300倍，但賦分上面僅僅差了5倍。
但換做大部分產品經理來決策的話，大多都會選擇優先做手機號這個需求。我們講的方法論感覺不適用了？
所以我開始就寫了“可以”採用評分制，但是否適用就見仁見智了。
4.2 優先順序核對單
這裡再提供1種優先順序核對單的方法，具體內容如下。即把需求和下表的7個等級來做對照，然後給出優先順序。
-
不做會造成嚴重甚至惡劣影響的：比如支付存在的BUG。 -
做了會產生巨大好處的：比如淘寶接入微信支付。 -
跟核心（高質量）使用者利益相關的。 -
跟主要（大部分）使用者利益相關的。 -
提高效率的：批次列印或資料匯出。 -
降低成本的：結算頁自動選擇最大折扣。 -
提升使用者體驗的：搜尋頁效率提升。
以B2B產品舉例說明。前提是當前階段的業務核心是以賣家為重點(3.核心高質量使用者)，那麼對應符合等級3的就可以先做，然後才是符合等級4567的需求。
讀者應該看出來了，這種方式也有侷限性和不足。例如同樣是核心高質量使用者即等級3的需求有5個，又該怎麼排？再有某些功能例如售後功能涉賣家和買家，也就是以上表的等級3和等級4，又該怎麼排？
聰明的讀者應該想到了，可以把上述2種方式有機結合起來。公司和行業不同，結合的方式可能也會有很大差異，這裡就不做延展了，讀者朋友們自己發揮吧。
4.3 KANO模型
該模型是由日本的卡諾博士（Noritaki Kano）提出的，KANO模型定義了三個層次的使用者需求：基本型需求、期望型需求和興奮型需求。小白型使用者、主流型使用者和專家型使用者這三個層次的使用者和 KANO模型中的三個層次的使用者需求有些類似，有興趣的可以詳細研究下。
KANO模型
當然，行業內還有很多判定需求優先順序的方法，限於篇幅這裡就不做展開了，歡迎大家在留言區補充。
來源 | 詹師兄（ID：zhanlaoshi2012）
作者 | 詹老師 ; 編輯 | 蝦餃
內容僅代表作者獨立觀點，不代表早讀課立場