度量开发人员生产力：17 家科技公司的经验总结

Gergely Orosz（The Pragmatic Engineer Newsletter 作者）和 Abi Noda（DX 首席执行官，DevEx 框架创建者之一）在 Pragmatic Engineer 上发表了一篇题为“开发生产力度量：真实案例分析”的文章。InfoQ 报道了 Noda 对 17 家知名科技巨头所使用的工程指标的调查结果。Noda 发现，位居前列的团队并不会大规模采用像 DORA 或 SPACE 这样的框架，而是会混合使用特定于组织的定性和定量指标。Noda 和 Orosz 从指标实现团队所寻求的结果倒推，提供了定义此类指标的建议。

Noda 写道，他“采访了 17 家知名科技公司负责度量开发人员生产力的团队。”在这篇文章中，Noda 和 Orosz 重点调查了 4 类规模的组织，10 万员工的谷歌、1 万员工的 LinkedIn、1 万员工以下的 Peloton，以及 1000 员工以下的 Notion 和 Postman 等。所使用的指标范围从典型的 PR 和 CI 指标到谷歌系统性选择的指标。

Noda 观察到，在实践中，“DORA 和 SPACE 指标是有选择性地使用的”，而不是全部采用。他写道，虽然调查显示“每家公司都有自己量身定制的方法”，但他相信“任何规模的组织都可以采用谷歌的整体理念和方法。”Noda 写道，谷歌的方法需要根据“速度、易用性和质量”这三类度量来选择指标。他写道，这三个维度之间存在着“紧张的关系”，“有助于揭示潜在的权衡取舍”。

Noda 写道，谷歌使用“定性和定量度量来计算指标”，因为这提供了“尽可能全面的画面”。Noda 列举了谷歌使用的一系列信息获取方法，从满意度调查到“使用日志度量”。他写道：

无论是度量工具、过程还是团队，谷歌的开发情报团队都认同这样的看法，即单个度量标准无法衡量生产力。相反，他们从速度、易用性和质量这三个维度来审视生产力。

类似地，Noda 和 Orosz 描述了 LinkedIn 如何将季度开发者满意度调查与定量指标相结合。Noda 在文章中提到了 LinkedIn 开发者洞察团队使用的一系列指标。这些指标旨在减少“关键开发活动的阻力”。该团队使用的指标包括 CI 稳定性指标、部署成功率、p50 和 p90 构建时间，代码审查响应时间，以及提交通过 CI 管道的时间。Noda 描述了团队如何用定性见解来支持这种定量度量，并举了一个例子，将构建时间与“开发人员对构建满意程度”做了比较。LinkedIn 还使用“温莎均值（winsorized mean）”对客观数值指标进行了去噪：

温莎均值的意思是，求出第 99 百分位数，然后把所有高于第 99 百分位数的数据点削减，而不是剔除。如果第 99 百分位是 100 秒，而你有一个数据点是 110 秒，则把 110 划掉，写上 100，现在，你计算出的（温莎）均值会是一个更有用的数字。

Noda 写道，Peloton（代表 3000 到 4000 名员工的组织）已经从最初的“通过开发体验调查获得定性见解”发展到结合定量指标。例如，用前置时间和部署频率作为速度度量的客观指标。他写道，Peloton 的指标还包括定性参与度得分、服务恢复时间，以及代码质量（“250 行以下 PR、行覆盖率和变更失败率”的百分比来衡量）。

在谈到 Notion 和 Postman 等规模较小的“扩张中”组织时，Noda 写道，这些组织通常专注于度量“可移动指标（movable metrics）”。他解释说，这是一个易受影响的度量指标，指标实现团队可以“通过其工作对指标产生积极或消极的影响来移动它”。这方面的一个例子是“交付难易度”。Noda 写道，这一指标反映了“认知负荷和反馈循环”，并且可以根据“开发者感受到的完成工作的难易程度”进行调整。另一个常见的可移动指标是“开发者因障碍和阻力而损失的时间占比”。Noda 描述了这个指标是如何体现其价值的：

这个指标可以转化为钱：这是一个最大的好处！这使得商业领袖很容易理解时间损失（Time Loss）。例如，如果一个工程工资成本为 1000 万美元的组织通过一项计划将时间损失从 20% 减少到 10%，那么这将节省 100 万美元。

考虑到此类工程指标的上下文特点，Noda 建议组织按以下几个步骤来定义指标：

• 在任务声明中定义你的目标，解释“为什么会存在开发生产力团队？”

• “从目标出发，根据速度、易用性和质量来定义最上层指标”

• 定义与“特定项目或目标关键结果”相关的“操作级指标”，例如，特定开发生产力增强服务的采用率

Noda 通过示例指出，所选择的指标应该综合考虑“速度、易用性和质量”等维度。他举例说，如果目标是让开发人员更容易“交付高质量的软件”，那么指标就应该包括“感知交付速度”、“交付难易程度”和“事件发生频率”。

Orosz 和 Noda 的这篇文章是继“回应 McKinsey：衡量开发者生产力？”之后发表的又一篇文章。在之前的文章中，Orosz 与 Kent Beck 合作向 Mckinsey 的文章“是的，你可以衡量软件开发人员的生产力”发起了挑战。Mckinsey 的文章提出了所谓的“以机会为中心”的指标，“用以确定如何改进产品交付方式以及改进价值。”这篇文章讨论了基于 DORA 和 SPACE 的开发人员生产力度量，内容包括鼓励领导者优化个体开发人员效率的建议，以及一个“非编码活动（如设计会议）”的例子。该文提出的指标包括跟踪“个人贡献”和度量“人才能力得分”。

Beck 警告说，衡量个人生产力而不是交付结果是有风险的，他分享了自己看到这些指标变成“用金钱和地位来激励改进度量标准”的经历。他表示，虽然这可能会导致“行为改变”，但它也会受到游戏化的影响，变成激励“以创造性的方式改进这些度量标准”。Beck 和 Orosz 鼓励领导者把重点放在衡量“影响”而不是“工作量”上。Beck 特别建议，这样的度量标准只能用于被度量之物的持续改进反馈循环，而不应该用于其他任何东西。他还警告说，滥用衡量个人的指标会导致安全问题：

要清楚你为什么要问这个问题，以及你和被度量者之间的权力关系。当有权力的人度量没有权力的人时，结果会失真……在哪个层面收集数据就在哪个层面分析，从而避免不当激励。我可以分析我自己的数据，而我的团队可以分析他们自己的汇总数据。‍

Noda 还提醒说，如果是 CTO、VPE 或工程总监级别的人需要提供开发人员绩效指标，最好是确保报告处于相当的层面上。Noda 建议选择代表“业务影响”、“系统性能”和“工程组织”级“开发效率”的指标，例如项目级指标“用户 NPS”和“周时间损失”。Noda 建议高层领导：

在这种情况下，我建议最好是重新定义问题。你的领导团队想要的并不是完美的生产力指标，而是可以进一步确认你是他们工程投资的好管家。

在对 McKinsey 报告的回应中，Orosz 和 Beck 提醒说，“人们会优化被度量的东西”。他们引用了古德哈特定律，即“当一项措施成为目标时，它就不再是一项好措施。”

原文链接：

https://www.infoq.com/news/2024/01/engineering-productivity-metrics/

声明：本文由 InfoQ 翻译，未经许可禁止转载。