大多数公司都致力于数字战略，并在寻找提高员工生产率的方法，与此同时，开发人员稀缺，对新软件的需求很高。Gartner的高级总监兼分析师Keith Mann表示，这激发了人们对理解和衡量开发人员生产率的兴趣。“公司需要最大限度地利用有限数量的开发人员，”他说，“Gartner的调查和来自客户询问的数据证实，开发人员的生产率仍然是软件工程领导者的首要任务。”
加利福尼亚州Delta Dental的CIO Dominic Titcombe补充说，最近围绕GenAI的进展启发了新的工作方式，关于应用AI来加速软件创建的讨论很多。他说：“在这个领域，显然有像GitHub Co-Pilot这样的巨大工具，开发人员可以使用它们来增强和提高他们的生产力。”
应付账款自动化软件和支付解决方案提供商AvidXchange的CIO Dominic Titcombe同意，消除开发者工作流程中的摩擦可以增强敏捷创新。她说：“专注于创新和技术部署有助于准确定位和消除阻碍技术团队的障碍。”她补充说，“虽然衡量软件开发产量对于IT数字化至关重要，但它也需要谨慎推出，以保持健康的团队活力。互联团队展现出更大的主人翁精神和责任感，从而提高了生产力。”她说。
精简以优化工作效率
敏捷软件开发对于创新和保持竞争力至关重要，因此，Mann说，工程领导应该衡量软件开发人员的生产率，但也应该了解如何有效地做到这一点，并警惕陷阱。他说：“如果操作得当，通过测量生产率，可以深入了解开发团队如何为用户和客户提供更多价值，这就是产生积极业务影响的原因。”
Titcombe同样认为，评估软件开发人员的效率是值得的，并指出它如何帮助IT实现为最终消费者提供优质产品的目标。他表示：“任何业务部门都有责任寻求提高生产率，并找到用更少的资源做更多事情的方法。为我们的客户打造体验的一个关键部分是，在提供出色产品的同时，快速且具有成本效益地完成这项工作。“
然而，如果软件开发团队不是为成功而建立的，那么交付伟大的数字产品可能是具有挑战性的。Gibson说，IT经常要处理大量积压的功能，这阻碍了新领域的发展。她说：“一旦它积压下来，让它重新投入生产所需的时间就至关重要。”
Gibson补充说，开发团队还经常遇到阻碍工作流顺利进行的瓶颈，包括复杂的代码、复杂的架构或自动化和测试不足。由于软件开发过程中的摩擦会降低生产率，她说，了解这些障碍对于避免阻碍团队的因素是非常必要的。
摩擦会减缓创新的速度，这可能会影响公司的整体收入和利润。Gibson表示：“就像Netflix凭借无缝技术开发对抗百视达一样，简化这一流程的公司可以加快市场创新，提高收入和盈利能力。”
然而，并不是所有的管理人员都相信开发人员生产率测量可以产生可操作的结果，相反，最重要的可能是这种对精简流程的强调。代码测试平台CTO.ai的CEO兼创始人Kyle Campbell说：“关注开发人员的工作效率是徒劳的。一个更有经验、更亲力亲为的领导者知道，一个团队的产出与他们必须专注于做好自己的工作所获得的支持程度直接相关。”
因此，他建议通过批判性地思考如何优化他们的开发人员工作流(如CI/CD)，并对这些领域的开发人员体验进行经验测量，来增强开发团队的能力。
衡量业务结果，而不是代码行
在整个软件开发生命周期(SDLC)中，从创意产生到生产阶段都有各种度量点，应该对其进行监控，以确保流程顺畅。“如果企业不提高这些阶段的效率或部署商业技术，他们就有可能落后于竞争对手。” Gibson说。
然而，衡量软件开发人员生产率的愿望本身就面临着障碍。尽管关于如何准确地完成这项工作有许多学派，但科技领导者的普遍看法是，避免在微观的个人贡献者层面上衡量贡献。
“计算每个开发人员每天生成的代码行数可能会导致错误的生产率测量，”Titcombe说，相反，检查新功能交付的速度是很好的。他说：“衡量开发人员效率的一个整体更好的衡量标准是，我们是否能更快地将工具和体验送到客户手中，这将带来整体更大的好处。”
对一些生产率衡量标准的一大警告是，其中一些指标可能会导致误报，或导致工程师玩弄系统。“一旦开发人员意识到他们是按照某个指标来衡量的，他们就会人为地夸大这个指标，” Titcombe说，“一个更好的指标是关注交付给客户的结果的企业生产率指标。”
Mann说，在Gartner，他们看到客户对实现某些开发人员生产力框架感兴趣，SPACE就是这样一个框架。SPACE由GitHub研究人员提出，它为DevOps研究和评估(DORA)框架提供了更多基于满意度和幸福感、绩效、活动、沟通和协作以及效率和工作流程的定性衡量标准。Mann看到的另一个正在使用的框架是Devex。
Mann指出，这些框架中的属性可以帮助衡量开发人员的生产率，其中一些比其他更客观，然而，他鼓励领导层在实施这些措施时，要有目的地实施这些措施。理想情况下，衡量活动应该揭示阻碍积极业务成果的障碍，而不是被用来崇拜特定的贡献者。
Mann说：“衡量的目的不是通过比较开发人员的指标来确定他们是更好还是更差。”相反，其目的是诊断哪些因素可能会导致相关开发人员的工作效率提高或降低，例如，他讲述了一位使用空间框架的客户如何揭示了通信故障，并成功修复了该故障，以减少质量问题和返工。
这些通过智能生产力监测暴露出来的小错误，可以让企业更快地扭亏为盈，带来红利。Gibson说：“说到生产率，关键在于企业从构思一个创意、定义其细节到规划架构的速度有多快。生产率直接转化为市场进入和创新的速度，最终影响利润。”
团队合作可提高工作效率
提高软件开发生产率并不一定要仅通过度量来鼓励，对整体生产力有重要贡献的另一个因素是开发人员对其团队的主人翁意识和承诺。
Gibson说：“团队连通性是生产力的基石。”她说：“为了拥有高效率的团队，人们需要有连通感，并对他们所在的团队有归属感和凝聚力。”
更好地把握生产率也可能意味着对这一概念的整体重新想象，因为典型的行业定义是什么是“多产”的根本不能很好地转移到流畅的软件设计和开发过程中。Mann说，软件不像是生产机械部件，每个部件的制造流程都是一样的，软件更加细致入微且不断变化，不同组件的终值也不同，这使得传统的生产力测量技术变得复杂。
“每个软件都是独一无二的，都有独一无二的价值，” Mann说，“说‘我们生产的软件数量是上周的两倍，所以我们的生产率是上周的两倍’是没有意义的，因为本周的软件价值可能只有上周的一半。”因此，生产率衡量往往可能是一种错觉，没有真正的有形利益。“我们需要做的是理解生产率，即我们每单位时间或成本所带来的价值。”他说。
另一个含义是意识到软件不是孤立地创建的——它是一个与每个Sprint中涉及的许多利益相关者合作的过程。“大多数软件都是由开发人员团队生产的，而不是个人开发人员，”Mann说，因此，领导者应该设法评估团队的生产率——Mann将生产率描述为“单位时间的价值”——以真正衡量生产率提高是否有效。
“如果你能在各个团队中一致地评估价值，那么你甚至可以比较他们的生产率，” Mann指出。不过，他补充说，这是一个很大的假设，因为价值在很大程度上取决于所涉及的业务领域，而且不同利益相关者之间的差异很大。
当然，价值并不总是容易衡量的，这突显了灵活方法的必要性，特别是在比较团队动态时，因此，与其依赖特定的通用指标，不如揭示与相关团队相关的趋势可能更有利。
“比较和理解趋势，并将其作为更深层次问题的基础，更有意义，” Mann说，例如，如果一个团队的生产率呈上升趋势，而类似团队的生产率没有上升，我们可能会问第一个团队的表现有什么不同，问这样的问题可能会让知识暴露在整个公司范围内，这将有助于其他团队的改进。
在开发人员体验的背景下，重点关注的领域呈现出略有不同的特点。Campbell说：“当我们从轶事中谈论开发产出时，评估开发人员经验的关键组成部分以及团队的反馈是至关重要的。”他将这些组件分为清晰度(如何部署)、易用性(部署的最小步骤)、功能(是否有我可以扩展的现有工作流、API或SDK)和稳定性(如果我现在部署它，我可以确保这不会在半夜中断)。
Campbell说，通过听取这些领域的工程师的反馈，领导力可以迅速培养出对哪些领域需要支持才能做得最好的同理心，有了这一点，IT可以最好地投资于提高工作效率并对业务产生积极影响的改进。
开发人员和客户体验
技术领导者应该谨慎地衡量开发人员的生产率，如果他们真的尝试这样做，结果必须基于对最终消费者的有形价值。
Titcombe说：“高管们应该确保衡量生产率的标准关注客户体验和结果，同时确保团队在新机会出现时保持敏捷。”他补充说：“我们希望优先考虑技术可以帮助我们现在和未来照顾病人的方式。”
领导者还应该记住，精神能量是有限的，对于知识型员工来说，精疲力竭是一种真实的可能性。因此，Gibson说，在衡量绩效时，关注过程而不是个人是至关重要的，以避免灌输恐惧。“通过强调整个过程的有效性和评估测量过程本身的效率，重点转移到个人在该框架内的运作情况。”她说。
对于其他人来说，单是衡量开发人员的生产率就可能是转移视线。相反，Campbell鼓励培养一种持续改进的文化，并发现策略以更好地规范开发人员工作流，并从那里度量这个工具链以获得可操作的开发洞察力。“就像我们衡量我们的软件对试图实现目标的终端用户的影响一样，我们也可以衡量我们的内部工具对我们的目标的影响。”他说。
