提升开发效率:17家科技公司的生产力度量经验分享

发表时间: 2024-02-18 18:02

作者 | Rafiq Gemmail

译者 | 平川

策划 | Tina

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.cn/article/jKNpX8GDUCGGXA5evkP2