1.10 工程效能与开发者生产力

概述与动机

任何大型软件组织的领导者，最终都会问出某种版本的同一个问题：我们在构建软件方面是否在变得更好，我们又如何知道这一点？本章正是要诚实地回答这个问题。工程效能指的是你的组织将工程投入转化为有价值、可靠软件的能力。开发者生产力则是这枚硬币的个人和团队一面：一名开发者能够产出多少有用的成果，以及工作环境把多少时间和注意力还给了他们，而不是从他们身上夺走。

只要有人试图把这一切压缩成一个单一数字，麻烦就开始了。统计代码行数，人们就会写更多代码。统计故事点数，估算就会被夸大。统计提交数、拉取请求数或坐在桌前的时长，你奖励的就是动作而非进展。对知识工作者而言，生产力不是零件计数。一名删除了一万行死代码的开发者，或者一名花一整天结对编程以帮助队友避免一次生产事故的开发者，都完成了出色的工作，而任何简单粗暴的指标都无法捕捉到这一点。对”我们的生产力如何”这个问题，诚实的答案是多维度的，它把开发者对工作的体验当作一个真实的信号，而不是一个软性的、可有可无的信号。

随着规模扩大，这一点变得更重要，而非更不重要。在一个拥有数十个团队的企业中，微小的摩擦（一次缓慢的构建、一个不稳定的测试套件、等待两天才能拿到一个环境）会在数百名工程师身上成倍放大，累积成巨大的损失产能。在政府机构中，由于产出没有市场价格，风险在于”产出剧场”：只衡量产出了多少文档、关闭了多少工单，而公共价值却始终未被衡量。本章的目标是帮助你衡量并改善工程组织的效能以及开发者的日常体验，同时避免博弈式应对、监控和相互排名。

核心原则

生产力是多维度的。 没有任何单一数字能够捕捉它。任何被宣称为唯一度量标准的指标都是错误的。
衡量是为了消除摩擦，而不是给人排名。 度量的对象是系统，而不是个人。
多方印证。 把开发者所描述的工作体感，与系统实际记录的数据结合起来看。
开发者的体验就是数据。 反馈回路、认知负荷和心流状态都是可以度量、值得改善的。
假定任何指标都会被博弈。 用多维度和真诚的意图，设计出能够抵御古德哈特定律的度量体系。
谨慎地与成果挂钩。 效能应当逐步上升为业务价值，但不能异化为一个会腐蚀行为的目标。

建议

拒绝单一指标陷阱

首要的纪律，是拒绝把某个单一数字指定为”生产力”。代码行数、提交次数、故事点速度和记录工时，都共享一个致命的缺陷：它们衡量的是活动，而非价值，而活动是极易被夸大的。这正是古德哈特定律在起作用的体现（）当一项度量成为目标时，它就不再是一项好的度量。速度这一概念最初是作为团队自身预测的辅助工具而发明的；一旦某位经理拿一个团队的点数与另一个团队相比较，各团队就会悄悄重新调整自己的估算尺度，这个数字也就随之失去意义。当有人要求你提供一个单一的生产力 KPI 时，要把这个请求当作一个需要你重新塑造的问题，而非一个需要满足的要求。转而提供一个小型的平衡指标集，并向对方解释为什么单一数字会误导他们。

使用 SPACE 来构建你的度量体系

SPACE 框架为你提供了五个值得一并考量的维度：Satisfaction and well-being（满意度与幸福感）、Performance（绩效）、Activity（活动）、Communication and collaboration（沟通与协作），以及 Efficiency and flow（效率与心流）。SPACE 的核心要点是，你应当至少选取几个维度，永远不要只用一个，也永远不要全部选自同一类别。活动类指标（提交次数、部署次数）之所以诱人，是因为它们很容易采集，但单独使用会造成失真。把它们与一个满意度信号和一个绩效信号搭配起来，这样任何单一维度被博弈时，其他维度就会暴露出来。一个部署次数在增加、但满意度骤降、变更失败率攀升的团队，并不算更有生产力，而一套平衡的指标集能立刻让你看清这一点。

把开发者体验理解为反馈回路、认知负荷和心流

