作為產品經理，每天都會面對一大堆需求，時間和人力有限，只能給每個需求排序，決定先后順序。本文從三個方面，用兩種方法決定需求的先后順序，希望對你有幫助。

每個產品都有一堆永遠做不完的堆積如山的需求，每個團隊都感覺人不夠用。怎么辦？產品經理的重要工作之一是：決定優先級先后順序。

決定需求的先后順序有兩種方法：定性評估法和定量計算法。定性評估法是通過評估影響需求排序的幾個要素，為需求排出先后順序；定量計算法是為影響排序的每個要素賦予一個數值，然后用公式計算出需求的唯一順序。

一、定性評估法

決定需求的優先級順序有以下幾個要素要考慮：

1. 延期成本

延期成本是當工作或里程碑延期交付所產生的財務成本，延期成本將價值和延期交付的時間合并起來，延期成本可能是創造的價值，也可能是經濟損失。

若想知道一個產品、一個特性的延期成本，只需要問一個問題：“如果我們晚交付一個月的話，會給我們造成什么損失？”或者正向問法：”如果我們提前交付一個月的話，會給我們帶來什么價值？“

為需求排序，延期成本是首要考慮的因素。當延期成本無法區分出先后順序的時候，比如：在很多時候，你會發現很多需求互相對比，它們的價值相當，時間上沒有一定非要什么時候上線的期望，這時候，可以考慮下面的幾個要素。

2. 實現成本

對于同等價值和時間要求的需求，團隊通常會選擇成本低、交付速度快的需求。因為越早完成，越早產生價值，并及早獲得用戶反饋，增加我們對用戶的認知。

3. 風險和不確定性

風險和不確定是兩個相互伴隨的兩個兄弟，但卻是兩個不同因素：不確定性可能蘊藏著風險，并不一定會帶來風險，但是風險一定是帶有不確定性。

如果需求具有不確定性，比如：在一定條件下這個需求會引爆市場，但是這個條件何時到來還不知道，那么一般采取的方法是推遲決策，同時密切跟蹤市場動向。早做了也是浪費，晚做了就白做。

如果需求的實現有風險，比如：需求需要對已有代碼模塊的實現邏輯甚至架構有重大沖擊，盡管這個需求價值很高， 團隊往往會會喜歡推遲到以后再做，其實這是逃避風險的自然反應?，F在不做，會繼續堆積現有實現邏輯的代碼，以后再做這個需求帶來的沖擊會更大。

因此，對于這種有風險的需求，如果決定必須做，就要早做，直面風險。

4.?依賴

也許你知道用戶故事的INVEST原則，INVEST其中的I（Independent）就是指的獨立性，即：拆分用戶故事盡量要避免相互依賴。但是依賴是不可能完全避免的，可以通過合并兩個依賴的故事，或者重新拆分來避免依賴。但是即便這樣，也無法完全避免依賴。

如果最后還是發生了故事A依賴于故事B，那么最好A和B錯開一個迭代來實現，至少錯開一周。尤其對于依賴的用戶故事由其他團隊交付的情況，進度不受自己團隊控制，更需要錯開節奏。如下圖：

對每個需求就這五個要素都分析后，就可以排出優先級順序。

二、定量計算法

SAFe（Scaled Agile Framework）提出了一種定量計算法來評估需求的優先級，稱為WSJF（Weighted Shortest Job First: 加權最短作業優先）。

計算公式如下：

其中分母的工作規模部分大家比較熟悉，即估算的需求規模（故事點方法、理想時間方法等）。

分母部分的延期成本包括三個因子：

1. User and Business Value(用戶和商業價值)

指的是對客戶或商業的相對價值，比如：用戶更喜歡哪個？對盈收有什么影響？不做會產生什么潛在的負面影響？

2. Time Criticality（時間關鍵性）

指的是給用戶的商業價值隨著時間的推進如何變化。比如：是否是固定交付日期類型的需求？用戶是否會愿意等待，還是會選擇其他產品在某個時間窗口不上線的話，是否會影響用戶的滿意度？

3. Risk Reduction& Opportunity Enablement（減少風險或幫助獲取新機會）

指的是除了第1和第2因子相關的因素之外，這個需求還能為業務帶來哪些價值, 比如：是否降低產品以后交付某些必要特性的風險？是否會學到我們不知道的知識或信息？是否會帶來新的商業機會？

這樣拆解后，WSJF的公式細化為：

如何操作呢？將所有特性列成表，如下：

對這個表中WSJF公式中的每個因子，采用與用戶故事的故事點相對估算類似的方法做估算。

比如，對于工作規模這一項，選擇一個工作規模最小的特性作為基準，它的工作規模設為1，其他特性的工作規模與之相對比, 采用近似斐波那契數列1, 2,3, 5, 8,13, 20…為單位。如果特性A是基準特性的3倍，那么特性A的工作規模就是3。

為WSJF公式分子的其他因子做同樣的相對估算法，即找到一個因子最小的基準特性，然后其他特性與之相比較，從而得到相應因子的估算數值。

就每一個特性，將WSJF的每個因子做相對估算后，就可以計算出每個特性的WSJF，這樣你就得到了量化的需求排序。

常見疑惑：WSJF適用于所有需求的排序嗎？

不是的。在SAFe里，WSJF可以適用于大粒度的Epic和Feature級需求，不適用于小顆粒的用戶故事級需求，原因是用戶故事通常很小，分母的幾個因子不容易對比出差異，此外這種定量計算法用在團隊里應用過于沉重。

三、三點提示

最后，兩點注意事項和一個常見疑問：

優先級是相對的，不是絕對的。只有將兩個需求放在一起，你才能判斷出哪個優先做，哪個靠后做，單獨地說某個需求優先級高是沒有意義的。

不要迷信公式，量化計算法評估出的優先級也只是參考。需求的排序不是完全數學公式可以計算的，而是個理性評估加藝術直覺的快速決策過程。團隊的交付節奏越密集、交付速度越快，花在排序上的時間就可以越少，因為即使排得不合理，或者不確定，下次發布馬上就可以發布你排在后面的需求。

常見疑問：需要對整個Backlog排出唯一的先后順序嗎?

通過以上介紹的方法，足以對哪些需求排在整個Backlog的頂部做出區分。然后，對于排在Backlog頂部的當前版本的需求，以及最近一、兩個迭代的需求排出唯一先后順序，對于以后版本以及一、兩個迭代以后的需求，不需要排出唯一的先后順序，也沒有足夠的認知來排出。隨著持續地發布產品，我們通過用戶的反饋對需求的優先級認識會有變化。

因此，過早排序也是一種浪費。

作者：王明蘭 ，中國最早期的精益看板國際認證教練(KCP)&培訓師(AKT)， 企業級規?；艚軸AFe認證咨詢師(SPC4)，咨詢轉型產品人、自媒體撰稿人

本文由 @ONES 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。