3.3 绩效指标与结果代理指标

概述与动机

绩效，SPACE（主题 3.1）中的P，是最常与活动混淆的维度，而防止这种混淆正是本主题存在的原因。绩效问的是一名工程师或一个团队的工作，是否真正产生了一个好的结果：一项发布出去并且真正好用的功能，一个保持可靠的系统，一项把某个业务或用户指标推向正确方向的变更。活动（主题 3.4）问的只是发生了多少动作。一个团队可以非常活跃却绩效低下，不停发布一些从未推动任何结果的小变更，反过来也同样成立：一个团队发布得很少，但它的变更总是恰到好处地落地。

这个维度的困难之处在于，结果往往无法归因于单一个人，甚至无法归因于单一团队；软件的结果来自协作，来自数月前由如今已经转去其他项目的人所做的决策，来自任何工程师都无法控制的市场条件。SPACE的研究者对此讲得很明确：绩效应当在系统或团队层面用多个相互印证的信号来衡量，而不应被压缩成单一数字，更不应被归因给孤立的单个工程师。本主题认真对待这一指导，把个人绩效归因当作一个应当被主动避免的陷阱，而不是一条在方便时可以抄的近路。

对大团队而言，把绩效测量做对，是一套真正能改善结果的指标项目，与一套只是奖励可见忙碌的指标项目之间的分水岭。跨越许多团队比较绩效的企业组织，需要能抵御靠原始产出量来操纵的信号；向监督机构证明技术投资合理性的政府组织，需要证明工程投入产生了真实的结果，而不只是交付了产出物，这正是主题 1.3 结果优先于产出的原则应用到这个具体维度上的体现。

核心原则

绩效衡量的是工作是否产生了好的结果，而不是发生了多少工作量。 这是与活动维度的核心区别。
使用多个相互印证的信号，绝不用单一的绩效数字。 没有任何单一的代理指标可靠到足以独立成立。
在团队或系统层面测量。 个人层面的结果归因通常不可靠，并且恰恰招致本书自始至终所警告的那种操纵。
质量是绩效的一部分，而不是一个独立的关切。 发布出去却破坏了其他东西的工作，并没有真正表现良好。
没有配上决策的绩效信号是装饰品，这正是主题 1.1 的一般原则应用到这个维度上的体现。

建议

组合多个相互印证的信号，而不是单一的绩效分数

从多个来源汲取绩效证据：变更失败率（主题 2.10）和缺陷逃逸率（主题 5.1）用于衡量质量，与实际功能采用率（主题 5.2）挂钩的部署结果用于衡量这项工作是否真正重要，以及关于一个团队对战略目标贡献的定性同行或经理评估，用于提供纯粹指标无法捕捉的背景信息。这些信号中没有任何一个单独可靠；当它们共同指向同一个结论时，合在一起远比任何单一数字更可信。

在团队层面测量，抵制个人归因

软件的结果很少仅仅是一个人工作的产物；它们来自设计决策、评审反馈、可能已经离开团队的人此前所做的工作，以及跨边界的协作。把一个结果归因给单一工程师，通常是一种忽视这一现实的虚假精确，并为个人创造出保护功劳而不是自由协作的强烈激励，这正是主题 1.2 所警告的那种激励扭曲。

把质量直接纳入绩效的定义之中

一项按时发布却引发一波生产事件的功能，并没有表现良好，尽管一种天真的、只看产出的视角会把它算作已交付。把变更失败率、缺陷逃逸率和发布后事件数据直接纳入你评估绩效的方式，而不是把质量当作一个独立的、脱节的关切，只在本书第4部分和第6部分中衡量。

用绩效数据来指导投资和流程决策，而不是个人排名

绩效数据的有效用法，是决定在哪里进一步投资（一个持续交付出色结果的团队理应获得更多资源和自主权），以及在哪里需要调查（一个工作持续未能落地的团队理应获得帮助，而不是指责，依据主题 1.1 的诊断性框架）。用绩效数据对个人或团队进行竞争性排名，恰恰招致本书所警告的那种操纵和士气损害，也很少能比诊断性用法产生更好的结果。

对归因的局限保持诚实，尤其是对平台团队和赋能团队而言

构建共享基础设施、内部工具或平台能力的团队（姊妹书籍software-engineering-guide的平台工程主题直接涵盖了这一点）对结果的贡献，往往与任何单一的面向客户的指标相隔好几步。用这些团队对它们所赋能的团队产生的影响，比如平台的采用情况、被服务团队所报告的摩擦减少，来衡量它们的绩效，而不是把一个不合适的直接结果指标硬套在本质上间接的工作上。

