2025 年如何衡量 AI 时代的开发者生产力

cover

Lenny's Podcast · 2025-10-19🎬 在 YouTube 观看原视频 →

摘要

Nicole Forsgren 是开发者生产力领域最具影响力的研究者之一——她创造了业界最广泛使用的两个衡量框架 DORA 和 SPACE，撰写了获奖著作《Accelerate》，并即将出版新书《Frictionless》。她目前是微软研究院（Microsoft Research）的合伙人，领导开发者体验实验室，同时协助微软跨公司改善开发者基础设施。在本期对话中，她系统梳理了开发者生产力、开发者体验与 DevOps 三者的关系与差异，深入解读了 DORA 四项关键指标如何揭示"速度与稳定性同行"这一反直觉的核心发现，以及 SPACE 框架如何帮助团队选择平衡的度量维度。

她特别强调，80% 的组织在起步阶段就面临最大障碍——对问题或目标缺乏清晰定义。她分享了精英团队的基准线数据（部署频率按需、变更前置时间小于一天、恢复时间小于一小时、变更失败率 0-15%），并指出小公司与大公司在这些指标上并无统计学显著差异。对话进一步探讨了 AI 对开发者工作方式的根本性改变——从"写代码"转向"审查代码"，认知负荷模型的转变，以及 SPACE 框架可能新增"信任"维度。她还介绍了实用的"四格框架"（Four-Box Framework）用于构建和验证因果假设，以及基于准则加权的决策方法。贯穿整场对话的核心理念是：真正的生产力提升不是蛮力驱动，而是通过好的技术实践、架构能力和文化同时实现速度与稳定性的双提升。

正文

从 IBM 工程师到开发者生产力研究先驱

Nicole Forsgren 的职业生涯始于 IBM 的软件工程师，为企业级大型系统编写软件。因为系统规模巨大，她同时承担了系统管理员的职责——上架服务器、运维超大规模实验室。在经历了数年的"七天行军"后，她意识到一定有更好的方式，而管理层并不买账。于是她决定用数据赢得这场战役，走上了攻读博士的道路。

她进入了亚利桑那大学的管理信息系统（Management Information Systems）项目——一个技术与商业的交叉学科。她选择这个方向的核心动机是：能够将软件交付方式与各层级成果建立强有力的商业论证——个体层面（我是否更高效？工作生活平衡是否更好？）、团队层面（团队是否更高效？）和组织层面（是否看到更好的投资回报率？）。她还拥有会计学硕士学位，这帮助她在财务报表层面建立更扎实的论证。

在学术界做了几年教授后，她放弃了终身教职——因为当时的学术界并不认为 DevOps 是一个真实的存在。与此同时，她与 Jez Humble、Gene Kim 合作，在 Puppet 的支持下持续推进 DORA（DevOps Research and Assessment）项目。随后 Chef 这家配置管理创业公司给了她"半时间做研究、半时间改善工程实践"的机会，这在创业公司中极为罕见。

一年半后，她全身心投入 DORA，推出了 SaaS 产品——因为大量大型企业需要定制化的度量评估与报告。她回忆，Gartner 曾评价他们的"超能力"是"把人骗进了战略"——基准对比只是漏斗顶端，真正重要的是"下一步该做什么"。这给了她深度指导大型组织转型旅程的独特视角。DORA 后来被 Google 收购，她作为 CEO 主导了整个收购与整合过程。此后她加入 GitHub 担任研究与战略副总裁，最终来到微软研究院（MSR），在开发者体验实验室继续从事生产力、社区与幸福感相关研究，同时协助微软跨公司改善开发者基础设施。

核心概念辨析：生产力、体验与 DevOps

Nicole 强调，开发者生产力、开发者体验与 DevOps 三个概念高度相关但并不等同，人们常常将它们混为一谈。

生产力（Productivity） 关注的是团队能在单位时间内完成多少工作。正因为如此，必须采用整体性度量——不能靠蛮力堆砌。这就是为什么研究生产力时必须纳入社区效应（软件是团队运动）和幸福感因素——以正确方式提升生产力时，会看到可持续性、幸福感的提升和倦怠感的降低。

