3.4 活动指标及其局限

概述与动机

活动，SPACE（主题 3.1）中的A，计量的是能从系统遥测中观察到的工程工作量：提交次数、打开的拉取请求、变更的代码行数、留下的代码评审评论。它是最容易衡量的SPACE维度，因为这些事件中的每一件都已经被工程团队日常使用的工具自动记录了下来，而这种衡量上的便利，恰恰是这个维度最危险、最不应被过度看重的原因。谨慎使用时，活动是一个真实、合法的信号。一旦被当作独立的生产力代理指标使用，它就是整个软件工程测量历史上最常被操纵、最具误导性的单一指标家族。

核心问题在于，活动衡量的是动作，而不是价值。提交次数无法区分一次优雅地解决了一个难题的提交，和一次为了显得更有生产力而把一项有意义的变更拆分成五份的提交（主题 1.2 的替代性操纵，直接应用于这个指标家族）。变更的代码行数奖励的是冗长，而不是那项远更有价值的技能：删除不必要的代码。一名工程师花一整天进行深入、不受打断的思考，然后写下十行优雅、经过充分测试的代码，按这些指标衡量，看起来比一名每二十分钟就提交一次浅薄、未经评审变更的工程师”不那么活跃”，尽管前者往往正在产生远更多的真实价值。

对大团队而言，用活动指标来做个人评估的诱惑一直存在，而且有据可查，因为与SPACE其他维度中那些更难、更诚实的信号不同，活动很容易归因给具体某个人，也很容易自动计算。本主题的存在，正是为了明确点出这种诱惑，并给团队提供语言和证据来抵制它，因为一个组织一旦开始按提交次数或代码行数对工程师进行个人排名，对协作、代码质量和士气造成的损害，就有据可查，而且很难逆转。

核心原则

活动衡量的是动作，而不是价值。 它是一个合法的背景信号，绝不是独立的生产力代理指标。
这是软件工程测量历史上被滥用得最多的单一指标家族。 把这段历史当作一个警示，而不是巧合。
个人活动排名几乎总是有害的。 它损害协作，奖励可见的忙碌工作，几乎会立刻招致操纵。
活动数据在汇总层面最有用，作为其他维度的背景信息， 而不是作为关于任何一个人或团队的独立信号。
深入、有价值的工作在活动仪表盘上往往显得安静。 这个指标家族在结构上，恰恰对能产生最佳工程成果的那种思考存在偏见。

建议

绝不按原始活动计数对个人进行排名或评估

这是本主题中最难、也最重要的一条规则。提交次数、代码行数和拉取请求数量，绝不应该出现在个人绩效评估、比较性排名，或任何工程师的薪酬、地位或声誉取决于这个数字的场合。这直接遵循主题 1.2 的激励暴露原则：活动一旦成为一项被激励的个人指标，操纵几乎立刻随之而来，由此产生的行为，堆砌提交、把变更拆得琐碎、回避那些产生很少可见事件的深入而不起眼的工作，会积极地损害组织。

在汇总层面把活动数据用作背景，而不是裁决

当活动数据在团队层面被汇总，并与SPACE的其他维度一并解读时，才会变得真正有用：团队层面提交活动的骤降，如果恰逢满意度上升，可能意味着团队终于有了喘息的空间来深入思考、偿还技术债务，这是一个积极的模式，而不是消极的模式。孤立地看，同样的下降会显得令人担忧。正是来自其他维度的背景信息，让活动数据变得可以解读，而不是具有误导性。

相比原始数量，优先选用与质量相关联的活动信号

在活动数据确实有用的地方，优先选用经过质量调整的信号，而不是原始计数：拉取请求规模相对于评审深度（主题 2.9），或新增代码与删除代码的比例，这能揭示一个团队是在积累复杂性，还是在积极地做简化工作。这些经过调整的信号仍然是活动维度的数据，但抵御了原始计数所招致的那种最粗糙的操纵。

专门留意活动数据中的替代性操纵模式

活动指标最常被操纵的方式，正是主题 1.2 的替代性模式：把真正有意义的工作拆分成许多琐碎的小事件，以推高计数。如果提交或拉取请求频率上升，而变更的底层复杂度或规模却急剧下降，那就在把它记为真正的生产力改善之前先做调查，采用主题 2.10 为部署频率所建议的同一种诊断纪律。

明确指出并劝阻活动剧场

活动剧场指的是一种工作方式，无论有意还是无意，主要是因为它可见、可计数，而不是因为它有价值：频繁的小提交、显眼的深夜活动，或在共享频道中显眼的忙碌表现。向你的团队明确点出这种模式，并透明地说明领导层不会用原始活动来评判贡献，这从一开始就消除了它发生的大部分动机。

