# 第 14 章 · 祸起萧墙

> 项目是怎么晚了一整年的？一天一天晚下来的。灾祸多半来自白蚁而不是龙卷风，因此里程碑必须具体到无法自欺。

---

LLMS 索引： [llms.txt](/llms.txt)

---

题记两句连读最有力量：索福克勒斯说"带来坏消息的人不受欢迎"，紧接着自问自答——"项目怎么会被延迟了整整一年的时间？……延迟的时间是一天天积累下来的。"

## 这一章讲了什么 {#summary}

作者先破除一个想象：人们听说某个项目进度发生灾难性偏离时，会以为它遭遇了一系列重大灾难。但通常的情形是——**灾祸来自白蚁的肆虐，而不是龙卷风的侵袭**。重大灾害其实比较好处理，因为它们伴随着压力、重组和新技术的出现，项目组往往能应付自如；真正难对付的是那种以难以察觉、却残酷无情的方式慢慢落后。

他列了一串每天都在发生的小事：关键人员生病，会议开不成；雷击打坏了大厦的供电变压器，所有机器无法启动；工厂磁盘供货晚了一周，例行测试做不了。下雪、应急任务、私人问题、跟顾客的紧急会议、管理人员来检查——这个列表可以无限延长。**每一件事都只拖延半天或一天，但整个进度就这样落后了**。

### 里程碑还是沉重的负担

控制进度从制定进度表开始，表上的每一件事叫"里程碑"，都带日期。日期的选择本质上是估计问题，很大程度依赖以往经验；而作者说里程碑的选择**只有一个原则：必须是具体的、特定的、可度量的事件，能够清晰定义**。

他给了几个反例，读起来很有既视感：编码在刚过一半时间时就已"90% 完成"；调试大多数时候都"99% 完成"；而"计划完毕"是任何人只要愿意就可以声明的事件。正面的例子则是百分之百的事件——"结构师和实现人员签字认可的规格说明"、"100% 源代码编制完成，纸带打孔完成并输入到磁盘库"、"测试版通过了所有的测试用例"。这类切实的里程碑，能澄清本来划分模糊的"计划、编码、调试"三个阶段。

他随后给出一个我觉得比"便于上级检查"更重要的判断：**里程碑边界明显、没有歧义，比它容易被老板核实更重要**。理由是：如果里程碑定义得足够明确、无法自欺欺人，很少有人会就进展弄虚作假；而里程碑一旦模糊，老板就常常收到与事实不符的报告——"毕竟，没有人愿意承受坏消息。这种做法只是为了起到缓和的作用，并没有任何蓄意的欺骗。"

他还引了政府承包商关于估计行为的两项研究，三条结论都反直觉：

1. 若在活动开始之前就着手估计并每两周仔细修订一次，那么随着开始时间临近，无论最后情况多么糟糕，它都不会有太大变化；
2. 活动期间，**过高的估计**会随着活动进行持续下降；
3. **过低的估计**在活动中不会有太大变化，一直到计划结束日期前大约三周。

最后他给里程碑定性：好的里程碑对团队其实是一项**服务**——一个可以向项目经理提出合理要求的依据；而模糊的里程碑是难以处理的负担。当里程碑没有正确反映损失的时间、并误导人们到事态无法挽回时，会彻底打击小组士气；慢性进度偏离同样是士气杀手。

### "其他的部分反正会落后"

落后一天又怎么样？我们可以赶上来——何况和我们有关的其他部分已经落后了。作者承认这种心态背后有合理成分：进取心是优秀队员和团队不可缺少的心理素质，**进取提供了缓冲和储备**，让队伍能处理常规灾祸；而对任务进行计算、对工作量进行度量，确实会对"超前"造成一些消极影响。但他随即划出底线：**仍然必须关心每一天的滞后，它们是大灾祸的基本组成元素**。

既然不是每一天的滞后都等于灾难，那怎么判断哪些偏离是关键？他的答案是唯一的：**只有采用 PERT 或者关键路径技术才能判断**。它能显示谁需要什么、谁位于关键路径上、在哪里发生滞后会真正影响最终完成日期，也能指出一个任务在成为关键路径之前还有多少余量。书里的图 14-1 就是 OS/360 的一份报告摘录——按地点、任务、日期列出状态，正是这套机制的产物。

这一节最有价值的是他引贝尔实验室 V. Vyssotsky 的一段观察，它把"计划日期"和"估计日期"分开了：

> 计划日期是项目经理的工作产物，代表了经协调后的项目整体工作计划，它是合理计划之前的判断。估计日期是最基层经理的工作产物，基层经理对所讨论的工作有着深刻的了解，估计日期代表了在现有资源和已得到了作为先决条件的必要输入的情况下，基层经理对实际实现日期的最佳判断。

