需求優先順序的管理，其實是為了幫助我們確定先做哪個需求後做哪個需求，從而可以最大化我們的回報、最小化我們的風險或投入。要做好優先順序管理，或者更直接來說是優先順序順序管理，我們需要做到如下幾件事情：
確定優先順序模型：優先順序看起來像是乙個簡單直接的值，但實際上它是乙個基於多種因素進行綜合判斷之後得出的乙個值，這些因素和判斷原則，就是我們所說的優先順序模型；
排定需求優先順序順序：將需求代入優先順序模型進行計算，得出每個需求的優先順序順序；
調整需求優先順序順序；
改進優先順序模型：如果經常發生需要調整需求優先順序順序的情況，那麼最好是對這些情況進行一定的覆盤分析，如有必要，修正或改進當前的優先順序模型，讓它可以適應實際情況，以避免調整優先順序順序的情況反**生；另外就是需求可能已經交付或發布上線，但是該功能的實際用量或價值不吻合預期，則需要反思我們對這些需求的分析和判斷，究竟是分析判斷有誤還是優先順序模型有誤，並進行相應的調整；
成本收益分析就是最簡單的一種優先順序模型，重要
/緊急的四象限也是一種優先順序模型，
kano
模型也是一種優先順序模型，它們都可以幫助我們去確定需求的優先順序順序。模型可以簡單也可以複雜，根據企業實際需要來確定即可。
務必切記優先順序模型不應追求完美，以避免模型過於複雜，導致優先順序管理的管理開銷過高，喧賓奪主，反而影響了需求的開發和交付。如果較為簡單的模型就可以滿足需要，就應該首選使用較簡單的模型。企業可以從簡單開始，逐漸完善，不需要也不應該在一開始就追求過於複雜的模型。
優先順序模型確定後，可以進行存檔管理，注意該模型宜供所有人或相關人員查閱學習，比如錄入到
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 10.1
0.1500% 1
5.05.1 1
根據上述**中所得出的結果，我們就應該依序將需求d
、需求a
、需求c
、需求b
排入開發計畫。優先順序順序，在
devcloud
中，可以使用工作項的
「優先順序順序
」欄位來實現，該欄位取值範圍
1-100
，如下圖所示。
調整順序本身非常簡單，只要在
devcloud
中重新設定該需求的
「優先順序順序
」欄位的值就可以。但重要的是，需要將優先順序順序調整這件事情記錄下來，包括為什麼要調整、具體如何調整的、調整背後的具體考慮等資訊都記錄下來，同樣，建議記錄在
wiki
知識管理系統中。用於後續的覆盤回顧中作為參考資訊，比如每個
sprint/
迭代結束時的回顧會議上拿出來進行**。
市場在變化，使用者在變化，產品在變化，優先順序模型自然也必須跟隨著發生變化。我們可以定期或不定期的安排對需求優先順序模型進行復盤分析，找出可以改進或優化的點，並跟進落實。可以是定期開展，例如每個月進行一次覆盤，把這個月所涉及的需求都拿出來審視，或者是其中有調整過優先順序順序或者出現過問題的需求拿出來審視均可；也可以是不定期，以問題驅動的方式，比如某天進行了大量需求優先順序的調整，那麼當天或第二天就可以臨時召集一次覆盤會議，分析為什麼會發生這種情況。
覆盤要有好的效果，就必須盡可能的復原問題發生當時的情況，所以前面提到的
wiki
記錄就變得非常重要。覆盤會議應提供盡可能多的相關資訊以便參會人員了解情況，充分**。
覆盤過程中，我們要定位出正確的根因，是模型本身設計有問題（例如要素和尺度），還是取值、加權有問題（比如某類需求的預計收入就是非常難估算），還是過程管理的問題（比如過早進行估算，因為缺乏必要資訊，導致估算得出的優先順序順序不準確），並進行針對性地改進。
維基百科上的
kano
模型詞條：
傑拉爾德·溫伯格：《成為技術領導者》
邱昭良：《覆盤
+：把經驗轉化為能力》
需求優先順序
需求優先順序主要是針對功能需求而言的，除卻被依賴的需求應當優先實現之外，需求優先順序主要反映了客戶希望最終系統提供某功能需求的迫切程度。一般而言，需求優先順序可以分為 鑑於此，我們也就不難理解，乙個專案中，需求優先順序為高 中 低的需求的比例應該科學 比如3 4 3 從而有利於專案管理。如果將需求優...
如何進行需求矩陣管理
字型 小 中需求管理 軟體測試管理 產品經理需要掌握並管理產品的全部需求，需求是軟體專案成敗的關鍵所在，好的需求應具備 內涵一致，外延完整 的特質，這個特質可以保證需求分析無歧義 完整 一致 正確 可行 必要 可檢驗 可跟蹤。軟體需求是多層次的，包括業務需求 使用者需求 功能需求和非功能需求。如下圖...
如何進行需求矩陣管理
產品經理需要掌握並管理產品的全部需求，需求是軟體專案成敗的關鍵所在，好的需求應具備 內涵一致，外延完整 的特質，這個特質可以保證需求分析無歧義 完整 一致 正確 可行 必要 可檢驗 可跟蹤。軟體需求是多層次的，包括業務需求 使用者需求 功能需求和非功能需求。如下圖所示 啟動乙個新產品時，產品經理需和...