需求管理｜避免瞎忙，先把需求管好

怎樣管理需求才能少背鍋？！

需求管理的時間占了產品日常工作的32%，是每個產品經理必備的工作內容之一，將業務部門的需求清單於內部的需求清單進行比對管理，因此總結了一下小團隊多而雜的需求來如何管理。

首先需要一個收集需求的管理池—需求池

一般通過需求列表對所有需求進行統一記錄管理

通常需求清單包括：提出人、提出時間、所屬模組、需求描述、需求分類、需求優先順序、狀態、責任人、專案名稱給、開發量、計畫開始時間、發佈時間、進度、備註等，隨便找了一張圖貼上。

提交人：即需求的原始提出者，

有疑惑時便於追溯

提交時間：原始需求的獲得時間，輔一致性的需求描述

分類：新增功能、功能改進、體驗提升、Bug修復、內部需求等

優先順序：需求的緊急重要程度

狀態：需求生命週期：待討論、暫緩、拒絕、需求中、開發中、已發佈

專案名稱:需求的發佈專案

開發量:需求的開發工作量，表徵實現難度

計畫開始時間:開始開發時間

發佈時間:計畫發佈時間

進度:當前需求進度

備註：其它任何資訊，如：1.被拒絕的理由2.被暫緩的理由和重啟條件3.其它相關文檔……

需求那麼多，我們應該先從哪個下手？

如何判定需求的優先順序——KANO模型

基本型需求：滿足使用者“剛需”的產品功能。

期望型需求：不是“必須有”的產品屬性，但是使用者希望得到的。這類需求在產品中實現的越多，用戶就越滿意。

興奮型需求：使用戶產生驚喜的需求。當產品提供了這類需求中的服務時，使用者就會對產品非常滿意，這類需求可以為產品增加額外價格。

通過這種分類方法，講需求大概分了三個級別，

所以我們就可以排優先順序啦，當然，如果老闆提需求了，那麼這些需求再怎麼優先都是往後靠，雖然我們都有產品人的職業素養，但是工資是老闆發的，聽老闆的。

如何提交需求

1、專案型需求

提交這類需求需說明：

業務背景&價值（為什麼要做）：讓其他產品同學明白業務價值以協調資源優先順序

業務目標（可量化數位目標）：使專案有關部門的同學有統一目標。如果某業務線多次上線的活動都不能達到目標，那該條業務線後續再提交的需求優先順序自然不高，而且更容易被挑戰。

系統的概述：描述系統要實現的業務功能。可以通過環境圖的方式描述使用者、本系統、其它業務系統之間的交互關係。

落地方案（如何做）：產品設計需基於完整的落地實施方案，

每個系統功能模組，以考慮到每一個實現細節邏輯和異常情況。

2、日常優化需求

產品小功能反覆運算或者體驗優化

一般這種需求被提出的姿勢都是：小陳，要把頁面結構改一下，要加幾個按鈕神馬的，這時候，我就會很鬱悶——那還找我幹嘛，你直接去找程式猿得了。

但是我們更應該耐心的挖掘解決方案背後的那個問題（或者更專業的，我們叫做用戶需求）。然後，由我們親自來做把使用者的需求轉化為產品功能這件事，這才是我們的核心職責（而不是細化功能這種事，沒錯，我指的是寫PRD什麼的）。

提交這類需求需說明：

目標使用者：這件事，是為誰而做的，一旦運營開始從這裡起步思考，

就可以自己排除掉很多需求了；

問題描述：目標使用者碰到的痛點，只說“何時/何地，怎麼難受”即可；

改進建議：建議如何優化

嚴重程度：對問題嚴重程度的判斷， “高/中/低”即可，具體的判斷方法，可以根據使用者重要程度（這個比較主觀，需要團隊一起討論達成共識，我們的產品是為哪幾類使用者服務的，他們的優先順序排序是什麼，這是產品原則的關鍵內容），問題出現的次數、頻率等因素（相對客觀，比較好辦）考慮；

現有方案：現在是如何解決此問題的，我會認為，一個值得解決的問題，通常已經有人著手解決了，所以也一定已經有一些解決方案，而沒有現有方案的問題，通常不嚴重；

解決方案：建議的產品改進方案，可以以原型或者簡單文檔的形式，甚至可以口頭說明，如果你不怕和開發撕逼的話。

如何跟需求方對接需求

需求方同學的需求提交上來之後自然需要得到明確的回饋，於是定期的需求對接會就很有必要了，需求對接會的主要內容包括：

針對提交的需求內容進行當面溝通確認，再確認，避免撕逼

我需要將每個需求的評估結果回饋、進展、預期上線時間等同步給需求方

上線之前，我要將已經在測試環境準備好的功能邀請需求方事前體驗

我把已經上線的產品後臺使用說明、前臺邏輯說明等，同步給需求方

需求管理是每個產品狗的必修課，特別是需求方較多時，比如銷售、財務、采銷、倉庫...巴拉巴拉，協調好各部門，才好按期完成每項需求，保證業務順利進行。

作者：王一點

甚至可以口頭說明，如果你不怕和開發撕逼的話。