需求管理，也是產品運營人工作中非常重要的一個任務。本人作者將從實際的工作中體會，以實踐和理論相結合的角度總結一下日常中需求管理的流程方法。

產品需求上線后，你是否經常有這樣的疑問：

• 頁面布局改版跟想象中的不一樣？
• 平臺新上的功能怎么沒人用呢？
• 新的算法上了以后，推薦效果怎么更差了？
• …..

產生這些問題的一個非常重要的原因是需求管理不到位。

大多數情況下需求管理是由產品經理或者項目經理來主導，而大部分運營人員只提需求。因此也導致運營人員對需求管理參與不夠，沒有全局思維，過度依賴其他人。當然也有些公司設有單獨的需求管理崗位，但是這個崗位更多是類似項目助理的角色，跟蹤需求的完成進度。

實際上，作為產品運營人需求管理是工作中非常重要的一個任務，做好需求管理可以幫助我們把握產品的版本節奏和運營的戰略方向。

接下來我將從實際工作中的體會，以實踐和理論相結合的角度總結一下日常中需求管理流程方法。

一、需求管理六步走

需求收集——需求分析——需求定義——需求評審——需求跟蹤——需求驗收。

1. 需求收集，避免一句話需求

需求三個重要來源，公司戰略層對產品規劃，產品經理對產品的探索，以及運營人員基于實際工作中提煉的運營效率提升需求。

需求提出人需要給出需求背景，屬于哪個模塊、要解決的問題及影響范圍的評估等。只有把需求背后解決的問題想清楚，我們才能盡可能規避偽需求。

同時在小組內或者產品模塊內進行初步的需求優先級排序。比如平臺組需要規劃平臺內流量運營策略，活動組的需求涉及支持多種類型的活動，用戶組需要做用戶體系建設。都可以在組內先進行優先級排序。否則所有人提上去的都是高優先級的需求，那等于沒有優先級排序。

2. 需求分析，通盤考慮，合并同類項

需求分析最重要的目的是去偽存真，合并同類項。綜合分析需求的價值，包括商業價值即對業務KPI的價值，和用戶價值。商業價值重點考量需求能為我們業務KPI的貢獻。

比如一個廣告平臺今年的商業化收入要求翻倍，但是按照目前的漲幅，差距還很大。商業化組要求在產品內再開發一個廣告位，預計能直接帶來收入增長20%，這樣的需求一看有很有必要做。

那我們下一步分析，增加廣告位，對用戶體驗有多大的影響，會不會造成用戶流失。犧牲的用戶體驗我們是否能接受，如果這個需求恰好推薦內容也符合用戶需求當然是最好的。

用戶價值主要體現在需求適用什么場景，解決什么問題，產品可以提供什么樣的解決方案。

一個大的需求可以分解其中核心點，采取迭代的辦法完成，也避免對其他需求資源的占用。

3. 需求定義，提供解決方案

基于需求價值分析后，產品可以提供什么樣的解決方案，SE提供什么樣的架構設計方案，開發評估相應的工作量，這個過程中運營人員需要去了解提供的解決方案是否符合預期。

4. 需求評審，納入版本

各模塊拉通，來評審確定哪些需求可以納入本次的版本計劃。這里涉及到總體對需求的排期，所以這里也必然是一場口舌大戰。

5. 需求跟蹤，把握進度

對于產品經理來說，需求跟蹤最重要的是減少延期風險。同時對于臨時增加的需求進行評估，對其帶來的延期風險，給出合理預估。

作為需求提出人跟蹤需求完成過程，及時與開發溝通，能確保需求理解契合業務需求。

我曾經就遇到過需求實現與預期不符的情況。提了一個報表需求，我以為是很清楚簡單的需求。可是等開發讓我驗收時，傻眼了，非常多指標數值不合理。后來溝通才發現他對指標的理解與我們定義的有偏差。這導致他要返工，而我們的需求延期，真的是非常慘！

強調需求跟蹤真的非常重要！甩手掌柜不可取！

6. 需求驗收，流程閉環

需求驗收一個是測試人員驗收，還有一個運營驗收。

測試驗收主要考慮功能實現問題，但多是在測試環境進行驗收，現網的情況他們可能無法接觸。因此運營驗收就格外重要，對運營來說，這可以說是需求管理中最重要的流程。

運營驗收：

對于功能型需求，運營需要組織內外部用戶眾測，重點測試流程是否跑得通。需要收集反饋意見，以便及時解決問題，避免正式版本出現問題。

對于涉及運營策略的需求，比如算法調整。就需要更加嚴密的實驗測試，小流量A/B測試，驗證效果是否符合預期。當然對于A/B測試結果衡量也需要綜合考慮，比如流量分配是否隨機，是否覆蓋了全部人群，測試時間是否充分，結果是否符合統計顯著性等等。

確認需求實現符合預期，才算完成對需求的閉環。當前版本可以優化的問題，即安排優化處理。不能解決的問題，如果對業務影響不大，可以作為遺留問題，下次迭代優先完成。

二、需求排序方法

需求目前需求排序的三個主流理論方法，KANO模型、四象限法則、ICE模型排序法。KANO模型比較理論化。四象限法則是非常實用的方法，在我們日常工作中使用非常多，此處不再贅述。除此之前個人認為比較實用的是ICE排序，兼顧理論和現實的平衡。

ICE模型：

• Impact：需求上線后的預期影響有多大；
• Confidence：需求成功的概率有多大；
• Ease：需求需要多少成本才能上線。

應用舉例：

三、（題外）需求使用情況跟蹤

有時候發現做了一個需求，實際利用率很低，這要怎么辦呢？

首先我們要進行需求回溯和用戶調研，找到沒有使用的原因。如果是功能不好用，那我們后期可以優化。其次，對使用者進行相關的培訓，引導他們正確使用，提供效率。

還有最糟糕的情況是當時提的需求后期發現沒有太大實用價值。這類情況只能從前期的需求分析階段把控，盡可能避免此類需求進入后續流程，耗費人力物力。

本文@雪莉 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議