3.0 第3部分导言：开发者体验与SPACE框架

第2部分从外部衡量交付：代码穿过一条流水线的速度有多快、有多安全。这一部分衡量的是生产这些代码的人的体验，它之所以存在，是因为一套交付指标可以看起来非常优秀，而其背后的人却正在耗竭、被打断淹没，或者正在悄悄地脱离投入。一个只盯着DORA指标的组织，可以靠更用力地压榨一个团队，让这些指标改善一两年，直到人员流失、质量崩溃或职业倦怠一次性抹平所有的收益。这一部分就是那个制衡力量。

核心是SPACE框架，由来自微软、GitHub和维多利亚大学的研究人员开发，专门用来纠正业界那种用单一、容易被操纵的代理指标（比如代码行数或提交次数）来衡量开发者生产力的习惯。SPACE涵盖五个维度：满意度与幸福感、绩效、活动、沟通与协作，以及效率与心流。这个框架的核心纪律，也是这一部分要以第2部分对待自身流动指标同等的严谨来对待它的原因，在于没有任何单一维度本身是可信的；价值恰恰来自把这五个维度一同放在视野之中，这样一个团队就无法靠悄悄损害另一个轴而在某一个轴上看起来出色。

对大团队而言，开发者体验指标回答了一个DORA无法回答的问题：这种交付绩效是否可持续，组织是否留住了生产它的人。忽视这一部分的企业组织，往往要等到通过人员流失数据和离职访谈发现代价时，损害早已造成；政府组织常常在公共部门薪酬限制之下运作，难以单靠薪酬竞争，因此尤其有充分的理由把开发者体验当作一项一流的、主动管理的关切，而不是事后才想起的补充。

本部分各主题

3.1 SPACE框架： 五个维度合在一起，为什么没有任何单一维度本身值得信赖，以及如何从中构建出一套真正均衡的指标集。
3.2 满意度与幸福感指标： 衡量成就感、挫败感与职业倦怠风险，这是任何系统遥测都无法直接观察到的维度。
3.3 绩效指标与结果代理指标： 这是最容易与活动混淆的维度，以及如何转而衡量真正的结果贡献。
3.4 活动指标及其局限： 提交次数、代码行数，以及为什么这是最危险、最不应被过度看重的维度。
3.5 沟通与协作指标： 信息实际上如何在人与团队之间流动，一种健康的模式看起来是什么样子。
3.6 效率与心流：深度工作与打断： 保护真正的工程工作所需要的不受打断的时间，并衡量侵蚀它的摩擦。
3.7 开发者体验调查与DevEx指标： 如何设计一份能产生可信信号、而不是一场人气竞赛的调查，以及如何把它与客观数据结合起来。

这些主题如何相互关联

主题 3.1 把SPACE的全部五个维度一并引入，随后主题 3.2 到主题 3.6 按照SPACE研究者呈现的顺序，逐一深入探讨每个维度。主题 3.7 以调查设计的实务机制为这一部分收尾，因为满意度、绩效和协作都部分依赖自我报告数据（主题 1.5 关于埋点数据与自我报告数据的区分在这一部分自始至终都直接相关），而一份设计糟糕的调查会削弱前面每个主题的成果。

这一部分的核心纪律，均衡地看待各个维度，而不是在某一个维度上追求强度，是本书对主题 1.3 结果优先于产出原则的最清晰实例，只是这次应用于人，而不是应用于交付流水线。活动（主题 3.4）是SPACE诸维度中最类似于纯粹产出指标的一个，这一部分也相应地对待它：作为五个输入之一时有用，作为独立信号时危险。与第2部分一并阅读，这一部分补全了DORA单独无法提供的图景：不只是软件是否交付得快、交付得安全，还有交付它的人能否维持这样的节奏。