权衡取舍：利与弊

方案	优点	缺点
每个团队一个绩效分数	呈现和比较起来简单	虚假精确；掩盖了究竟是哪个底层信号真正驱动了这个分数
多个相互印证的信号	更可信，抵御单一指标操纵	更难用一个数字概括；需要更多背景信息才能解读
团队层面的绩效测量	符合软件结果实际产生的方式	无法直接回答关于个人贡献的问题
个人层面的绩效归因	对评估而言感觉更直接可操作	通常是一种虚假精确；带来强烈的操纵和保护功劳的风险

核心张力是精确性与诚实性之间的张力。每个团队一个绩效数字，或者更糟，每个个人一个绩效数字，比较和排名起来很容易，但这种精确性通常是虚假的，把归因和质量方面真实存在的不确定性，掩藏在一个看起来干净利落的数字背后。解决这种张力的办法，是把一幅不那么整齐、多信号的图景当作诚实的图景来接受，并抵制来自领导层或绩效评估流程要把它重新压缩成单一、虚假精确分数的压力。

与团队讨论的问题

我们当前的绩效测量是组合了多个相互印证的信号，还是依赖一个感觉比实际更精确的单一数字？ 审计你目前所称的”绩效指标”，检查究竟有多少个独立的、相互印证的信号真正输入其中。
我们是否曾在没有考虑到结果实际是如何通过协作、跨团队方式产生的情况下，把某个团队或个人的绩效归因出去？ 挑一个近期的成功案例，追溯它在多大程度上依赖了被记功的团队或个人之外的人、决策或此前的工作。
我们的绩效测量是否包括质量，还是只有交付速度和产出量？ 一项发布出去后引发了严重生产事件的功能，不应该被算作高绩效；检查你当前的测量是否真的能捕捉到这种情况。
我们如何测量那些对结果的贡献是间接的平台团队或赋能团队的绩效？ 如果诚实的答案是”我们其实没有测量”，那这个缺口就值得被直接点明并解决，而不是让这些团队实际上未被测量，或者被拿一个不适合它们工作的、面向客户的结果指标不公平地测量。
绩效数据是否曾经，无论正式还是非正式，被用来对个人进行竞争性排名？ 这种漂移，类似于主题 3.2 中满意度数据面临的风险，会同时损害数据的诚实性和团队公开协作的意愿。
当我们相互印证的信号出现分歧时，比如交付速度很高但缺陷率在上升，我们会得出什么结论，我们的流程能很好地处理这种分歧吗？ 信号之间的分歧本身就是有价值的信息；讨论你的团队目前是把它当作可以忽略的噪声，还是当作一个值得调查的真实发现。

行业视角

初创公司。 绩效通常是直接可见的：功能有没有用，客户有没有采用它，指标有没有变动。在这个规模上，正式的多信号测量往往没有必要；风险反而在于，在一个快速移动、高度协作的小团队中，过快地把成功或失败归因给某一个人，而功劳和责任很少只属于某一个个人。

小型企业。 把你已经拥有的任何交付和质量数据（主题 2.10、主题 5.1）与关于近期工作是否真正帮助了业务的直接、诚实的对话结合起来，而不是构建你没有能力维护的正式多信号埋点。

企业。 这正是团队层面、多信号测量的纪律发挥其投资价值的地方，因为在这里，把绩效压缩成一个可以跨几十个团队比较的单一数字的压力最强，而虚假精确带来的损害，会在整个组织的资源配置决策中不断累积。明确地抵制这种压力，并建立起为什么多信号方式重要的论证。

政府。 证明工程投资产生了真实的结果，而不只是交付了产出物，往往是监督机构提出的核心问题。与结果指标（主题 5.3）明确挂钩的多信号绩效测量，而不是仅有交付的代理指标，给出的答案远比单纯的活动或交付计数更有力、更站得住脚。

案例

企业。 一家零售科技公司的领导层此前一直非正式地按每个冲刺完成的故事点数给工程团队排名，把这当作绩效代理指标。在采用一种多信号方法，结合交付数据、变更失败率和发布后功能采用率之后，领导层发现，故事点完成率最高的团队，在全公司范围内功能采用率却最低：他们发布得很快，但构建的东西客户并不使用。基于这幅更完整的绩效图景，而不是那种具有误导性的单一数字排名，重新调整该团队的路线图优先级，在一个季度内把大量工程产能重新导向了影响力更高的工作。