权衡取舍：利与弊

方案	优点	缺点
个人活动排名	简单，容易计算，感觉直接可操作	几乎立刻被操纵；损害协作与士气；衡量了错误的东西
完全不测量活动	完全避免了滥用风险	失去了对团队层面模式发现真正有用的背景信号
团队层面的活动汇总，结合背景解读	在没有个人风险的情况下提供有用的背景信息	需要纪律，把它与其他维度一并解读，而不是孤立地看
经过质量调整的活动信号	抵御了最粗糙的原始计数操纵	比简单计数更复杂，更难计算和解释

核心张力是有用性与滥用风险之间的张力。经过审慎汇总、结合背景解读的活动数据，对发现像不可持续的节奏，或一个团队正悄悄找到空间处理技术债务这样的模式，是真正有用的。同样的数据一旦被用作个人记分卡，则几乎无一例外是有害的。解决这种张力的办法，不是完全回避活动数据，而是建立一条针对个人使用的硬性组织规则，同时允许、甚至鼓励经过深思熟虑、结合背景的团队层面使用。

与团队讨论的问题

我们组织中是否有人曾经，无论正式还是非正式地，被用像提交次数或代码行数这样的原始活动计数来评估？ 直接问这个问题，并做好准备接受一个不舒服但必要的答案；这种滥用往往悄悄发生，通过一位经理的一句随口评论，从未成为正式政策。
在我们团队上，活动剧场具体会是什么样子，我们见过它的迹象吗？ 明确点出这种模式在你自己团队上可能采取的具体、合理的形式，会让它一旦开始发生时更容易被识别出来。
当我们团队层面的活动数据发生变动时，我们是把它与SPACE的其他维度一并解读，还是孤立地解读？ 孤立地看，活动下降显得令人担忧；同样的下降如果与满意度或绩效的改善一并解读，可能看起来像一个真正积极的模式。对照这个区分检查你实际的审阅做法。
我们是否曾见过提交或拉取请求频率上升，同时平均变更规模却在缩小，暗示的是琐碎的拆分而不是真正的生产力提升？ 拉出真实数据，检查这种具体的替代性操纵模式。
我们目前是如何谈论”谁的贡献最大”的，这种对话是否即使没有正式指标，也在暗中依赖活动数据？ 对可见忙碌的非正式、未被测量的偏见，即使没有明确的基于活动的政策，也能塑造认知和奖励；诚实地把这一点摆出来。
在我们团队上，真正有价值但安静的工作，深入思考、细致的设计、指导他人，看起来是什么样子，我们如何确保它得到认可，尽管它产生的可见活动数据很少？这个问题是前面几个问题积极的补充：明确指出优秀而安静的工作看起来是什么样子，有助于保护它不被更响亮、更可计数的工作所忽视。

行业视角

初创公司。 在一个紧密协作的小团队中，活动数据通常根本不需要仪表盘就能被看见，本主题所警告的个人排名风险也不太可能出现，原因很简单，人人都已经知道其他人在做什么。风险反而在于，创始人在做早期招聘或股权决策时，无意识地偏爱那种看起来”忙碌”的行为。

小型企业。 浏览你现有工具中的活动数据，以获得对团队吞吐量的一般感觉是可以的，但要抵制用它来直接比较个人贡献者；一个小团队的真实价值，往往集中在少数几个从事安静、高杠杆工作的人身上，而一种按提交计数的视角会系统性地低估这种工作。

企业。 这正是个人排名诱惑最强、也最具破坏性的地方，因为对于一个横跨数千名工程师的绩效评估流程而言，活动数据是最容易拉取的信号，而找到某种可量化输入的压力是真实存在的。建立一条明确、经过传达、被强制执行的政策来反对个人活动排名，并定期审计绩效评估实践，确认这项政策在实践中确实被遵守，而不只是被写在纸上。

政府。 在一份公开报告中引用活动指标作为生产力证据（“今年十万次提交”）可能很诱人，但这种标题性的数字几乎毫无意义，一旦一位懂行的审阅者指出原始活动量对结果只字未提，它还可能招致恰恰错误的审查。转而报告结果与绩效数据（主题 3.3），并在任何面向外部的沟通中避免使用活动计数。

案例

企业。 一家软件公司的工程领导层，在没有正式政策的情况下，已经开始在晋升讨论中非正式地引用个人提交频率数据。一次由一个不相关的人员流失分析项目引发的内部审查发现，那些在公司最复杂、最高价值系统上工作、需要在编写任何代码之前经历长时间细致设计工作的工程师，提交次数系统性地低于在更简单、更增量式开发的系统上工作的工程师，并因此在晋升对话中被微妙地处于不利地位。领导层发布了一项明确、经过传达的政策，禁止在绩效和晋升讨论中引用活动计数，并把晋升证据转向了主题 3.3 的多信号绩效方法。

