项目复盘：从事实到改进，而不是找人负责
按目标、结果、根因、改进四步走，结束时最多留下三条有人负责的改进项。
适用场景
适用于已经结束的项目、重大里程碑或一次明显偏离预期的专项工作。复盘的价值在于把一次性经验变成下次可用的判断，因此需要先摆事实，再讨论原因，最后只留少数能落地的改进。如果项目刚结束、团队情绪仍然激烈，可以先做一次轻量的情绪与事实收集，隔几天再开正式复盘会，避免把复盘开成追责。
涉及角色
- 复盘主持人
- 项目负责人
- 核心成员
- 改进项负责人
前置输入
开始之前先把这些材料放到同一个位置。缺哪一项，先补哪一项，不要让步骤表替你承担信息缺口。
- 原定目标、成功标准与承诺时间
- 实际结果、关键数据与偏差
- 项目时间线与主要转折点
- 参与者的反馈与一手记录（聊天、邮件、会议纪要）
步骤表
步骤 · 动作 · 产出 · 负责人 · 时限| 步骤 | 动作 | 产出 | 负责人 | 时限 |
|---|---|---|---|---|
| 1 | 会前收集事实与数据，避免现场凭记忆争论 | 事实与数据材料 | 复盘主持人 | 会前 2 小时 |
| 2 | 发议程并收集匿名反馈，提前暴露分歧 | 议程与反馈汇总 | 复盘主持人 | 会前 30 分钟 |
| 3 | 对照目标与结果，只讨论差异最大的部分 | 差异清单 | 主持人 + 项目负责人 | 会中 30 分钟 |
| 4 | 按「现象—假设—证据」分析根因，避免归因到个人态度 | 根因结论 | 全体参会人 | 会中 40 分钟 |
| 5 | 选出不超过 3 条改进，绑定负责人、截止时间与验收标准 | 改进清单 | 全体参会人 | 会中 20 分钟 |
| 6 | 两周后检查改进落地情况，未完成的重新评估 | 改进跟进记录 | 改进项负责人 | 会后 2 周，15 分钟 |
在手机上可左右滑动查看完整表格；负责人和时限建议换成你们团队的真实角色与节奏。
关键检查点
每一步之间停一下，用这几条判断是否真的可以进入下一步。检查点不通过时，补信息比赶进度更省时间。
- 讨论基于数据与记录，而不是印象和情绪。
- 根因可以被验证，写清支持证据与反证条件。
- 保留了做对的事，避免复盘只剩问题清单。
- 改进项不超过 3 条，每条有负责人、时间与验收标准。
- 设定了跟进时间，复盘报告不会归档后失效。
常见失败模式
| 常见表现 | 怎么调整 |
|---|---|
| 复盘开成批斗会，大家开始防御和互相指责。 | 主持人先声明「对事不对人」，根因必须带证据，不允许评价动机。 |
| 根因写成「沟通不到位」「执行力不够」这类空话。 | 追问到可验证的机制：哪次信息没有同步、哪个节点没有检查。 |
| 改进项列了十条，两周后一条也没动。 | 限制三条以内，当场确认负责人和时间，并设跟进日期。 |
一页纸 SOP
下面的清单可以整段复制或下载，贴进团队文档、打印出来或放进任务工具。 跑过几次后，把不适用的条目删掉，把反复卡住的地方补成一条新的检查点。
可整段复制 勾选项可直接改成你们团队的检查清单
# 项目复盘 SOP（一页纸）
## 会前 3 天
- ☐ 收集目标、结果、数据与时间线
- ☐ 找出 3 个最大的差异点
- ☐ 发匿名反馈表，收集参与者观察
- ☐ 发议程，说明复盘规则：对事不对人
## 会中
- ☐ 先对齐事实：目标是什么、实际发生了什么
- ☐ 只讨论差异最大的部分，不逐条回顾全过程
- ☐ 区分「做对了什么」与「需要改进什么」
- ☐ 根因写到可验证：现象、假设、证据
- ☐ 改进项不超过 3 条，每条指定负责人与截止时间
## 会后 1 天
- ☐ 发复盘报告：事实、根因、改进清单
- ☐ 把改进项写进相关人的任务清单
- ☐ 归档可复用的方法、模板与检查清单
## 会后 2 周
- ☐ 逐条检查改进是否落地
- ☐ 未落地的说明原因，重新安排或放弃
- ☐ 把有效的改进写进下一次项目的启动清单
复制与下载都在浏览器本地完成，不会上传内容，也不需要登录。