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

 

 

 

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

 

 

 

定性評估法

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

延期成本

 

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

 

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

 

上篇文章還在為產品優先級決策犯愁嗎：教你服務級別分析方法介紹了延期成本，以及如何從延期成本的角度區分需求的服務級別。本文不再贅述。為需求排序，延期成本是首要考慮的因素。當延期成本無法區分出先后順序的時候，比如：在很多時候，你會發現很多需求互相對比，它們的價值相當，時間上沒有一定非要什么時候上線的期望，這時候，可以考慮下面的幾個要素。

 

   2.實現成本

 

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

 

  3. 風險和不確定性

 

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

 

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

 

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

 

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頂部的當前版本的需求，以及最近一、兩個迭代的需求排出唯一先后順序，對于以后版本以及一、兩個迭代以后的需求，不需要排出唯一的先后順序，也沒有足夠的認知來排出。隨著持續地發布產品，我們通過用戶的反饋對需求的優先級認識會有變化。因此，過早排序也是一種浪費。

 

當然，比決定優先級更重要的是決定做與不做（后續文章介紹）。