团队的执行节奏需要在周期末完成复盘，避免问题只被罗列，最后又落到对个人的追究上。这里记录我把 PDCA 和 5 WHY 用在团队复盘中的做法。
触发我写这篇的是一次不算成功的复盘。前阵子一次交付出了偏差（待确认：补充这次偏差的项目背景），复盘会开完了，纪要里记了几条问题，大家也都表了态，但下一个周期同类问题又冒了出来。回头看那次纪要，问题有两类：记下来的多是”某某环节没对上”这种结果描述，没有原因；定的改进动作是”以后加强沟通”这种没法检查的话。等于会议开了，闭环没闭上。
带小团队那几年，复盘没有这个问题。三四个人出了问题，当场几个人就聊清楚了，谁改了什么、以后注意什么，说完大家都记得，改进靠自觉就生效，不需要纪要，更不需要跟踪。这套随口的做法搬到 10 多人的团队就不灵了：参与的人多，不当场记下来的共识散会后各有版本；改进项没有负责人和检查点，散会就等于没有下文。那次失败的复盘让我确认了一件事：在这个团队里，复盘必须显性化，有范围、有事实、有改进项、有跟踪，少一样就会退回罗列问题和追究个人责任。
工具现成。2 月记过 PDCA 循环和 5 WHY 分析法，定义和丰田的例子都在那两篇里。这篇只补一件事：这两个工具放到团队复盘场景里的使用条件。
先圈定复盘范围
复盘的第一个动作是选题目。适合复盘的是影响明确的一件事：一次项目延期、一次线上问题、一次协作失误。不适合的是”最近团队状态不太好”这种弥漫性的题目，它没有边界，讨论两小时也落不到任何动作上。
题目定了，开会之前要收材料。至少要凑齐三样：事情的时间线，过程中的事实数据，当时关键决策的记录（谁在什么时间按什么信息定的）。没有这些，复盘会就变成记忆对账，每个人记的版本都不一样，讨论先从”当时到底怎样”开始吵，后面就没时间了。
参会范围也收一收。直接相关的成员、协作方的接口人到场就够了，不扩大。人多了，发言趋于谨慎，事实层的信息反而出不来。（待确认：补充当时复盘会的实际参会范围。）
先还原事实，再谈原因
开会先做一件事：把影响和时间线铺在桌面上，所有人先对事实达成一致，再开始分析。这一步省不得，因为后面所有讨论都建立在”发生了什么”上，事实没对齐，原因分析就是各说各话。
分析原因时，培训里给的分法是三层：直接原因、过程缺口、系统性条件。直接原因是”这次改动引入了问题”；过程缺口是”这个改动没有经过评审”；系统性条件是”这类改动一直没有规定检查点”。复盘的价值在后两层。只停在直接原因，改法是”下次小心”，小心是没法检查的。
这一步最容易犯的错，是从结果倒推个人动机。结果不好，就开始猜”是不是没上心""是不是能力不够”。倒推动机有两个问题：一是无法验证，对方不承认就僵在那；二是把改进方向引到人身上，而人恰恰是管理者最难直接改的东西。培训里的说法是，先假设流程有问题，把流程、工具、职责、检查点都排一遍，确实找不到，再谈人的问题。我后来复盘都按这个顺序走，大部分情况走不到”人”那一步就有结论了。
用 5 WHY 追到能改的那一层
5 WHY 在团队复盘里的用法，和旧文里说的有一点差别：不追求机械地问满五次，追到”团队能通过流程、工具、职责或检查点改变”的那一层，就可以停。
拿一次延期举例（角色化描述，细节从略）。为什么延期？联调时发现接口对不上。为什么对不上？两边各自按自己的理解实现。为什么理解不一致没被发现？开发过程中没有对齐过接口定义。为什么没有对齐？项目计划里没有这个环节。到这里就能改了：加一个接口确认的检查点。再往下问”为什么计划里没有这个环节”，答案多半是”当时没想到”，这一层改不动，追问就没有意义了。
追问的方向也要留意，对着事，不对着人。“你为什么没检查”问出来的是辩解，“这个环节为什么没有被检查到”问出来的是流程缺口。同样一个为什么，主语换成事，讨论才进行得下去。
另外旧文里提过 5 WHY 的三个层面：为什么会发生、为什么没被发现、为什么流程上没防住。复盘时拿这三个层面自查一遍很有用。只回答第一个层面的复盘，改的是这一次；三个层面都走到，改的才是这一类。
按 PDCA 写改进项
分析完不落行动，复盘就只是一次讨论。改进项按 PDCA 的要素写全：目标是改掉什么，动作是具体做什么，负责人是谁，完成时间是什么，验证方式是什么。
负责人要落到主 R，就是 RASCI 里说的每件事尽早确定谁负责。“大家一起注意”等于没有负责人。
验证方式是最容易漏的一项，必须在行动开始之前定。比如改进项是”加接口确认环节”，验证方式可以是”下一个项目联调时接口返工的次数”。不定验证方式，到期只能凭感觉说一句”应该有改善”，这种结论过不了 Check。
还有一个约束：改进项必须能放进下一个周期的 Plan 里。上一篇说过，团队场景里 Action 要靠节奏固定下来，改进项不进入下一周期的计划，就不会有人检查它，闭环断在最后一步。
数量上也收一收。一次复盘出一两个能落实的改进项，比列十条没人跟的强。我那次失败的复盘，纪要里列了六七条，一条都没跟踪，等于零。
改进项要回到节奏里跟踪
改进项定完要进例会跟踪。每一次复盘的第一项议程，应该是先看上一轮改进项的执行情况：做了没有，生效没有。
跟踪结果要公开，包括无效的结果。哪个措施起了作用，哪个没起作用、准备怎么调，都摆到桌面上。无效的结果不公开，团队成员会默认复盘结论没人看，下次开会就只剩应付。这也回到第 9 篇说的信号：同一类问题反复出现，说明闭环断在了 Action，而复盘恰恰是 Action 的入口。小团队里这一环靠大家天天见面就能兜住，谁答应了什么彼此都看得见；现在只能靠例会这个固定的场合。
复盘质量检查清单
复盘结束、文档归档之前，我拿这几条检查一遍：
- 事实是否可核对：时间线和数据有来源，还是凭记忆口述。
- 原因是否指向可改变的条件：落在流程、工具、职责、检查点上，还是停在”谁没注意”。
- 每个改进项是否有主 R。
- 验证标准是否在行动开始前确定。
- 会上有没有讨论对某个人的评价：有，说明复盘已经偏成了员工评价会议，要拉回来。
五条里有任何一条过不了，这次的复盘结论就要打问号。
小结
复盘在十几人的团队里和在小团队里，用的工具是一样的。差别在完成度：小团队里事实对齐、原因分析、改进项、验证、跟踪这五步由面对面自然走完，现在每一步都要显式检查有没有跳过。那次失败的复盘让我确认的就是这个——跳过一步，复盘就退化成一场会。
这篇是这个系列的最后一篇。从 4 月写职责变化开始，目标、沟通、授权、辅导、节奏、复盘一路写下来，回头看这 10 篇，做的其实是同一件事：把过去小团队里靠默契维持的东西，一项一项替换成显性机制。目标以前靠共识，现在拆到个人、确认边界；信息以前靠高频的日常同步，现在靠一对一和例会；决策以前近乎全权放手，现在先说清授权范围再交出去；复盘以前随口就做，现在有范围、事实、改进项和跟踪。培训提供的是替换用的框架，每失效一项隐性做法，就有一个现成的机制可以接上。替换完不等于就做对了，这些做法合不合适，要在实践中继续校对，跑出了值得记的变化再写。
