工程领导者长期以来一直致力于提升开发者生产力和研发效能，但如何衡量甚至如何定义开发者生产力，始终是一个难题。过去常见的方法，例如衡量开发者的产出，或衡量完成任务所需的时间，都没有充分考虑开发者日常工作中复杂而多样的活动。因此，问题依然存在：如果想提升开发者生产力，领导者到底应该衡量什么，又应该关注什么？

如今，许多致力于提升开发者效率的组织发现，一种以开发者为中心、聚焦开发者体验（Developer Experience，简称 DevEx）的方法，能够带来有价值的洞察和改进机会。海外某咨询机构报告称，78% 的受访组织已经建立或计划开展正式的 DevEx 项目。因此，越来越多组织开始组建专门的 DevEx 团队和平台团队，以改善内部开发者体验。

开发者体验关注的是开发者在日常工作中的真实体验，以及他们遇到的痛点。除了提升生产力之外，DevEx 还可以通过提升工程效率、产品质量和员工留任率来推动业务增长。海外某咨询机构在 2020 年的一项研究发现，为开发者提供更好工作环境的公司，其收入增长速度是竞争对手的四到五倍。13

本文提出了一个理解开发者体验的实用框架，并给出了一套结合开发者反馈与工程系统数据的衡量方法。这两个框架可以为领导者提供清晰、可操作的洞察，帮助他们判断应该衡量哪些指标、应该关注哪些领域，从而真正提升开发者生产力和研发效能。

DevEx 是什么？

开发者体验涵盖开发者对自身工作的感受、思考和评价。9 在此前的研究中，我们识别出超过 25 个影响开发者体验的社会技术因素。例如，频繁干扰、不切实际的截止日期以及开发工具中的摩擦，都会对开发者体验产生负面影响；而清晰的任务、结构良好的代码以及顺畅的发布流程，则有助于提升开发者体验。

人们常常误以为，开发者表现主要受工具影响。然而，我们的研究表明，项目目标是否清晰、团队是否具备心理安全感等人为因素，也会显著影响开发者表现。9 改善开发者体验不仅能提升生产力，也能提升员工满意度、敬业度和留任率。9

摩擦点会在不同组织层级上影响开发者体验。构建时间过长、基础设施复杂等基础性问题，往往会影响整个组织，因此需要领导层或专门团队介入。相比之下，减少中断、明确工作内容等更局部的问题，则可能需要根据团队或个人的具体情况进行改进。

每位开发者的体验都具有高度的个人性和情境依赖性。开发者所在团队、角色、职责和资历，都会影响他们的真实体验。因此，要深入理解开发者体验，既需要研究具体用户画像，也需要观察组织层面的共性模式。本文后文将给出具体方法。

DevEx 的三个核心维度

我们的框架将开发者体验提炼为三个核心维度：反馈循环、认知负荷和心流状态。这些维度来自我们此前研究中的实际应用，该研究识别了影响开发者体验的 25 个社会技术因素。9 这三个关键维度贯穿这些因素，为理解开发者体验提供了一个实用模型。

反馈循环、认知负荷和心流状态，共同概括了开发者在工作中遇到的主要摩擦类型。尽管开发者体验本身复杂而微妙，但团队和组织可以通过聚焦这三个关键领域，采取有针对性的改进措施。

反馈循环：影响开发效率的关键因素

软件组织通常会通过减少或消除软件交付过程中的延迟来优化价值流。这样做有助于更快获得反馈，更快了解正在构建的内容是否有效，并据此及时调整。研究持续表明，与竞争对手相比，那些部署频率更高、交付周期更短的组织，实现绩效目标的可能性是前者的两倍。3

缩短反馈循环，也就是提高对已执行操作的响应速度和反馈质量，对于提升开发者体验至关重要。开发者日常工作中包含大量依赖工具和人员反馈的任务。例如，开发者可能需要花费大量时间等待代码重新编译或测试运行。之后，他们可能还需要等待代码审查者批准，这会阻碍他们继续推进工作。

快速反馈循环能够帮助开发者更顺畅地完成工作，并最大限度减少阻力。相反，缓慢的反馈循环会打断开发流程，使开发者因等待或频繁切换任务而感到沮丧和延误。当系统反馈，例如集成测试结果，或人员反馈，例如评审意见，延迟返回但又需要立即处理时，缓慢反馈循环还会制造额外中断。

