如何評估需求?

張在旺
5 評論 16486 瀏覽 115 收藏 18 分鐘
🔗 产品经理在不同的职业阶段,需要侧重不同的方面,从基础技能、业务深度、专业领域到战略规划和管理能力。

編輯導(dǎo)語:每一個用戶端的需求,到了用產(chǎn)品方案來實現(xiàn)的時候,往往對應(yīng)著多個產(chǎn)品需求,用戶需求越多,產(chǎn)品需求也會越多。那么怎么來進行評估和判斷呢?作者給出了以下建議,一起來看看吧!

需求處理5步法:

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

如何評估需求?

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

正是這種資源不足的常態(tài),導(dǎo)致在產(chǎn)品經(jīng)理的日常工作中,需要經(jīng)常面臨一個問題,那就是如何評估需求,如何合理安排需求優(yōu)先級。

關(guān)于評估需求,我們先從一個故事開始。

應(yīng)用于企業(yè)內(nèi)部的知識管理系統(tǒng)項目啟動后,產(chǎn)品經(jīng)理老王經(jīng)過一番調(diào)研,得到了一個長長的需求列表,接下來他想制定項目迭代計劃,于是約了業(yè)務(wù)代表來溝通需求的優(yōu)先級。

產(chǎn)品經(jīng)理:通過前期對你們的調(diào)研,我們對你們的需求有了大致的了解,現(xiàn)在我們要制定項目迭代計劃,所以我們想從已經(jīng)識別出來的需求中,選擇一些需求放在最開始的版本中。

業(yè)務(wù)代表:啊?我們提的那些需求,我們?nèi)家?/p>

產(chǎn)品經(jīng)理:我們打算先做重要的那些需求。

業(yè)務(wù)代表:我們提的那些需求都很重要??!沒有不重要的,否則我們也不會向你提那些需求。

產(chǎn)品經(jīng)理:我明白,這些需求都很重要。這么多需求不可能一下子全部做完的,還是得分清先后順序。我們需要你們來幫助區(qū)分優(yōu)先級,我們把這些需求按照優(yōu)先級分成幾批,優(yōu)先上線那些你們最想要的功能,其他次要的功能在后續(xù)的版本中陸續(xù)上線。

業(yè)務(wù)代表:說到上線,這個知識管理系統(tǒng)大老板很重視,下個月能不能上線?

產(chǎn)品經(jīng)理:今天約你就是想溝通一下需求的優(yōu)先級,我這邊好制定項目迭代計劃。這是前期識別出來的需求清單,接下來我們對這些需求先進行粗略的優(yōu)先級排序,以便我們能夠了解哪些需求是你們最想要、最希望在第一個版本看到的。這也可以幫助我們更準確理解你們的期望。

業(yè)務(wù)代表:哦,這樣啊,那我們先做一個像百度百科那樣的知識庫,把知識沉淀先開展起來。至于問答系統(tǒng)、在線視頻課堂、知識交流社區(qū)可以先稍微緩一緩。

產(chǎn)品經(jīng)理:那知識庫相關(guān)的功能,哪些你最想先用到呢?

業(yè)務(wù)代表:文章編輯、文章提交、給文章評論、點贊、收藏這些功能是最基本的,肯定得有。還需要單點登錄功能,也就是說員工可以利用OA系統(tǒng)的賬號直接登錄,不需要在知識管理系統(tǒng)里面再注冊一個賬號。另外,文章搜索功能先做標題搜索就行,全文搜索可以等以后再做。我剛才說的這些需求,什么時候能夠上線呢?

產(chǎn)品經(jīng)理:謝謝你向我們提供這些有價值的信息。接下來我還要找開發(fā)人員與項目經(jīng)理來評估一下工作量,再根據(jù)您剛才說的需求優(yōu)先級,我來制定一個初步的項目迭代計劃跟你確認,預(yù)計明天上午可以給你反饋,你看可以嗎?

業(yè)務(wù)代表:好,那我們明天再溝通。

以上描述的故事是產(chǎn)品經(jīng)理在需求工作中的一個典型場景。

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

通過溝通,產(chǎn)品經(jīng)理要讓業(yè)務(wù)代表認識到,每個項目的資源特別是時間資源是有限的,不可能一下子全部交付他們想要的全部功能,對需求進行優(yōu)先級排序,把最高優(yōu)先級的歸為一類,可以在第一批盡早實現(xiàn),其他可以遲些在后續(xù)的版本中實現(xiàn)。

作為產(chǎn)品經(jīng)理,要通過評估需求優(yōu)先級、估算開發(fā)工作量來制定項目迭代計劃,并在這個過程中與業(yè)務(wù)代表達成共識。

接下來介紹評估需求優(yōu)先級、估算開發(fā)工作量的方法。

1. 如何評估需求優(yōu)先級?

