衡量开发人员工作效率的好处引发了激烈的争论，这取决于你问的是谁。由于定义和跟踪它有许多不确定，因此更加关注简化开发人员的工作流程可能是更好的选择。当谈到生产力时，关键是企业从概念化想法和定义其细节到规划架构的进展速度。生产力直接转化为进入市场和创新的速度，最终影响到盈亏平衡点。

图源：GORODENKOFF

大多数企业都致力于数字化战略，并寻找提高员工生产力的方法。与此同时，开发人员稀缺，对新软件的需求也很高。Gartner（高德纳，Gartner Group公司成立于1979年，它是第一家信息技术研究和分析的公司。它为有需要的技术用户来提供专门的服务。Gartner已经成为了一家独立的咨询公司，Gartner公司的服务主要是迎合中型公司的需要，它希望使自己的业务覆盖到IT行业的所有领域，从而让自己成为每一位用户的一站式信息技术服务公司。）的高级董事、分析师Keith Mann（基思·曼）说，这激发了人们对理解和衡量开发人员工作效率的兴趣。“组织需要充分利用有限数量的开发人员。”他说，“Gartner（高德纳）的调查和客户调查数据证实，开发人员的生产力仍然是软件工程领导者的首要任务。”

加州Delta Dental（是美国最大的牙科系统，运营着美国最大的两个参与牙医网络。德尔塔牙科为美国50个州、波多黎各和其他地区的7800多万人提供牙科和正畸服务，包括小型企业、政府实体和各种专业组织。）的首席信息官Dominic Titcombe（多米尼克·泰特库姆）补充说，最近关于生成式人工智能的进展激发了新的工作方式，关于应用人工智能加速软件创建也有很多讨论。他说：“在这个领域里，显然有一些巨大的工具，比如GitHub Co-Pilot（微软与OpenAI共同推出了一款AI编程工具，能够基于 GitHub 及其他网站的源代码，可根据上文提示为程序员自动编写下文代码。），开发者可以使用这些工具来提高和提高他们的生产力。”

应付账款自动化软件和支付解决方案提供商AvidXchange（是一家自动化支付解决方案提供商，主要为中小企业提供支付账户管理和按需发票/票据管理解决方案。还推出了基于Web的无纸化应付账款和支付解决方案，通过自动化技术和服务减少中小企业运作成本，提升企业运营效率。）的首席信息官Angelic Gibson（安吉利奇·吉布森）赞同消除开发人员工作流程中的摩擦可以增强敏捷创新。她说：“专注于创新和技术部署有助于查明和消除阻碍技术团队的障碍。”她补充道，虽然衡量软件开发生产对IT数字化至关重要，但它也需要谨慎地推出，以保持健康的团队动态。她说：“互联团队表现出更大的所有权和承诺，从而提高了生产力。”

一、精简以优化生产力

敏捷软件开发对于创新和保持竞争力至关重要。Mann（曼）说，因此，工程领导层应该衡量软件开发人员的工作效率，同时也应该了解如何有效地做到这一点，并警惕陷阱。他说：“如果得当，衡量生产力可以深入了解开发团队如何为用户和客户提供更多价值，这是带来积极业务影响的原因。”

Titcombe（泰特库姆）同样认为，评估软件开发人员的效率是值得的，并指出它如何帮助IT实现其为终端消费者提供优质产品的目标。“任何业务部门都应该寻求提高生产率，并想办法用更少的钱做更多的事情。”他说，“为客户打造体验的一个关键部分是在提供优秀产品的同时，快速、经济地完成。”

然而，如果软件开发团队没有取得成功，那么交付优秀的数字产品可能是一项挑战。Gibson（吉布森）说，IT经常处理大量的功能，阻碍了greenfield development（绿地软件开发是指为全新环境开发系统,需要从头开始开发——没有遗留代码。）。她说：“一旦IT积压，恢复生产所需的时间至关重要。”

开发团队还经常遇到阻碍工作流程顺利进行的瓶颈，Gibson（吉布森）补充说，包括复杂的代码、复杂的体系结构或劣质的自动化和测试不足。她说，由于软件开发过程中的摩擦会降低工作效率，因此，深入了解这些障碍对于避免阻碍团队发展至关重要。

摩擦会减缓创新的速度，从而影响公司的整体收入和利润。Gibson（吉布森）说：“就像Netflix（美国奈飞公司，简称网飞。是一家会员订阅制的流媒体播放平台，总部位于美国加利福尼亚州洛斯盖图。成立于1997年，曾经是一家在线DVD及蓝光租赁提供商，用户可以通过免费快递信封租赁及归还Netflix库存的大量影片实体光盘。）通过无缝技术开发对Blockbuster（百视达，是一家美国家庭影视娱乐供应商，最初只是出租录像，后来发展到了流媒体、随选视讯和影院等行业。）进行创新一样，简化这一过程的公司可以加速市场创新，提高收入和盈利能力。”

