是的 ， 您可以衡量软件开发人员的工作效率

技术、媒体和电信实践 是的，您可以衡量软件开发人员的工作效率 测量，跟踪和基准开发人员的生产力一直被认为是一个黑匣子。 本文是ChandraGnanasambandam，MartinHarrysson，AlharithHussin，JasonKeovichit和ShivamSrivastava 的合作成果，代表了麦肯锡的数字与技术，媒体与电信实践的观点。 2023年8月 与其他关键业务相比诸如销售或客户运营之类的功能，软件开发一直被低估。许多技术人员长期以来一直认为不可能正确地做到这一点-而且无论如何，只有训练有素的工程师才有足够的知识来评估同行的绩效。然而这种现状不再是可持续的。现在大多数公司正在成为(在某种程度上 或其他)软件公司，无论行业如何，领导者都需要知道他们正在成功部署最有价值的人才 尽可能。 不可否认，衡量开发人员的生产率是困难的。其他功能可以 可以很好地衡量，有些甚至只有一个指标；而在软件开发中，输入和输出之间的联系却不那么清晰。软件开发也是高度协作、复杂和创造性的工作，需要针对不同级别(如系统、团队和个人)的不同度量。更重要的是，即使有真正的跟踪承诺 生产力正常，传统指标可能需要设置的系统和软件允许更细致和全面的测量。 对于某些标准指标，整个技术堆栈 和开发管道需要重新配置，以实现跟踪，并放置必要的工具和工具，以产生有意义的见解 可能需要大量的长期投资。此外，随着生成AI工具的出现 ，软件开发的格局正在迅速变化因为CopilotX和ChatGPT有潜力使开发人员能够更快地完成任务。 为了帮助克服这些挑战并使这项关键任务更加可行，我们开发了一种衡量软件开发人员生产力的方法，该方法更易于使用调查或现有数据（例如在积压管理工具中）进行部署。 行业领导者多年来开发的现有生产率指标，着眼于揭示性能改进的机会。 这种新方法已经在近20家科技、金融和制药公司实施，初步结果很有希望。它们包括以下改进: —客户报告的产品缺陷减少20%至30% —员工体验评分提高20% —客户满意度评分提高60个百分点 现在大多数公司正在成为软件公司，领导者需要知道他们正在尽可能成功地部署最有价值的人才。 利用生产力洞察 通过获得更丰富的生产力数据和见解，领导者可以开始回答有关他们为吸引和留住软件工程人才而奋斗的紧迫问题，例如： —工程师在最佳水平工作的障碍是什么？ —文化和组织对他们制作最佳作品的能力有多大影响 ？ —我们如何知道我们是否正在将他们的时间用于真正推动价值的活动？ —我们如何知道我们是否拥有所需的所有软件工程人才？ 了解基础 要使用足够细致入微的系统来衡量开发人员的生产力，必须了解需要跟踪的三种类型的指标：系统级别，团队级别和个人级别。与诸如销售之类的函数不同，在该函数中，可以使用系统级的美元收入或交易完成来衡量团队和个人的工作，即软件开发。 是一种独特的合作方式，需要 例如，虽然部署频率是评估系统或团队的一个非常好的指标，但它取决于所有团队成员完成各自的任务，因此不是跟踪个人表现的有用方法。 要识别的另一个关键维度是各种指标所做的和不告诉你的。对于 例如，测量部署频率或更改的前置时间可以让您清楚地了解某些结果，但不能清楚地了解工程组织是否得到了优化 。 由于故事点完成或中断可以帮助确定优化，他们需要更多的调查，以确定可能有益的改进。 在构建我们的指标集时，我们希望扩展软件行业已经开发的两套指标。第一个是DORA指标，以Google的DevOps研究和评估团队命名。这些是科技行业最接近标准的指标，它们非常擅长衡量结果。当DORA指标返回低于标准的结果时，它是调查什么的信号 出了问题，这通常会涉及旷日持久的调查。例如，如果部署频率等指标增加或减少，则可能有多个原因。确定它们是什么以及如何解决它们通常并不简单。 我们的方法旨在确定可以做些什么来改进产品的交付方式以及这些改进的价值，而不需要重型仪器。 第二套行业开发的衡量标准是SPACE指标（满意度和幸福感，绩效，活动，沟通和协作以及效率和流程），GitHb和MicrosoftResearch开发这些指标来增强DORA指标。通过采用单独的镜头，特别是围绕开发人员的福祉，SPACE指标可以很好地阐明工程组织是否得到了优化。例如，开发人员经历的中断增加表明需要优化。 在这些已经强大的指标之上，我们的方法试图确定可以做些什么 改进产品的交付方式以及这些改进的价值，而不需要繁重的仪器。以机会为中心的指标补充DORA和SPACE指标可以创建软件开发人员生产力的端到端视图（图表1） 。 这些以机会为中心的生产力指标使用几个不同的镜头来生成细微差别的 查看软件产品开发所涉及的复杂活动范围。 内/外循环所花费的时间。为了确定需要改进的具体领域 ，考虑 附件1 将重点放在软件开发人员生产力指标的机会上，可以提供更清晰的改进途径。 按级别划分的重点领域DORA1度量标准空间2指标以机会为中心的指标 成果重点你们交付的产品令人满意吗？ 系统部署频率level客户满意度可靠性(正 常运行时间) 优化重点³ 您是否以优化的方式交付产品？ 代码审查时间通过系统的速度/流量 机会重点是否有特定的机会来改善您交付产品的方式，以及它们的价值是什么？ 对工程系统的满意度 内/外循环所花费的时间 团队更改的前置时间level更改故障率恢复服务时 间代码审查速度 故事点已完成移交 文档质量 开发人员VelocityIndex基准测试4 贡献分析 个人开发人员满意度level保留 中断 贡献分析人才能力得分 1Google的DevOps研究和评估团队开发了这些结果指标。 2满意度和幸福感，绩效，活动，沟通和协作以及效率和流程;GitHub和MicrosoftResearch开发了这些指标，旨在将开发人员的幸福感视为个人层面的衡量指标。 3非详尽无遗。 4对组织的技术，工作实践和组织支持进行基准测试；请参阅ShivamSrivastava，KartikTrehan，DilipWagle和JaneWang，“开发人员速度：软件卓越如何促进业务绩效”，麦肯锡，2020年4月20日。 麦肯锡公司 软件开发中涉及的活动被安排在两个循环中(图表2)。内部循环包括与创建产品直接相关的活动：编码、构建和单元测试。外部循环包括开发人员将其代码推送到生产中必须执行的其他任务：集成，集成测试，发布和部署。从生产力和个人经验的角度来看，最大限度地提高开发人员在内部循环中花费的时间是可取的：构建产品直接产生价值 ，这是大多数开发人员兴奋的事情。大多数开发人员认为外部循环活动是必要的，但通常不令人满意的琐事。将时间投入到外部循环的更好的工具和自动化中，允许开发人员将更多的时间花在内部循环活动上。 顶级科技公司的目标是让开发人员花70%的时间做内部循环活动。例如，一家以前成功完成敏捷转型的公司了解到，其开发人员， 而不是编码，花费了太多时间在低附加值的任务上，如配置基础设施、运行手动单元测试和管理测试数据。它启动了一系列新工具和自动化项目，以帮助在整个软件开发生命周期中完成这些任务。 开发者速度指数基准。DeveloperVelocityIndex(DVI)是一项调查，用于衡量企业的技术、工作实践和组织能力，并将其与同行进行比较。这种比较有助于挖掘特定的机会领域，无论是积压管理、测试还是安全性和合规性。1例如，一家以其技术实力和全明星开发人员而闻名的公司，在发现开发人员报告的大量不满、返工和低效率后，试图为跨团队协作更深思熟虑地定义标准工作实践。 附件2 软件开发可以大致分为两组任务或循环；花在完成较少的外部循环活动上的时间越少越好。 软件开发活动 大规模部署 Build 代码内回 路 测试 外环1 Meetings 安全性和合规性 集成 1列出的活动是非详尽的。 麦肯锡公司 1要了解有关麦肯锡的DVI调查的更多信息，请参阅ShivamSrivastava，KartikTrehan，DilipWagle和JaneWang，“开发人员速度：软件卓越如何促进业务绩效”，麦肯锡，2020年4月20日；和ChandraGnanasambandam，NehaJindal，ShivamSrivastava和DilipWagle， 贡献分析。评估个人对团队积压工作的贡献（从Jira等积压管理工具的数据开始，并使用专有算法对数据进行标准化以解决细微差别）可以帮助揭示阻碍团队能力优化的趋势。 Thiskindofinsightcanenableteamleaderstomanageclearexpectationsforoutputandimproveperformanceasaresult.Additionally,itcanhelpidentifyopportunitiesforindividualupskilling 或培训和重新思考团队中的角色分配(例如，如果质量保证测试人员 有足够的工作要做)。例如，一家公司发现其最有才华的开发人员在非编码活动上花费了过多的时间，例如设计会议或跨团队管理相互依赖。作为回应，该公司改变了运营模式，明确了角色和职责，使那些价值最高的开发人员能够做他们最擅长的事情：代码。另一家公司在发现新开发人员对组织的贡献相对较低之后，重新审查了他们的入职和个人指导计划。 人才能力得分。根据行业标准能力图，此分数是特定组织的个人知识，技能和能力的摘要。理想情况下，组织应渴望熟练程度的“钻石”分布，大多数开发人员处于中等能力范围。2Thiscanshowcoachingandupskillingopportunities,andinextremecasescallsforareconsiderationoftalentstrategy.Forexample,onecompanyfoundahigherconcentrationoftheirdevelopersinthe“novice”capabilitythanwasidreadonspecificgationsand 30％的开发人员在六个月内达到新的专业知识水平。 避免度量错误 尽管有价值，但如果使用不当，开发人员生产力数据可能会对组织造成损害，因此避免某些陷阱很重要。在我们的工作中，我们看到两种主要类型的错误发生：滥用指标和未能超越旧的思维方式。 当公司试图采用过于简单的度量时，例如生成的代码行数或代码提交数（当开发人员将代码提交到版本控制系统时），误用是最常见的。这些简单的指标不仅无法产生真正有用的见解，还会产生意想不到的后果，例如领导者做出不恰当的权衡。例如,优化前置时间或部署频率可允许质量受损。专注于单个度量或过于简单的度量集合也可以很容易地激励不良做法;例如，在测量提交的情况下，开发人员可能会在寻求游戏系统时更频繁地提交较小的更改 。 为了真正从衡量生产力中受益，领导者和开发人员都需要超越过时的观念，即领导者“无法”理解软件工程的复杂性 ，或者工程太复杂而无法衡量。工程人才对公司成功的重要性，以及近年来对开发人员人才的激烈竞争，突显了我们需要承认软件开发和其他许多事情一样，需要衡量。在系统层面测量生产力使雇主能够看到阻碍工作和创造力的隐藏摩擦点。 2KlemensHjartar，PeterJacobs，EricLamarre和LarsVinter，“是时候重置IT人才模型了”，《麻省理工学院斯隆管理评论》，2020年3月5日。 找到更多这样的内容 麦肯锡见解应用程序 扫描•下载•个性化 开始使用 建立开发人员生产力计划的机制似乎令人生畏，但是现在没有时间开始奠定基础。推动将有关软件开发人员生产力的讨论提升到C级领导者的需要的因素超过了这样做的障碍。 远程工作的增加及其在开发人员中的受欢迎程度是最重要的因素之一。 开发人员长期以来一直在敏捷团队中工作，在同一物理空间中进行协作，一些技术领导者认为，面对面的团队合