1.1 为何衡量软件工程

概述与动机

软件工程抵御衡量的方式与制造业不同。工厂生产线产出的是完全相同的单元，因此数一数有实际意义。而软件工作是在不断变化的需求下产出独一无二的成果，因此一个天真的计数，不管是提交次数、代码行数，还是关闭的工单数，几乎无法说明交付了多少价值。衡量软件工作的困难，与真实存在的、想知道进展是否顺利的需求之间的这道鸿沟，正是本书整体所在之处。本主题要做的，就是诚实地弥合这道鸿沟：不是假装软件工作像零件一样可数，而是精确说明衡量对一个工程组织能做什么、不能做什么。

衡量存在的意义，是回答一个组织若不借助衡量便无法自信作答的问题：我们的交付在变快还是变慢、质量在提升还是在恶化、工程师是否正在耗竭、这笔投资是否值得。没有指标，这些问题就会由房间里说话最自信的人来回答，通常是在场资历最深或最善辩的人，而这个答案往往是错的。跳过衡量的 软件工程 团队并不会因此就避免对自身表现作出判断。他们只是凭感觉、轶事和近因偏差来作判断，而不是凭证据。

对大团队而言，这不再是锦上添花，而变成了结构性的需求。六人小团队可以通过每天的交流共享一个关于事情进展的心智模型。而一个跨越多个时区和业务单元、拥有六百人的部门做不到这一点。在那样的规模上，一套共享的、可信赖的数字，是小团队免费获得的那种非正式认知的唯一实际替代品。企业领导层需要指标来在争夺同一预算的几十个团队之间分配投资。政府工程组织需要指标向立法机构和公众证明，拨付的资金产生了真实的能力，而不只是活动。在这两种情境下，“我们努力工作了”都不是证据，一个站得住脚的数字才是。

核心原则

为学习而衡量，而非为评判而衡量。 工程指标的首要目的是为决策提供信息，而不是给个人或团队打分。
没有附带决策的数字只是装饰。 如果读取某个指标的任何结果都不会改变你接下来的行动，它就不该出现在仪表盘上。
衡量是手段，不是目标。 目标是由一支可持续的团队更可靠地交付更好的软件。指标的存在只是为了服务这个目标。
每个指标都有成本。 埋点、评审时间，以及主题 1.2 所涉及的行为扭曲风险，都要付出代价。一个指标必须把这份代价赚回来。
沉默同样是一种决策。 选择不衡量某件事是一个有后果的选择，而不是一个中性的默认状态。

建议

从决策出发，而非从仪表盘出发

在着手埋点之前，先说清楚这个指标将为哪个决策提供信息。“我们想知道新的部署流水线是否降低了事故率”是一个具有决策形态的问题；“让我们把工具能导出的一切都跟踪起来”则不是。从决策倒推，能让指标集保持精简，也能让每一块仪表盘瓷砖在被问及”它为什么存在”时都站得住脚。如果你说不出某个指标会为哪个决策提供信息，那就暂时不要构建它。主题 1.3 会更深入地探讨这门学科中”结果优先于产出”的那个版本。

把诊断性用途与评价性用途分开

用于诊断系统问题的指标（为什么我们的交付周期在悄悄变长）与用于评价某个人或团队的同一指标（谁的交付周期最差）表现完全不同。前者招来调查与改进；后者招来隐瞒与操纵，因为这个数字现在附带了声誉或财务上的后果。要明确地、书面地决定某个指标用于何种用途，并且永远不要让一个诊断性指标在没有人刻意重新权衡风险的情况下滑向评价性用途。这一区分在本书中反复出现，并在主题 1.4 所述的指标章程的”非目标”部分被正式确立。

把衡量当作一个假设，而非一个事实

指标是你真正关心的那件事的代理，而不是那件事本身。部署频率是交付能力的代理，而不是交付能力本身。把每一个指标都当作一个正在持续接受检验的假设：这个数字是否仍然追踪着我们所关心的事物，还是世界已经变化而代理指标却被落在了后面？按固定节奏重新审视这个问题，而不要假设两年前选得好的指标今天依然选得好，尤其是当工具、团队结构，或者（参见第7部分）工作本身的性质发生变化时。

让衡量的缺失变得可见

在大型组织中，最危险的缺口往往不是一个糟糕的指标，而是一个因为难以埋点、根本无人衡量的领域：开发者体验、跨团队依赖摩擦、机构知识的流失。在指标章程中明确地点出这些缺口，而不要任其默认保持不可见。一个知道自己没在衡量什么、以及为什么的组织，其处境要比一个已经悄然忘记这些领域存在的组织强得多。

权衡取舍：利与弊

方案	优点	缺点
重度埋点，指标繁多	视野广阔，盲点较少	仪表盘疲劳、可操纵面更大、维护成本更高
极简、由决策驱动的指标	聚焦、开销低、每个指标都站得住脚	有可能错过所选集合之外正在冒头的问题
仅用于诊断的指标	鼓励诚实报告与调查	领导层仍可能非正式地将其用于评价
与个人评价挂钩的指标	感觉有问责性，易于向高管解释	操纵动机强烈；损害信任；通常衡量的是错误的东西