为了提升开发效率，组织应识别哪些开发工具可以加速，例如构建流程、测试流程和开发环境配置；也应识别哪些人为交接流程可以优化。此外，组织还应优化团队结构，促进更精简的团队协作，从而最大限度减少延误。

认知负荷：开发者体验中的隐性成本

软件开发本身就十分复杂，而不断出现的新工具和新技术，进一步加重了开发者的认知负荷。认知负荷指的是开发者完成任务所需的心理处理量。例如，当开发者处理本身就困难或复杂的任务，或需要理解一个陌生的开发框架时，认知负荷通常会增加。外部信息的呈现方式也会影响认知负荷。当开发者需要把信息转化为长期的领域知识和心智模型时，认知负荷同样会增加。

认知负荷会阻碍开发者履行最重要的职责：为客户创造价值。当代码结构混乱、系统文档不完善等问题导致认知负荷居高不下时，开发者就必须投入额外时间和精力来完成任务，并努力避免出错。

为了提升开发者体验，团队和组织应致力于降低认知负荷，尽可能消除开发过程中的不必要障碍。重点应放在创建结构良好的代码和文档上，这既有助于开发者理解他们所使用的系统，也能减少完成项目所需的上下文切换和任务切换次数。专门的 DevEx 团队和平台团队，也应提供易于使用的自助式工具，帮助开发者简化开发和发布步骤。

心流状态：开发者生产力的关键体验

开发者经常谈到“进入心流”或“进入最佳状态”。这些说法通俗地描述了心流状态：人在进行某项活动时完全沉浸其中，感到精力充沛、全神贯注，并从中获得愉悦感。

频繁体验心流状态，有助于提升工作效率、创新能力和员工成长。2 同样，研究表明，享受工作的开发者表现更好，也更有可能产出高质量产品。8 干扰和延迟，也就是与反馈循环相关的问题，是阻碍开发者进入心流状态的重要因素。10 其他影响因素还包括：能否自主安排工作结构、团队和项目目标是否清晰，以及工作任务是否具有挑战性和启发性。12

为了提升开发者体验，团队和组织应努力创造有利于心流状态的工作环境。可以通过集中安排会议、减少计划外工作、批量处理求助请求等方式，最大程度减少干扰。领导者还应认识到，心流状态的形成依赖积极的团队文化。这种文化应赋予开发者足够自主权，并让他们有机会参与具有挑战性的工作。

如何衡量 DevEx？

希望提升开发者生产力的组织，必然会面临一个挑战：如何确定衡量内容和衡量方式。衡量开发者体验，对于发现改进机会、观察趋势变化，以及理解相关投入的影响至关重要。

衡量开发者体验的关键，是关注开发者及其在软件交付过程中的真实体验。这既包括工程系统本身的性能，也包括开发者在使用这些系统、与这些系统交互时的主观感受。协作和文化等社会因素同样重要，也需要纳入考虑。

与开发者生产力一样，开发者体验也无法用单一指标或单一维度来衡量。5 通过多维度识别和衡量开发者体验，团队和组织可以更好地理解个人和团队的工作方式，从而做出更明智的决策。本节将介绍一个用于确定衡量指标的框架，并给出在组织中收集 DevEx 指标的建议。

DevEx 应该衡量什么？

DevEx 的三个维度，为识别潜在衡量领域提供了框架。要准确衡量开发者体验的不同方面，不仅需要捕捉开发者在这些维度上的感知和工作流情况，还需要能够反映整体结果的关键绩效指标，也可以称为“北极星指标”。

一种有效的方法，是将整体 KPI 与三个维度下的感知测量和工作流测量结合起来。接下来两节将进一步说明感知测量与工作流测量的区别，以及跟踪整体 KPI 的重要性。

感知测量与工作流测量

衡量开发者体验，不仅需要来自工程系统和流程的客观数据，也需要收集开发者的主观感知，包括他们的态度、感受和意见。“开发者之声”通过开发者自我报告的感知和体验，直接反映开发者体验的三个维度。而关于系统和流程的客观数据，则可以帮助我们深入理解具体摩擦点，并提出改进方向。

