工程领导者长期以来一直致力于提升开发者生产力和研发效能但如何衡量甚至如何定义开发者生产力始终是一个难题。过去常见的方法例如衡量开发者的产出或衡量完成任务所需的时间都没有充分考虑开发者日常工作中复杂而多样的活动。因此问题依然存在如果想提升开发者生产力领导者到底应该衡量什么又应该关注什么如今许多致力于提升开发者效率的组织发现一种以开发者为中心、聚焦开发者体验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 对快速创新和寻找市场契合点至关重要。随着组织不断发展开发者体验将通过提升工程效率、产品质量和员工留任率来推动业务增长。尽管全面理解开发者生产力仍然困难重重但衡量并改善开发者体验已经被证明是构建高效工程组织、提升研发效能的有效路径。