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

技术、媒体和电信实践 是的，您可以衡量软件开发人员的工作效率 测量，跟踪和基准开发人员的生产力一直被认为是一个黑匣子。 本文是Chandra Gnanasambandam，Martin Harrysson，Alharith Hussin，Jason Keovichit和Shivam Srivastava的合作成果，代表了麦肯锡的数字与技术，媒体与电信实践的观点。 2023年8月 与其他关键业务相比诸如销售或客户运营之类的功能，软件开发一直被低估。许多技术人员长期以来一直认为不可能正确地做到这一点-而且无论如何，只有训练有素的工程师才有足够的知识来评估同行的绩效。然而这种现状不再是可持续的。现在大多数公司正在成为(在某种程度上 可能需要大量的长期投资。此外，随着生成AI工具的出现，软件开发的格局正在迅速变化因为Copilot X和ChatGPT有潜力使开发人员能够更快地完成任务。 为了帮助克服这些挑战并使这项关键任务更加可行，我们开发了一种衡量软件开发人员生产力的方法，该方法更易于使用调查或现有数据（例如在积压管理工具中）进行部署。行业领导者多年来开发的现有生产率指标，着眼于揭示性能改进的机会。 或其他)软件公司，无论行业如何，领导者都需要知道他们正在成功部署最有价值的人才尽可能。 不可否认，衡量开发人员的生产率是困难的。其他功能可以 可以很好地衡量，有些甚至只有一个指标；而在软件开发中，输入和输出之间的联系却不那么清晰。软件开发也是高度协作、复杂和创造性的工作，需要针对不同级别(如系统、团队和个人)的不同度量。更重要的是，即使有真正的跟踪承诺 这种新方法已经在近20家科技、金融和制药公司实施，初步结果很有希望。它们包括以下改进: —客户报告的产品缺陷减少20%至30% 生产力正常，传统指标可能需要设置的系统和软件允许更细致和全面的测量。 —员工体验评分提高20% —客户满意度评分提高60个百分点 和开发管道需要重新配置，以实现跟踪，并放置必要的工具和工具，以产生有意义的见解 现在大多数公司正在成为软件公司，领导者需要知道他们正在尽可能成功地部署最有价值的人才。 利用生产力洞察 例如，虽然部署频率是评估系统或团队的一个非常好的指标，但它取决于所有团队成员完成各自的任务，因此不是跟踪个人表现的有用方法。 通过获得更丰富的生产力数据和见解，领导者可以开始回答有关他们为吸引和留住软件工程人才而奋斗的紧迫问题，例如： 要识别的另一个关键维度是各种指标所做的和不告诉你的。对于 例如，测量部署频率或更改的前置时间可以让您清楚地了解某些结果，但不能清楚地了解工程组织是否得到了优化。由于故事点完成或中断可以帮助确定优化，他们需要更多的调查，以确定可能有益的改进。 —工程师在最佳水平工作的障碍是什么？ —文化和组织对他们制作最佳作品的能力有多大影响？ —我们如何知道我们是否正在将他们的时间用于真正推动价值的活动？ 在构建我们的指标集时，我们希望扩展软件行业已经开发的两套指标。第一个是DORA指标，以Google的DevOps研究和评估团队命名。这些是科技行业最接近标准的指标，它们非常擅长衡量结果。当DORA指标返回低于标准的结果时，它是调查什么的信号出了问题，这通常会涉及旷日持久的调查。例如，如果部署频率等指标增加或减少，则可能有多个原因。确定它们是什么以及如何解决它们通常并不简单。 —我们如何知道我们是否拥有所需的所有软件工程人才？ 了解基础 要使用足够细致入微的系统来衡量开发人员的生产力，必须了解需要跟踪的三种类型的指标：系统级别，团队级别和个人级别。与诸如销售之类的函数不同，在该函数中，可以使用系统级的美元收入或交易完成来衡量团队和个人的工作，即软件开发。是一种独特的合作方式，需要 我们的方法旨在确定可以做些什么来改进产品的交付方式以及这些改进的价值，而不需要重型仪器。 第二套行业开发的衡量标准是SPACE指标（满意度和幸福感，绩效，活动，沟通和协作以及效率和流程），GitHb和Microsoft Research开发这些指标来增强DORA指标。通过采用单独的镜头，特别是围绕开发人员的福祉，SPACE指标可以很好地阐明工程组织是否得到了优化。例如，开发人员经历的中断增加表明需要优化。 改进产品的交付方式以及这些改进的价值，而不需要繁重的仪器。以机会为中心的指标补充DORA和SPACE指标可以创建软件开发人员生产力的端到端视图（图表1）。 这些以机会为中心的生产力指标使用几个不同的镜头来生成细微差别的查看软件产品开发所涉及的复杂活动范围。 在这些已经强大的指标之上，我们的方法试图确定可以做些什么 内/外循环所花费的时间。为了确定需要改进的具体领域，考虑 麦肯锡公司 软件开发中涉及的活动被安排在两个循环中(图表2)。内部循环包括与创建产品直接相关的活动：编码、构建和单元测试。外部循环包括开发人员将其代码推送到生产中必须执行的其他任务：集成，集成测试，发布和部署。从生产力和个人经验的角度来看，最大限度地提高开发人员在内部循环中花费的时间是可取的：构建产品直接产生价值，这是大多数开发人员兴奋的事情。大多数开发人员认为外部循环活动是必要的，但通常不令人满意的琐事。将时间投入到外部循环的更好的工具和自动化中，允许开发人员将更多的时间花在内部循环活动上。 而不是编码，花费了太多时间在低附加值的任务上，如配置基础设施、运行手动单元测试和管理测试数据。它启动了一系列新工具和自动化项目，以帮助在整个软件开发生命周期中完成这些任务。 开发者速度指数基准。DeveloperVelocityIndex(DVI)是一项调查，用于衡量企业的技术、工作实践和组织能力，并将其与同行进行比较。这种比较有助于挖掘特定的机会领域，无论是积压管理、测试还是安全性和合规性。1例如，一家以其技术实力和全明星开发人员而闻名的公司，在发现开发人员报告的大量不满、返工和低效率后，试图为跨团队协作更深思熟虑地定义标准工作实践。 顶级科技公司的目标是让开发人员花70%的时间做内部循环活动。例如，一家以前成功完成敏捷转型的公司了解到，其开发人员， 软件开发可以大致分为两组任务或循环；花在完成较少的外部循环活动上的时间越少越好。 麦肯锡公司 避免度量错误 贡献分析。评估个人对团队积压工作的贡献（从Jira等积压管理工具的数据开始，并使用专有算法对数据进行标准化以解决细微差别）可以帮助揭示阻碍团队能力优化的趋势。 尽管有价值，但如果使用不当，开发人员生产力数据可能会对组织造成损害，因此避免某些陷阱很重要。在我们的工作中，我们看到两种主要类型的错误发生：滥用指标和未能超越旧的思维方式。 This kind of insight can enable team leaders to manage clearexpectations for output and improve performance as a result.Additionally, it can help identify opportunities for individualupskilling 当公司试图采用过于简单的度量时，例如生成的代码行数或代码提交数（当开发人员将代码提交到版本控制系统时），误用是最常见的。这些简单的指标不仅无法产生真正有用的见解，还会产生意想不到的后果，例如领导者做出不恰当的权衡。例如,优化前置时间或部署频率可允许质量受损。专注于单个度量或过于简单的度量集合也可以很容易地激励不良做法;例如，在测量提交的情况下，开发人员可能会在寻求游戏系统时更频繁地提交较小的更改。 或培训和重新思考团队中的角色分配(例如，如果质量保证测试人员 有足够的工作要做)。例如，一家公司发现其最有才华的开发人员在非编码活动上花费了过多的时间，例如设计会议或跨团队管理相互依赖。作为回应，该公司改变了运营模式，明确了角色和职责，使那些价值最高的开发人员能够做他们最擅长的事情：代码。另一家公司在发现新开发人员对组织的贡献相对较低之后，重新审查了他们的入职和个人指导计划。 为了真正从衡量生产力中受益，领导者和开发人员都需要超越过时的观念，即领导者“无法”理解软件工程的复杂性，或者工程太复杂而无法衡量。工程人才对公司成功的重要性，以及近年来对开发人员人才的激烈竞争，突显了我们需要承认软件开发和其他许多事情一样，需要衡量。在系统层面测量生产力使雇主能够看到阻碍工作和创造力的隐藏摩擦点。 人才能力得分。根据行业标准能力图，此分数是特定组织的个人知识，技能和能力的摘要。理想情况下，组织应渴望熟练程度的“钻石”分布，大多数开发人员处于中等能力范围。2This can show coaching and upskilling opportunities, andin extreme cases calls for a reconsideration of talent strategy.For example, one company found a higher concentration oftheir developers in the “novice ” capability than was idread onspecific gations and 30％的开发人员在六个月内达到新的专业知识水平。 开始使用 相反，他们可以从许多关键步骤开始这个过程： 建立开发人员生产力计划的机制似乎令人生畏，但是现在没有时间开始奠定基础。推动将有关软件开发人员生产力的讨论提升到C级领导者的需要的因素超过了这样做的障碍。 学习基础知识。所有不是工程师或曾在管理中工作过的高级管理人员 在很长一段时间内，将需要一个入门的软件开发过程和它是如何演变的。 远程工作的增加及其在开发人员中的受欢迎程度是最重要的因素之一。 评估你的系统。由于开发人员的生产力通常没有在确定改进机会所需的水平上进行测量，因此大多数公司的技术堆栈将需要潜在的大规模重新配置。 开发人员长期以来一直在敏捷团队中工作，在同一物理空间中进行协作，一些技术领导者认为，面对面的团队合作对这项工作至关重要。然而，对他们的工作如此重要的数字工具使得在大流行封锁期间很容易转向远程工作，就像在大多数行业一样，这种转变很难撤销。随着远程和混合工作越来越成为常态，组织将需要依靠广泛、客观的测量来保持对这些新工作安排的信心，并确保他们稳步改善职能。 例如，为了测量测试覆盖率（代码领域已经被充分测试的程度），开发团队需要为他们的代码库配备一个可以跟踪测试运行期间执行的代码的工具。 制定一个计划。与大多数分析计划一样，迷失在堆积如山的数据中也是一种风险。重要的是要从一个领域开始，你知道这个领域将导致一条清晰的改进之路，比如确定摩擦点和瓶颈。要明确这样一个计划的范围，因为即使是最好的方法，无论多么全面，都不会是灵丹妙药。 这很容易决定他们未来的成功或失败。事实上，市场现在更加重视有效的增长和投资回报率，这使得知道他们如何优化他们高价值的工程人才的表现比以往任何时候都更加重要。 请记住，衡量生产力是有背景的。关键是要看整个系统，并了解它如何通过改进系统，团队或个人级别的开发环境来更好地工作。 对更大可见性的需求的另一个关键驱动因素是人工智能工具的快速发展，尤其是大型语言模型，如生成人工智能。这些已经在迅速改变工作方式，这意味着衡量软件开发人员的生产力只是了解这些宝贵资源如何部署的第一步。 无论采用哪种具体方法，衡量生产率都应在理想情况下创建透明度和对关键改进领域的见解。只有这样组织可以构建特定的计划来推动对开发人员生产力和经验的影响-影响将使这些个人和整个公司受益。 但是，随着开发人员的生产力变得越来越重要，公司不应该觉得他们必须进行大规模的，戏剧性的改革 Chandra Gnanasambandamand马丁·哈里森是麦肯锡湾区办公室的高级合伙人Alharith Hussin