核心张力是覆盖面与聚焦度之间的张力，而这一张力又因诊断与评判之间的张力而更加尖锐。指标太少会形成盲点，往往要等到危机爆发才浮出水面；指标太多则没有人能据以行动，而每一个被赋予评价权重的指标都会招致扭曲。解决之道是从精简、由决策驱动的做法起步，只有在某个具体、被点名的决策确实需要时才增加一个指标，并在主题 1.4 的治理工作中明确捍卫”仅供诊断”这条边界，而不是任其默认地被侵蚀。

与团队讨论的问题

对我们当前仪表盘上的每个指标而言，一个好的读数和一个坏的读数分别会触发什么决策？ 如果两种读数都导向同一个行动，或者根本不导向任何行动，那这个指标就是装饰。逐块检视你的仪表盘，逼出对每一块瓷砖的诚实回答。这项练习往往能在一次坐下来的时间里就把一个臃肿的仪表盘砍掉一半，因为大部分冗余是由无人移除的指标累积而成，而不是由有人为了一个至今仍然成立的理由刻意添加的指标累积而成。
我们的哪些指标是被诊断性地使用的，哪些又已经悄悄变成评价性的了？ 一个为理解系统约束而构建的指标，可能在没有任何人刻意决定的情况下，逐渐演变为用来给团队或个人排名的工具，往往是通过评审会议上一句随口的评论逐渐变成习惯。一旦发生这种漂移，这个数字就不再可信，因为人们现在有理由让它看起来好看，而不是让它准确。用书面形式写明每个指标的预期用途，并对照当前实践进行核查。
我们因为难以埋点而没有在衡量什么，这个缺口又让我们付出了什么代价？ 最危险的盲点，恰恰是那些因为难以轻易衡量而从未登上仪表盘的领域：跨团队依赖摩擦、机构知识的流失，或者脆弱变通方案的悄然累积。列出每个人私下担心、却无人跟踪的事项清单，并诚实面对其中的原因。
如果我们明天删掉这个指标，谁会注意到，他们会失去什么？ 一个没人会想念的指标，就是一个没有为任何决策提供信息的指标。这个问题能揪出纯粹靠惯性存活的虚荣瓷砖。对于拥有几十个团队仪表盘的大型组织而言，这种剪枝的自律与最初添加新指标的自律同样重要。
我们仪表盘上的每个指标实际生产和维护起来到底要花多少成本，包括埋点背后的工程时间？ 指标不是免费的。流水线、仪表盘，以及讨论某个数字所花的评审时间，都带来经常性成本，而这份成本很容易被低估，因为它分散在许多小任务中，而不是一条显眼的账目。拿出你实际的埋点与维护投入，与第一个问题中的决策价值进行权衡。
在哪些地方，衡量已经取代了判断，又在哪些地方，判断已经取代了衡量？ 两种失败模式都是真实存在的。一个把每个决策都外包给仪表盘的团队，会失去能够捕捉数字所遗漏之处的情境判断力；而一个无视现有数据、只听房间里嗓门最大的人的团队，重演的正是本主题开篇所指出的问题。目标是让指标为判断提供信息，而不是取代判断。

行业视角

初创公司。 团队只有寥寥数名工程师时，本主题所警示的大部分问题，向评价性用途的漂移、盲点、仪表盘臃肿，都很容易避免，仅仅因为大家每天都在交流。真正的风险在于相反的方向：因为觉得是团队负担不起的开销而干脆完全跳过衡量。挑出两三个具有决策形态的问题（我们交付得够快吗、质量是否保持住了），只为这些问题埋点。

小型企业。 在没有专门的平台或数据团队的情况下，依靠你现有工具已经报告的数据，而不要构建定制埋点。支付处理商的仪表盘、支持工具的响应指标，以及你的CI提供商的构建历史，通常已经覆盖了最重要的决策。在证明自己会根据某个专门的工程分析平台所告诉你的信息采取行动之前，克制住购买它的冲动。

企业。 核心风险是指标在层层上报管理层的过程中，从诊断性用途悄然漂移到评价性用途，以及仪表盘因无人负责剪枝而不断堆积。在这样的规模上，治理（主题 1.4）并非可有可无。在各业务单元之间统一定义，并把定期的退役审查内建到指标项目本身之中。

政府。 这里的指标往往带有法定或预算方面的分量，这既提高了把它们做对的价值，也提高了做错的代价。上报给立法机构或监督机构的数字，需要有文档化的方法论、跨报告周期保持稳定的定义，以及对其局限性的诚实说明。把”我们目前没有衡量这个”当作一个你可能需要为之辩护的答案，而不是一个要私下隐藏的失职。

案例