政府。 一家数字服务机构，在需要向一个立法监督委员会证明生产力的压力之下，最初提议把其工程项目中的总提交数和编写的代码行数，作为交付价值的证据来报告。一位内部技术顾问提出了反对意见，正确地指出这种框架会招致恰恰错误的审查，因为一位具备技术素养的委员会成员很容易指出，原始代码量对代码是否有效或是否重要只字未提。该机构修订后的报告转而使用了结果指标（主题 5.3）：公民报告的错误减少，以及自助服务成功完成率提高，这在委员会质询下的表现，远比活动数字本会有的表现更站得住脚。

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

把活动指标用对，在情境中使用它们，而不是当作个人记分卡，其回报是避免了损害：那些按活动对工程师进行个人排名的组织，可靠地会看到操纵行为、协作减少（工程师保护自己可见的产出，而不是帮助队友），以及对深入、高杠杆工作系统性的偏见，尽管这类工作往往产生最多的价值，却产生最少的可见活动。一旦这种损害在绩效评估文化中根深蒂固，要逆转它真正是困难且缓慢的。

避免这个陷阱的总拥有成本，主要是组织纪律：一项明确、一贯执行的、反对个人活动排名的政策，以及转而投资于主题 3.3 所述那种更难、更诚实的绩效测量的承诺。这份纪律的成本，低于个人活动指标随时间可靠地产生的被误导的晋升决策、受损的协作和操纵行为。

反模式与陷阱

按提交次数或代码行数对个人排名： 本书全书中破坏性最大、历史上最常见的一种滥用。
活动剧场： 主要为了可见性而不是价值而进行的工作，是对基于活动的评估完全可以预见的一种反应。
孤立地解读团队层面的活动下降，而不检查其他SPACE维度： 可能把一个真正积极的模式误认为令人担忧的模式。
在面向外部或面向领导层的沟通中引用原始活动计数： 招致恰恰错误的审查，对真实价值几乎只字未提。
系统性地低估那些产生很少可见事件的深入、细致工作： 一种烙印在整个指标家族结构之中的偏见。
非正式的、没有政策约束的活动偏见悄悄渗入晋升或评估对话： 即使背后没有一项官方指标，也具有破坏性。

成熟度模型

第一级，启动： 活动指标被用来评估或排名个人，无论正式还是非正式，完全没有意识到其中的风险。
第二级，发展： 对风险存在一些意识，但没有明确的政策防止活动数据非正式地影响评估或晋升讨论。
第三级，标准化： 一项明确、经过传达的全组织政策禁止个人活动排名，活动数据只在汇总的、团队层面的背景中被使用。
第四级，管理： 绩效评估和晋升实践被定期审计，以确认这项政策在实践中被遵守，在确实使用活动数据的地方，经过质量调整的活动信号取代了原始计数。
第五级，协奏： 组织已经明显地把评估文化从活动指标转向主题 3.3 的多信号绩效方法，协作方面的可见改善和操纵行为的减少，证明了这种转变行之有效。

讨论思路

这里有没有人曾经感觉自己，哪怕只是非正式地，因为活动看起来有多”忙碌”而被评估？
在我们团队上，活动剧场具体会是什么样子？
我们是否有一项明确的、书面的政策反对个人活动排名，它是否确实被遵守？
在我们团队上，目前哪些安静、高价值的工作产生的可见活动数据最少？
我们要如何重新设计绩效评估证据，才能完全去除活动计数？

要点回顾

活动衡量的是动作，而不是价值；它是软件工程历史上被滥用得最多的单一指标家族。
绝不按原始活动计数对个人进行排名或评估；这是本主题中最难、也最重要的一条规则。
把活动数据用在汇总层面，作为背景，服务于SPACE的其他维度，绝不作为独立的裁决。
专门在这个指标家族内留意活动剧场和替代性操纵模式（主题 1.2）。
深入、高价值的工作往往产生最少的可见活动数据；保护它不被系统性地低估。

参考文献与延伸阅读

Forsgren, Nicole, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler, “The SPACE of Developer Productivity,” ACM Queue (2021)。
Peopleware: Productive Projects and Teams，Tom DeMarco、Timothy Lister著（反对用可见忙碌来衡量工程师的经典论证）。
Deep Work: Rules for Focused Success in a Distracted World，Cal Newport著（活动指标系统性低估的那种安静、不受打断工作的价值）。
The Tyranny of Metrics，Jerry Z. Muller著（指标迷恋及其代价，直接适用于基于活动的评估）。