对感知指标和工作流指标进行对比分析是必要的，因为单独使用任何一种指标都无法全面反映情况。例如，即使代码审查的周转时间看起来很短，如果代码审查经常打断开发者的工作节奏，他们仍然会感到不便。反过来，即使开发者对构建流程整体感到满意，构建时间等客观指标也可能显示反馈循环较慢，开发工作流并不够精简。

开发者常常担心领导者滥用或误解指标。衡量开发者感知，可以帮助领导者平衡那些自上而下设计、只从管理视角出发的指标。关注开发者的真实体验，能够确保领导者始终敏锐地理解开发者实际面临的挑战。

关键绩效指标的重要性

如前所述，开发者体验的三个维度，源于我们此前研究中识别的 25 个社会技术因素。在评估这些维度时，组织应衡量多个方面，以确定开发者体验中可以采取行动并加以改进的具体领域。

然而，如果只关注个别因素，组织可能会忽略全局，并把资源投入错误的领域。因此，组织还必须衡量更高层次的 DevEx 关键绩效指标。这些指标应成为 DevEx 计划的指路明灯。设计良好的 KPI 应衡量 DevEx 改进所关联、并试图推动的结果，例如生产力、满意度、参与度和留任率。

KPI 可以帮助组织设定战略重点，并全面了解工作的实际影响。例如，减少团队会议可能会改善开发者深度工作的体验。但会议减少也可能让同事之间的协作变得更困难，从而降低整体满意度这一 KPI。在这个例子中，关注 KPI 可以引导团队采取更平衡的策略：既增加深度工作时间，又不损害整体满意度。

如何衡量开发者体验？

衡量开发者体验，应重点捕捉开发者的主观感知，以及他们在工作所涉及的各种系统和流程中的工作流情况。为此，组织应从人员和系统两个方面收集数据，以全面理解软件交付流程。4

调查问卷尤其重要。它是衡量 DevEx、收集开发者对软件交付流程痛点反馈的关键工具。调查数据通常可以在几周内快速收集。如果设计得当，调查可以提供快速、准确的测量结果，帮助组织建立基准线，并指导后续改进工作。4

为了补充调查数据，组织还应从系统中收集数据。然而，获取端到端的系统数据并不容易，因为这需要集成和标准化来自不同工具、不同团队的数据。11 在系统尚未完全打通的情况下，组织可以通过调查收集关于系统表现的自我报告信息，虽然这种方式在精度和频率上都不如系统数据。

在实践中，团队可以借助 PingCode 这类智能化研发管理工具，将目标、需求、任务、开发、测试、发布和 Wiki 知识沉淀等环节连接起来，并与研发过程中使用的其他工具打通，让工程系统数据在同一上下文中流转。这样做的价值不是为了制造更多指标，而是帮助团队更准确地识别反馈循环、认知负荷和心流状态中的真实摩擦。

鉴于调查在评估过程中的重要性，本节余下部分将为开展 DevEx 调查的组织提供建议。这些建议来自我们与大量组织合作设计和实施 DevEx 调查的经验。

精心设计调查问卷

设计不佳的调查问卷会导致结果不准确、不可靠。至少，调查问卷应基于清晰的结构，并通过访谈进行严格测试，以确保不同受访者对问题的理解一致。6 如有可能，应咨询具备问卷开发经验的专家。

按团队和角色细分结果

组织领导者常犯的一个错误是，只关注公司整体结果，而忽略按团队和角色细分后的数据，例如职位、任期和资历等。如前所述，开发者体验具有很强的情境性，不同团队或角色之间可能存在显著差异。只关注总体结果，可能会掩盖影响组织内部少数但重要群体的问题，例如移动端开发者。

将结果与基准进行比较

对比分析有助于理解数据背景，并推动行动。例如，开发者通常对技术债务持较负面态度，这使得识别问题或评估问题规模变得困难。然而，如果某个团队的得分明显低于同行，或某个组织的得分明显低于行业竞争对手，就说明存在显著改进机会。

结合事务型调查

事务型调查用于收集开发者工作流中特定接触点或交互环节的反馈。例如，平台团队可以在开发者安装命令行界面工具并遇到特定错误时，触发一项简短调查，征求开发者反馈。事务型调查还可以提供更高频、更细粒度的反馈，用来补充周期性调查的数据。

