編輯導語：每一個用戶端的需求，到了用産品方案來實現的時候，往往對應着多個産品需求，用戶需求越多，産品需求也會越多。那麼怎麼來進行評估和判斷呢？作者給出了以下建議，一起來看看吧！

需求處理5步法：

1. 收集需求：從各種渠道收集原始需求
2. 還原需求：對需求的關鍵要素進行還原
3. 挖掘需求：對需求進行深入挖掘，找到深層次的需求
4. 補充需求：舉一反三，對相似、相關的需求進行補充，避免遺漏
5. 評估需求：評估需求的優先級、開發工作量，幫助制定項目叠代計劃

我們從前面4個步驟中，收集到了很多待開發的需求，這些需求看起來都很重要，但我們不可能一下子全部都開發出來，畢竟，在任何企業中，資源不足永遠是常态，即使像華為這樣有十幾萬員工的大公司，投入到一個産品線的資源也總是有限的。

正是這種資源不足的常态，導緻在産品經理的日常工作中，需要經常面臨一個問題，那就是如何評估需求，如何合理安排需求優先級。

關于評估需求，我們先從一個故事開始。

應用于企業内部的知識管理系統項目啟動後，産品經理老王經過一番調研，得到了一個長長的需求列表，接下來他想制定項目叠代計劃，于是約了業務代表來溝通需求的優先級。

産品經理：通過前期對你們的調研，我們對你們的需求有了大緻的了解，現在我們要制定項目叠代計劃，所以我們想從已經識别出來的需求中，選擇一些需求放在最開始的版本中。

業務代表：啊？我們提的那些需求，我們全都要！

産品經理：我們打算先做重要的那些需求。

業務代表：我們提的那些需求都很重要！！沒有不重要的，否則我們也不會向你提那些需求。

産品經理：我明白，這些需求都很重要。這麼多需求不可能一下子全部做完的，還是得分清先後順序。我們需要你們來幫助區分優先級，我們把這些需求按照優先級分成幾批，優先上線那些你們最想要的功能，其他次要的功能在後續的版本中陸續上線。

業務代表：說到上線，這個知識管理系統大老闆很重視，下個月能不能上線？

産品經理：今天約你就是想溝通一下需求的優先級，我這邊好制定項目叠代計劃。這是前期識别出來的需求清單，接下來我們對這些需求先進行粗略的優先級排序，以便我們能夠了解哪些需求是你們最想要、最希望在第一個版本看到的。這也可以幫助我們更準确理解你們的期望。

業務代表：哦，這樣啊，那我們先做一個像百度百科那樣的知識庫，把知識沉澱先開展起來。至于問答系統、在線視頻課堂、知識交流社區可以先稍微緩一緩。

産品經理：那知識庫相關的功能，哪些你最想先用到呢？

業務代表：文章編輯、文章提交、給文章評論、點贊、收藏這些功能是最基本的，肯定得有。還需要單點登錄功能，也就是說員工可以利用OA系統的賬号直接登錄，不需要在知識管理系統裡面再注冊一個賬号。另外，文章搜索功能先做标題搜索就行，全文搜索可以等以後再做。我剛才說的這些需求，什麼時候能夠上線呢？

産品經理：謝謝你向我們提供這些有價值的信息。接下來我還要找開發人員與項目經理來評估一下工作量，再根據您剛才說的需求優先級，我來制定一個初步的項目叠代計劃跟你确認，預計明天上午可以給你反饋，你看可以嗎？

業務代表：好，那我們明天再溝通。

以上描述的故事是産品經理在需求工作中的一個典型場景。

“都很重要”、“全部都要”、“馬上就要”，是很多甲方爸爸的口頭禅。

通過溝通，産品經理要讓業務代表認識到，每個項目的資源特别是時間資源是有限的，不可能一下子全部交付他們想要的全部功能，對需求進行優先級排序，把最高優先級的歸為一類，可以在第一批盡早實現，其他可以遲些在後續的版本中實現。

作為産品經理，要通過評估需求優先級、估算開發工作量來制定項目叠代計劃，并在這個過程中與業務代表達成共識。

接下來介紹評估需求優先級、估算開發工作量的方法。