企业。 一家全球保险公司的工程组织已经壮大到六十多个敏捷团队，每个团队都有自己的非正式仪表盘，彼此之间毫无可比性。领导层无法回答一个基本问题：我们十项战略平台投资中，究竟哪一项真正让软件交付得更快。解决办法不是增加更多指标，而是精简出更好的指标：该组织定义了一套共享的、由决策驱动的DORA指标核心（主题 2.10），在各处均从同一套流水线数据中以相同方式计算，退役了四十个团队专属的仪表盘，并在两个季度内终于能够在共同的基础上比较各投资领域。

政府。 一家国家税务机构的数字服务团队被一个监督委员会要求证明一项多年现代化项目的投资回报。该团队现有的指标完全是内部的、以活动为基础的：完成的故事点、结束的冲刺。这些都没有回答委员会真正的问题。团队转而构建了一套小型的结果指标：解决公民申报问题的中位时间、数字渠道采用率，以及新系统中的逃逸缺陷率，并以文档化的方法论按季度上报这些数据。委员会的问题从”证明你们在工作”转变为”我们如何在下一个机构复制这个做法”，而这正是一套选得好的指标应当产生的结果。

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

刻意衡量的回报是决策质量。一个能够拿出证据说”平台投资之后我们的交付周期改善了30%“的组织，能够为这笔投资辩护、重复有效的做法、停止无效的做法。而一个依赖轶事的组织无法自信地做到这些，结果每个预算周期都要重新打同样的官司，因为没有人能指出一个双方都信任的数字。

衡量的成本不在仪表盘本身，而在于持续的自律：埋点、定义的维护，以及本主题所建议的定期剪枝。这份总拥有成本是真实存在的，但相较于另一种选择，一个大型组织在数百万美元的技术决策上，依据的是房间里谁最能言善辩，这份成本是温和的。一个指标项目的回报不在指标本身，而在于因为它而变得更好的那些决策。

反模式与陷阱

衡量工具能导出的一切： 把仪表盘变成噪声，并在毫无相应决策价值的巨大表面上招致操纵。
没有指明决策的指标： 只是消耗维护精力、却对任何人都毫无可行动价值的装饰。
从诊断性用途悄然漂移到评价性用途： 摧毁一个数字可信度的最快方式。
把指标当作事实而非假设来对待： 两年前正确的代理指标，今天可能已经错了，却无人核查。
把”没有坏数字”误当作”存在好数字”： 一个你从不查看的指标，无法告诉你任何事情出了问题。
在决定要决策什么之前就先建立衡量能力： 为寻找问题而做的埋点，浪费真正的工程时间。

成熟度模型

第一级，启动： 指标即便存在，也是临时拼凑、因人而异的，没有人能说出其中任何一个为哪个决策提供信息。
第二级，发展： 部分团队拥有一套基本指标，大多是从某个框架或工具的默认设置照搬而来，与决策没有清晰的关联。
第三级，标准化： 每个被跟踪的指标都有文档化的用途，以及明确的诊断性与评价性分类，并在整个组织中一致地应用。
第四级，管理： 指标按固定节奏对照其所支持的决策进行审查；不再值得维护的指标被退役，整套指标既衡量价值，也衡量成本。
第五级，协奏： 衡量成为一种活的能力：组织会例行地识别自己的盲点，检验其代理指标是否仍然追踪着现实，并把指标项目本身当作需要不断改进、而非仅仅维护的对象。

讨论思路

如果今天被问及，我们仪表盘上哪个指标最难以证明保留的合理性？
在过去一个季度里，我们有哪一次决策是依据指标、而非依据意见做出的？
在我们组织中，哪里的诊断性指标已经悄悄变成了评价性指标？
我们害怕衡量什么，为什么？
如果我们的指标项目明天消失，哪些决策会变得更糟？

要点回顾

衡量的存在是为了服务决策，而不是为了衡量本身而存在；一个没有附带决策的指标只是装饰。
把诊断性用途与评价性用途以书面形式分开，并留意二者之间的悄然漂移。
把每个指标都当作关于它所代表之物的假设，而非既定事实，并按节奏重新审视这个假设。
沉默，选择不衡量某件事，本身就是一个有后果的决策；要让盲点变得可见，而不是任其默认保持不可见。
指标项目的总成本是真实存在的；要明确地将其与每个指标所提供的决策价值进行权衡。

参考文献与延伸阅读

Accelerate: The Science of Lean Software and DevOps，Nicole Forsgren、Jez Humble、Gene Kim著（基于结果的工程衡量的研究基础）。
How to Measure Anything，Douglas W. Hubbard著（一个用于量化看似不可衡量之事物的通用框架）。
Measuring and Managing Performance in Organizations，Robert D. Austin著（关于衡量可能给组织带来的失灵现象的奠基性分析）。
Thinking, Fast and Slow，Daniel Kahneman著（使得未经辅助的判断成为不可靠的衡量替代品的认知偏差）。
Google的DevOps研究与评估（DORA）项目，dora.dev（本书通篇所依据的持续进行的《DevOps现状》研究）。