How to measure and improve developer productivity

嘉宾：Nicole Forsgren ｜微软研究院合作伙伴、开发者生产力研究领域顶级专家｜领域：AI 产品与开发者体验

背景与引子

每一个技术负责人都在问同一个问题：我的工程团队是否足够高效？

这听起来是个简单的问题。但如果你深入追问“什么是开发者生产力”“我们为什么要提升它”“具体要提升什么”，就会发现——这可能是技术管理领域最容易被误解、也最难回答的问题之一。

80%的企业和团队在启动“提升开发者体验”这个项目时，出发前甚至没有弄清楚终点在哪里。他们会把文化问题和工具链摩擦混为一谈，把性能优化和流程改进混在一起讨论。结果呢？团队花了几周甚至几个月，做了大量工作，最后却发现做的东西根本不是领导想要的。

这不是危言耸听。这是Nicole Forslein在过去二十年中反复看到的现实。

在AI浪潮席卷整个软件行业的今天，这个问题的紧迫性被放大了十倍。“我们不需要那么多工程师了”“AI编程工具让每个人都变成10倍工程师”……这些论调此起彼伏。但真正的问题不是“AI能不能帮你更快写代码”，而是：你的团队是否真的在高效运作？瓶颈到底在哪里？你测量它的方式是否正确？

本期播客邀请到了开发者生产力领域最具权威的研究者之一——Nicole Forslein。她是《Accelerate》一书的作者、DORA框架和SPACE框架的联合创始人，曾任GitHub研发与战略VP，现为微软研究院合作伙伴，领导开发者体验实验室。过去的二十年里，她与全球最顶尖的科技公司深度合作，帮助它们真正理解并系统性改进工程团队的效能。

这是一场关于“如何科学地衡量并提升开发者生产力”的深度对话。读完这篇文章，你会得到一套完整的框架、一组经过验证的基准数据，以及若干立刻可以落地的行动建议。

嘉宾是谁

Nicole Forslein的职业生涯本身就是一部“开发者生产力的进化史”。

她的起点是IBM的的软件工程师，负责大型企业系统的开发与运维。这段经历让她亲身体验了什么叫做“明明知道有更好的方法，但管理层不买账”。带着这个困惑，她去读了PhD——管理信息系统方向，既懂技术又懂商业的那种。她想要用数据证明：改进软件交付方式，不仅能提升效率，还能带来真实的商业回报。

博士毕业后，她成为学者，同时深度参与DORA（DevOps Research and Assessment）项目，与Jez Humble、Gene Kim等业界先驱合作，启动了后来影响整个行业的《State of DevOps Report》。2016年，她与DORA团队创办了SaaS公司，专注于帮助企业测量和改进软件交付能力。2018年，公司被Google收购，她主导了整合工作。

此后，她加入GitHub担任研发与战略VP，后转任微软研究院，创立开发者体验实验室（Developer Experience Lab）。她的研究横跨生产力、Community和健康三个维度，同时参与微软内部跨公司的开发者基础设施改进项目。

她的代表作《Accelerate》被翻译成十几种语言， SPACE框架成为学术界和工业界测量复杂创造性工作的标准工具。如果你曾经听说过“DORA四指标”或“SPACE五维度”，这些概念都出自她的手笔。

她告诉Lenny，她正在写一本新书，专门回答“如何从零开始测量并改进开发者生产力”这个看似简单、实则极其复杂的问题。预计一年后问世。

核心观点 TOP10

提升开发者生产力的第一步，是极其清晰地定义你要解决的问题——是文化问题？工具链摩擦？还是内环与外环的效率差异？定义不清，所有努力都指向错误的方向。
DORA四指标（部署频率、变更前置时间、变更失败率、平均恢复时间）是衡量软件交付能力的最佳起点，但这四者只是冰山一角——背后是完整的研发能力体系。
速度和稳定性不是对立关系，而是协同关系。当你更频繁地部署小变更时，系统反而更稳定，因为变更的“爆炸半径”更小，出问题时更容易定位和修复。
大量企业存在“过度等待”的反模式：为了追求稳定而强制引入变更审批等待期，结果是变更批量越来越大、风险越来越高、工程师的上下文丢失越来越严重。
SPACE框架提供了测量任何复杂创造性工作的完整思路：满意度与健康（S）、成效（P）、活动（A）、协作与沟通（C）、效率与流程（E）。使用至少三个维度，才能保证指标的平衡性。
来自人的数据（访谈、调研）和来自系统的数据（埋点、日志）是互补的，不是替代关系。很多系统数据永远捕捉不到的问题——比如“完成这件事需要英雄式的个人牺牲”——只有通过人的反馈才能发现。
AI编程工具（如GitHub Copilot）改变了工程师的时间分配：写代码的时间减少，审阅代码的时间增加。生产力测量需要重新思考“什么是活动”“什么是成效”。
精益的测量比完美的测量更重要。不要等系统完全成熟才开始行动——先收集定性数据，快速验证假设，再逐步引入定量指标。
基准数据的作用不是让你焦虑，而是帮助你定位差距并制定改进策略。知道自己在哪里，比知道“ Elite公司是什么样”更重要。
改进开发者生产力的核心杠杆是技术能力、架构能力、文化能力和精益管理实践的综合提升，而不是购买某个“DevOps工具”。

