用五熵做复盘

复盘最常见的结局，是所有人都同意「下次注意」，然后下次照旧。

原因不在于态度，在于归因方式。按责任归因的复盘，结论必然是「某个人/某个环节没做好」，而人和环节在下一个项目里会换，结论就失效了。按机制归因的复盘，结论是「某一层的不确定性没有被收敛」，这个结论可以变成下一单的检查项。

这一节讲怎么把复盘做成后者。这也是第一章最后一次用模型，用它解剖一个真实形态的失败。

三种失败的复盘会

第一种：时间线复盘。 从立项讲到上线，每周发生了什么，谁做了什么。信息很全，但没有判断。散会时大家的感受是「确实不容易」，学不到东西。

第二种：表扬式复盘。 强调「团队很拼」「客户很配合」，把问题归到外部（预算、市场、竞品）。这种复盘的功能是维护士气，不是改进方法——它有用，但不要叫复盘。

第三种：精准追责。 找到了「谁漏了那个字段」「谁答应了那个需求」。这种复盘短期有效（当事人会改），长期有害（下一个人会隐藏信息）。

三种的共同问题是：它们都在回答「发生了什么」，没有回答「哪一层的判断错了」。

诊断三问

把复盘从叙事改成诊断，只需要三个问题。

第一问：哪一层最先出现信号？

注意是「信号」，不是「问题」。信号往往很微弱，当时被当成正常波动。比如需求会上客户对某个功能说了句「这个先做着看」，这就是意图层的信号。

第二问：当时被归因为什么？

这一问是核心。同一个信号，可以被归因成「客户还没想好」（需要等）或「客户已经想清楚了，只是表达随意」（可以往前走）。两种归因导致完全不同的行动，而当时的归因往往是错的。

第三问：代价在第几层显现？

这一问把因果链闭合。信号出现在第一层，代价出现在第三层，中间隔了六周——这就是为什么跳层行为会被强化：它没有即时反馈。

三问答完，复盘结论就是一句话：「第 X 层在第 Y 周出现信号，被归因为 Z，代价在第 W 层的某件事上显现。」这句话可以直接写进下一单的检查项。

一个完整的复盘：B 项目

锦程精工的 B 项目，和 A 项目是同一个客户、同一个团队、同一个季度启动的。

B 项目做的是售后工单的自动分派。启动会上，客户的信息中心主任拿来一份四十页的方案文档，是外部咨询公司做的，说：「方案已经定了，你们按这个实现就行，六周上线。」

团队没有做需求发现。理由很充分：客户已经想清楚了，而且有文档。重新问一遍是不专业，也是不尊重。

六周后系统上线。第一周，分派准确率看起来还行。第二周，售后主管开始人工改派——系统把急单派给了正在休假的工程师，把需要现场测量的工单派给了只做电话支持的组。第三周，业务方要求停用。

验收会开了两次。第一次，业务方说「这不是我们要的」。第二次，信息中心说「方案就是这么写的」。

用三问拆这个项目：

第一问：哪一层最先出现信号？

第 2 周，团队做实现排期时发现，方案里有一条规则是「按工程师技能标签匹配」。有人问了一句：「技能标签在系统里准吗？」信息中心回答：「这个你们不用管，按方案做。」

这就是信号。它出现在现实层，但根在意图层——因为整份方案里，没有任何一句话说明「分派对了」是什么样子。

第二问：当时被归因为什么？

被归因为「实施细节，后续再确认」。这个归因在当时是合理的：客户明确说了按方案做，追问会被视为不配合。

但换个角度看，这个归因跳过了真正的问题：客户为什么要求按方案做？可能的答案有三个——他真的想清楚了；他要的是「按期上线」这个结果；他不相信供应商能想出更好的方案。三个答案对应三种完全不同的应对，而团队一个都没有验证。

第三问：代价在第几层显现？

在效果层，第九周的验收会上。因为没有成果定义，也没有考题集，「这不是我们要的」这句话无法被反驳，也无法被满足——双方都不知道「要的」是什么。

代价的形式很典型：不是系统不能用，是无法证明它该不该被接受。

如果按责任复盘，结论是「咨询公司的方案有问题」或「客户不配合」。这两个结论都对，但都不能用。

按机制复盘，结论是：

意图层在第 1 周就失守（接受了「按方案实现」而没有确认成果），信号在第 2 周的现实层出现（技能标签存疑），被归因为实施细节，代价在第 9 周的效果层显现（无考题，验收无法收敛）。

这句话可以直接变成下一单的检查项：当客户提供现成方案时，必须先回答「这份方案要让什么数字变化」，答不出来就不能进入实现。

复盘表的字段

一页足够，六个字段：

第六个字段是复盘的价值所在。没有它，复盘就只是回忆。

判据卡

第三行值得说明：复盘时要假设当时的人是理性的。如果结论是「他当时怎么这么蠢」，那多半是你还没找到他面对的真实约束。找到那个约束，才有可复用的判断。

动手练习

第一题（找漏）

以下是一份复盘记录的结论部分，它缺了诊断三问中的哪几问？

项目延期两个月，主要原因是客户需求变更频繁，以及我方对数据准备难度估计不足。改进措施：加强需求变更管理，前期增加数据评估环节。

第二题（改写）

把下面这句话从责任归因改写成机制归因，并补上检查项。

这次失败主要是测试不够充分，上线前没有覆盖关键场景。

参考答案

第一题

三问全缺，但缺得最厉害的是第二问（当时的归因）和第三问（代价的层与形式）。

「需求变更频繁」是一个现象，不是一个归因。真正的归因要回答：第一次变更时，团队把它理解成了什么？是「客户不专业」，还是「我们范围没冻结」？这两种理解导致完全不同的动作。

「数据准备难度估计不足」听起来像归因，其实还是现象——为什么估计不足？是因为没做勘察，还是勘察了但没信？前者是方法问题，后者是判断问题。

改进措施也有问题：「加强变更管理」「增加评估环节」都是流程动作，不是判断动作。它们会让流程变重，但不会让下一次的判断变准。

第二题

改写：

这次失败的机制是：效果层从未收敛。上线前团队没有考题集，判断「够不够好」依据的是内部演示（3 个场景全部通过）。信号在第 4 周出现——测试同学提出「边界情况没有样本」，被归因为「时间不够，先上再补」。代价在上线第二周显现：真实流量里有 40% 的请求属于演示中没出现过的类型，系统给出错误答案且不报错。

检查项：上线前，我们有没有一套不依赖项目组自编的考题？如果没有，演示通过能否作为上线依据？

这个改写的关键差别：原文把问题定位在「测试做得不够」（一个动作），改写把它定位在「效果层没收敛」（一个状态）。动作可以靠加班补，状态只能靠方法改。

自检清单

• [ ] 我的复盘结论只指向一层，不是三四条并列
• [ ] 我能指出信号出现的具体时间和具体的话
• [ ] 我能还原当时的归因，并承认它在当时是合理的
• [ ] 我的结论里没有「加强」「重视」「提升」这类无法执行的动词
• [ ] 我产出了至少一条可以写进下一单检查项的问句

本节为原创论述。

关于主张的边界：有些失败确实是能力问题——判断力不足、经验不够、技术方案选错。这类失败用五熵归因会失真，容易把「不会」说成「机制」。区分方法：如果同一个人在同一层反复失败，那是能力问题；如果不同的人在同一层反复失败，那是机制问题。

B 项目的后续会在第 9.4 节和第 12.3 节各回访一次：前者看它的验收为什么无法收敛，后者看它如何变成了产品团队的输入。