作为产品经理，每天面对很多需求，时间和人才有限，只能按需求排序，决定优先顺序。 本文从三个方面，用两种方法决定需求的优先顺序，希望对你有帮助。
每个产品都有永远做不完的山一样的需求，每个团队都觉得人手不够。 怎么办？ 产品经理的重要工作之一是决定优先顺序。
决定需求的优先顺序有定性评价法和定量计算法两种方法。 定性评价法是对影响需求排序的几个要素进行评价，划分需求优先级的定量计算法是对影响排序的各要素赋予数值，用公式计算需求的唯一顺序。
一、定性评估法
要确定需求的优先级，必须考虑以下因素：
1. 延期成本
延期成本是指工作或里程碑延期交货时产生的财务成本，延期成本综合了价值和延期交货时间，延期成本可能是创造性的价值，也可能是经济损失。如果你想知道一个产品，一个特性的延期成本，“如果我们晚交一个月，会给我们带来什么损失？ ”我只是问。 或者，“如果我们提前一个月交货，会给我们带来什么价值？ 「
对需求进行排名，延期成本是首要考虑因素。 在延期成本无法区分优先顺序的情况下，例如，往往会比较很多需求，它们的价值是相等的，在时间上并没有什么时候必须在线的期待。 在这种情况下，可以考虑以下因素。
2. 实现成本
对于需要同等价值和时间的需求，团队通常会选择成本低、交货速度快的需求。 因为完成得越早，价值就产生得越早，得到的用户反馈就越早，对用户的认识就越高。
3. 风险和不确定性
风险和不确定是彼此相伴的两兄弟，但却是两个不同的因素。 不确定性有可能蕴藏着风险，不一定会带来风险，但风险一定具有不确定性。在需求存在不确定性的情况下，例如，在一定条件下，这个需求会引爆市场，但在还不知道这个条件何时到来的情况下，一般采取的方法是一边推迟决策，一边密切跟踪市场走势。 早做没用，晚做没用。
如果需求的实现有风险，例如，需求必须对现有代码模块的实现逻辑和体系结构产生重大冲击。 但是，尽管这种需求价值很高，球队往往喜欢推后，其实这是逃避风险的自然反应。 如果现在不做，现有实现逻辑的代码就会不断积累，以后做这个需求会带来更大的影响。
因此，针对这种有风险的需求，如果决定必须做的话，就必须快点做，面对风险。
4. 依赖
您可能知道用户故事的INVEST原则，但INVEST中的I (独立)是指独立性。 也就是说，分割用户文章需要尽量避免相互依存。 但是，依赖是不能完全避免的。 可以通过合并或重新分割两个依赖的故事来避免依赖。 但是，尽管如此，也不能完全避免依赖。最后，如果故事a依赖于故事b，最好通过错开反复来实现，以使a和b至少错开一周。 特别是在其他团队交付所依赖的用户故事时，进度不受自己团队的控制，需要错开节奏。 下图：
根据不同的需求分析这五个要素，可以排列优先顺序。
二、定量计算法
safe (Scale Dagile Framework )提出了一种被称为WSJF (WEIGHTED Shortest Jobfirst :加权最短工作优先)的定量算法。计算公式如下。
其中分母的工作规模部分大家都很清楚。 也就是说，估算的需求规模(故事点方法、理想的时间方法等)。
分母的延迟成本有三个因素：
1 .“用户和业务价值”) )。
指对顾客或商业的相对价值。 例如，用户喜欢哪个？ 盈余有什么影响？ 有什么潜在的负面影响吗？
2. Time Criticality (时间上的重要性) ) )。
指对用户的业务价值随着时间的推移如何变化。 例如，确定交货期类型的需求吗？ 用户等待吗？ 还是选择其他产品，不在某个时间的窗口在线，会影响用户的满意度吗？
3.riskreductionopportunityenablement (减少风险或帮助获得新机会) )。
除了第1因子和第2因子相关的要素以外，还指出了这种需求会给业务带来什么样的价值。 例如，降低产品今后交付某些必要特性的风险吗？ 你会学习我们不知道的知识和信息吗？ 会带来新的商业机会吗？
这样分解后，WSJF的公式细分如下。
怎么操作？ 所有特性如下表所示。
比如，对于工作规模这一项，选择一个工作规模最小的特性作为基准，它的工作规模设为1，其他特性的工作规模与之相对比, 采用近似斐波那契数列1, 2,3, 5, 8,13, 20…为单位。如果特性A是基准特性的3倍，那么特性A的工作规模就是3。
为WSJF公式分子的其他因子做同样的相对估算法，即找到一个因子最小的基准特性，然后其他特性与之相比较，从而得到相应因子的估算数值。
就每一个特性，将WSJF的每个因子做相对估算后，就可以计算出每个特性的WSJF，这样你就得到了量化的需求排序。
常见疑惑：WSJF适用于所有需求的排序吗？
不是的。在SAFe里，WSJF可以适用于大粒度的Epic和Feature级需求，不适用于小颗粒的用户故事级需求，原因是用户故事通常很小，分母的几个因子不容易对比出差异，此外这种定量计算法用在团队里应用过于沉重。
三、三点提示
最后，两点注意事项和一个常见疑问：
优先级是相对的，不是绝对的。只有将两个需求放在一起，你才能判断出哪个优先做，哪个靠后做，单独地说某个需求优先级高是没有意义的。
不要迷信公式，量化计算法评估出的优先级也只是参考。需求的排序不是完全数学公式可以计算的，而是个理性评估加艺术直觉的快速决策过程。团队的交付节奏越密集、交付速度越快，花在排序上的时间就可以越少，因为即使排得不合理，或者不确定，下次发布马上就可以发布你排在后面的需求。
常见疑问：需要对整个Backlog排出唯一的先后顺序吗?
通过以上介绍的方法，足以对哪些需求排在整个Backlog的顶部做出区分。然后，对于排在Backlog顶部的当前版本的需求，以及最近一、两个迭代的需求排出唯一先后顺序，对于以后版本以及一、两个迭代以后的需求，不需要排出唯一的先后顺序，也没有足够的认知来排出。随着持续地发布产品，我们通过用户的反馈对需求的优先级认识会有变化。
因此，过早排序也是一种浪费。
作者：lmdym ，中国最早期的精益看板国际认证教练(KCP)&培训师(AKT)， 企业级规模化敏捷SAFe认证咨询师(SPC4)，咨询转型产品人、自媒体撰稿人
本文由 @ONES 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。