关键洞察

洞察一：移动更快反而更安全

大多数管理者本能地认为“提速”会牺牲“稳定性”。但DORA研究给出了完全相反的结论：部署频率与变更失败率呈强负相关——部署越频繁，每次变更越小，系统越稳定。这是因为小变更的“爆炸半径”有限，出问题时可以快速定位和回滚。相反，半年才部署一次的企业，每次变更涉及数百个文件改动，一旦出问题，恢复时间可能是几周而非几小时。

这意味着“追求稳定”的传统ITIL变更管理流程，实际上是在制造不稳定。强制等待两周审批，不仅没有降低风险，反而让风险积累到了爆发点。

洞察二：规模大小不影响“应该是怎样的”

很多大型企业的管理者会说：“我们规模大、系统复杂，不能和小公司比。”小公司的工程师会说：“他们有钱有资源，我们没法比。”

Nicole的研究团队发现：在软件交付能力上，小型和大型企业之间没有统计学上的显著差异。唯一的例外是零售行业——它们的表现反而更好。原因是“零售大灭绝”式的市场竞争自然淘汰了效率低下的企业，活下来的都是精英。

这个发现打破了一个常见的借口。无论你的企业是5人还是5万人，DevOps的原理和基准是通用的。

洞察三：调研数据往往比系统数据更准确

Google拥有业界最完善的工程遥测和监控体系。当他们的工程遥测数据与开发者调研数据出现矛盾时，几乎每一次，都是调研反映的真实情况更准确。

这是因为系统只能记录它能捕捉到的行为，而人的主观体验包含了大量系统看不到的信息：某段代码提交花了多少“暗时间”？修复一个问题需要跨越多少部门壁垒？系统不知道，但工程师知道。

洞察四：AI不会替代工程师，但会重新定义“做什么”

AI编程工具显著提升了代码生成效率，但Nicole提醒我们：这不是“任务时间减半，所以可以裁员一半”那么简单。

AI改变的是工程师的工作结构：写代码的时间减少，审阅代码的时间增加。工程师从“代码执行者”更多地转向“代码判断者”。这带来了新的测量挑战：如何衡量“审阅质量”而非“代码行数”？如何衡量工程师的“AI依赖度”是否在合理范围内？如何确保过度依赖AI不会削弱团队的技术判断力？

洞察五：测量旅程本身就是战略资产

很多团队以为测量是改进之后的“验证环节”。Nicole的观点恰恰相反：测量本身就是改进的一部分。

当你强迫自己把目标写成清晰可验证的语句（“客户满意度会导致复购率提升”），当你被迫思考每个概念的操作化定义（“如何测量客户满意度——NPS？CSAT？复购金额？”），当你发现数据无法支撑你的假设而被迫重新审视逻辑链条——这个过程本身就在塑造更清晰的战略思考。

精彩金句

“如果你在谈论文化，这和谈论工具链摩擦是完全不同的事情。如果你们不在同一页纸上，你们就是在朝完全不同的方向前进。”

解读：改进开发者生产力最常见的失败原因不是执行，而是定义。出发前，先让所有人对齐“我们到底在解决什么问题”。

“部署越频繁，每次变更越小，系统越稳定。部署越少，变更批量越大，风险越高。这听起来违反直觉，但数据不会说谎。”

解读：DORA研究最反直觉的发现，也是对传统“稳定优先”思维的颠覆性挑战。

“系统数据告诉你’what’，人的数据告诉你’why’。两者缺一不可。”

解读：很多工程团队沉迷于Dashboard和埋点，却忽略了定期与开发者面对面交流的价值。数据是冰冷的，人是活的。

“当你的调研数据和系统数据不一致时——几乎每一次，调研是对的。”

解读：这句话来自Google内部无数次验证。它的含义是：不要迷信系统数据，尤其不要用它来反驳工程师的真实感受。

“让工程师每天能有一个小时不被打断、专注写代码的时间——这可能是你今天能做的最有价值的改进。”

解读：上下文切换是开发者生产力的最大杀手之一。保护深度工作时间是成本最低、回报最高的干预手段。

实战案例

案例一：某金融机构的“代码失控”事件

Nicole曾与一家大型金融机构合作。表面上，他们的部署频率指标显示一切正常。但当团队开始进行开发者调研时，发现了一个致命问题：很大一部分关键代码根本没有进入版本控制系统。

工程师们为了绕过复杂的审批流程，直接在生产环境修改代码——这不是系统能捕捉到的行为，因为它根本没走CI/CD管道。

