时间: 2021-07-30 11:22:48 人气: 11 评论: 0
作为产品经理，每天都**面对一大堆需求，时间和人力有限，只能给每个需求排序，决定先后顺序。本文从三个方面，用两种方法决定需求的先后顺序，希望对你有帮助。
每个产品都有一堆永远做不完的堆积如山的需求，每个团队都感觉人不够用。怎么办？产品经理的重要工作之一是：决定优先级先后顺序。
决定需求的先后顺序有两种方法：定性评估法和定量计算法。定性评估法是通过评估影响需求排序的几个要素，为需求排出先后顺序；定量计算法是为影响排序的每个要素赋予一个数值，然后用公式计算出需求的唯一顺序。
决定需求的优先级顺序有以下几个要素要考虑：
延期成本是当工作或里程碑延期交付所产生的财务成本，延期成本将价值和延期交付的时间合并起来，延期成本可能是创造的价值，也可能是经济损失。
若想知道一个产品、一个特性的延期成本，只需要问一个问题：“如果我们晚交付一个月的话，**给我们造成什么损失？”或者正向问法：”如果我们提前交付一个月的话，**给我们带来什么价值？“
为需求排序，延期成本是首要考虑的因素。当延期成本无法区分出先后顺序的时候，比如：在很多时候，你**发现很多需求互相对比，它们的价值相当，时间上没有一定非要什么时候上线的期望，这时候，可以考虑下面的几个要素。
对于同等价值和时间要求的需求，团队通常**选择成本低、交付速度快的需求。因为越早完成，越早产生价值，并及早获得用户反馈，增加我们对用户的认知。
风险和不确定是两个相互伴随的两个兄弟，但却是两个不同因素：不确定性可能蕴藏着风险，并不一定**带来风险，但是风险一定是带有不确定性。
如果需求具有不确定性，比如：在一定条件下这个需求**引爆市场，但是这个条件何时到来还不知道，那么一般采取的方法是推迟决策，同时密切跟踪市场动向。早做了也是浪费，晚做了就白做。
如果需求的实现有风险，比如：需求需要对已有代码模块的实现逻辑甚至架构有重大冲击，尽管这个需求价值很高， 团队往往****喜欢推迟到以后再做，其实这是逃避风险的自然反应。现在不做，**继续堆积现有实现逻辑的代码，以后再做这个需求带来的冲击**更大。
因此，对于这种有风险的需求，如果决定必须做，就要早做，直面风险。
也许你知道用户故事的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 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