然而，并不是所有的高管都相信开发人员的生产力度量可以产生可操作的结果。相反，最重要的可能是这种对精简流程的重视。代码测试平台CTO.ai（是一家于2017年在加拿大温哥华成立的初创企业，主要业务是将开发工具引入Slack频道以提高协作能力，进而简化DevOps实施流程。该平台能够通过Slack命令行共享复杂的工作流，从而将开发团队与运营团队紧密联系起来。借助这种“SlackOps”模式，CTO.ai得以有效促进分布式员工之间的协作能力。以此为基础，现有DevOps工具可以直接插入该平台，最终实现DevOps整体周期的全面自动化。）的首席执行官和创始人Kyle Campbell（凯尔·坎贝尔）说：“专注于开发人员的生产力是一件愚蠢的事情。一个更有经验和具有实践能力的领导者知道，团队的产出与他们必须专注于做好工作的支持水平直接相关。”

因此，他建议通过批判性地思考如何优化开发人员工作流，如CI/CD（Continuous Integration持续集成/Continuous Delivery持续交付，属于DevOps的概念，指将传统开发过程中的代码构建、测试、部署以及基础设施配置等一系列流程的人工干预转变为自动化。使用CI/CD，代码经由开发人员更改后，可进行自动化测试并完成交付和部署。恰当的CI/CD管道可使计算机停机时间最小化，从而更快发布代码。），并根据经验衡量开发人员在这些领域的经验，来增强开发团队的能力。

二、衡量业务成果，而不是代码行

在整个software development lifecycle/SDLC/软件开发生命周期中，从想法生成到生产阶段，都有各种测量点，应该对这些测量点进行监控，以确保流程顺畅。Gibson（吉布森）说：“如果企业不提高这些阶段的效率或商业技术的部署，他们就有落后于竞争对手的风险。”

然而，衡量软件开发人员生产力的愿望本身就面临着障碍。尽管关于如何准确地做到这一点，有很多学派的观点，但技术领导者的普遍观点是避免从微观的个人贡献者层面来衡量贡献。

Titcombe（泰特库姆）说：“计算每天生成的代码行可能会导致错误的生产力测量。”相反，最好检查一下新功能交付的速度。他说：“如果我们能更快地向客户提供工具和体验，就可以更好地衡量开发人员的效率，这将带来更大的整体效益。”

生产力测量的一个重要警告是，有些测量可能会导致误报，或导致工程师与系统博弈。“一旦开发者意识到他们是用某个指标来衡量的，他们就会人为地夸大这个指标。”Titcombe（泰特库姆）说，“更好的指标是企业生产力指标，它关注交付给客户的结果。”

Mann（曼）说，在Gartner（高德纳），他们看到客户对实现某些开发者生产力框架感兴趣。SPACE就是这样一个框架。由GitHub（是一个面向开源及私有软件项目的托管平台，因为只支持Git作为唯一的版本库格式进行托管，故名GitHub。Github拥有1亿以上的开发人员，400万以上组织机构和3.3亿以上资料库。）研究人员提出，SPACE通过基于满意度和幸福感、绩效、活动、沟通和协作以及效率和工作流程的更多定性测量，增强了 DevOps Research and Assessment/DORA/DevOps研究与评估框架。Mann（曼）在使用中看到的另一个框架是DevEx（开发者体验，开发者体验聚焦于开发者的真实体验及其在日常工作中遇到的摩擦点。DevEx 框架将影响开发者体验的因素提炼为三个维度：反馈回路、认知负荷和心流状态。领导者可以在这三个维度中选择指标，以衡量和确定需要关注的领域，最终推动生产力的提高。）。

Mann（曼）指出，这些框架中的属性可以帮助衡量开发人员的生产力，有些比其他的更客观。然而，他鼓励领导在实施这些计划时要有目的。同样，测量活动应该揭示阻碍积极业务结果的障碍，而不是用于将特定的贡献者放在基座上。

“衡量标准的目的不是通过比较他们的指标来确定一个开发人员是更好还是更差。”Mann（曼）说，“相反，其目的是诊断哪些因素可能导致相关开发人员的生产力提高或降低。”例如，他讲述了一个使用SPACE框架的客户是如何发现通信故障的，该故障被成功修复，以减少质量问题和返工。

通过智能生产力监控，这些小的修复可以实现更快的周转，并带来回报。Gibson（吉布森）说：“当谈到生产力时，关键是企业从概念化想法和定义其细节到规划架构的进展速度。生产力直接转化为进入市场和创新的速度，最终影响到盈亏平衡点(bottom line 在财务报表中是“最终赢利或亏损”的意思,引申开是指“最重要的因素最关键的一点”)。”

