今年八月，咨询巨头麦肯锡在一篇题为“是的，你可以衡量软件开发人员的生产力”的文章中宣布了自己的解决方案，但引起了不同的反应。
开发人员的生产力是一个很难定义的概念。为此，麦肯锡选择了两个流行的工程度量框架：DORA 和 SPACE。
DORA 指标
DORA 指标于 2014 年由谷歌的 DevOps 研究与评估团队提出，旨在衡量工程设计和运营部门如何有效合作，在此基础上交付软件：
- 变更失败率
- 失败部署的恢复时间（直到最近才被称为平均恢复时间 (MTTR)
- 部署频率
- 准备时间
2021 年，一些 DORA 原作者聚集在一起，提出了 25 个社会技术因素，分别归入以下五个类别：
- 满意度和幸福感
- 绩效
- 活动
- 沟通与协作
- 效率与流程
麦肯锡的论文认为，这两套衡量标准是科技行业最接近一致认可的标准。
然后，他们又增加了四项指标，重点关注绩效改进的机会：
- 内环/外环花费的时间
- 开发人员速度指数（DVI）基准
- 贡献分析
- 人才能力得分
麦肯锡的框架只衡量努力或产出，而不是结果和影响，这就忽略了软件开发人员一半生命周期。
机会指标 1：内/外循环所用时间
麦肯锡说明了 "非详尽 "的内环和外环软件开发活动。
麦肯锡认为，开发人员应将至少 70% 的时间花在 "内环 "任务上。这些都是有助于应用程序的构建、编码和测试的工作。剩下的外环任务被作者称为 "不太充实 "的任务，包括会议、集成、安全和合规性以及大规模部署。
虽然从 DevOps 到平台工程等现代软件开发方法都在寻求减少重复性工作和开发人员的认知负荷，以便他们能够专注于解决问题，但麦肯锡认为，衡量生产率的目标是激励开发人员编写更多代码，这削弱了开发人员是创造性工作者的理念。
麦肯锡有可能进一步妖魔化会议，而会议是形成团队纽带、共享信息、提高质量以及使工程设计与业务目标保持一致的重要仪式。
机会指标 2：DVI 基准
开发人员季度调查是迄今为止定性衡量开发人员体验的最常见方法之一。自 2014 年以来，麦肯锡的 DVI 分析了由 46 个单独绩效驱动因素组成的 13 种能力，试图衡量企业的技术、工作实践和组织能力。该指数可用于与同行进行基准比较，并突出速度改进领域，例如通过积压管理、测试或安全性与合规性等。
然而，除了技术、工作实践和组织能力这三个维度之外，DVI 方法的范围似乎很有限。
速度很容易成为一种不一致的衡量标准，可能会为了速度而牺牲质量。
机会指标 3：贡献分析
麦肯锡识别个人对团队积压工作的贡献，将生产率指标与绩效混为一谈。
部分原因是生产率跟踪通常与 "数豆子 "联系在一起，无论是单个任务，还是做事情需要多少时间。
开发人员讨厌这种方法。他们觉得这会让人焦虑。
他们发现这种方法并不能真正体现他们工作的多面性和复杂性，对他们来说，这感觉很像间谍，就像有人在监视他们做了多少事情，或者他们做一件事情花了多长时间。
SPACE 框架不遗余力地告诫我们，不要用故事点完成量或代码行数来衡量开发人员。
麦肯锡在文章中列举了一个匿名的 "成功案例"，该客户通过贡献分析认识到，其最有才华的开发人员在非编码活动上花费了过多的时间，如设计会议或管理跨团队的相互依存关系。该公司随后改变了运营模式，让这些价值最高的开发人员能够从事更多的编码工作。
这再次表明，编码是开发人员最有价值的工作。
这种做法无法扩大规模，而且会迅速导致人才流失。由于只关注个人贡献而非团队，这种方法未能将代码审查、指导他人和实验等重要的粘合工作包括在内。它还贬低了设计会议等工作的价值，而设计会议有助于确保您构建的是用户真正需要的东西，而不是在不必要的解决方案上浪费时间。
机会指标 4：人才能力得分
麦肯锡的人才能力评分试图映射组织中个人的知识、技能和能力，以确定辅导和提高技能的机会。
问题在于，软件开发并不能通过增加人员来扩大规模，我们所掌握的证据也表明，成功并不取决于拥有合适的工程人才，项目成功与否取决于团队如何组织工作以及团队成员之间的信任程度，而麦肯锡的框架显然不具备这些要素。
现阶段还不清楚这些指标的收集有多少是传达给工程团队的。大多数开发人员生产力指标，包括 SPACE 中概述的指标，都是通过询问开发人员的需求来启动的。这是建立管理者与团队之间心理安全的重要一步。
文化在哪里？
麦肯锡忽略了社会技术软件开发工作中的社会层面，从而陷入了 "开发人员在编码时最有价值 "的误区。
美国计算机协会（Association for Computing Machinery，ACM）在 5 月份发表了一篇题为《DevEx：究竟是什么驱动了生产力》的论文。这篇文章认为，开发人员的体验和生产力通过三个维度内在地联系在一起：
- 反馈回路--开发人员多快能将工作交付到生产中
- 认知负荷--开发人员需要学习多少知识才能真正实现生产价值
- 流动状态--没有分心和计划外的工作干扰
该文认为，为了提高开发人员的工作效率，企业需要消除摩擦和挫折感，而这正是本文主要作者 Abi Noda 所称的 "高度个人化且依赖于上下文的体验"。
文化对生产力的重要性不容忽视。
关注个人不利于提高团队生产力
”开发人员生产力 "一词本身可能就是问题的一部分。相反，企业应该以衡量软件开发团队的能力为目标，以确定流程、工作方式、技术和文化变革，从而让开发团队发挥出最佳水平。
麦肯锡的方法与谷歌、微软和 Atlassian 等领先科技公司的方法直接相悖：后者这些公司不是试图衡量个人产出，而是专注于了解和改善开发人员的体验，通过解决开发人员最大的摩擦和挫折来源，这些公司能够始终如一地培养出最具生产力的开发团队。
以开发人员的个人生产力来衡量软件开发是一个糟糕的想法。
最后的想法
麦肯锡的方法完全忽视了开发人员也是人，他们也会受到生产率指标的激励或打击，因此，在软件开发人员团队处于高度紧张状态的时候，麦肯锡的方法不受欢迎地回归到了命令与控制的按钮推动方式。
当工程领导者继续寻找衡量和提高团队向用户发布高质量软件的速度的方法时，这个框架危险地将重点放在了简单的结果上，而忽略了开发人员的快乐、协作和团队精神对于更快地开发出更好的软件的重要性。