开发者体验（Developer Experience） 与生产力密切相关并贡献于生产力，但关注点不同。如果把开发者视为"用户"，开发者体验问的是：写软件的过程是什么样的？是否无摩擦？是否可预测？能否减少不确定性、增加可预测性？

DevOps 则是一系列能力、工具和流程的总和，用于端到端改善软件开发与交付——使其更快、更可靠。它涵盖技术、架构和文化实践，目的是同时实现更高的生产力和更好的开发者体验。Nicole 特别指出，营销团队把工具链贴上"DevOps"标签只是想赚你的钱——DevOps 不是你买的一个产品。

DORA 框架：速度与稳定性的反直觉同行

DORA 是一个完整的研究项目，但最为人知的是四项软件交付绩效指标——两项目速度指标和两项稳定性指标：

速度指标：
- 变更前置时间（Lead Time for Changes）：从代码提交到代码运行在生产环境中需要多长时间？
- 部署频率（Deployment Frequency）：多久部署一次代码？

稳定性指标：
- 平均恢复时间（MTTR, Mean Time to Restore）：出问题后多长时间能恢复？
- 变更失败率（Change Fail Rate）：每次推送的变更中，需要人工干预的事故占比多少？

DORA 研究最核心也最反直觉的发现是：速度与稳定性在统计上显著同步变化。这意味着当你移动更快时，你同时也更稳定——因为你频繁推送，每次变更体量更小，爆炸半径更小，出错后更容易调试和恢复。反过来，当你推送频率低时，每次变更都是大批次，爆炸半径巨大，出问题时需要从一团乱麻中定位错误根源。

这一发现彻底颠覆了传统 ITIL/ITSM 的常识——后者要求至少两周的变更审批等待期以换取稳定性。而实际上，强制等待只会导致变更批量堆积，引发更多合并冲突和更难以排查的问题。

精英团队的基准线

Nicole 分享了 2019 年的基准数据（后续报告在 dora.dev 持续更新，但数值保持相对稳定）：

指标	精英表现
部署频率	按需部署
变更前置时间	不到一天
恢复时间	不到一小时
变更失败率	0–15%

她特别强调，精度在此并不重要——如果变更前置时间不到一天，是四小时还是四小时零两分钟从业务角度看并无差别，大致类别即可。次一级（高水平表现）的变更前置时间为一天到一周，再往下依次是一周到一个月、一个月到六个月。

大公司 vs 小公司：没有显著差异

一个常被问及的问题是这些基准线是否因公司规模而异。DORA 数据给出了明确回答：小公司与大型公司在四项指标上没有统计学显著差异。大公司说"这不公平，我们的代码库更复杂"；小公司说"这不公平，大公司有更多资源"——Nicole 打趣道，"选你的借口吧，下拉菜单都有。"

唯一有统计显著差异的行业是零售业——但他们的差异是表现更好。Nicole 推测这是因为零售业经历了"零售末日"的自然选择：不能在黑色星期五保持系统高性能、没有完成云端转型的企业已被淘汰出局。

DORA 不仅是四项指标

许多人对 DORA 的批评是"你只让我觉得自己很差，却不告诉我怎么改善"。对此 Nicole 指出，DORA 是一个完整的研究项目，四项指标只是冰山一角。《Accelerate》一书详细阐述了支撑速度与稳定性的一系列能力：

技术能力：自动化测试、持续集成/持续部署（CI/CD）、基于主干的开发（Trunk-Based Development）、版本控制系统
架构能力：松耦合架构、正确使用云（很多人"做了云但没做对"）
文化能力：Westrum 组织文化模型中的生成式文化
精益管理实践

逻辑链条是：如果你想要商业成果（收入），就需要快速稳定地交付功能；要实现快速稳定交付，就需要落实上述能力。在 dora.dev 的"Quick Check"工具中，你可以输入自己大致所处的水平，它会告诉你当前的行业基准定位，并根据你的绩效档案和行业统计推断你最可能的瓶颈所在——比如金融业的高绩效团队通常在某些特定领域挣扎。该工具不收集姓名和个人信息，没有任何营销引导。

SPACE 框架：选择正确度量的方法论