开发者体验（DevEx）指的是在这里做工程工作的感受，它比听起来要具体得多。它建立在三个可以度量、可以改善的要素之上。反馈回路指的是开发者需要等待多久才能知道某件事是否成功：本地构建时间、测试套件运行时长、代码评审的周转时间、部署时间。缓慢的反馈回路会迫使开发者不断切换上下文、空等结果。认知负荷，即一项任务所要求的全部心智投入，会在开发者为了完成一次简单的更改，却必须同时应对过多工具、无文档记录的系统和纠缠不清的依赖关系时不断攀升。心流是一种专注、高效的沉浸状态，而破碎的日程安排和持续的打断会摧毁它。当你缩短一个反馈回路、消除一个开发者原本必须记在脑子里的概念，或者保护出一段专注时间时，你就以一种任何活动计数都无法体现的方式提升了生产力。这正是平台工程通过铺好的路径和自助服务所服务的同一个 DevEx 关切（8.4 章）。

用系统指标印证主观感受

任何单一数据来源都不足以单独信任，因此要把两类数据结合起来。感知数据来自开发者本人，通过开发者体验调查获取：一份定期、基本匿名的问卷，询问他们对交付工作的信心、时间损耗在哪里，以及什么让他们感到沮丧。系统数据来自你的工具：流水线耗时、评审延迟、事件发生频率。两者相互印证、相互修正。调查能捕捉到仪表工具会遗漏的痛点，比如一个让人士气低落的待命轮值，或一个人人畏惧的遗留服务。系统指标则能捕捉到那些人们已经习以为常、不再上报的问题。当调查显示构建过程令人痛苦，而你的流水线数据也证实中位构建时间长达十五分钟时，你就获得了一项有优先级、站得住脚的投资依据。要以稳定的节奏运行这项调查，保持问卷简短，并且始终闭环（）展示因这项调查而带来的实际改变。

把 DORA 用作交付信号，而非排行榜

四项 DevOps 研究与评估（DORA）指标（部署频率、变更前置时间、变更失败率和服务恢复时间）是对你交付能力的一个强有力的、有研究支撑的解读，它把速度与稳定性配对衡量，避免任何一方被牺牲。11.5 章负责这些指标的深入探讨，11.2 章则介绍它们所衡量的交付流水线；请在那里使用它们。本章的指导重点在于如何看待这些指标。要把 DORA 当作一个团队层面的健康信号，用来显示你的交付系统是否在改善，而不是用来给团队或个人排名的记分牌。一旦 DORA 的数字出现在某人的绩效评估里，各团队就会开始拆分部署以虚报频率、隐瞒事件以保护自己的失败率，这个信号也就随之失效了。

衡量系统，绝不监控个人

这是一条你绝不能逾越的界线。把指标汇总到团队和组织层面，并用它们来发现和消除摩擦。不要搭建按提交数、工时或”生产力分数”给开发者排名的仪表盘，也不要让个人层面的遥测数据影响薪酬或晋升。监控会摧毁有效工程所依赖的心理安全感和信任，并且会教会人们去优化指标本身，而不是优化实际工作。个人的成长与评估，应当交给职业阶梯和经理对话这一套独立的、以人为本的机制来处理（1.3 章）。效能度量问的是”是什么拖慢了我们团队的速度？“，而绝不是”谁是我们最慢的工程师？”

直接向”劳作”和摩擦开刀

一旦你能看清时间流失在何处，就把它挣回来。限制效能的很大一部分，是劳作（toil）（）那种随规模增长而扩大、却不产生持久价值的手工重复性工作（9.1 章）。缓慢的评审同样是一种摩擦，因此通过更小的变更和清晰的预期来精简代码评审（2.5 章），能缩短一个核心的反馈回路。铺好的路径和自助服务平台（8.4 章）能一次性消除整类的等待和认知负荷。同时也要为技术债务编列预算（）即过去走捷径所累积的成本，它会向每一次未来的变更征税（）因为一个没有人能安全修改的代码库，才是最深的生产力黑洞。

权衡取舍：优缺点

方法	优点	缺点
单一生产力指标（代码行数、速度、提交数）	成本低、简单，能给领导一个数字	立刻被博弈；衡量的是活动而非价值；侵蚀信任
SPACE 式的平衡指标集	抵御博弈；反映真实情况	采集工作量更大；更难汇总成一个数字
DevEx 调查（感知类）	能捕捉仪表工具遗漏的真实痛点	主观；需要信任和后续跟进才能保持诚实
系统指标（DORA、流水线耗时）	客观、持续、汇总层面难以造假	对士气和情境视而不见；用于个人时危险
两者相互印证	各数据源相互修正；稳健	需要在工具和调查纪律上投入

