【DevCloud · 敏捷智庫】如何進行需求優先級管理？

需求優先級管理四步走

需求優先級的管理，其實是為了幫助我們確定先做哪個需求后做哪個需求，從而可以最大化我們的回報、最小化我們的風險或投入。要做好優先級管理，或者更直接來說是優先級順序管理，我們需要做到如下幾件事情：

確定優先級模型：優先級看起來像是一個簡單直接的值，但實際上它是一個基于多種因素進行綜合判斷之后得出的一個值，這些因素和判斷原則，就是我們所說的優先級模型；

排定需求優先級順序：將需求代入優先級模型進行計算，得出每個需求的優先級順序；

調整需求優先級順序；

改進優先級模型：如果經常發生需要調整需求優先級順序的情況，那么最好是對這些情況進行一定的復盤分析，如有必要，修正或改進當前的優先級模型，讓它可以適應實際情況，以避免調整優先級順序的情況反復發生；另外就是需求可能已經交付或發布上線，但是該功能的實際用量或價值不吻合預期，則需要反思我們對這些需求的分析和判斷，究竟是分析判斷有誤還是優先級模型有誤，并進行相應的調整；

一，確定優先級模型

成本收益分析就是最簡單的一種優先級模型，重要/緊急的四象限也是一種優先級模型，Kano模型也是一種優先級模型，它們都可以幫助我們去確定需求的優先級順序。模型可以簡單也可以復雜，根據企業實際需要來確定即可。

務必切記優先級模型不應追求完美，以避免模型過于復雜，導致優先級管理的管理開銷過高，喧賓奪主，反而影響了需求的開發和交付。如果較為簡單的模型就可以滿足需要，就應該首選使用較簡單的模型。企業可以從簡單開始，逐漸完善，不需要也不應該在一開始就追求過于復雜的模型。

簡單可以體現在考慮的要素更少，比如成本收益分析只考慮兩個要素，就比考慮更多要素的模型簡單；

簡單還可以體現在要素的取值范圍更窄或精度要求更低，比如預計利潤只要求評估高/中/低，就比要求以萬元為單位評估預計利潤更簡單；

優先級模型確定后，可以進行存檔管理，注意該模型宜供所有人或相關人員查閱學習，比如錄入到DevCloud的Wiki知識管理系統就是一個很好的做法，如下圖：

二，排定需求優先級順序

比如成本收益分析，可以是把預期市場收入作為收益值，把預期研發投入作為成本值，計算差值，或計算ROI均可。假設需求A預計收益為10萬元，研發投入按人天折算預計3萬元，那么預計利潤就是7萬元，預計ROI是?233%；需求B預計收益為5萬元，研發投入折算預計4萬元，那么預計利潤1萬元，預計ROI為?25%。那么需求A的優先級順序就要比需求B更靠前。這種相差懸殊的情況往往不難判斷，我們假設還有需求C預計利潤也是7萬元、預計ROI是50%，以及需求D是預計利潤1萬元、預計ROI是500%。那么A、B、C、D這四個需求的具體順序怎么排定呢？

如果真的出現這種情況，那就更復雜一些了，需要考慮引入權重，然后計算出一個綜合值，這個值按照某種規則（例如從大到小）排列出來就是最終的優先級順序，比如：

預計收入（萬元）

預計成本（萬元）

預計利潤（萬元）

利潤權重

利潤加權值

ROI（%）

ROI權重

ROI加權值

綜合值

優先級順序

需求A

10

3

7

0.1

0.7

233%

1

2.33

3.03

2

需求B

5

4

1

0.1

0.1

25%

1

0.25

0.35

4

需求C

21

14

7

0.1

0.7

50%

1

0.5

1.2

3

需求D

2

1

1

0.1

0.1

500%

1

5.0

5.1

1

根據上述表格中所得出的結果，我們就應該依序將需求D、需求A、需求C、需求B排入開發計劃。優先級順序，在DevCloud中，可以使用工作項的“優先級順序”字段來實現，該字段取值范圍1-100，如下圖所示。

三，調整需求優先級順序

調整順序本身非常簡單，只要在DevCloud中重新設定該需求的“優先級順序”字段的值就可以。但重要的是，需要將優先級順序調整這件事情記錄下來，包括為什么要調整、具體如何調整的、調整背后的具體考慮等信息都記錄下來，同樣，建議記錄在Wiki知識管理系統中。用于后續的復盤回顧中作為參考信息，比如每個Sprint/迭代結束時的回顧會議上拿出來進行探討。

四，改進優先級模型

市場在變化，用戶在變化，產品在變化，優先級模型自然也必須跟隨著發生變化。我們可以定期或不定期的安排對需求優先級模型進行復盤分析，找出可以改進或優化的點，并跟進落實。可以是定期開展，例如每個月進行一次復盤，把這個月所涉及的需求都拿出來審視，或者是其中有調整過優先級順序或者出現過問題的需求拿出來審視均可；也可以是不定期，以問題驅動的方式，比如某天進行了大量需求優先級的調整，那么當天或第二天就可以臨時召集一次復盤會議，分析為什么會發生這種情況。

復盤要有好的效果，就必須盡可能的復原問題發生當時的情況，所以前面提到的Wiki記錄就變得非常重要。復盤會議應提供盡可能多的相關信息以便參會人員了解情況，充分探討。

復盤過程中，我們要定位出正確的根因，是模型本身設計有問題（例如要素和尺度），還是取值、加權有問題（比如某類需求的預計收入就是非常難估算），還是過程管理的問題（比如過早進行估算，因為缺乏必要信息，導致估算得出的優先級順序不準確），并進行針對性地改進。

參考附錄

相關文章

維基百科上的Kano模型詞條：https://en.wikipedia.org/wiki/Kano_model

相關書籍

杰拉爾德·溫伯格：《成為技術領導者》

邱昭良：《復盤+：把經驗轉化為能力》

敏捷開發 項目管理 DevCloud

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。