导言

本书是一本关于如何把软件工程衡量好的实用指南，面向任何团队，从五人的初创公司，到拥有数千名工程师的企业，或是要对照法定绩效框架汇报的政府机构。它之所以存在，是因为大多数关于指标的建议，要么是缺少运营细节的框架概述，要么是工具供应商的功能清单。本书试图两者都不是：它对该衡量什么态度明确，对每项指标如何被操纵直言不讳，并且对如何运营一套团队信任而不是畏惧的指标项目务实可行。

这本书写给谁

主要读者是决定组织衡量什么的人：工程负责人、Staff 与 Principal 工程师、平台与 DevOps 团队，以及项目与产品经理。次要读者是所有想弄明白一块仪表盘背后的逻辑（有人要求他们让它的数字动起来），或想质疑一项已不再服务于其目的的指标的工程师。你不必从头读到尾。每个主题都自成一体，先陈述原则，以实用要点、成熟度模型和参考文献收尾。

本书如何组织

本书分为部分（整数）和主题（小数）。主题 N.0 介绍每个部分，并说明其各个主题如何相互关联；主题 N.1、N.2、… 对各个主题做深入探讨。

第 1 部分，度量的基础： 为什么要度量，古德哈特定律与操纵心理，选择成果而非产出，治理与所有权，数据来源，以及每个指标项目都需要的统计素养。
第 2 部分，流动指标： 流动框架、流动项目与五项流动指标、周期时间、排队论、经典的精益价值流指标、拉取请求与代码评审指标，以及作为参考主题的 DORA 框架。
第 3 部分，开发者体验与 SPACE 框架： SPACE 框架及其五个维度，以及如何开展开发者体验调查而不把它变成人气竞赛。
第 4 部分，代码与质量指标： 复杂度，测试覆盖率与有效性，代码变动与热点，静态分析，技术债务和文档。
第 5 部分，产品与业务指标： 逃逸缺陷，功能采用，客户与业务成果，单位经济，以及投资回报。
第 6 部分，可靠性、运维与安全指标： SLI、SLO 与错误预算，事件指标，值班与容量，以及安全与漏洞指标。
第 7 部分，AI 时代的指标： 生成式 AI 的范式转变，如何衡量 AI 辅助开发，指标膨胀的风险，以及产出变得廉价时，为什么成果遥测会成为北极星。
第 8 部分，建立指标项目： 设计仪表盘，自建还是购买，推行指标而不滋生恐惧，成熟度模型，以及分阶段的采用路线图。
第 9 部分，附录： 术语表，指标定义与公式参考，检查清单，模板，成熟度自评，参考文献和索引。

指导原则

八项原则构成本书的主干：

一项度量一旦变成目标，就不再是好的度量。 从一开始就针对古德哈特定律做设计，而不是等扭曲出现之后。
成果高于产出，产出高于活动。 让每一组指标都偏向对客户或业务发生了什么改变，而不是团队产出了什么或有多忙。
每一项带有激励的指标都需要一道护栏。 把速度与质量配对，把吞吐量与稳定性配对，永远不要孤立地追逐某一个数字。
衡量系统，而不是衡量人。 把过错个人化的指标会损害信任并招致操纵；揭示系统约束的指标则招来改进。
能用工具埋点就不靠自我报告，不能的才用自我报告。 部署次数来自流水线；满意度来自询问。
指标要么赢得自己的位置，要么退休。 仪表盘上的每一个磁贴都要消耗注意力。有意识地修剪。
定义比仪表盘更重要。 两个对“前置时间”计算方式不同的团队，花在争论数字上的时间比据此行动的时间更多。
生成式 AI 是重新审视的理由，而不只是重设基线。 产出变得廉价时，围绕产出量构建的指标需要的不只是新目标，还有新护栏。

贯穿始终的主题

古德哈特定律是贯穿本书每个部分的一个主题，而不只是主题 1.2。每个指标家族的主题都会点明所讨论的指标如何被操纵，以及哪道护栏能抓住它。政府和企业的汇报义务（指标可能具有法律或合同分量的地方）在全书中被当作设计的输入，而不是局限于单个主题的事后补充。

如何使用

分阶段采用；不要一次性把仪表盘丢给一个从未有过仪表盘的团队。从痛点最大的地方开始，用每个主题的成熟度模型诚实地给自己定位，并让采用路线图（主题 8.5）来排定工作顺序。目标不是一面图表墙。目标是一个能够用证据说明自己所做之事是否有效，并且足够信任自己的数字而据此行动的组织。