核心张力在于严谨性与诚实性之间的取舍。单一数字容易汇报，也容易被腐蚀；丰富的多维度图景更诚实，但更难向一位忙碌的高管说清楚。解决办法是选取一个小型的平衡指标集（几个 SPACE 维度，加上一项调查，再加上 DORA 作为交付层面的解读），汇报趋势而非快照，并明确说明这些数字的存在是为了改善系统，而不是给人打分。当领导层想要”一张图”时，给他们几个互补信号的趋势图，抵住把它们压缩成一个虚假综合指标的诱惑。

与团队讨论的问题

如果明天领导要求一个单一的生产力数字，你会给他们什么？ 这个问题会暴露出你的组织是否理解这个陷阱。诚实的答案是，没有任何单一数字是安全的，你的工作是把这个请求重新塑造成一个能抵御博弈的小型平衡指标集。带上你们目前已经在汇报的指标，逐一追问：“一个精明而愤世嫉俗的团队，会如何在不真正做出更好工作的情况下，把这项指标做得更高？“如果答案很容易得出，那么这项指标一旦成为目标就是危险的。讨论你会提供什么来替代它，以及你会如何向领导层解释，为什么一个数字会误导他们去优化错误的东西。这场对话的质量，预示着度量究竟会帮助你们，还是会腐蚀你们。
你们最慢的反馈回路是什么，它每天让你们付出什么代价？ 反馈回路正是生产力悄悄流失的地方：十五分钟的构建、两天的评审等待、一个不稳定的测试套件不断侵蚀人们对每一次绿色检查标记的信任。带上开发者体验调查和流水线仪表工具的真实数据，看看感知到的痛苦和实测的延迟是否一致。用等待时长乘以有多少开发者、以多高频率遭遇它，估算出每日的成本，投资的理由通常就会自然显现。决定先缩短哪个回路，由谁负责修复。一个说不出自己最慢反馈回路是什么的团队，还没有开始衡量真正重要的东西。
你们的度量在哪些地方有可能让人感觉像是监控，你们将如何防止这种情况？ 度量系统与监控个人之间的差别，就是信任与恐惧之间的差别，而这条界限很容易在不知不觉中被跨越。逐一审视每一个仪表盘和报告，问一问它们中是否有任何一个可以用来给某个个人排名，或输入到绩效评估中。明确决定哪些数据始终保持汇总状态、哪些始终保持匿名、哪些是绝对禁区，然后向被度量的团队公开说明这一点。在企业和政府场景中，监督和审计压力很大，深挖到个人层面的诱惑始终存在，因此这道防线必须是一条明确宣示的原则，而不是一种美好的期望。如果开发者相信这些数字会被用来对付他们，他们就会去优化这些数字，而真相就会随之消失。
我们上一次询问开发者工作感受时，因此发生了什么改变，他们最终知道了吗？ 一次没有产生任何可见行动的调查，会教会开发者不再诚实作答，因此第二次悄无声息的调查得到的回复会比第一次更少、更含糊，而你所依赖的这个工具，恰恰会随着你扩大它的使用规模而逐渐失效。对大型组织而言，这种浪费会不断累积：数百人花时间反映摩擦，一份报告流传开来，却什么都没有真正落地。带上上一次调查排名前三的发现、每一项发现所触发的具体工作，以及你如何把结果反馈给提出问题的那些人。权衡两种相互竞争的做法（）回应声音最大的抱怨，还是回应最普遍的问题（）因为这两者往往是不同的问题。在调查疲劳和咨询过载已经很严重的企业和政府场景中，要把闭环反馈当作一项治理承诺：明确谁负责回应，公开有哪些改变，并接受一个事实（）一次没有回应的调查，比根本不做调查更糟糕。
我们如何在不建立一个惩罚诚实的排行榜的前提下比较各个团队？ 大型组织的领导者自然想知道哪些团队蓬勃发展、哪些团队陷入困境，但仅凭原始的速度、部署频率或 DORA 数字给团队排名，忽略了一个事实：一个受到严格监管的支付团队，与一个从零开始的原型团队，生活在完全不同的世界里。这里存在真实的相互竞争的考量：你确实需要发现陷入困境的团队，并推广行之有效的做法，但一旦比较变成了记分牌，各团队就会重新调整估算、隐瞒事件、拆分部署来维护自己的排名。带上你们组织中团队情境存在差异的具体例子，并提出一项建议：把每个团队与它自身随时间推移的轨迹相比较，而不是与邻近团队相比较。在审计和监督压力强烈推动跨团队排名的企业和政府场景中，要提前商定哪些内容可以被比较、哪些内容永远只能作为单个团队的趋势来解读，以及谁有权拒绝一次不公平的比较。
我们如何在不把交付指标异化为腐蚀性目标的前提下，把效能与真实成果连接起来？ 一项从未上升为价值的效能度量，在领导层看来就像是自我陶醉，但一旦前置时间或部署频率这样的交付信号成为绩效评估中的目标，团队就会去优化这个数字，而抛弃它本应代表的那个成果。对大型组织而言，这种张力尤为尖锐，因为高管希望看到一条从工程投入到业务成果的清晰路径，而诚实的路径往往是混乱且滞后的。带上你们当前的成果度量指标、你打算与之挂钩的交付信号，以及一份坦诚的说明：一旦这些指标成为目标，各自会如何被博弈。权衡两种拉力（）一个领导层可以反复讲述的简单故事，与一幅能抵御失真的真实图景。在政府机构或一个没有市场机制的内部平台中，由于没有收入可以锚定价值，要准备好把成果定义为服务可靠性、修复的周期时间和公共利益，而不是原始的活动量，并要准备好向可能更偏爱易于计数的成果的监督机构，为这一选择辩护。

