迭代目标未达成时，复盘记录需要回答四件事：原定目标是什么、实际做到什么程度、差距为什么产生、下一步由谁在什么时间完成什么动作。一份可用的记录通常包含迭代基本信息、目标与承诺范围、实际结果与差距、未完成事项的重新评估、原因分析、改进动作与责任人、经验沉淀与跟踪安排。下面提供一张可直接复制填写的空白表，并配套字段说明、必填与选填规则、完整填写示例和维护方法。
要点总览（TL;DR）
- 迭代目标未达成的复盘记录应覆盖基本信息、目标与承诺范围、实际结果与差距、未完成事项重新评估、原因分析、改进动作与责任人、结论与跟踪安排。
- 空白模板按“基本信息—目标与结果—差距与原因—改进与跟踪—结论签字”五区组织，复制到文档工具即可填写。
- 必填项保证记录的最低完整度：目标、承诺范围、验收口径、实际完成情况、偏差描述、未完成事项重新评估、根因、改进动作、责任人、完成期限和复盘结论。
- 未完成事项要逐项写出重新排期、拆分、取消或转入后续迭代的结论及依据，避免一句“顺延”带过。
- 模板可按团队规模与迭代节奏裁剪，并用版本记录和定期回看保持字段与示例同步。
可直接复制的迭代复盘记录空白模板
下表按“基本信息—目标与结果—差距与原因—改进与跟踪—结论签字”的顺序组织，复制到文档工具后即可填写。填写提示列在正式使用时可以删除。
| 区域 | 字段 | 填写提示 |
|---|---|---|
| 基本信息 | 迭代名称 | 填写团队通用的迭代编号或名称，如“支付团队 2025 年第 8 迭代” |
| 迭代周期 | 填写起止日期，跨团队迭代注明各团队对齐的起止时间 | |
| 迭代负责人 | 填写对迭代结果负责的人 | |
| 复盘参与人 | 列出参与复盘的角色与姓名 | |
| 复盘日期 | 填写实际召开复盘的日期 | |
| 记录人 | 填写本记录的整理人 | |
| 目标与承诺 | 迭代目标 | 抄录迭代启动时确定的目标原文，不改写 |
| 承诺范围 | 列出本迭代承诺交付的需求或工作项清单 | |
| 验收口径 | 写明每项目标的完成标准，如上线、通过验收、达到某指标 | |
| 目标优先级 | 标注目标之间的优先顺序，便于判断部分达成时的取舍 | |
| 结果与差距 | 实际完成情况 | 逐项对照承诺范围，写明完成、部分完成、未完成 |
| 达成率 | 按承诺项数或工作量计算，注明计算口径 | |
| 偏差描述 | 写清差距的具体表现，如延期天数、范围缩减、质量未达标 | |
| 未完成事项重新评估 | 逐项给出结论：重新排期、拆分、取消或转入后续迭代，并说明依据 | |
| 差距与原因 | 直接原因 | 描述导致差距的直接事件或状态 |
| 根因分析 | 追问到可干预的层面，如需求变更未评估、依赖未对齐、估算偏差 | |
| 影响范围 | 说明差距对后续迭代、关联团队或交付节点的影响 | |
| 改进与跟踪 | 改进动作 | 每条动作写成一个可执行、可验证的事项 |
| 责任人 | 每项动作指定一名负责人 | |
| 完成期限 | 填写具体日期或所属迭代 | |
| 验证方式与复查时点 | 写明如何判断动作生效，以及何时复查 | |
| 结论与签字 | 复盘结论 | 用几句话概括本次复盘的主要判断 |
| 经验沉淀 | 记录值得写入团队知识库的做法或教训 | |
| 确认签字 | 迭代负责人与主要参与人确认 |
模板字段逐项说明：每个格子填什么
空白表解决“填哪些格子”，字段说明解决“每个格子按什么口径填”。以下说明与上表字段一一对应，示例写法可直接参照。
| 字段 | 含义 | 填写口径 | 示例写法 |
|---|---|---|---|
| 迭代名称 | 标识本次复盘对应的迭代 | 使用团队既有命名，保持与项目管理系统一致 | 订单团队 2025 年第 8 迭代 |
| 迭代周期 | 界定复盘覆盖的时间范围 | 填写起止日期；跨团队迭代注明对齐口径 | 2025-04-07 至 2025-04-18 |
| 迭代负责人 | 对迭代结果负责的人 | 填写单一责任人，便于后续跟踪 | 张明（迭代负责人） |
| 参与人 | 参与复盘讨论的角色 | 列出角色与姓名，覆盖开发、测试、产品等 | 产品：李华；开发：王强、赵敏；测试：陈静 |
| 迭代目标 | 迭代启动时确定的目标 | 抄录原文，不在复盘中改写目标 | 完成订单退款流程改造并上线，退款平均处理时长降至 2 小时内 |
| 承诺范围 | 本迭代承诺交付的工作项 | 逐条列出，与工作项管理系统中的记录对应 | 退款申请页重构、退款审核接口改造、退款状态通知 |
| 验收口径 | 判断目标是否达成的标准 | 写可核验的条件，避免“基本完成”这类表述 | 三项需求全部上线，退款处理时长连续三天低于 2 小时 |
| 实际完成情况 | 承诺范围的逐项结果 | 按完成、部分完成、未完成三档标注，并附简要说明 | 退款申请页重构：完成；审核接口改造：部分完成；状态通知：未开始 |
| 达成率 | 目标完成程度的量化表达 | 注明按项数还是按工作量计算 | 按承诺项数计算 2/3，约 67% |
| 偏差描述 | 差距的具体表现 | 写事实与数据，不写评价性形容词 | 审核接口改造延期 4 天，退款处理时长未达标，上线后平均 3.5 小时 |
| 未完成事项重新评估 | 对未完成工作的处理结论 | 逐项给出重新排期、拆分、取消或转入后续迭代的结论及依据 | 状态通知转入第 9 迭代；审核接口剩余部分拆为两个子任务，优先完成对账逻辑 |
| 直接原因 | 导致差距的直接事件 | 描述可观察的事实 | 审核接口依赖的第三方字段在迭代中期变更 |
| 根因分析 | 差距背后的可干预因素 | 追问到团队能够改变的做法或机制 | 外部依赖未在迭代启动时确认冻结时间，变更后未及时评估影响 |
| 改进动作 | 针对根因采取的行动 | 每条动作可执行、可验证，避免“加强沟通”这类笼统表述 | 迭代启动会上逐项确认外部依赖的冻结时间，并写入承诺范围 |
| 责任人 | 动作的执行人 | 一项动作对应一名负责人 | 王强 |
| 完成期限 | 动作的完成时间 | 填写具体日期或所属迭代 | 第 9 迭代启动会前（2025-04-21） |
| 验证方式与复查时点 | 判断动作是否生效的方法 | 写明观察指标或检查动作，以及复查时间 | 第 9 迭代启动会检查依赖清单是否完整；第 9 迭代结束时复查延期次数 |
| 复盘结论 | 本次复盘的主要判断 | 概括目标达成情况与核心问题 | 目标部分达成，主要问题在外部依赖管理，改进动作已排入下一迭代 |
| 经验沉淀 | 可复用的做法或教训 | 写成可被其他迭代参照的条目 | 外部依赖需在迭代启动时确认冻结时间并纳入承诺范围 |
必填与选填：哪些字段不能空
必填项的作用是保证记录具备最低完整度：任何人拿到这份记录，都能看懂目标、结果、原因和下一步。选填项用于补充背景，按迭代情况取舍。
| 类别 | 字段 | 理由或适用情形 |
|---|---|---|
| 必填 | 迭代名称、迭代周期、迭代负责人 | 缺少基本信息，记录无法归档和追溯 |
| 必填 | 迭代目标、承诺范围、验收口径 | 没有目标和口径，就无法判断是否达成 |
| 必填 | 实际完成情况、偏差描述 | 复盘的核心事实依据 |
| 必填 | 未完成事项重新评估 | 未完成工作需要有明确去向，不能默认自动结转 |
| 必填 | 根因分析、改进动作、责任人、完成期限 | 缺少任一项，改进就无法落地和跟踪 |
| 必填 | 复盘结论 | 记录对本次迭代的总体判断 |
| 选填 | 达成率 | 承诺项数少或工作量难以统一口径时，可用完成情况描述替代 |
| 选填 | 目标优先级 | 目标之间存在取舍时填写，单目标迭代可省略 |
| 选填 | 影响范围 | 差距波及关联团队或交付节点时填写 |
| 选填 | 验证方式与复查时点 | 改进动作需要跨迭代观察时填写，短期可验证的动作可简化 |
| 选填 | 经验沉淀、确认签字 | 有可复用经验时填写；签字按团队惯例执行 |
如果必填项在复盘会上无法当场确定，例如根因尚未查清，应在记录中标注“待确认”、指定确认人和确认时间，并在下次跟踪时补齐。把空白项留成无说明的空格，会让记录在后续复查时失去参考价值。
字段取舍可以按迭代类型调整。一周或两周的短周期迭代，可合并“直接原因”和“根因分析”为一栏，减少填写负担；跨团队迭代建议保留“影响范围”和“目标优先级”，并补充各团队的承诺范围与对齐时间。团队规模较小时，参与人可只写角色；规模较大或涉及多个职能时，建议列出姓名以便跟踪。
填写示例：一次目标未达成的完整复盘记录
以下示例为演示情景，用于说明各字段如何落地，数据为虚构。示例中的字段顺序与空白模板一致。
| 字段 | 填写内容 |
|---|---|
| 迭代名称 | 订单团队 2025 年第 8 迭代 |
| 迭代周期 | 2025-04-07 至 2025-04-18 |
| 迭代负责人 | 张明 |
| 复盘参与人 | 产品：李华；开发：王强、赵敏；测试：陈静 |
| 复盘日期 | 2025-04-21 |
| 记录人 | 赵敏 |
| 迭代目标 | 完成订单退款流程改造并上线，退款平均处理时长降至 2 小时内 |
| 承诺范围 | 退款申请页重构、退款审核接口改造、退款状态通知 |
| 验收口径 | 三项需求全部上线，退款处理时长连续三天低于 2 小时 |
| 目标优先级 | 审核接口改造 > 申请页重构 > 状态通知 |
| 实际完成情况 | 申请页重构完成；审核接口改造部分完成，对账逻辑未完成；状态通知未开始 |
| 达成率 | 按承诺项数计算 2/3，约 67% |
| 偏差描述 | 审核接口改造延期 4 天；上线后退款平均处理时长 3.5 小时，未达到 2 小时目标 |
| 未完成事项重新评估 | 状态通知转入第 9 迭代；审核接口剩余的对账逻辑拆为两个子任务，第 9 迭代优先完成，依据是对账错误会直接影响退款准确性 |
| 直接原因 | 审核接口依赖的第三方字段在迭代中期变更，联调返工两次 |
| 根因分析 | 迭代启动时未确认外部依赖的冻结时间；变更发生后未及时评估对承诺范围的影响，仍按原计划推进 |
| 影响范围 | 退款处理时长未达标，客服侧咨询量在迭代末期上升；状态通知延期影响用户感知 |
| 改进动作 | 迭代启动会上逐项确认外部依赖的冻结时间并写入承诺范围；外部依赖变更时，当天评估影响并更新承诺范围 |
| 责任人 | 王强（依赖确认）；张明（变更影响评估） |
| 完成期限 | 第 9 迭代启动会前（2025-04-21）；变更评估机制自第 9 迭代起执行 |
| 验证方式与复查时点 | 第 9 迭代启动会检查依赖清单是否完整；第 9 迭代结束时复查因外部依赖导致的延期次数是否下降 |
| 复盘结论 | 目标部分达成，主要问题在外部依赖管理和变更影响评估，改进动作已排入第 9 迭代 |
| 经验沉淀 | 外部依赖需在迭代启动时确认冻结时间并纳入承诺范围；依赖变更当天完成影响评估 |
| 确认签字 | 张明、李华、王强、赵敏、陈静 |
这份示例中，“未完成事项重新评估”没有写成“顺延到下一迭代”一句带过，而是逐项说明去向和依据；“改进动作”对应根因，写成可检查的动作，并配了责任人和复查时点。填写本团队记录时，可以保留这个结构，替换为实际的目标、数据和人员。
复盘所需的数据可以从迭代过程中的记录中整理，例如燃尽图、工时日志和持续集成报告，用于对照进度、质量和成本偏差。ONES 支持在迭代完成后通过这类报表复盘迭代情况，并可用 ONES Wiki 将经验沉淀为团队知识库；Wiki 文档可关联任务，也可插入 ONES Project 的工作项列表，便于把改进动作与未完成事项直接对应到具体工作项。将复盘记录放入 Wiki 后，下一迭代复查时可以直接从文档跳转到相关工作项查看状态。
模板的调整与长期维护方法
模板的价值在于稳定复用，同时允许团队按实际情况裁剪。以下操作清单可用于模板的日常维护。
- 按团队规模裁剪：小团队可合并原因分析与影响范围，保留目标、结果、根因、动作四块核心内容；多团队协作时增加各团队承诺范围和对齐时间两栏。
- 按迭代节奏裁剪：短周期迭代减少描述性字段，把重点放在未完成事项去向和改进动作；长周期或跨版本迭代保留目标优先级和影响范围。
- 建立版本记录：在模板文档顶部记录版本号、修改日期、修改人和修改原因，例如“v1.2，2025-05，新增外部依赖确认字段”。
- 让结论进入下一迭代：复盘结束后，把改进动作和未完成事项的重新评估结论转为下一迭代的工作项，指定责任人和期限，并在迭代启动会上确认。
- 定期回看模板有效性：每季度或每若干迭代检查一次，统计哪些字段经常空白、哪些字段从未被使用、改进动作的完成率如何，据此增删字段。
- 保持字段与示例同步：修改模板字段后，同步更新字段说明和填写示例，避免新成员参照旧示例填写。
维护模板时，判断字段去留的标准可以很简单：这个字段是否帮助团队看清目标达成情况，或者是否帮助改进动作被跟踪。两个作用都不具备的字段可以删除；经常空白但确实影响判断的字段，应检查填写口径是否清楚，而不是直接取消。
常见问题
复盘会上根因还没查清，记录该怎么处理？
在对应字段标注“待确认”，同时写明确认人和确认时间，并在下次跟踪时补齐。把空白项留成无说明的空格，后续复查时无法判断是遗漏还是尚未查清。若根因涉及外部依赖或跨团队事项，可先记录已观察到的事实和临时处理动作，再约定补充分析的时点。
未完成的工作可以直接顺延到下一迭代吗？
不建议默认顺延。复盘记录中应逐项给出重新评估结论：重新排期、拆分、取消或转入后续迭代，并说明依据。例如对账逻辑影响退款准确性，可以拆成子任务优先排入下一迭代；用户感知类需求可以重新排期。这样下一迭代的承诺范围才有明确来源，而不是把上一迭代的剩余项原样搬过去。
短周期迭代和跨团队迭代的字段取舍有什么不同？
一周或两周的短周期迭代可合并“直接原因”和“根因分析”，减少描述性字段，把重点放在未完成事项去向和改进动作。跨团队迭代建议保留“影响范围”和“目标优先级”，并补充各团队的承诺范围与对齐时间。团队规模较小时参与人可只写角色；涉及多个职能时列出姓名，便于跟踪动作。
复盘记录放在哪里，改进动作如何跟进？
记录可以放在团队文档工具中统一归档，改进动作和未完成事项的重新评估结论转为下一迭代的工作项，指定责任人和期限，并在迭代启动会上确认。ONES 支持在迭代完成后通过燃尽图、工时日志、持续集成报告等报表复盘迭代情况，并可用 ONES Wiki 沉淀经验；Wiki 文档可关联任务，也可插入 ONES Project 的工作项列表，便于复查时从文档直接跳转到相关工作项查看状态。
模板用久了字段越来越多，怎么判断哪些该删？
判断标准可以归结为两个作用：这个字段是否帮助团队看清目标达成情况，或者是否帮助改进动作被跟踪。两个作用都不具备的字段可以删除；经常空白但确实影响判断的字段，先检查填写口径是否清楚，再决定是否保留。建议每季度或每若干迭代统计一次字段空白率和改进动作完成率，据此调整模板并同步更新字段说明与示例。