如果说 DORA 告诉你"在哪里"，SPACE 则告诉你"怎么量"。SPACE 是为衡量复杂创造性工作（Complex Creative Work）而设计的框架，其名称代表五个维度：

S——满意度与幸福感（Satisfaction and Wellbeing）：看似"软性"指标，实际上与所有其他生产力维度高度相关。一旦满意度开始下滑，其他方面会连锁崩溃。这是一个极强的信号。
P——绩效（Performance）：流程的结果指标。DORA 中的恢复时间或变更失败率就属于此类。
A——活动（Activity）：任何可计数的项目——拉取请求数、提交数等。这些最容易从系统自动采集，但也最容易让人误入歧途（比如仅用代码行数衡量产出）。
C——沟通与协作（Communication and Collaboration）：人与人如何协作、系统之间如何交互、代码库的可搜索性等。
E——效率与流（Efficiency and Flow）：工作通过系统的流动速度。在 SRE 或事件管理语境下，可以是一个工单经过多少次流转才能到达对的人。

正确使用 SPACE 的关键原则是：至少同时选择三个维度进行度量，以此强制完成"我还能选什么"的思考练习，确保度量维度之间的平衡与对齐。你不需要五个维度全部覆盖——这不是黑心宾果游戏——但至少三个来自不同维度。

事实上，DORA 本身就是 SPACE 的一种实现——主要针对"外循环"（Outer Loop）的度量。

拉取请求的案例：为什么平衡至关重要

Nicole 分享了一个实例。一个团队想要"改善拉取请求"，初步想法是每 15 分钟提醒一次审查者。Nicole 立即意识到这会很糟——护理学文献中已有充分证据表明警报疲劳（Alert Fatigue）会导致人们关闭通知或对警报充耳不闻。

用 SPACE 重新审视：如果只用"活动"维度（提醒次数），会导致流被打断；引入"效率与流"维度，需要保护专注编码时间与代码审查时间之间的平衡；再加入"满意度"维度——你对审查流程和审查者分配是否满意？三个维度形成了一套平衡的度量体系。

主观数据与客观数据的互补

度量满意度最直接的方式是问——定期（每几个月一次）面向工程团队的调查。很多人质疑调查数据的可靠性，认为"人会撒谎"。Nicole 对此有两点回应：第一，人们有什么动机在抱怨系统难用这件事上撒谎？除非工作环境充满敌意，那时你有更大的问题。第二，系统数据同样会"撒谎"——缺失数据、不完整数据到处都是，我们找到了应对方式。

她与 Mik Kersten 合著的论文深入探讨了人源数据与系统数据的互补性。一个经典例子：变更前置时间从系统数据看可能很快，但人们会告诉你那靠的是"英雄主义"式的加班和荒谬的鲁布·戈德堡机械——系统永远不会告诉你这些。她曾与一家公司合作，发现大量关键代码根本没有进入版本控制系统——你永远无法从系统数据中发现这一点，因为那些数据根本不在系统里。

即使是拥有最先进遥测与仪表化的顶级团队，也至少每年做一次开发者调查，因为人的洞察能提供系统永远无法提供的视角。

最常见的陷阱：目标不清晰与单向推进

Nicole 指出，企业在推行开发者体验和生产力度量时最容易掉入两个陷阱：

第一，目标定义不清晰。 这是 80% 的组织面临的最大问题。即便在高管层面，团队可能花了几个月推进某项工作，回来后充满不确定性："你让我改善开发者体验，但我不知道你指的是内循环与外循环、摩擦、还是文化——这些是完全不同的方向。"如果上下不在同一页，团队就会朝不同方向狂奔。

第二，缺乏自上而下与自下而上的双轨推进。 仅靠一方驱动都不够——需要让一线工程师理解这是为他们而做，了解他们使用的词汇和术语；同时需要与领导者对话，理解他们的动机或帮助他们看到可能的动机。很多 DevX 的积极推动者面临的核心挑战是："我的工程师正在倦怠，我如何向高管证明这很重要？"——需要将开发者体验翻译成领导者关心的价值语言。

行业变迁与 AI 时代的新挑战