行业视角

初创企业。 只有寥寥几名工程师、跑道有限，因此完全跳过仪表盘，只衡量变化最快的两件事：一份十道题的开发者体验调查和基本的流水线耗时。你们最大的生产力风险是缓慢或不稳定的测试套件，以及持续的上下文切换，因此找出最糟糕的反馈回路，把它缩短，然后继续前进。不要搭建一套没有人负责运行的度量计划，因为一次诚实地讨论时间损耗在哪里的谈话，胜过任何你之后还得维护的工具。

小型企业。 没有专职的度量专家，预算也紧张，因此要依靠你现有工具已经记录下来的数据：来自你已经付费使用的系统的构建时间、评审延迟和事件计数。购买一个轻量级的调查工具，而不是自己搭建一个，并抵制供应商推销个人生产力仪表盘的诱惑，那会消耗你消耗不起的信任。把整个工作的定位设定为：为一个没有余力浪费任何人一天时间的小团队消除摩擦。

企业。 在数十个团队之间，好处是能在规模上重新赢回产能，而危险在于一个中央仪表盘会悄悄滑向给人排名。要将一套平衡的计划标准化（一份季度性的 DevEx 调查、几个 SPACE 维度，以及作为团队级交付趋势解读的 DORA），并对其加以治理，确保绝不采集个人层面的遥测数据。把每个团队与它自身的轨迹相比较，依据数据揭示出的摩擦来论证平台投资（8.4 章），并授权一位负责人拒绝任何可能演变成排行榜的指标。

政府。 由于产出没有市场价格，加上强烈的监督压力，走向”产出剧场”（统计文档数量和已关闭的工单）的拉力始终存在，而在审计下监控具名个人的拉力则更为强烈。转而衡量成果和交付能力：一项服务发布修复的速度有多快、它的可靠性如何，以及员工和承包商通过一份匿名调查所反映出的工作体验。对公务员和承包商采用同一套系统层面的基准来衡量，公开这项度量的目的，并做好准备向立法机构论证：一个团队层面的交付趋势，比任何个人分数都更能诚实地反映公共价值。

示例

初创企业。 一家二十人规模的初创公司发现，尽管每个人都很忙碌，交付速度却慢了下来。工程负责人没有安装一个生产力仪表盘，而是运行了一份十道题的 DevEx 调查，并调取了基本的流水线耗时数据。调查结果和数据相互印证：测试套件耗时二十二分钟，且会随机失败，因此人们会把变更打包在一起、在等待期间不断切换上下文。团队花了两周时间修复不稳定的测试并将套件并行化，把耗时缩短到四分钟。部署频率随之自然上升，下一次调查中满意度也跃升，而这一切的实现，从未依靠给任何人排名或打分。

