分享一个研发工作优先级的计算公式 | Liga 译文

我最喜欢的一张激励海报上印着吉萨金字塔，标题处写着「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 个工时的工作，其优先级系数将如下所示：

无论为每个变量选择怎样的计量单位和度量标准，确定优先级顺序时，对所有新需求/事务应用相同的单位和参考标准是最重要的。

三、如何确定缺陷的优先次序？

确定缺陷修复的优先级时，一个最重要的判断因素是该缺陷是否阻碍了用户。在本篇指南的语境中，用户无法继续完成预期的使用，就是被阻挡了。

• 最高级：妨碍大多数用户使用产品的缺陷

• 高级：妨碍少数用户使用的缺陷

• 中级：大多数用户遇到但不妨碍使用的缺陷

• 初级：少数用户遇到但不妨碍使用的缺陷

四、关于优先级排序的实用技巧

1. 始终使用相同的公式进行优先级排序。用相同的计算公式比较多项工作，优先级排序才能奏效。

2. 在每项工作的标题上添加优先级值。这将能让你更轻松地根据优先级系数，完成项目/产品管理面板的排序。

3. 每项工作都要记录下计算方式、计算者以及结果日期。这会帮助其他成员更好地理解你的预估值来源，并对估算结果提出质疑；还将帮你确定估算是否过时，以及是否需要更新。

4. 培养直觉。进行数百次数学运算后，你将会发展出无需手动计算，就能确定工作优先级的能力，并且结果仍然具有很高的准确性。

# Liga 总结

Prioridad 是一个经过多次实践和验证的框架，通过引入「优先级系数」概念，量化并确定新功能、产品设计缺陷（事务）和产品使用缺陷（Bug）的优先次序。

优先级系数通过综合新功能的预期效果、成功几率和工作量等指标，帮助敏捷团队更直观地掌握和分析研发工作的重要性。 

原文作者：Alexander Torrenegra

文章出处：Medium