团队的执行节奏需要在周期末完成复盘，避免问题只被罗列，最后又落到对个人的追究上。这里记录我把 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。
- 验证标准是否在行动开始前确定。
- 会上有没有讨论对某个人的评价：有，说明复盘已经偏成了员工评价会议，要拉回来。
五条中任一条无法满足时，应重新检查复盘结论和改进项。
小结
十几人的团队与小团队可使用相同的复盘工具，但需要显式检查事实对齐、原因分析、改进项、验证和跟踪是否完成。缺少任一步骤，复盘都难以形成改进闭环。
本系列从职责变化、目标、沟通、授权、辅导、执行节奏写到复盘，记录了团队规模扩大后如何将日常默契转化为明确机制：目标拆解到个人并确认边界，信息通过一对一和例会获取，授权前明确范围，复盘保留范围、事实、改进项和跟踪。培训提供了这些机制的框架，具体是否适用仍需在实践中持续检查。