Nicole 回顾了她从事这一领域以来观察到的几大变化：

系统复杂度的量级跃升：10 到 15 年前互联网虽已存在，但与今天相比不可同日而语。如今几乎每家公司都拥有高度复杂的大型系统。
开发者短缺：至少是被感知到的短缺。
技术驱动成为共识：几年前她遇到的一家金融机构的 CTO 还坚称"我们不是科技公司"——今天这种情况已经极为罕见。
AI 时代的到来：在过去 6 到 12 个月中，AI 像往火上浇油一样加剧了所有压力。竞争不再只是关于你构建什么，而是关于创造绝对新颖的体验并以前所未有的速度交付——唯一的方式就是拥有既快又安全、稳定、可靠的软件交付管道。

AI 如何改变开发者的工作方式

Nicole 认为这是一个极其有趣的开放性问题，目前看到的变化包括：

工作重心从"写"转向"审"：使用 GitHub Copilot 等 AI 工具后，开发者花在审查代码上的时间大幅增加。微软研究院的一项研究使用了 CUPS 模型，发现约 50% 的时间从编写转移到了审查。这是工作性质的根本转变。

认知负荷模型的变化：当你接受 AI 生成的文本然后审查它时，心理模型和摩擦预期都发生了变化。

信任与过度依赖的问题：AI 工具的引入带来了对输出可靠性的依赖，以及过度依赖的风险。

学习曲线的分化：对已有计算思维（Computational Thinking）基础的人，AI 可能加速学习新代码库或新语言；但对刚学编程语言的人，情况可能完全不同。

SPACE 框架可能需要新增维度：Nicole 推测，SPACE 的五个维度仍会保留，但可能需要增加一个类似"信任"或"可靠性"的维度——"我能依赖它吗？我会过度依赖它吗？"

她特别警告了对 AI 生产力影响的过度简化：有研究表明用 AI 构建一个 HTTP 服务器可以快 50%，但如果据此认为"可以裁掉一半工程师"，那就完全误解了生产力的本质。AI 工具释放的不是让你做同样事情更快的时间，而是释放认知空间让你去做更难的事情。衡量 AI 时代的生产力需要更全面、更平衡的框架，否则极易"见树不见林"。

新书《Frictionless》：从零开始的度量之旅

Nicole 正在撰写一本新书，系统回答她被频繁问到的度量实践问题。核心章节涵盖：

定义问题和目标：看似显而易见，实际是最大痛点。80% 的合作方在此处卡壳——团队之间对"改善开发者体验"的理解可能南辕北辙。

从零开始的度量：如何在没有任何既有数据的情况下起步。

度量旅程（Measurement Journey）：主观数据（人源数据——访谈、调查）与客观数据（系统数据）之间的比例如何随成熟度变化。初期更多依赖人源数据——获取快、成本低；随着成熟度提升，系统数据的比重增加——可扩展、可工程化。核心原则是"不要让完美成为好的敌人"。

丰富的实操模板：包括访谈脚本范例、人员筛选方法、调查脚本范例、分析方法指引——目标是让任何人都能上手，不需要是数据科学家；但如果你有数据科学家，可以直接把模板交给他们执行。

四格框架：从假设到验证的结构化方法

这是 Nicole 从教授时期至今一直在用的实用工具——她至今仍会在酒吧、会议的餐巾纸上画给人们看。

基本模式：

在纸上画四个方格，上排两个、下排两个，两两对齐。
上排左侧标注"词语"（Words），下方对应标注"数据"（Data）。
在上排两个方格之间画箭头。

使用步骤：

从词语开始，不要从数据开始。 明确你想验证的因果假设。例如："客户满意度 → 回头客"。
将"客户满意度"填入上排左格，"回头客"填入上排右格。
拿着这个因果陈述去找利益相关者确认："你同意这个假设吗？"在达成共识之前，不碰数据。
在下排方格中填入对应的度量方式。客户满意度可度量方式：CSAT 问卷、NPS 评分；回头客可度量方式：网站重复访问、推荐链接、后续调查。

关键优势： 当数据分析结果不理想时，可以精准定位问题——是数据格中的代理指标选错了？数据质量差？还是上方词语格中的因果假设本身不成立？而不是去指责提出假设的人。这让讨论变得客观而富有建设性。