避免调查疲劳

许多组织很难长期维持较高的调查参与率。缺乏后续行动，通常会导致开发者认为反复填写调查问卷没有意义。因此，领导者和团队必须对调查结果进行跟进。对大多数组织来说，每季度或每半年进行一次调查是较合适的频率；但对某些组织而言，更高频的调查也可能带来额外价值。

DevEx 真实案例

以下两个案例充分说明了组织重视 DevEx 如何提升开发者生产力。

海外某全球电商平台：加速开发者成长

作为一家全球电商平台，该公司一直在寻找新的方法，希望将软件交付能力打造为业务竞争优势。

该公司正在实施一项为期多年的“速度提升计划”，旨在提升开发者生产力和开发者体验。改善反馈循环、降低认知负荷，是该公司的重点关注领域。其内部平台团队和 DevEx 团队负责收集问题洞察，并推动改进。

DevEx 团队通过季度调查衡量开发者体验，调查内容涵盖开发者整体满意度、开发便捷性等关键绩效指标。此外，调查还会收集开发者在日常工作各个环节中的感知和工作流数据。这些数据会结合工程系统的实时洞察和焦点小组讨论，用于确定并实施具体改进措施。

基于这些洞察，DevEx 团队主导了多项举措，例如修复组织内工具和文档方面的不足，简化开发和发布过程中的手动步骤和流程，以及优化跨领域团队协作。为了协助落地推广，DevEx 团队与功能团队紧密合作，并定期开展回顾会议、演示和培训。

该公司对 DevEx 的持续投入，不断提升开发者开发效率，并进一步强化软件交付作为竞争优势的地位。过去一年，各项改进措施使开发者的发布频率提高了一倍，部署周期缩短了六倍。

更重要的是，该公司的目标是确保开发者每天都能带着动力投入工作，并拥有创造出色客户成果所需的工具和环境。

海外某制药企业：以极快速度交付突破性成果

自从在极短时间内成功研发出关键疫苗以来，这家海外制药企业一直致力于改善 DevEx，以赋能开发者更快交付突破性成果。

从 2018 年到 2022 年，该公司的工程团队规模增长了近十倍，同时通过开源和云原生技术实现了软件交付能力的现代化。如今，该公司的 DevEx 团队正通过改善开发者体验，寻找更多方法来帮助团队更快交付成果。

尽管身处监管严格的环境，该公司的领导层仍然坚信小型团队的优势，并致力于赋予开发者充分自主权，使他们成为组织中富有创造力的力量。为了实现这一目标，DevEx 团队主要关注开发者体验的两个维度：反馈循环和心流状态。

季度调查会收集关键绩效指标，例如整体满意度和参与度，也会收集更具体的因素，例如代码库质量和团队自主性。DevEx 团队不仅会分析汇总结果，用于制定自身计划，也会为各个团队提供定制化洞察。

该公司通过提供专门的时间和资源，赋能各团队自主开展本地化改进。让团队有机会在自身职责范围内推进改进，使该公司的转型速度远快于单纯自上而下的模式。这种创新方法也使 DevEx 团队能够腾出精力管理企业级项目，例如创建统一的开发者门户、减少跨团队代码重复，以及改进源代码管理工具。

如何开始改善 DevEx？

上述框架为领导者提供了清晰视角，帮助他们理解应该衡量哪些指标，以及应该重点关注哪些方面来提升开发者生产力。DevEx 的三个维度——反馈循环、认知负荷和心流状态——共同构成了理解开发者体验的实用框架，而相应的衡量方法则可以系统地指导改进工作。

即使企业尚未正式设立 DevEx 项目，也尚未计划投入相关团队，也应该尽早开始衡量开发者体验。相关指标可以帮助成长型企业发现趋势、判断最佳投入时机，并应对远程办公、人工智能编程等宏观变化带来的影响。

对于规模较小的组织和初创公司而言，DevEx 对快速创新和寻找市场契合点至关重要。随着组织不断发展，开发者体验将通过提升工程效率、产品质量和员工留任率来推动业务增长。尽管全面理解开发者生产力仍然困难重重，但衡量并改善开发者体验，已经被证明是构建高效工程组织、提升研发效能的有效路径。