复盘 GRAI：目标、结果、分析、改进
复盘不是追责会，而是把一次性经验变成下一次可用的判断。
结论先行：按 Goal（目标）、Result（结果）、Analysis（分析）、Insight（改进）四步走，结束时最多留三条有人负责的改进项。
复盘容易开成两种会：一种是轮流汇报，最后变成总结会；另一种是找问题，最后变成追责会。GRAI 的价值在于给讨论一个固定顺序：先对齐目标，再看结果，然后分析差异，最后只留下能执行的改进。
四步分别做什么
| 步骤 | 要回答的问题 | 产出 |
|---|---|---|
| Goal 目标 | 当初承诺做到什么 | 原定目标与成功标准 |
| Result 结果 | 实际做到了什么 | 结果、数据与偏差 |
| Analysis 分析 | 差异是怎么产生的 | 可验证的根因与证据 |
| Insight 改进 | 下一次要改什么 | 不超过三条改进项 |
分析阶段的两个规则
- 先摆事实再讨论感受：数据、时间线、会议记录先放到同一页。
- 根因必须可验证：写「需求变更没有同步到测试」，而不是「沟通不到位」。
- 允许保留做对的事：只列问题的复盘会让团队下一次更保守。
- 区分信息不足与执行失误：前者改流程，后者改检查点，处理方式不同。
从空话到可验证的根因
- 空话：这次延期主要是沟通不到位。
- 追问：哪一次信息没有传达到？
- 事实：设计稿在开发启动后才更新，测试仍按旧版本用例执行。
- 根因：缺少「设计变更后重新发版并通知测试」的固定动作。
- 改进：在设计变更流程中增加一条通知检查点，由设计负责人确认。
改进项怎么写才算落地
- 每条改进只对应一个动作，不写「提升协作效率」这类方向。
- 写清负责人、截止时间和验收标准，三者缺一不可。
- 控制在三条以内，多了就没有优先级。
- 两周后设一次跟进，未完成的说明原因，而不是默认自动完成。
复盘会怎么组织
会前把目标、结果数据和关键时间线发给参会人，要求每人先写一条事实和一条疑问；会中按 GRAI 顺序推进，主持人负责把跑题拉回分析；会后当天发出改进项与负责人。参会人控制在真正参与执行的范围，人越多，越容易变成轮流汇报而不是复盘。会议时长建议控制在 90 分钟以内，超过这个长度，注意力下降，讨论容易重复。
关于情绪： 如果项目刚结束、团队情绪仍然激烈，可以先做一次匿名的事实与感受收集，隔几天再开正式复盘。复盘要讨论机制，不评价动机；一旦开始猜测「他是不是不上心」，讨论就会转向防御。