硬核公式计算研发工作优先级
我最喜欢的一张激励海报上印着吉萨金字塔，标题处写着「Achievement」；它底下的解释有些讽刺，但非常有说服力：当你有远见、决心和无穷无尽的可消耗劳动力供应时，你可以做任何你想做的事情。
不幸的是，于我们而言——作为产品经理的我们——我们或许有远见和决心，但却很可能缺乏无穷无尽的可消耗的劳动力（和时间）。这就是为什么我们要对团队的工作进行优先级排序。我们必须确定哪些成果唾手可得：相较预期的成果而言，这些工作可以轻而易举、不费吹灰之力地完成。
几年前，我编译了这个优先级排序框架的早期版本，并将它投入Voice123，Bunny Studio和Torre等多家公司的团队进行测试。经过多年的调整、改进和验证，我想公开分享它——Prioridad。
一、需求、事务和缺陷，如何确定三者的优先次序？
产品经理和研发团队通常会处理三种类型的工作：需求、事务和缺陷。
缺陷（Bug） 是与规格相比，会导致意外行为的产品漏洞，通常由开发团队产生；而事务是产品设计中导致用户体验不佳的缺陷，通常由产品经理或产品设计师产生。
首先，我们需要一个用于确定需求、事务和缺陷三者优先次序的方法——这很大程度上取决于业务性质、产品所处的阶段（跑通PMF前/后）和团队规模。两种常见的方法分别是基于产品卓越性，或基于时间分配确定优先级。
01 基于产品卓越性排序
这种排序基于一个前提：拥有一个（近乎）完美无缺的产品，至关重要。对于「产品即业务」的公司而言，这很常见，比如SaaS产品和视频游戏。基于产品卓越性的工作优先级也很容易确定：
[*]总是先修复缺陷
[*]然后处理事务
[*]最后再开发新需求
它对产品经理和研发成员都适用；但是，对尚未跑通PMF的产品不太适用：默认情况下，此时产研团队应该专注于实现达到市场需要的新需求，而事务和缺陷往往只在需求完成后才解决。
02 基于时间分配排序
这种排序方法的前提是，即使产品存在一些缺陷，持续推出新的产品功能依旧是必不可少的。它适用于「产品是业务推动者，而非业务本身」的公司，例如Steam V.S. 羊了个羊——前者属于服务型产品，后者属于流量型产品。
对于这种情况，可以尝试在三种工作之间平均分配精力，将产品团队和研发团队的可用时间划分为三周的循环：
在某些情况下，比如实现复杂功能或偿还大量技术债务时，这样的循环是行不通的。需要注意，尽管开发团队可以在解决事务和实现新需求时修补技术债，但仍需要时常为它分配特定的解决时间。
无论你采用哪种方式，每组任务、需求、事务和缺陷都有自己的优先级排序逻辑。
二、如何确定需求/事务的优先次序？
确定多个需求/事务的优先级，可以结合优先级系数辅助完成。优先级系数的计算公式如下：
核心KPI （Core KPI ） 反映的是产品的核心交互。 于Bunny Studio而言，核心KPI是完成的项目数量；对Voice123来说，核心KPI则是提交的项目和提交的信息。
核心效果指标（Effect in core KPI ） 指新需求/功能或事务发布后，核心KPI的预期增量，可以用一段时间内核心KPI的绝对数量、与之相关的收入增长或各自的百分比来估计。下面是一些参考指标：
[*]50, 000 次授权/年
[*]300 万项目收入/月
[*]提升 20% 的功能使用率
[*]线上收入占比提升 20%
此外，核心效果指标也可以是一个结合多个因素计算得出的指标。 因子是否相乘或相加取决于它们是否相互复合。如果需要相加，那么所有因子在相加前，都需要遵循统一的数据基准进行标准化，比如使用 1 到 10 的评分体系。
举个例子，Torre的大多数团队会为每个新需求，分析下面这些复合因素：
[*]与用户用途的相关性：使用 0-10 的衡量等级，0 代表「没有解决用户需求」，10 代表「总能解决用户需求」。
[*]用户粘性：每周潜在的互动数量。
[*]新功能的总可寻市场：以可能使用新功能的人数为计量单位。
[*]Wow因子：用 1-10 的评分衡量，1 分代表「不怎么样」，10 分代表「和我第一次看到iPhone一样令人印象深刻」。
[*]转化率提升：指增加的访客成为注册用户的可能性，测量范围可以从 0 到 100% 或更多。
[*]价值感知速度：以 1/d 为单位，其中d是新用户在注册后感知价值所需的天数。
[*]病毒式传播：一个普通用户在使用Torre的前 30 天内会给Torre带来多少新用户。
[*]病毒传播速度：以 1/d 为单位，其中d是新用户发送第一个邀请给其他人可能需要的天数。
[*]公关 潜力：以 1-10 的评分衡量，1 分代表「没啥可吹的」，10 表示「媲美首次登月」。
这些因素适用于Torre大多数团队，但并不适用于所有团队。例如，SEO团队就使用每月搜索量、竞争力、用户生成内容（UGC）等其他因素指标。
成功几率（Chance of success） 是一个 0%-100% 的估计值，用于捕捉交付的努力能够达成核心效果指标的可能性。这最开始会是一个大胆的预估，但通过后续的原型设计和分割A/B测试，可以降低其不确定性。
实现复杂度（Implementation complexity） 用于衡量实现新功能或事务所需的工作量。理想情况下，这个估计值会受到产品经理、产品设计师和技术主管意见的影响。这个值可以是工时，也可以是斐波那契数列。
例如，预计能将核心KPI提高 30%、成功几率仅为 10%、需要耗费 15 个工时的工作，其优先级系数将如下所示：
无论为每个变量选择怎样的计量单位和度量标准，确定优先级顺序时，对所有新需求/事务应用相同的单位和参考标准是最重要的。
三、如何确定缺陷的优先次序？
确定缺陷修复的优先级时，一个最重要的判断因素是该缺陷是否阻碍了用户。 在本篇指南的语境中，用户无法继续完成预期的使用，就是被阻挡了。
[*]最高级：妨碍大多数用户使用产品的缺陷
[*]高级：妨碍少数用户使用的缺陷
[*]中级：大多数用户遇到但不妨碍使用的缺陷
[*]初级：少数用户遇到但不妨碍使用的缺陷
四、关于优先级排序的实用技巧
[*]始终使用相同的公式进行优先级排序。 用相同的计算公式比较多项工作，优先级排序才能奏效。
[*]在每项工作的标题上添加优先级值。 这将能让你更轻松地根据优先级系数，完成项目/产品管理面板的排序。
[*]每项工作都要记录下计算方式、计算者以及结果日期。 这会帮助其他成员更好地理解你的预估值来源，并对估算结果提出质疑；还将帮你确定估算是否过时，以及是否需要更新。
[*]培养直觉。 进行数百次数学运算后，你将会发展出无需手动计算，就能确定工作优先级的能力，并且结果仍然具有很高的准确性。
# Liga总结
Prioridad是一个经过多次实践和验证的框架，通过引入「优先级系数」概念，量化并确定新功能、产品设计缺陷（事务）和产品使用缺陷（Bug）的优先次序。
优先级系数通过综合新功能的预期效果、成功几率和工作量等指标，帮助敏捷团队更直观地掌握和分析研发工作的重要性。
原文作者：Alexander Torrenegra
文章出处：Medium
了解更多敏捷开发、项目管理、行业动态等消息，关注我们 LigaAI@oschina 或点击LigaAI - 新一代智能研发协作平台，在线申请体验我们的产品。
https://my.oschina.net/u/5057806/blog/5579958
页:
[1]