【需求管理】訓練決策力，高效管理需求閉環

來自專欄 產品經理術道器

產品經理處於需求的源頭，需求管理能力是產品經理核心能力之一，貫穿著項目的始終。

需求的收集、錄入、調研、評估、劃分和跟蹤、反饋，每一個環節都有大學問，需要產品經理根據項目團隊和產品特性，去做方法總結。

筆者以軟體產品（軟體相對複雜，所以軟體類產品需求管理覆蓋面也很廣，有較全面的參考價值）為例，進行分享：

一、需求收集

分析需求的來源，定義需求收集人，並定義時間節點和需求提交標準。

首先，需要列出產品需求的各種可能性來源。

例如：

其次，需要指定需求反饋人，提高需求收集效率。

為了避免過多的需求反饋線，分散時間和精力，產品經理需要和團隊溝通，某些需求渠道集中一個人反饋。

例如：

比如在線反饋、官方渠道、客服反饋、卸載反饋等都有運營去收集，每周一次反饋給產品經理；產品調研和競品分析，由產品經理根據用戶需求、市場趨勢去做需求收集；需求提交人越少越好，可以減少產品經理的對接和溝通成本。

最終由產品經理統一匯總需求。

二、需求錄入

首先，需求是多渠道且巨細皆有的，需要一個工具來承載和管理。

例如，測試通常使用mantis去記錄和跟蹤BUG解決；項目管理師用project或者一些團隊協作工具去管理任務進度。我們使用的是excel表格去管理需求。先給大家看下錶格要素：

需求表對應的屬性為：

其次，需要定義整理時間與規範。

如果產品需求比較少，且無大的功能迭代，每周五匯總和錄入一次需求即可。

需求較多且繁雜的話，可以每天花1-2個小時進行需求整理和收集，緩解累積到一天的壓力。

尤其是進入當前版本測試階段，每天在BUG系統都會有測試提出的建議或問題，如果是暫緩的建議，則需要及時劃分版本和納入需求池，進行規劃。

三、需求分析

首先，通過各種方法聯繫需求提出人（尤其是公司外部的客戶、合作方等），進行需求挖掘。

需求挖掘的深度和精準度，決定了我們制定的方案的可行性和最優性價比，是非常重要的一環。

那麼，如何進行需求挖掘呢？

1.掌握儘可能多的信息。特別是用戶遇到了BUG，則需要收集以下信息：用戶是什麼電腦環境（系統、解析度）、什麼操作場景（休眠狀態後；長時間未使用；打開超多進程）、什麼操作步驟（點擊了哪些功能）、引起了什麼現象（閃退、崩潰？）。

2.引產式提問，進行需求挖掘。一般用戶會反饋哪裡用得不爽，或者直接說我要某某功能，這個時候需要去挖掘：為什麼想要這個功能，產品現有功能可以滿足嗎？是個人習慣還是通用的操作規範？本質需求是什麼，用另外一種方案是不是能更好的解決？

其次，進行需求的細緻評估。

1.評估需求所屬的分類，是新增功能、功能優化、交互體驗還是介面需求等，方便評估需求的優先順序，合理分配每個版本的內容（比如版本里有一個新增功能，3個功能優化，4個交互體驗完善點）

2.進行重要性、緊迫度、商業價值等的初步評估

從重要性、緊迫度、頻次、商業價值、開發量等維度，計算性價比：

需求性價比=重要性*0.35+緊迫度*0.2+商業價值*0.3-開發量*0.1+頻次*0.05

分值越高，優先順序越高。

需求評估常用的方法有KANO模型、四象限模型、波士頓矩陣模型等。

比較常用的就是四象限模型，優先順序：象限一 重要且緊急 ＞ 象限二 重要且非緊急 ＞ 象限三 非重要且緊急 ＞ 象限四 非重要且非緊急。

如何判斷需求的重要性和緊急度？已經有很多人有很精妙的見解，以下摘錄一段：

1.重要性的判斷標準，幾個比較重要的情況

• 公司戰略：產品經理是為產品服務，產品是為業務服務，業務為公司服務，公司戰略落地的需求是從頂層下來，是需要優先考慮的。
• 利潤相關：公司是要賺錢和生存的，通常客戶＞用戶，大客戶＞小客戶。
• 基礎結構：產品是一座樓，基礎結構就是地基，稍蓋幾層沒有太大關係，如果地基沒搭好就會有坍塌的風險。包括角色、實體、主業務邏輯、系統架構、賬號體系等。

2.緊急性的判斷標準

• 摸清實際情況：業務方、用戶等通常會提出很多非常緊急的需求，產品經理不要被打蒙了，要先摸清實際情況，影響了多少業務，影響了多少用戶，什麼原因造成的等等。
• 根據影響評估：摸清實際情況後，根據需求的影響進行評估。核心業務高於邊緣業務，影響用戶多高於影響用戶少，造成損失高於未造成損失等等

3.四象限模型

• 重要且緊急的比較少，如果多了就需要反思是評估問題還是產品基礎沒打好；
• 重要且不緊急的要多做，這些代表了產品的未來，而且要慎重，決策要慎重迭代也要慎重，要花時間去打磨他，不要急於求成，也不要一上一整個；
• 不重要且緊急的要少做，做多了產品容易被牽著鼻子走，還會造成資源浪費，如果多了就需要反思是不是以前產品迭代沒做到位；
• 不重要且不緊急的要不做。

這些理論都需要在實際工作中多加運用，直到變為直覺。下次遇到眾多需求時，一定要冷靜下來，慢下來，從一個個小需求的嚴謹評判中積累需求評估方法，只有「質」的累計，才能到「速」的蛻變。

四、需求劃分

根據需求分析結果和版本迭代周期去定義每一個版本要做的需求。

比如兩周發布一個版本。那麼考慮，這個周期內，哪些需求優先做。

比較大的需求，要進行需求點分解，看要做到什麼程度，先做什麼功能點，後補充什麼功能點。

完成需求的收集、錄入、分析和劃分後，就進入到需求方案設計-原型設計-評審交付需求-任務排期-日常跟進-功能驗收等項目開發推進和管理環節。

（可參照閱讀：【項目管理】科學協作，目標激勵）

六、需求反饋

需要定期將需求解決情況反饋給需求提交人；如果是用戶私聊的BUG和建議，完成之後，統一標註好狀態，再由需求提交人（比如客服）對應狀態去告知用戶。

這樣可以與需求提交人形成良性的互動，獲得越來越多的產品使用反饋。

七、需求復盤

總結需求主要分布於什麼功能模塊，好進行整體上的定位和梳理。為下一次迭代做準備。

另外，需要通過數字化的評估，來體現每個版本需求完成的數量和質量（對於活躍度和卸載率的影響），開發量是否飽和，效率是否達到預期。

如果是產品負責人，還可以在需求管理的各個環節，考核產品團隊的工作效率和質量。

（可參照閱讀：【項目管理】科學協作，目標激勵）

推薦閱讀：