1. 如何評估需求優先級？

排優先級的思想常常被稱作“分診”，來自于醫療領域，最早在拿破侖的戰争中得到應用。戰場上有大量的受傷士兵，但戰地醫院的醫療資源顯然沒辦法治療所有的傷兵。戰地醫生應用分診的方法把士兵分為3類：

由于缺少醫療資源，醫生隻治療第一類“治療了可以活下去”的傷兵。

這種分診的思想同樣可以應用于排需求優先級。

即使是一個中等規模的項目，往往也有好幾十個用例和幾百個功能需求，很少有軟件項目能夠在預定的日期交付幹系人想要的所有功能。畢竟每一個項目的資源都是有限的，特别是時間資源。

對産品團隊而言，需求優先級也是一個時間管理的問題，我們可以應用時間管理的方法來評估需求優先級。

先簡單介紹時間管理的方法。

我們每天要做的事情很多，總感覺時間不夠，所以就要按照輕重緩急對事情進行分類、排優先級，然後按要事優先的原則來處理事情。

按照時間管理四象限這個工具，可以把事情按照“重要”、“緊急”進行分類放到四個象限。

• 重要且緊急：比如産品崩潰，有大量的用戶投訴。這樣的事情要立即處理。
• 重要不緊急：比如産品規劃、參加培訓、運動。這樣的事情要有計劃地做。
• 不重要但緊急：比如出席無關會議、接到騷擾電話。這樣的事情可以授權别人做或暫緩。
• 不重要不緊急：比如刷短視頻、刷朋友圈。這樣的事情盡量少做。

我們可以按照時間管理四象限這個工具來評估需求優先級（如下圖所示）：

• 重要且緊急的需求，算高優先級。
• 重要不緊急的需求，算中優先級。
• 不重要但緊急的需求，算低優先級
• 不重要不緊急的需求，算低優先級

那我們怎麼判斷需求是否“重要”、“緊急”呢？我們可以站在業務視角來進行評估：

• 重要：判斷是否重要的依據是業務價值，包括用戶價值、商業價值。例如：核心業務相關的需求算重要；核心用戶的核心需求算重要；能顯著提升産品的競争優勢的話算重要。
• 緊急：廣度（涉及的用戶數量）；頻度（需求相關的場景出現的頻率）；競争（比如跟競争對手搶時間）

從業務視角安排好優先級之後，還要請開發人員從技術視角、請項目管理人員從項目管理視角對需求優先級進行微調。

（1）技術視角

有的需求在實現層面與其他需求有依賴關系，被依賴的要優先做。

例如，知識管理系統中，有“提交詞條”、“登錄系統”這兩個用例，在提交詞條時要驗證身份，要求用戶要先登錄系統才能提交詞條。“登錄系統”被依賴，所以“登錄系統”的優先級要高于“提交詞條”。

（2）項目視角

項目經理要考慮需求的實現成本、是否存在技術風險。

同樣都是高優先級的需求項，要優先做成本小的，這樣更容易見到成效。

同樣都是高優先級的需求項，要優先做風險大的，因為提早做風險大的話，風險出現時還有機會與時間來補救。

上面介紹了先從業務視角來評估優先級，再從技術視角、項目視角微調優先級的方法。這個方法屬于定性評估，還可以用定量評估的方法來排需求優先級。

定量評估的方法先列出排優先級要考慮的維度（如業務價值、開發成本等），再邀請跨職能代表（業務代表、開發人員、項目經理等）從各個維度對要評估的需求項進行打分，然後就可以根據需求項的得分來排需求優先級。

排優先級要考慮的常見維度如下：

• 業務價值
• 用戶量
• 發生頻率
• 技術風險
• 開發成本
• 上市時間
• 政策要求
• 合同約定

定量評估的方法參考如下表格：

在中大型項目中，幹系人很多，他們對哪些需求更重要往往達不成一緻意見，容易産生争吵，可能會根據“音量優先級”來安排需求優先級。這種情況下，可以通過定量評估的方法來打破僵局。通過多人打分的方式更加客觀，減少情緒方面的影響，促使團隊對需求優先級達成共識。