排優(yōu)先級的思想常常被稱作“分診”,來自于醫(yī)療領(lǐng)域,最早在拿破侖的戰(zhàn)爭中得到應(yīng)用。戰(zhàn)場上有大量的受傷士兵,但戰(zhàn)地醫(yī)院的醫(yī)療資源顯然沒辦法治療所有的傷兵。戰(zhàn)地醫(yī)生應(yīng)用分診的方法把士兵分為3類:

  • 治療了可以活下去
  • 不治療也能活下去
  • 治療了也活不下去

由于缺少醫(yī)療資源,醫(yī)生只治療第一類“治療了可以活下去”的傷兵。

這種分診的思想同樣可以應(yīng)用于排需求優(yōu)先級。

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

對產(chǎn)品團隊而言,需求優(yōu)先級也是一個時間管理的問題,我們可以應(yīng)用時間管理的方法來評估需求優(yōu)先級。

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

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

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

  • 重要且緊急:比如產(chǎn)品崩潰,有大量的用戶投訴。這樣的事情要立即處理。
  • 重要不緊急:比如產(chǎn)品規(guī)劃、參加培訓(xùn)、運動。這樣的事情要有計劃地做。
  • 不重要但緊急:比如出席無關(guān)會議、接到騷擾電話。這樣的事情可以授權(quán)別人做或暫緩。
  • 不重要不緊急:比如刷短視頻、刷朋友圈。這樣的事情盡量少做。

如何評估需求?

我們可以按照時間管理四象限這個工具來評估需求優(yōu)先級(如下圖所示):

  • 重要且緊急的需求,算高優(yōu)先級。
  • 重要不緊急的需求,算中優(yōu)先級。
  • 不重要但緊急的需求,算低優(yōu)先級
  • 不重要不緊急的需求,算低優(yōu)先級

如何評估需求?

那我們怎么判斷需求是否“重要”、“緊急”呢?我們可以站在業(yè)務(wù)視角來進行評估:

  • 重要:判斷是否重要的依據(jù)是業(yè)務(wù)價值,包括用戶價值、商業(yè)價值。例如:核心業(yè)務(wù)相關(guān)的需求算重要;核心用戶的核心需求算重要;能顯著提升產(chǎn)品的競爭優(yōu)勢的話算重要。
  • 緊急:廣度(涉及的用戶數(shù)量);頻度(需求相關(guān)的場景出現(xiàn)的頻率);競爭(比如跟競爭對手搶時間)

從業(yè)務(wù)視角安排好優(yōu)先級之后,還要請開發(fā)人員從技術(shù)視角、請項目管理人員從項目管理視角對需求優(yōu)先級進行微調(diào)。

(1)技術(shù)視角

有的需求在實現(xiàn)層面與其他需求有依賴關(guān)系,被依賴的要優(yōu)先做。

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

(2)項目視角

項目經(jīng)理要考慮需求的實現(xiàn)成本、是否存在技術(shù)風(fēng)險。

同樣都是高優(yōu)先級的需求項,要優(yōu)先做成本小的,這樣更容易見到成效。

同樣都是高優(yōu)先級的需求項,要優(yōu)先做風(fēng)險大的,因為提早做風(fēng)險大的話,風(fēng)險出現(xiàn)時還有機會與時間來補救。

上面介紹了先從業(yè)務(wù)視角來評估優(yōu)先級,再從技術(shù)視角、項目視角微調(diào)優(yōu)先級的方法。這個方法屬于定性評估,還可以用定量評估的方法來排需求優(yōu)先級。

定量評估的方法先列出排優(yōu)先級要考慮的維度(如業(yè)務(wù)價值、開發(fā)成本等),再邀請跨職能代表(業(yè)務(wù)代表、開發(fā)人員、項目經(jīng)理等)從各個維度對要評估的需求項進行打分,然后就可以根據(jù)需求項的得分來排需求優(yōu)先級。

排優(yōu)先級要考慮的常見維度如下:

  • 業(yè)務(wù)價值
  • 用戶量
  • 發(fā)生頻率
  • 技術(shù)風(fēng)險
  • 開發(fā)成本
  • 上市時間
  • 政策要求
  • 合同約定

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

如何評估需求?

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

不管用定性評估的方法,還是用定量評估的方法,我們可能會遇到2個需求優(yōu)先級一樣的情況,如果你很糾結(jié)該先做哪個需求的時候,要記?。?/p>

需求優(yōu)先級的本質(zhì)是性價比。

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

對于需求優(yōu)先級,有以下幾點需要提醒:

  • 優(yōu)先級是相對的。用定量評估的方法進行打分的時候,是通過比較來打分。
  • 排優(yōu)先級是一個動態(tài)、持續(xù)的過程。隨著項目條件的變化、需求變更,要及時調(diào)整需求優(yōu)先級。

