需求評審的維度與評分體系

今天給大家一個思維工具，程序員們可以拿去用於評價一個產品需求是否靠譜。

這個既可以用於程序員與產品經理之間的日常溝通，也可以用於公司中流程化的需求評審，甚至可以建立評分體系做大團隊的數據分析。

評估需求的三個維度

研發人員對於產品需求的評估可以分為三個維度：

• 價值認同 - 對用戶有沒有價值，投入產出比怎樣

• 需求質量 - 需求是否易於理解，細節有沒有說清楚，邏輯是否成立

• 技術可行性 - 能不能做，成本多大規模，有多大風險

對一個需求的評價分成獨立且互斥的三個維度之後，開發與產品的交流就會更全面了。當我們說產品經理的需求靠譜或者不靠譜的時候，往往是指三個維度中的其中一兩個維度。

舉個例子，如果產品經理提出需求要在六一兒童節那天把所有用戶的昵稱都加上寶寶倆字，研發可以這樣答覆：

「需求我是理解的（需求質量 - 高），但是擅自修改用戶的昵稱不符合用戶利益，還可能有法律風險（價值認同 - 低），改全部用戶昵稱實現起來有難度，我需要跟其它開發一起調研一下（技術可行性 - 低）」

分維度評分體系

我們在評估需求時，可以分別對三個維度進行量化評分。做量化評分有兩個目的，一方面能讓研發的評估結論更嚴謹且明確，另一方面，有了量化評分之後我們能做數據分析，比如橫向對比每個產品經理的需求質量分布。

可以參考下面的評分標準，範圍0-5，中位數為3。

價值認同：

• 0 - 完全不認同該需求的價值，不可能投入開發

• 1 - 價值有限，投入產出不成比例，不同意現階段投入開發

• 2 - 保留意見，需要探討

• 3 - 基本認同，可以投入開發

• 4 - 比較認同

• 5 - 非常認同

需求質量：

• 0 - 不可接受

• 1 - 需求質量很差，重新梳理之後再評審

• 2 - 有產品BUG/邏輯不清晰/有重要遺漏/難以理解，需要修改

• 3 - 基本可以理解，需要補充細節

• 4 - 需求質量較好

• 5 - 質量很好

技術可行性：

• 0 - 無法實現

• 1 - 難度較高，部分功能可能無法實現，需要調研

• 2 - 有一定難度，成本較高

• 3 - 常規項目

• 4 - 容易實現，或者不需要發布

• 5 - 不需要開發

每一個可能進入開發的需求都要有研發團隊的評分結果，這個結果可以作為需求文檔的附錄記錄下來，評分也要隨著實際情況動態更新。

還是舉兒童節給用戶昵稱加寶寶的例子，如果按評分體系去評估的話，可能是以下結果：

• 價值認同：0 - 擅自修改用戶資料，違背用戶利益，很可能有法律風險，不同意進入開發

• 需求質量：4 - 已經理解了需求

• 技術可行性：1 - 更改全體用戶的昵稱，實現有難度，需要討論方案

這樣一來研發團隊對於這個需求的態度就已經很明確了。

總結

建立了評價需求的三個維度之後，開發者就可以與產品經理更全面地溝通。在此基礎上，我們可以建立評分體系，使得結果更嚴謹、更明確。評分結果記錄匯總之後還可以做團隊數據分析。

數據分析方面的經驗我會在後續的文章中具體展開。希望三個維度和評分體系會對你有用。