企业。 一家拥有四十个工程团队的银行，希望为持续投资于内部平台找到依据。平台团队采用了一套平衡的度量计划：面向所有团队的季度性 DevEx 调查、SPACE 式的信号，以及在团队层面作为交付健康趋势解读的 DORA 指标（11.5 章）。关键在于，他们通过把每个团队与它自身随时间推移的轨迹相比较，而非相互比较，来公平地进行基准评估，因为各团队的情境差异极大。数据显示，处于铺好的路径（8.4 章）之上的团队，能在几天而非几周内完成新工程师的上手，并反映出低得多的认知负荷。这项证据被定位为在数百名开发者身上重新赢回的产能，为该平台争取到了又一年的资金。个人层面的遥测数据被刻意地从未采集。

政府。 一家联邦数字服务机构必须向立法机构证明，其工程支出创造了价值，而这是在一个没有市场价格来衡量产出的环境中进行的。它拒绝了”产出剧场”（统计文档数量或已关闭的工单），转而衡量成果和交付能力：各项服务能多快发布一次修复、它们的可靠性如何，以及员工及其承包商通过一份匿名调查所反映出的工作体验。DORA 式的交付信号显示出现代化改造是否真正提升了吞吐量和稳定性，并与公共成果而非原始活动量挂钩（11.5 章）。由于度量从不给个人排名，并且承包商员工和公务员采用同一套系统层面的基准来衡量，该机构避免了拖垮此类工作的监控和士气问题，并为监督机构提供了对价值的诚实解读。

商业案例：动机、投资回报率与总体拥有成本

度量并改善效能所带来的回报，是重新赢回的产能，而在大规模场景下，这个数字相当可观。微小的摩擦会在一个大型组织中成倍放大：一次十分钟的构建，如果被一百名工程师每天多次触发，一年下来就是数千个工程师工时的空等。缩短这个回路，你就在不招聘任何人的情况下，增加了实实在在的产能。这里的主导性投资回报，与平台工程中的情形相同（8.4 章）：把昂贵的工程时间从等待和劳作中重新导向有价值的工作。

总体拥有成本是适度但真实存在的。你要为调查工具及运行它所需的纪律付费，为流水线的仪表化付费，还要为管理层解读趋势并据此行动所投入的注意力付费。对投资回报率而言，更大的风险在于度量做得不好。一个被博弈的单一指标，或一套监控计划，都可能产生负回报：花上几个月优化一个数字，而真实成果却停滞不前，再加上信任的腐蚀，使得未来的每一次改变都变得更加困难。完全不做度量的代价是弥散而巨大的：摩擦和劳作会在无形中累积，资深工程师会在本可避免的浪费中逐渐倦怠，而领导层也无法判断投资是否真正起了作用。向领导层论证时，要把它定位为杠杆和诚实：一套小型、可信、平衡的度量计划，能找出一支庞大的员工队伍在哪里流失时间，而一旦你依据第一项发现采取行动，它就会多倍地收回自身的成本。

反模式与陷阱

单一生产力指标。 任何单一数字（代码行数、速度、提交数、工时）一旦成为目标，当天就会被博弈。
给个人排名。 排行榜和个人”生产力分数”会摧毁信任，并教会人们去优化指标本身。
把度量当作监控。 细粒度的个人遥测数据被输入绩效评估，会侵蚀有效工作所需的心理安全感。
调查之后没有下文。 询问开发者工作感受之后却什么都不改变，会教会他们不再诚实作答。
比较团队的原始数字。 团队所处的情境各不相同；跨团队的速度或 DORA 比较会惩罚诚实、奖励博弈。
产出剧场。 统计产出的制品数量（文档、工单、已发布功能），而真实成果却始终未被衡量，这在没有市场价格的场景中很常见。
把 DORA 用于绩效评估。 一旦交付指标给人打分，各团队就会隐瞒事件、拆分部署，这个信号也就随之失效。

成熟度模型

