长期以来，测量、跟踪和基准测试开发人员生产力一直被认为是黑匣子。事情并不一定是这样的。
现在，大多数公司（在某种程度上）正在成为软件公司，无论哪个行业，领导者都需要知道他们正在尽可能成功地部署最有价值的人才。
不可否认，衡量开发人员的生产力是很困难的。在软件开发中，输入和输出之间的联系则相当不明确。软件开发也是高度协作、复杂和创造性的工作，对于不同级别（例如系统、团队和个人）需要不同的度量标准。
但是，软件开发的格局正在迅速变化，因为 Copilot X 和 ChatGPT 等生成式人工智能工具有潜力使开发人员能够以两倍的速度完成任务。
为了帮助克服这些挑战并使这项关键任务更加可行，我们开发了一种衡量软件开发人员生产力的方法，该方法更容易通过调查或现有数据（例如积压管理工具）进行部署。在此过程中，我们建立在行业领导者多年来开发的现有生产力指标的基础上，着眼于揭示绩效改进的机会。
这种新方法已在近 20 家科技、金融和制药公司实施，初步结果令人鼓舞。它们包括以下改进：
- 客户报告的产品缺陷减少 20% 至 30%
- 员工体验得分提高 20%
- 客户满意度提高 60 个百分点
利用生产力洞察 通过获得更丰富的生产力数据和见解，领导者可以开始回答有关他们努力吸引和留住的软件工程人才的紧迫问题，例如：
- 工程师发挥最佳水平的障碍是什么？
- 文化和组织对他们创作最佳作品的能力有多大影响？
- 我们如何知道我们是否将他们的时间用于真正推动价值的活动？
- 我们如何知道我们是否拥有所需的所有软件工程人才？
DORA指标与 SPACE 标准 我们希望扩展软件行业已经开发的两组指标：第一个是 DORA 指标，以 Google 的 DevOps 研究和评估团队命名。这些是科技行业最接近的标准，并且非常擅长衡量结果。
当 DORA 指标返回低于标准的结果时，这是一个需要调查问题所在的信号，这通常可能涉及长时间的调查。例如，如果部署频率等指标增加或减少，可能有多种原因。确定它们是什么以及如何解决它们通常并不简单。
第二组行业开发的衡量标准是 SPACE 衡量标准（满意度和幸福感、绩效、活动、沟通和协作以及效率和流程），GitHub 和 Microsoft Research 开发该衡量标准是为了增强 DORA 衡量标准。
通过采用单独的视角，特别是围绕开发人员的福祉，SPACE 指标非常适合阐明工程组织是否得到优化。例如，开发人员遇到的中断增加表明需要进行优化。
除了这些已经很强大的指标之外，我们的方法旨在确定可以采取哪些措施来改进产品的交付方式以及这些改进的价值，而无需重型仪器。将 DORA 和 SPACE 指标与以机会为中心的指标相补充，可以创建软件开发人员生产力的端到端视图
内/外循环所花费的时间 为了确定需要改进的具体领域，将软件开发中涉及的活动视为安排在两个循环中会很有帮助。
- 内循环包括与创建产品直接相关的活动：编码、构建和单元测试。
- 外循环包含开发人员将代码投入生产所必须执行的其他任务：集成、集成测试、发布和部署。
顶级科技公司的目标是让开发人员花费 70% 的时间进行内循环活动。例如，一家之前成功完成敏捷转型的公司发现，其开发人员没有将太多时间花在编码上，而是花在低附加值任务上，例如配置基础设施、运行手动单元测试和管理测试数据。有了这种洞察力，它推出了一系列新工具和自动化项目，以帮助完成整个软件开发生命周期中的这些任务。
开发者速度指数基准 开发人员速度指数 (DVI) 是一项衡量企业技术、工作实践和组织能力并将其与同行进行比较的调查。这种比较有助于挖掘特定领域的机会，无论是积压管理、测试还是安全性和合规性。
例如，一家以其技术实力和全明星开发人员而闻名的公司，在发现开发人员报告的大量不满、返工和低效率后，试图更周全地定义跨团队协作的标准工作实践。
贡献分析 评估个人对团队积压工作的贡献（从 Jira 等积压工作管理工具的数据开始，并使用专有算法规范数据以考虑细微差别）可以帮助揭示阻碍团队能力优化的趋势。
这种洞察力可以使团队领导者管理明确的产出期望并从而提高绩效。此外，它还可以帮助确定个人技能提升或培训的机会，并重新考虑团队内的角色分配（例如，如果质量保证测试人员有足够的工作要做）。
例如，一家公司发现其最有才华的开发人员在非编码活动上花费了过多的时间，例如设计会议或管理团队之间的相互依赖关系。作为回应，该公司改变了运营模式并明确了角色和职责，使那些最高价值的开发人员能够做他们最擅长的事情：编码。
另一家公司在发现新加入该组织的开发人员的贡献相对较低后，重新审查了他们的入职和个人指导计划。
人才能力得分 该分数基于行业标准能力图，是对特定组织的个人知识、技能和能力的总结。理想情况下，组织应该追求“钻石”的熟练程度分布，大多数开发人员处于中等能力范围。2这可能会带来辅导和技能提升的机会，在极端情况下需要重新思考人才战略。
例如，一家公司发现其开发人员在“新手”能力方面的集中程度高于理想水平。他们根据特定差距部署了个性化学习旅程，并能够在六个月内将 30% 的开发人员提升到更高的专业水平。
反驳观点：
1、软件开发衡量不足？ 这篇文章首先断言，软件开发的衡量标准不足。
相反，在所有商业活动中，软件开发是受到最严格审查和衡量的活动之一。从上世纪六七十年代开始，软件开发一直是一项昂贵而又充满风险的工作。起初，这是由于计算和操作机器的成本造成的，后来随着成本下降和程序员工资的飙升，这就变成了报酬问题。
对任何高风险和/或高成本的工作进行审查都是合情合理的，但不幸的是，对于软件行业来说，我们采用了与工业--土木工程和工厂生产--相同的简化模式，如甘特图、资源分配和其他工业时代的科学管理工具。这种认为软件开发与组装汽车一样具有可还原复杂性的假设，是开发人员生产力挑战的核心所在。
敏捷运动兴起于 20 世纪 90 年代，源于人们对多年期工作计划成果不佳的不满，尽管这些工作计划经过了精心的规划、衡量和审查，但仍然会超出预算并交付错误的成果。在这个时代，有一件事你不能称之为 "衡量不足"。当然，也有一些衡量软件开发的方法，可以跟踪生产率并突出需要关注的领域，但绝不是衡量不足！
开门见山地说，我认为这篇文章的论点有两个主要方面都是错误的：
- 软件开发是一种可还原的活动，可以用还原论工具来衡量。
- 软件开发的主要内容是编码，除了在计算机终端输入代码之外，其他任何事情都是浪费，我们应该设法消除这种浪费。
2、Gen-AI 工具能让开发人员快一倍吗？ 生成式人工智能工具可能会让开发人员以两倍的速度编写代码。不过，我在许多大型和小型企业中积累了三十年的实践开发经验，使用过许多编程语言、范式和技术，涉及许多业务领域，并为无数其他企业提供过咨询服务，我可以自信地断言，大部分编程工作都不是在输入代码。
编程的大部分工作是学习业务领域；理解问题；评估可能的解决方案；通过反馈和实验验证假设；识别、评估和满足跨职能需求，如合规性、安全性、可用性、弹性、可访问性、可用性，这些需求可能会使产品从令人讨厌到非法；确保大规模的一致性；预测可能的变化矢量而不过度设计；评估和选择合适的技术；识别和利用已有的解决方案，无论是内部的还是第三方的。
键入代码只是所有这些工作中的一小部分，因此使用 Gen-AI 来加快键入代码的速度虽然有用，但很难 "让开发人员的速度快一倍"。
3、初步结果如何？ 丹尼尔-卡尼曼（Daniel Kahneman）教授在其著作《思考的快与慢》（Thinking Fast and Slow）中提出了 "小数法则"（Law of Small Numbers）。这是指研究人员倾向于根据小数据集进行概括。他将此称为错误的直觉。
这篇文章有 20 个案例研究，这对于一家咨询公司来说看似很多，但从统计学角度来看，仍然几乎没有意义。还有其他方法论问题：
- 似乎没有任何对照基础；在类似的团队中，你没有采用这种方法作为基线，或者你尝试了其他方法作为替代假设。
- 你没有考虑霍桑效应，即当团队意识到他们正在被观察时，他们的行为会有所不同，尽管这一点存在争议。
- 你似乎没有对这些指标进行隔离。当时还有什么其他情况可以解释这些改进？这种方法是因果关系，只是相关关系，还是巧合？
- 我知道这只是一篇非正式的文章，而不是同行评议的论文，但用轶事证据来展示一种新方法的 "有前途的结果"，可能会产生误导。
4、让那些最高价值的开发人员能够编码？ 这就是整篇文章的核心所在：最高价值开发人员是其他开发人员的 10 倍！ 但是，他们所做的最有用的事情不是自己编写代码，最无用的事情反而是自己编写代码。
高盛特别根据影响力和影响力以及这些变化在公司发展过程中的平衡来评估员：在某人职业生涯的早期，重点是影响力；他们生产什么以及如何生产。接下来，是关于他们对周围人的影响程度，不仅是上级和下级，而且是整个组织的横向影响。高级员工因培育丰富的网络并能够完成工作而获得奖励。
现实很容易描述，但很难衡量：
- 多想，少做，缩短实现价值的时间。
- 让事情变得小而简单，这样您就可以快速行动并适应。