由此推出一条管理纪律：**项目经理必须停止对这些日期的怀疑，把重点放在让它们更精确上**——目标是得到没有偏见的估计，而不是合乎心意的乐观估计或者自我保护的保守估计。一旦这两类日期在每个人脑海中形成清晰印象，项目经理就能预见到：如果自己在哪里不采取措施，将来就会出现问题。

PERT 图的准备是老板与向他汇报的经理们共同的职责，但需要一个小班子（1–3 人）负责它的更新、修订与报告，可以看作老板的延伸。对大型项目，这种**计划和控制小组**的价值非常可贵：它的职权仅限于询问产品线经理什么时候设定或更改里程碑、是否达到了里程碑；所有文字工作由它处理，于是产品线经理的负担减到最少——只需要做决策。作者说自己运气不错，小组由 A. M. Pietrasanta 负责，此人在设计"有效而谦逊"的控制方法上很有天赋，结果这个小组**被广为尊重，而不仅仅是被容忍**——对一个本来就很敏感的角色，这是成功。

全章落在一句评价上：对计划和控制职能做适度的技术人力投资非常值得，它的贡献方式与直接开发软件差异很大——计划和控制小组作为监督者，**明确指出了不易察觉的延迟、强调关键因素，是早期的预警系统，防止项目以一次一天的方式落后一年**。

## 我的判断 {#reading}

- 这一章解决的是第 2 章那个"进度灾难"的另一半：第 2 章解释**为什么加人无用**，这一章解释**为什么问题总是在很晚才被发现**。两章合起来才完整——灾难不是一次形成的，而是被一系列"不算灾难"的延误喂养出来的。
- "灾祸来自白蚁而不是龙卷风"这个判断，我认为是全书最实用的一句组织学结论。它意味着**风险管理的重点应该放在累积型的小事上**，而不是戏剧性的大事件；后者有压力、有资源、有注意力，前者什么都没有。
- "里程碑的清晰比可核实更重要"这一条我完全认同，而且它比表面看起来更深：模糊的里程碑不是"管理不便"，而是**在制度上为自我欺骗留了空间**。当一个人无法确定自己是否完成了什么，他倾向于选择对自己有利的解读；这不是道德问题，而是定义问题。
- 那三条关于估计的研究结论里，最让我停住的是第三条：**过低的估计在活动中不会改善，一直到结束前三周才变**。它解释了为什么"进度落后"总是突然爆发——不是突然落后，而是突然承认。
- Vyssotsky 对"计划日期"与"估计日期"的区分，是这一章的管理精髓。两者混在一起时，估计会被计划污染（"你应该能做到吧？"），从而失去预警价值。**保护估计的诚实性，比让它准确更优先**，因为没有诚实的估计，准确无从谈起。
- 计划和控制小组的定位也值得学：职权被刻意限制在"询问和记录"，不介入决策。作者说这个小角色"被广为尊重而不仅仅是被容忍"——我认为关键正在于它的谦逊：**它提供事实，不争夺判断**。
- 我对"必须用 PERT/关键路径才能判断"持一点保留。今天判断关键路径的工具已经很多（依赖图、燃尽图、关键链），形式不同，内核仍是"找出哪些延迟真的影响终点"。但作者那句话的要点是对的：**不做路径分析，就无法区分"延误"与"无关紧要的波动"**。

## 和我手上的工作有什么关系 {#relevance}

- 这一章几乎是在描述我的个人项目：单人开发没有"其他部分会落后"的借口，但仍然天天在消耗"半天到一天"的小延误，而且没有人替我记录。我以前把这些当成噪音，现在按作者的说法，它们是**大灾祸的基本组成元素**，应该被显式记下来。
- "里程碑必须具体到无法自欺"这条我打算直接落地成写作与开发上的检查点，例如"这一章的笔记四节全部写完且构建零警告"这种可判定的表述，而不是"这章差不多写完了"。**模糊的里程碑会让我对自己撒谎**，这一点我在写这个系列的过程中已经体会到了。
- 计划和控制小组在单人项目里的最小等价物是"记录 + 定期回顾"：把延误与状态码写进 `docs/sessions/`，每完成一篇就回看一次偏差。它的价值不是问责（我无人可责），而是**把不易察觉的延迟变得可见**。
- 区分"计划日期"与"估计日期"对我的用处很具体：当我给自己定下某个日期时，要分清这是"我希望的"还是"我基于现状的真实判断"。把前者当成后者，就是作者说的"合乎心意的乐观估计"。
- 那三条估计研究结论给了我一个自查方法：如果我的任务总是"感觉快完成了"，然后长时间没动，再突然延期——那就是典型的过低估计模式。**结束前三周才开始变化**是信号，不是意外。

## 一句话记住 {#takeaway}

项目不是被一场龙卷风毁掉的，而是被白蚁一天天啃空的：里程碑必须具体到无法自欺，每天的延迟都要记录，因为它们是所有大灾祸的基本组成元素。