評估完需求優(yōu)先級后,還要評估需求的開發(fā)工作量,然后來制定版本迭代計劃。

2. 如何評估開發(fā)工作量?

估算開發(fā)工作量時,不能由產(chǎn)品經(jīng)理拍腦袋估算,然后制定不切實際的項目計劃。需要邀請開發(fā)團隊來一起評估開發(fā)工作量。

(1)估算過程

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

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

(2)估算方法

分解法:分而治之

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

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

類比法:歷史數(shù)據(jù)+修正系數(shù)

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

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

撲克牌估算法

如何評估需求?

如何評估需求?

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

0、每一名團隊成員(產(chǎn)品負責(zé)人除外)取一種顏色的卡片(如圖所示)。

1、產(chǎn)品負責(zé)人描述待預(yù)估的Backlog項目,并解答團隊成員的提問。

2、團隊討論。

3、每一名團隊成員根據(jù)自己的判斷進行預(yù)估,將預(yù)估結(jié)果倒扣在桌上。

4、當所有團隊成員都完成預(yù)估,大家同時把卡片估值翻轉(zhuǎn)過來公示。

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

6、如果團隊成員估值差異較大,則需要對預(yù)估結(jié)果進行討論。

7、重復(fù)上面的過程,直到團隊達成一致意見。

8、產(chǎn)品負責(zé)人選擇下一個Backlog項目進行預(yù)估。

注1:一般情況下,建議預(yù)估分值為單張紙牌的數(shù)值。

注2:問號用于表示對當前項目仍有疑問;咖啡用于提示實在太累了,需要休息一下。

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

  • 很多開發(fā)人員在估算工作量時會偏樂觀,對風(fēng)險預(yù)估不足,經(jīng)常會看到實際工期遠大于預(yù)計工期的情況。
  • 不要因為外部壓力或迎合領(lǐng)導(dǎo)的喜好而做出不切實際的估算,這樣的后果往往是兩敗俱傷,而你最終將成為背鍋俠。
  • 報給客戶的工作量要留余地。比如你預(yù)估2天能做完,你報給客戶時要說3天。一方面要預(yù)留時間以免發(fā)生特殊情況,影響交付時間,另一方面要留給客戶“砍價”的余地(客戶聽說要3天,極有可能讓你在2天內(nèi)完成)。
  • 度量就是認知。在項目初期做的初步估算都是基于估算者當時的認知及其所做的假設(shè),具有很大的不確定性。隨著項目的進展,根據(jù)實際進度,以及任務(wù)的進一步細化,應(yīng)該動態(tài)調(diào)整估算值,估算值應(yīng)該越來越接近實際值。

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

#專欄作家#

張在旺,微信公眾號:張在旺,人人都是產(chǎn)品經(jīng)理專欄作家。資深咨詢師、創(chuàng)投顧問、《有效競品分析》作者;擅長最佳實踐與方法論的總結(jié),兼具實戰(zhàn)經(jīng)驗與產(chǎn)品方法論體系,創(chuàng)造性地總結(jié)了競品分析的系統(tǒng)方法論。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載

題圖來自Unsplash,基于 CC0 協(xié)議

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 對于重要和緊急的判斷上,我有一點想要請教。文章說將對于用戶廣度和頻率等作為是否緊急的判斷,而按我理解涉及用戶的廣度和頻率等也是用戶價值大小的衡量標準,而不是緊急與否的衡量標準。除非已經(jīng)認定這個需求不做是不利于用戶的,才會把影響范圍作為是否緊急的標準。

    來自上海 回復(fù)
    1. 把用戶廣度和頻率等作為是否緊急的判斷,是來源于Bug管理的方法,Bug涉及的用戶數(shù)量(廣度)以及出現(xiàn)的頻率可以幫助判斷bug的緊急程度。
      很多需求管理系統(tǒng)和Bug管理系統(tǒng)可以共用(如禪道、bugfree等),所以需求緊急程度的判斷思路就沿用了bug緊急程度的判斷思路。
      其實按您說的判斷方法也可以,殊途同歸。

      來自福建 回復(fù)
    2. 對,如果是有明確負向影響的,其實可以通過廣度和頻度對比來很快的判斷優(yōu)先級。而對于沒有負向影響,而是不做沒啥影響,做了有一定積極效果的這類需求,在緊急程度上的判斷,我就一直不能很好把控的是。

      來自上海 回復(fù)
    3. 用戶廣度和頻率作為是否緊急的判斷,以APP功能點為例,我認為就是
      P1,基礎(chǔ)功能體驗,穩(wěn)定性
      P2,好

      來自北京 回復(fù)
    4. P2:良好的體驗;P3:好口碑,P4,超預(yù)期

      來自北京 回復(fù)