政府。 一家国家税务机构的工程项目需要向一个监督委员会证明，一项重大系统投资改善了绩效，而不只是交付了合同规定的范围。该项目没有只报告故事点或里程碑完成情况，而是呈现了一组相互印证的信号：处理错误率下降、处理时间中位数下降、自助服务成功完成率上升，全部与所交付的具体系统组件挂钩。这种与结果挂钩的多信号呈现方式，经受住了委员会的审查，而前一年一份来自此前某个项目、仅有”按期交付”的简单报告没能做到这一点。

商业理由：动机、投资回报与总拥有成本

通过相互印证、与结果挂钩的信号来测量绩效，而不是用一个虚假精确的单一数字，其回报是更好的资源配置决策：一个能够看清哪些团队的工作真正推动了结果的组织，能够在真正重要的地方进一步投资，在没有起作用的地方进行调查，而不是奖励恰好看起来最忙碌的那个团队。上面的零售案例很典型：一个具有误导性的单一数字排名，此前一直把投资关注引离了它本可以真正发挥作用的地方。

总拥有成本高于单一指标方法，因为它需要组合来自多个来源（交付、质量、结果）的数据，并抵制组织把这幅图景重新压缩成一个可比较数字的压力。这份成本值得付出，因为替代方案，一个虚假精确的单一分数，会积极地误导绩效数据本应指导的资源配置决策。

反模式与陷阱

把活动与绩效混为一谈： 这正是这个维度专门用来防止的最常见错误。
对协作性、跨团队的结果做个人绩效归因： 通常是一种阻碍协作的虚假精确。
把质量排除在绩效的定义之外： 奖励了发布出去却破坏了其他东西的工作。
把一个直接结果指标硬套在平台团队或赋能团队身上： 对本质上间接的工作衡量了错误的东西。
在组织压力之下，把多个相互印证的信号重新压缩成一个虚假精确的数字： 失去了多信号方法本应提供的诚实性。
用绩效数据对个人进行竞争性排名： 同时损害数据的诚实性和团队协作。

成熟度模型

第一级，启动： 绩效与活动或产出量被混为一谈，用一个未经审视的单一数字来衡量。
第二级，发展： 一些质量信号与产出一并被考虑，但没有一致的多信号方法，个人归因仍在非正式地发生。
第三级，标准化： 绩效在团队层面用多个相互印证的信号来测量，包括质量，在全组织范围内保持一致。
第四级，管理： 相互印证的信号之间的分歧被主动调查；平台团队和赋能团队拥有适合其实际工作的、恰当间接的绩效衡量方式。
第五级，协奏： 绩效数据直接为资源配置和投资决策提供依据，组织能够指出具体的重新配置决策，这些决策是多信号视角所促成的，而单一数字视角本会遗漏它们。

讨论思路

我们目前正在用哪个单一数字作为绩效代理指标，应该用一组相互印证的信号取而代之？
我们是否曾因为归因不清，而把一个结果记功给了错误的团队或个人？
我们目前如何测量一个平台团队或赋能团队的绩效？
如果我们相互印证的信号在下个季度出现分歧，会是什么样子？
故事点或交付计数排名，曾在哪里误导了我们的投资关注？

要点回顾

绩效衡量的是工作是否产生了好的结果，而不是发生了多少动作；不要把它与活动（主题 3.4）混淆。
使用多个相互印证的信号，绝不用单一的绩效数字，并对虚假精确保持警惕。
在团队或系统层面测量；个人层面的结果归因通常不可靠，并且损害协作。
质量是绩效的一部分，而不是一个独立的、脱节的关切。
给平台团队和赋能团队恰当的间接绩效衡量方式，而不是把一个不合适的直接结果指标硬套在它们的工作上。

参考文献与延伸阅读

Forsgren, Nicole, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler, “The SPACE of Developer Productivity,” ACM Queue (2021)。
Accelerate: The Science of Lean Software and DevOps，Nicole Forsgren、Jez Humble、Gene Kim著（基于结果的绩效测量）。
Team Topologies，Matthew Skelton、Manuel Pais著（平台团队与赋能团队的结构，以及如何测量它们的贡献）。
Measuring and Managing Performance in Organizations，Robert D. Austin著（虚假精确绩效指标的风险）。