进阶模式： 如果手头已有大量数据但缺乏假设，可以从数据端反向推导——先列出可用数据及其可能的关系，然后回到词语层：这些数据代表什么？能否构成一个可沟通的陈述？务必找人验证，避免虚假相关（Spurious Correlation）。Nicole 提到她最爱的网站之一就是专门收集荒谬相关性的图表集。

在 DORA 框架内，四格框架同样适用：如果要提升速度与稳定性，假设改善构建时间有帮助，那么如何度量构建时间？——这就是下排数据格要回答的问题。

决策框架：准则加权法

Nicole 分享了她的决策方法论——她甚至有一个自己使用的决策电子表格，已分享给多位朋友和被指导者。

步骤：

列出所有选项：比如三个工作机会、三个居住城市。
识别评估准则：对工作而言，可能是总薪酬、现金收入、声望、团队、工作可预测性、工作生活平衡等。
为准则赋权：各准则的相对重要性，加总为 100%。
打分并计算：每个选项在各准则上打分，乘以权重后加总。

她坦言，很多时候只走到第二步，被指导者就自己知道答案了——仅仅是识别"什么对我重要"这个过程本身就足以澄清决策。

最终的数据结果提供的是一个类别或方向，而非精确指令。Nicole 将自己定位为"数据告知（Data-Informed）"而非"数据驱动（Data-Driven）"——有时算出来的结果不对，你会发现自己调整权重来迎合真实偏好，那恰恰说明你内心已有答案。

她引用了一句关于战略的名言："好战略的关键是知道不做什么，执行好战略的关键是真的不去做。" 作为领导者，你面对众多选项但只资助其中一部分——什么都资助必然失败。识别准则、排序准则、确定截止线，才是战略的本质。

Google：系统化度量的典范

当被问及有哪些公司做得特别好时，Nicole 提到了 Google。虽然很多人会说"我们不是 Google"，但她欣赏的是 Google 的系统化方法论：令人惊叹的遥测与仪表化、持续投入的开发者体验调查、以及两者的三角验证（Triangulation）。

她特别指出一个耐人寻味的现象：当调查数据与仪表数据出现矛盾时，几乎每一次都是调查数据正确而非仪表数据。 这再次印证了人源数据的不可替代性。

可立即采取的行动

Nicole 为听众提供了两步即刻行动指南：

检查定义：你团队的目标和问题是否已写下来？是否足够清晰？所有人是否在同一页上？
寻找信号：是否存在与问题相关的任何数据？数据可以是非常宽泛的定义——任何信号都算数。去找几名开发者，问他们对工作工具和工作流程的感受，以及生产力的最大障碍是什么。

这两步可以在一周甚至一天内完成——取决于组织内部信息散乱的程度。

闪电问答

最常推荐的书籍： 《Good Strategy Bad Strategy》（Richard Rumelt）——战略思考的必读；《Designing Your Life》（Bill Burnett & Dave Evans）——人生设计；以及《Ender's Game》（Orson Scott Card）——纯粹好读的科幻小说。

最近喜欢的影视： 重温《Suits》，《Ted Lasso》是心头好，刚刷完《Never Have I Ever》——John McEnroe 旁白非常搞笑。

最爱的面试问题： 围绕候选人做过的艰难决定展开——想听到他们有某种决策过程、有评估准则，而不是完全凭直觉行事。

最近发现的好产品： Eight Sleep（让床变凉还提供数据）和韩国面膜（推荐 COSRX，十片约 15 美元，日常自我护理的好方式）。

小幅改变带来大影响的实践： 在任何工作产出前先问两个问题——"我们的受众是谁？"和"我们将如何分享？"在微软研究院做前瞻研究时，核心挑战是"如何把远方拉近（Bring the Far Near）"；在改善开发者基础设施时，挑战反过来是"如何把近处推远（Bring the Near Far）"——让近期的战术行动与长期愿景对齐。

一句话行动建议： 今天就去找几名开发者，问他们：你对工作工具和工作流程感受如何？你生产力的最大障碍是什么？