2024 年软件工程 KPIs 的问题及其解决之道 [译]
大部分工程 KPIs 根本站不住脚。
成为一名工程领导者，你不可避免地会面临一个挑战：必须提供关于团队健康、生产力和产出的度量指标。在初创公司里，这通常是 CEO 提出的要求——“我们需要一个清晰的进展衡量方式”。这个要求看似合理，毕竟工程部门也应该像销售团队一样被问责。
但事实上，这是一个复杂的问题；我曾在高层会议和对外汇报中努力解释这个问题。多年来，我回答这个问题总是从同样的一句话开始。
“大多数工程 KPIs 其实毫无意义。”
为了解释这一点，我参考了麦肯锡关于度量开发者生产力的研究。他们在 2023 年 8 月发布的文章*“是的，你可以衡量软件开发者的生产力”*引起了不少争议。
我建议你阅读麦肯锡的这篇文章。它确实提供了一种观点。但我认为这种观点被误导了，主要针对那些从未真正组建或管理过高效工程团队的非技术人士。不过，这篇文章的存在也说明到目前为止，首席技术官和工程领导者在回答这类问题时表现不佳。
我们不妨将其与另一个擅长回答生产力问题的部门进行比较——销售。销售的核心是影响力——个人或团队完成了多少交易？以及“这对公司年度目标产生了什么影响”。这里有很多层面，比如新业务、续签业务等。我虽然不是销售专家，但曾与许多销售人员紧密合作，他们的问责性通常很强。因此，高层随时都能了解销售部门的整体表现，因为这相对容易理解。
在寻找工程度量指标的过程中，工程领导者（有时包括非技术高管）经常做出错误决定，他们倾向于衡量产出而不是影响。比如，每个迭代交付的故事点数、提交的拉取请求等。这是因为这些指标更容易衡量，至少能提供一个相对简单的答案，而不是去回答更微妙、更复杂的“这项工作的影响是什么？”。
绝大多数工程领域的 KPI 只是空话。
确实，这些指标毫无意义。它们无法提供任何有效信息，关键是，它们在衡量实际影响力时未能命中要害。此外，我想在这里引用 Goodhart 法则。一旦设定了这些指标，人们就会开始钻空子。回顾一下 Uber 开始采用这类指标时发生的情况吧。
目前，在工程界有几个广受尊敬的框架：DORA、SPACE 以及最近的 DevEx。它们是回答 KPI 问题的实用工具，尤其是最近的 DevEx 论文中专门讨论了 KPI。我建议大家阅读这些论文，它们在一定程度上改变了我在 2023 年的观点。实际上，Mckinsey 的文章是基于 DORA 和 SPACE 来构建其方法论的，并增添了一些有趣的元素。但这也暴露了单独使用这些工具的风险 - 毕竟，一个不称职的木匠总是抱怨他的工具！
那么，应该如何衡量工程生产力，以及应该设定哪些 KPI 呢？
到了 2024 年，我的答案是：
首先，将工程健康指标与 KPI 区分开。DORA、SPACE 和 DevEx 框架为设定有效的健康指标提供了不错的思路。例如：开发周期、错误率、工程师满意度。密切关注这些指标；高水平的健康指标意味着工程设置良好，但并不一定表示所完成的工作对业务产生了实质性推动。
其次，设定能够衡量业务影响的 KPI。很难具体告诉你这些应该是什么，因为它们会因公司而异。但一个通用的思路是，从公司的价值角度衡量每一个潜在的产品或工程变革。然后，评估所完成的工作是否实现了预期目标，以及与其他任务的对比情况。
亚马逊在其“客户至上”理念中采用了这一思路的变体。它不是用金钱来衡量，而是从客户价值的角度出发。选择与你的商业愿景相符的指标。
将 KPI 与业务价值对齐后，组织中的每个人都能更容易理解取得的进展。这种方法还确保了对完成的工作高度负责。以业务价值为基础的 KPI，使高层管理人员能够轻松追踪工程对公司的影响，并据此做出明智的投资和绩效决策。CTO 和工程领导者可以单独监控健康指标，并视情况进行改进。两套指标均高意味着一个真正高效的工程部门。
因此，我的结论是：大多数工程关键绩效指标（KPIs）都是无稽之谈 - 但实际上并不需要如此！
软件工程是一个新兴领域。互联网公司这个概念顶多只有 30 年的历史。软件工程是这些组织的核心，我们还在摸索如何高效地建设和评估工程。
如果你所在的组织正在用基于产出的指标来评估工程表现，我建议你重新思考，将工程与你的愿景相结合，并依据其对实际商业影响的贡献来衡量进展。
参考文献：
McKinsey Paper - Yes, you can measure software developer productivity
Uber - Measuring Developer Productivity
Amazon - Customer Obsession