这是一个典型的“系统数据盲区”案例。如果只依赖遥测数据，这家机构的“真实”软件交付能力被完全掩盖了。解决方案不是购买更好的监控工具，而是简化提交流程，降低摩擦，让正确的做法比错误的做法更容易。

案例二：Google的“调研先行”策略

Google在改进开发者体验时，采用了极其系统化的方法：先用调研捕捉工程师的主观反馈，再用遥测数据验证假设，然后才是工具和流程的迭代。

这与中国很多企业的做法恰恰相反——很多团队上来就建Dashboard、做埋点、上监控，然后发现一堆数字却不知道意味着什么。

Google的经验表明：先理解“工程师的感受是什么”，再理解“系统表现是什么”，最后才是“他们为什么不同步”。这个顺序不能颠倒。

案例三：零售行业的“自然选择”效应

Nicole提到零售行业是唯—一个在软件交付能力上呈现显著差异的领域——而且是“更好”而非“更差”。

原因不难推测：在Amazon和电商的冲击下，零售企业如果不能在高并发、极限流量下保持系统稳定，根本活不下来。Black Friday不允许系统崩溃，峰值时段不允许响应缓慢。这种极端的生存压力，反而锻造出了更强的工程能力。

对其他行业的启示是：如果你的业务压力不够极端，你需要人为地制造“压力测试”——比如更短的发布周期、更严格的SLO、更频繁的代码审查。

行动建议

建议一：从定义问题开始，而不是从找工具开始

为什么要做：80%的团队在启动改进项目时，出发前没有对齐目标。结果是做了大量工作，却没有解决核心问题。

如何开始：用一个简洁的句子写下你要解决的问题：“我们想要__（具体描述），以便__（业务或团队结果）。”然后找3-5个利益相关者（包括工程师）验证这个定义是否准确。

能得到什么：减少团队无效努力，确保改进工作与业务目标对齐。

建议二：用DORA四指标做一次基线测量

为什么要做：如果你不知道起点在哪里，任何改进都是盲目的。DORA四指标是业界验证最充分的测量框架，能快速定位你的软件交付能力处于什么水平。

如何开始：访问dora.dev，使用免费的Quick Check工具。根据你的直觉选择当前状态，它会给出你的基准定位（Elite/High/Medium/Low）。不需要精确到分钟——重要的是知道自己在哪里。

能得到什么：一个可量化的起点，以及针对你当前水平的重点改进建议。

建议三：每季度做一次开发者体验调研

为什么要做：系统数据告诉你“发生了什么”，但不会告诉你“工程师的感受是什么”。调研是捕捉主观体验、发现系统盲区的唯一途径。

如何开始：设计一个简短的调研（10-15题），覆盖工作满意度、工具链摩擦、协作痛点、改进建议四个维度。频率不要太高——每季度一次足够，留出时间让问题被识别和解决。

能得到什么：真实反映工程师需求的改进方向，以及团队归属感和信任度的提升。

建议四：识别并消除审批等待的“伪稳定”措施

为什么要做：很多团队引入变更审批冷却期是为了“更安全”，但实际上在制造更大的风险和更严重的上下文丢失。

如何开始：审视你现有的变更管理流程，问自己：这道审批是真正的风险控制，还是“感觉更安全”的心理安慰？如果是后者，计算一下等待时间造成的成本和风险。

能得到什么：更快的交付速度，同时通过小批量部署和自动化测试保持真正的稳定性。

建议五：建立“平衡指标”意识，用SPACE框架思考测量策略

为什么要做：单一维度指标（如代码行数、PR数量）不仅无法反映真实生产力，还会激励错误的行为——比如为了PR数量而拆分提交。

如何开始：下次你需要测量某个工程活动时，先想清楚三个问题：这个指标属于SPACE的哪个维度？还有哪些维度与它相关？如果只用一个维度，会有什么风险？

能得到什么：更全面、更平衡的生产力视图，以及避免“指标游戏”的免疫能力。

我的总结

衡量和改进开发者生产力，是一件看起来简单、做起来极其复杂的事情。Nicole Forslein用二十年的研究与实践告诉我们：核心不在于选哪个工具、上哪个平台，而在于——你是否能清晰地定义你要解决的问题，是否有勇气去问工程师真实感受，是否愿意用平衡的视角看待定量与定性数据，是否理解“移动更快”本身就是提升稳定性的最佳策略。

在AI重新定义工程师角色的今天，这套方法论的价值不是减弱了，而是更强了。因为无论工具如何变化，“理解你的团队在想什么”“让软件交付更顺畅”“让工程师更专注”的本质从未改变。

如果你今天只记住一件事：出发前，先问自己——我们到底在解决什么问题？定义清楚这个问题，你就已经赢了一半。

📺 播客信息

发布时间：2023-07-30
时长：1小时16分钟17秒
播放量：33006 次观看
原版视频：『YouTube』