产品经理：需求排序大法

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

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

一、定性评估法

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

1. 延期成本

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

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

为需求排序，延期成本是首要考虑的因素。当延期成本无法区分出先后顺序的时候，比如：在很多时候，你会发现很多需求互相对比，它们的价值相当，时间上没有一定非要什么时候上线的期望，这时候，可以考虑下面的几个要素。

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

因此，过早排序也是一种浪费。

作者：王明兰 ，中国最早期的精益看板国际认证教练(KCP)&培训师(AKT)， 企业级规模化敏捷SAFe认证咨询师(SPC4)，咨询转型产品人、自媒体撰稿人

本文作者 @ONES 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！