不管用定性評估的方法，還是用定量評估的方法，我們可能會遇到2個需求優先級一樣的情況，如果你很糾結該先做哪個需求的時候，要記住：

需求優先級的本質是性價比。

這時候你判斷的依據就是哪個性價比高就先做哪個。

對于需求優先級，有以下幾點需要提醒：

• 優先級是相對的。用定量評估的方法進行打分的時候，是通過比較來打分。
• 排優先級是一個動态、持續的過程。随着項目條件的變化、需求變更，要及時調整需求優先級。

評估完需求優先級後，還要評估需求的開發工作量，然後來制定版本叠代計劃。

2. 如何評估開發工作量？

估算開發工作量時，不能由産品經理拍腦袋估算，然後制定不切實際的項目計劃。需要邀請開發團隊來一起評估開發工作量。

（1）估算過程

以敏捷項目為例，介紹估算工作量的過程。

1. 先估算項目包含的故事點的數量（用分解法、類比法、撲克牌估算法）
2. 根據以往經驗、早期叠代結果估算團隊速率（一個叠代能夠完成多少故事點）
3. 算出工期（故事點數量÷團隊速率）

（2）估算方法

分解法：分而治之

比如，一個手機硬件工程師要估算一款競争對手新上市的手機的硬件成本，可以用分解法把這款手機的所有零部件都拆解出來，就可以得到這款手機的BOM成本。

對一整個項目的工作量不容易估算，即使估算的話偏差也會比較大，可以利用分解法拆成好估算的模塊，然後彙總就可以得到整個項目的工作量。

類比法：曆史數據 修正系數

比如，你家裡要裝修房子，你要估算裝修費用。如果你以前有裝修過，參考曆史數據，再針對面積大小、豪華程度、物價水平等因素進行修正，就可以估算出裝修費用了。

如果你是第一次裝修沒有經驗，可以去最近剛裝修完房子的朋友家裡了解一下，再根據你家的面積大小、豪華程度進行修正，就可以估算出你家房子的裝修費用了。

撲克牌估算法

敏捷撲克牌估算法的使用方法：

0、每一名團隊成員（産品負責人除外）取一種顔色的卡片（如圖所示）。

1、産品負責人描述待預估的Backlog項目，并解答團隊成員的提問。

2、團隊讨論。

3、每一名團隊成員根據自己的判斷進行預估，将預估結果倒扣在桌上。

4、當所有團隊成員都完成預估，大家同時把卡片估值翻轉過來公示。

5、如果所有人的預估值相等或相近，該值即為Backlog項目的故事點。

6、如果團隊成員估值差異較大，則需要對預估結果進行讨論。

7、重複上面的過程，直到團隊達成一緻意見。

8、産品負責人選擇下一個Backlog項目進行預估。

注1：一般情況下，建議預估分值為單張紙牌的數值。

注2：問号用于表示對當前項目仍有疑問；咖啡用于提示實在太累了，需要休息一下。

對于工作量估算，有以下幾點需要提醒：

• 很多開發人員在估算工作量時會偏樂觀，對風險預估不足，經常會看到實際工期遠大于預計工期的情況。
• 不要因為外部壓力或迎合領導的喜好而做出不切實際的估算，這樣的後果往往是兩敗俱傷，而你最終将成為背鍋俠。
• 報給客戶的工作量要留餘地。比如你預估2天能做完，你報給客戶時要說3天。一方面要預留時間以免發生特殊情況，影響交付時間，另一方面要留給客戶“砍價”的餘地（客戶聽說要3天，極有可能讓你在2天内完成）。
• 度量就是認知。在項目初期做的初步估算都是基于估算者當時的認知及其所做的假設，具有很大的不确定性。随着項目的進展，根據實際進度，以及任務的進一步細化，應該動态調整估算值，估算值應該越來越接近實際值。

還有很多方法可以用來排優先級，比如“入選與落選法”、Kano模型、百元購物法、MoSCoW優先級排序法等，本文介紹的是我認為比較實用的方法，希望對你有幫助。

本文由 @張在旺 原創發布于人人都是産品經理，未經許可，禁止轉載

題圖來自Unsplash，基于 CC0 協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部