回顾会议做什么
回顾会议是迭代或阶段结束后，团队检视协作方式并形成改进动作的固定环节。常用技术有时间线、5 Whys、起止续、帆船图与四项列表等，共同结构是：先收集事实与感受，再聚焦根因，最后收敛为少量带责任人的行动项，并在下次回顾验收。技术只是载体，能不能把感受转成可跟踪的改动才是关键。
基本信息
| 发生时机 | 迭代或阶段结束、重大项目事件之后 |
|---|---|
| 参会人 | 团队全体，必要时邀请相关干系人 |
| 典型技术 | 时间线、5 Whys、起止续、帆船图 |
| 产出 | 两三条行动项，含责任人、验证方式与时限 |
| 跟踪方式 | 下次回顾开场先检查上轮行动项完成情况 |
典型使用场景
- 每个迭代固定时间做回顾，避免改进事项被日常任务挤掉
- 发布或重大故障之后做专项回顾，聚焦根因而非追责
- 团队协作摩擦明显、堆积与返工增多时，用数据驱动的回顾定位损耗
- 新团队组建初期用轻量技术快速形成协作约定
- 跨团队问题反复出现时，把回顾结论上升到协调机制层面处理
起止续要点
起止续要点
# 开始做：哪些做法值得开始，预期解决什么问题
# 停止做：哪些做法消耗多、收益低，应当停止
# 继续做：哪些做法有效，要保持并固化为约定
# 输出：两三条行动项，含负责人、验证方式与时限
# 复查：下次回顾开场逐条确认完成情况与效果技术与适用场景
| 技术 | 适用场景 | 要点 |
|---|---|---|
| 时间线 | 周期较长的阶段或事件复盘 | 按时间排列事实，再讨论感受 |
| 5 Whys | 问题反复出现需找根因 | 追问到可改动的原因层为止 |
| 起止续 | 团队协作约定调整 | 每类控制在少数几条 |
| 帆船图 | 识别推动与阻碍因素 | 把阻碍转成具体改动项 |
行动项并非越多越好：能完成少量并验证效果的团队，改进速度反而更可持续。
回顾一旦变成追责会，坏消息会消失，之后的讨论数据与结论都不再可信。