项目复盘报告
项目结束后把事实、根因与改进项分开，别让经验随项目一起结束。
可整段复制 占位符用双大括号标出，替换成你的内容即可
# {{项目名称}} 复盘报告
## 一、项目概况
- 目标：{{原定目标与成功标准}}
- 周期：{{开始时间}} 至 {{结束时间}}
- 角色：{{负责人}} / {{核心成员}}
- 结果：{{达成 / 部分达成 / 未达成}}
## 二、目标与结果对照
| 维度 | 原定目标 | 实际结果 | 差异 |
| --- | --- | --- | --- |
| {{范围}} | {{目标}} | {{结果}} | {{差异}} |
| {{质量}} | {{目标}} | {{结果}} | {{差异}} |
| {{时间}} | {{目标}} | {{结果}} | {{差异}} |
## 三、关键时间线（只写转折点）
- {{日期}}：{{发生了什么}}，导致 {{影响}}
- {{日期}}：{{发生了什么}}，导致 {{影响}}
## 四、做对了什么（可复用）
1. {{做法}}：当时为什么有效；换到什么场景仍然适用
2. {{做法}}：当时为什么有效；换到什么场景仍然适用
## 五、问题与根因
- 现象：{{看到的问题}}；根因：{{可验证的判断}}；证据：{{数据或事实}}
- 现象：{{看到的问题}}；根因：{{可验证的判断}}；证据：{{数据或事实}}
## 六、改进项
| 改进动作 | 负责人 | 截止时间 | 验收标准 |
| --- | --- | --- | --- |
| {{动作}} | {{姓名}} | {{日期}} | {{怎么算完成}} |
| {{动作}} | {{姓名}} | {{日期}} | {{怎么算完成}} |
## 七、需要升级到流程或规范的内容
{{是否形成 SOP、检查清单或模板；没有可删除}}
复制与下载都在浏览器本地完成，不会上传内容，也不需要登录。
怎么用
- 先把时间线与数据摆出来，再讨论感受，避免复盘变成印象争论。
- 根因写到可以被验证的程度：「需求变更没有同步」比「沟通不到位」更有用。
- 改进项最多三条，每条都要有负责人、截止时间和验收标准。
为什么这么写
- 把「目标与结果」放在最前，先统一事实基础，后续讨论才不容易跑偏。
- 做对了什么单独成节，是为了保留可复用经验，而不只盯着问题。
- 根因要求证据，能区分「当时信息不足」与「执行失误」，减少追责氛围。
- 改进项绑定负责人和验收标准，复盘才不会停在文档里。
常见错误
- 只列问题不列做对的事，团队越复盘越泄气。
- 把根因写成个人态度问题，导致防御和甩锅。
- 改进项没有负责人和时间，下一次项目重复同样的坑。