第 1 级，启动： 生产力凭直觉判断，或依据一个容易被博弈的单一指标，如代码行数、速度或工时。度量是随意、被动的，摩擦是不可见的，抱怨只是零星轶事，没有人能说清组织是否在变好。
第 2 级，发展： 一些团队采用了基本的实践：几项指标（通常是活动计数），以及偶尔进行的开发者体验调查。各团队之间的做法并不一致，数据被采集了却很少被采取行动，原始的跨团队比较开始悄悄出现，也没有一条共同的原则来保护个人不被排名。
第 3 级，标准化： 一套平衡的度量计划已在全组织范围内形成文档并得到落实，使用 SPACE 式的维度、定期的 DevEx 调查，以及作为交付信号的 DORA（11.5 章）。指标依据政策汇总到团队层面，个人从不被排名，发现的问题会推动具体的工作去缩短反馈回路、削减劳作（9.1 章）。
第 4 级，管理： 该计划相对于基线被度量和控制。反馈回路耗时、调查得分和 DORA 趋势都有商定的目标，并被持续跟踪；每个团队都与自身的轨迹相比较，而非与邻近团队相比较；平台和劳作削减方面的投资，都依据重新赢回产能的前后对比数据来论证其合理性；任何信号出现回退都会触发复核，而不会悄无声息地被忽略。
第 5 级，编排： 度量是被信任的、常态化的、可自适应的。感知数据与系统数据相互印证，趋势数据推动持续改进，摩擦和认知负荷被主动搜寻和消除，度量指标集本身也会随组织的变化而修订，效能与业务成果和公共成果实现深度融合，同时不允许任何一项指标异化为腐蚀性的目标。

讨论思路

你们目前的哪些指标，一个愤世嫉俗的团队可以在不真正做出更好工作的情况下把它们夸大，你会用什么来替代它们？
如果你只能缩短整个组织中的一个反馈回路，哪一个能带来最多重新赢回的产能？
当各团队的情境不同时，你们如何公平地对众多团队进行基准评估，同时又不建立一个惩罚诚实的排行榜？
度量系统与监控个人之间的界线在哪里，你们组织中由谁有权来维护这条界线？
在一个没有市场价格衡量产出的场景中，比如政府或一个内部平台，你们如何衡量真实价值而非活动量？
你会向一名开发者展示什么，来证明这个季度的调查确实带来了改变？

关键要点

工程师的生产力是多维度的。拒绝把任何单一数字（代码行数、速度、提交数、工时）当作唯一的度量标准，因为古德哈特定律保证它一定会被博弈。
使用 SPACE 框架（满意度与幸福感、绩效、活动、沟通与协作、效率与心流）把多个维度结合在一起，使任何单一维度都无法独自被博弈。
开发者体验归根结底体现在反馈回路、认知负荷和心流之中。缩短回路、消除负荷是任何活动计数都无法体现的真实生产力提升。
用来自 DevEx 调查的感知数据，与来自你工具的系统数据相互印证；两者相互修正。
把 DORA 指标当作团队层面的交付信号，而非排行榜；其深入内容见 11.5 章，相关流水线见 11.2 章。
衡量系统，绝不衡量个人。把数据汇总到团队层面，将评估留给 1.3 章中独立的、以人为本的渠道，绝不让度量异化为监控。
把重新赢回的时间用于削减劳作（9.1 章）、加快代码评审（2.5 章）和铺设道路（8.4 章）。把效能与业务成果连接起来，同时不让任何一项指标异化为腐蚀性的目标。

参考文献与延伸阅读

Nicole Forsgren、Margaret-Anne Storey、Chandra Maddila、Thomas Zimmermann、Brian Houck 与 Jenna Butler，“The SPACE of Developer Productivity”（ACM Queue，2021 年）：多维度框架的出处。
Abi Noda、Margaret-Anne Storey、Nicole Forsgren 与 Michaela Greiler，“DevEx: What Actually Drives Productivity”（ACM Queue，2023 年）：反馈回路、认知负荷与心流。
Nicole Forsgren、Jez Humble 与 Gene Kim，Accelerate: The Science of Lean Software and DevOps（DORA 指标及其研究基础）。
DORA，Accelerate State of DevOps Report（年度报告）：支撑这四项指标的持续研究项目。
Betsy Beyer、Chris Jones、Jennifer Petoff 与 Niall Richard Murphy 编，Site Reliability Engineering（劳作及其消除）。
Matthew Skelton 与 Manuel Pais，Team Topologies（把认知负荷作为一等重要的设计考量）。
Mihaly Csikszentmihalyi，Flow: The Psychology of Optimal Experience（心流状态的起源）。
Tom DeMarco 与 Timothy Lister，Peopleware: Productive Projects and Teams（专注、打断以及生产力中以人为本的一面）。
Goodhart, C. A. E.，“Problems of Monetary Management: The UK Experience”（1975 年）：古德哈特定律的出处；另见 Marilyn Strathern 被广泛引用的表述方式。
美国政府问责局（GAO）关于绩效度量的指南：在非市场化的公共部门场景中衡量价值。