主要观点

Gergely Orosz 和 Abi Noda 在其文章《Measuring Developer Productivity: Real-World Examples》中分析了多家知名科技公司在开发人员生产力衡量方面的实践，并提供了定义此类指标的指导。文章强调了根据组织的具体需求选择指标的重要性，而非盲目采用通用的 DORA 或 SPACE 指标。

关键信息

1. 指标选择的多样性：调查显示，不同公司根据其特定需求选择不同的定性和定量指标，而非全面采用 DORA 或 SPACE 指标。
2. Google 的方法：Google 通过“速度、易用性和质量”三个维度选择指标，并使用定性和定量测量相结合的方法。
3. LinkedIn 的实践：LinkedIn 结合季度开发人员满意度调查和定量指标，如 CI 稳定性、部署成功率等，并通过“winsorized mean”方法减少异常值的影响。
4. Peloton 的演变：Peloton 从最初的定性调查发展到结合定量指标，如交付时间、部署频率等。
5. 小规模公司的关注点：小规模公司（如 Notion 和 Postman）更关注“可移动指标”，如交付的易用性和开发人员时间损失。
6. 指标定义的四步法：建议组织在定义指标时，首先确定目标，然后从目标出发定义顶层指标，再定义与具体项目或目标关键结果相关的操作指标。

重要细节

1. Google 的指标选择：Google 选择指标时考虑速度、易用性和质量之间的权衡，认为单一的指标无法全面反映生产力。
2. LinkedIn 的定量与定性结合：LinkedIn 通过定量指标和定性洞察相结合，如比较构建时间与开发人员对构建的满意度。
3. Peloton 的指标：Peloton 的指标包括代码质量（如 PR 行数、行覆盖率和变更失败率）和服务恢复时间。
4. 小规模公司的指标：小规模公司关注“可移动指标”，如开发人员时间损失，这些指标可以直接转化为财务影响。
5. 对 McKinsey 的回应：Orosz 和 Beck 在之前的合作中挑战了 McKinsey 提出的“机会导向”指标，警告了衡量个人生产力的风险，建议关注“影响”而非“努力”，并引用 Goodhart’s Law 提醒当衡量指标成为目标时，它就不再是一个好的衡量标准。

总结

文章强调了根据组织具体需求选择开发人员生产力指标的重要性，并提供了从目标出发定义指标的实用方法。通过对多家知名科技公司的实践分析，展示了定性和定量指标结合的有效性，同时警告了衡量个人生产力的潜在风险，建议组织关注影响而非努力。