三、团队合作提高生产力

提高软件开发生产力不一定仅通过指标来鼓励。提高整体生产力的另一个重要因素是开发人员对团队的归属感和承诺。

“团队连接是生产力的基石，”Gibson（吉布森）说，“为了拥有高效的团队，人们需要感觉到彼此之间的联系，并与合作的团队有归属感和凝聚力。”

更好地理解生产力也意味着重新构想整个概念，因为对“生产力”的典型工业定义并不能很好地转移到流体的软件设计和开发过程中。Mann（曼）说，软件不像生产一些机械部件，每个单元的制造过程是相同的。软件更加微妙，不断变化，而且每个组件的最终价值不同，这使传统的生产力测量技术复杂化。

“每一个软件都是独特的，都有独特的价值，”Mann（曼）说，“说‘我们生产的软件数量是上周的两倍，所以产量是上周的一倍’是毫无意义的，因为上周的软件价值可能是现在的一半。”因此，生产力衡量往往是幻想，没有真正切实的好处。他说：“我们需要做的是将生产力理解为我们每单位时间或成本所带来的价值。”

另一个含义是，我们意识到软件并不是孤立创建的——它是一个与每个sprint（敏捷开发领域的 Sprint/冲刺是指一个固定时间段内的开发循环,通常为2至4周。在Sprint中,团队通过计划、执行、回顾和反馈的过程来完成一个可交付的产品增量。）中涉及的许多利益相关者进行的协作过程。“大多数软件是由开发团队而非个人开发的，”Mann（曼）说。因此，领导者应该寻求长期评估团队的生产力——Mann（曼）将生产力描述为“单位时间的价值”——以真正衡量生产力的提高是否有效。

Mann（曼）指出：“如果你能始终如一地评估各个团队的价值，那么你甚至可以比较他们的生产力。”不过，他补充道，这是一个很大的“如果”，因为价值在很大程度上取决于所涉及的业务领域，并且在利益相关者之间差异很大。

当然，价值并不总是容易衡量的，这突出了灵活方法的必要性，特别是在比较团队动态时。因此，与其依赖于特定的通用指标，不如揭示与相关团队相关的趋势。

“比较和理解趋势，并将这些趋势作为提出更深层次问题的基础，这更有意义。”Mann（曼）说，“例如，如果一个团队的生产力呈上升趋势，而类似的团队的生产力没有上升，我们可能会问第一支团队做了什么。”提出这样的问题可以让整个公司共享知识，这将有助于其他团队提高。

在开发人员经验的背景下，需要关注的关键领域具有略有不同的特点。Campbell（坎贝尔）说：“当我们间接地谈论开发结果时，通过来自团队的反馈来评估开发人员经验的关键组件是至关重要的。”他将这些组件分为Clarity/透明度（我如何部署）、Ease of use/易用性（部署的最低步骤是什么）、Functionality/功能性（是否有我可以扩展的现有工作流、API或SDK）和Stability/稳定性（如果我现在部署它，我能确定这不会在半夜中断吗）。

Campbell（坎贝尔）说，通过听取这些领域工程师的反馈，领导层可以“迅速培养出对他们需要支持的领域的同理心，以完成他们的最佳工作。”有了这一点，IT就可以最好地投资于提高生产力并积极影响业务的改进。

四、开发人员和客户体验

技术领导者在衡量开发人员的生产力时应该谨慎，如果他们确实尝试了，结果必须基于对终端消费者的有形价值。

Titcombe（泰特库姆）说：“高管应该确保生产力衡量标准侧重于客户体验和结果，团队在支持新机会出现时保持敏捷。”他补充说：““我们希望优先考虑技术可以帮助我们现在和未来照顾患者的方式。”

领导者还应该记住，精神能量也有局限性，而职业倦怠对知识工作者来说是一种真正的可能性。因此，Gibson（吉布森）表示，在衡量绩效时，关注过程而不是个人是至关重要的，以避免灌输恐惧。她说：“通过强调整个过程的有效性和评估衡量过程本身的效率，重点转移到个人在该框架内的运作情况。”

对于另一些人来说，单独衡量开发人员的生产力可能会转移注意力。相反，Campbell（坎贝尔）鼓励培养一种持续改进和发现策略的文化，以更好地为开发人员的工作流程提供工具，并从中衡量这一工具链，以获得可操作的开发见解。他说：“正如我们衡量我们的软件对试图实现目标的最终用户的影响一样，我们也可以衡量我们的内部工具对我们的目标的影响。”

作者：Bill Doerrfeld（比尔·多菲尔德）

Bill（比尔）是一名专门研究企业云软件领域最先进技术的技术记者。他也是API从业人员知识中心Nordic API的主编，并为DevOps.com、Cloud Native Now（前身为Container Journal）和Acceleration Economy撰稿。