产品经理：需求排序大法

2017-10-30 16:48 来源：http://www.ceo315.org/ 阅读：次

每个产品都有一堆永远做不完的堆积如山的需求，每个团队都感觉人不够用。怎么办？产品经理的重要工作之一是：决定优先级，哪个先做，哪个后做。

决定需求的优先级顺序有两种方法：定性评估法和定量计算法。定性评估法是通过评估影响需求排序的几个要素，为需求排出先后顺序；定量计算法是为影响排序的每个要素赋予一个数值，然后用公式计算出需求的唯一顺序。

定性评估法

决定需求的优先级顺序有以下几个要素要考虑：

延期成本

延期成本是当工作或里程碑延期交付所产生的财务成本。延期成本将价值和延期交付的时间合并起来。延期成本可能是创造的价值，也可能是经济损失。

若想知道一个产品、一个特性的延期成本，只需要问一个问题：“如果我们晚交付一个月的话，会给我们造成什么损失？”或者正向问法：”如果我们提前交付一个月的话，会给我们带来什么价值？“

上篇文章还在为产品优先级决策犯愁吗：教你服务级别分析方法介绍了延期成本，以及如何从延期成本的角度区分需求的服务级别。本文不再赘述。为需求排序，延期成本是首要考虑的因素。当延期成本无法区分出先后顺序的时候，比如：在很多时候，你会发现很多需求互相对比，它们的价值相当，时间上没有一定非要什么时候上线的期望，这时候，可以考虑下面的几个要素。

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顶部的当前版本的需求，以及最近一、两个迭代的需求排出唯一先后顺序，对于以后版本以及一、两个迭代以后的需求，不需要排出唯一的先后顺序，也没有足够的认知来排出。随着持续地发布产品，我们通过用户的反馈对需求的优先级认识会有变化。因此，过早排序也是一种浪费。

当然，比决定优先级更重要的是决定做与不做（后续文章介绍）。