迭代目标未达成时，复盘记录需要把目标、差距、原因、改进动作和未完成工作处置写在同一张表里，避免会后只剩零散讨论。这份模板包含五个区块，可直接复制到文档或表格工具中填写，并附字段说明、必填清单和一份演示示例。适用于已完成迭代、需要形成书面复盘结论的团队。
要点总览（TL;DR）
- 模板由表头信息、迭代目标与承诺范围、实际结果与差距清单、原因分析、改进动作与责任、未完成工作重新评估六个区块组成，可直接复制到文档或表格工具中填写。
- 目标描述、衡量口径、承诺范围、实际结果、达成状态、差距描述、直接原因、原因归类、改进动作、负责人、完成时间、未完成事项与处置结论为必填字段，缺失会导致复盘无法闭环。
- 差距写事实差额，原因写为什么差，两者分开记录；每条差距编号后，原因和改进动作引用同一编号，结论才能逐条对应。
- 未完成工作需重新评估后给出处置结论（转入下一迭代、拆解后转入、退回待办池或取消），不默认自动带入下一迭代。
- 模板可按团队规模和迭代长度裁剪，字段增删记入版本变更记录，历史复盘保留原版本以便前后比较。
可复制空白复盘记录表
下表按复盘讨论的自然顺序排列：先确认当初承诺了什么，再对照实际结果，随后分析原因、确定改进动作，最后处理未完成工作。复制到文档工具时，可保留表格结构；复制到表格工具时，建议每个区块单独占一段连续行，便于筛选和统计。
| 区块 | 字段 | 填写内容 |
|---|---|---|
| 表头信息 | 迭代名称 | |
| 迭代周期 | 开始日期至结束日期 | |
| 复盘日期 | ||
| 参与人 | ||
| 记录人 | ||
| 一、迭代目标与承诺范围 | 目标描述 | |
| 衡量口径 | ||
| 承诺范围 | ||
| 目标优先级 | ||
| 二、实际结果与差距清单 | 实际结果 | |
| 达成状态 | 达成 / 部分达成 / 未达成 | |
| 差距描述 | ||
| 差距影响 | ||
| 三、原因分析 | 直接原因 | |
| 原因归类 | 可控 / 不可控 | |
| 对应差距编号 | ||
| 是否重复出现 | 是 / 否 | |
| 四、改进动作与责任 | 改进动作 | |
| 负责人 | ||
| 完成时间 | ||
| 验证方式 | ||
| 五、未完成工作重新评估 | 未完成事项 | |
| 处置结论 | 转入下一迭代 / 拆解后转入 / 退回待办池 / 取消 | |
| 评估依据 | ||
| 确认人 |
表格中“对应差距编号”用于把原因和改进动作挂到具体差距上。差距清单超过一条时，建议在差距描述前加编号（如 G1、G2），后续原因和改进动作引用同一编号，复盘结论才能逐条对应。
每个字段记录什么：字段说明
字段说明解决的是“写什么算合格”。同一份记录里，目标、结果、差距、原因四类内容容易混在一起，填写时按下面的口径区分，可以减少会后争议。
| 字段 | 填写含义 | 判断口径 |
|---|---|---|
| 目标描述 | 迭代开始时团队承诺要达成的结果 | 写结果而非活动，例如“完成支付流程上线并通过验收”，不写“开发支付流程” |
| 衡量口径 | 判断目标是否达成的依据 | 写明指标、数量或验收条件，避免“基本完成”“大致达到”这类无法核对的表述 |
| 承诺范围 | 本迭代明确纳入的工作边界 | 列出纳入项和明确排除项，范围变更需注明变更时间和原因 |
| 实际结果 | 迭代结束时的事实状态 | 用与衡量口径一致的方式记录，例如完成数量、验收结论、上线状态 |
| 达成状态 | 目标整体完成程度 | 按达成、部分达成、未达成三档选择，部分达成需说明哪部分完成 |
| 差距描述 | 实际结果与目标之间的具体差额 | 只写事实差额，不写原因；例如“验收项 8 项中完成 5 项” |
| 差距影响 | 差距对后续工作的实际影响 | 说明影响对象和时间，例如“上线时间推迟一周，影响市场活动排期” |
| 直接原因 | 导致差距发生的具体事件或条件 | 写到可观察的层面，例如“接口联调比计划多耗 3 天”，不写“沟通不畅”这类笼统判断 |
| 原因归类 | 原因是否在团队影响范围内 | 可控指团队可通过调整做法改变；不可控指外部依赖、政策变化等，两类都要记录，但改进动作主要针对可控原因 |
| 改进动作 | 下一次迭代要改变的具体做法 | 写动作而非态度，例如“需求评审前完成接口依赖确认”，不写“加强沟通” |
| 负责人 | 对改进动作落地负责的人 | 写具体角色或姓名，一项动作对应一个负责人 |
| 完成时间 | 改进动作的截止日期 | 写具体日期，并与下一迭代的关键节点对齐 |
| 验证方式 | 判断改进动作是否生效的依据 | 例如“下一迭代同类联调耗时不超过 2 天”，便于在下次复盘中核对 |
| 处置结论 | 未完成工作的去向 | 四个选项择一：转入下一迭代、拆解后转入、退回待办池、取消；选择后需写明依据 |
差距与原因最容易混淆。差距回答“差了多少”，原因回答“为什么差”。填写时先完成差距清单，再逐条分析原因，可以避免把原因写进差距描述，导致后续改进动作失去对应对象。
必填与选填：哪些字段不能空
必填字段决定复盘能否闭环。缺少目标或衡量口径，达成状态无法判断；缺少差距和原因，改进动作没有依据；缺少负责人和完成时间，动作无法跟踪；缺少未完成工作处置结论，下一迭代的范围就不清楚。
| 类别 | 字段 | 缺失后果或适用情形 |
|---|---|---|
| 必填 | 迭代名称、迭代周期、复盘日期、记录人 | 缺少则记录无法归档和追溯 |
| 必填 | 目标描述、衡量口径、承诺范围 | 缺少则无法判断是否达成，复盘失去基准 |
| 必填 | 实际结果、达成状态、差距描述 | 缺少则原因分析没有对象 |
| 必填 | 直接原因、原因归类 | 缺少则改进动作只能凭印象提出 |
| 必填 | 改进动作、负责人、完成时间 | 缺少任一项，动作都无法跟踪到落地 |
| 必填 | 未完成事项、处置结论 | 缺少则下一迭代范围不清，未完成工作容易被默认带入 |
| 选填 | 参与人 | 小团队口头复盘时可省略，需要留痕时补填 |
| 选填 | 目标优先级 | 迭代只有一个目标时可省略，多目标时用于区分主次 |
| 选填 | 差距影响、是否重复出现 | 差距影响较小或首次出现时可省略；重复出现的原因建议填写，便于识别系统性问题 |
| 选填 | 验证方式、评估依据、确认人 | 改进动作需要下次核对时填写验证方式；未完成工作涉及范围调整时填写评估依据和确认人 |
必填字段的最小可接受写法是“具体到可核对”。目标描述至少包含结果对象和完成条件；差距描述至少包含计划值与实际值；改进动作至少包含一个可执行动作和一个截止日期。归档前做一次最低完整性检查：必填字段无空项，每条差距都有对应原因，每条可控原因都有改进动作，每项未完成工作都有处置结论。
填写示例：一次未达成迭代的完整记录
以下为演示情景，用于展示各区块如何连贯填写，非真实项目案例。
| 区块 | 字段 | 示例内容 |
|---|---|---|
| 表头信息 | 迭代名称 | 订单模块迭代 12 |
| 迭代周期 | 3 月 3 日至 3 月 14 日 | |
| 复盘日期 | 3 月 17 日 | |
| 参与人 | 产品、开发、测试共 6 人 | |
| 记录人 | 迭代负责人 | |
| 一、迭代目标与承诺范围 | 目标描述 | 完成订单退款流程上线，并通过业务方验收 |
| 衡量口径 | 验收项 8 项全部通过，上线后 3 天内无阻断性缺陷 | |
| 承诺范围 | 纳入：退款申请、审核、原路退回三个环节；排除：部分退款和跨币种退款 | |
| 目标优先级 | 高 | |
| 二、实际结果与差距清单 | 实际结果 | 退款申请和审核已上线，原路退回未完成；验收项通过 5 项 |
| 达成状态 | 部分达成 | |
| 差距描述 | G1：验收项 8 项中完成 5 项；G2：原路退回环节未上线 | |
| 差距影响 | 退款需人工处理，业务方每日增加约 2 小时人工核对 | |
| 三、原因分析 | 直接原因 | G1：测试环境支付渠道配置延迟 3 天；G2：原路退回依赖外部支付渠道接口，接口文档在迭代中期才提供 |
| 原因归类 | G1 可控；G2 部分可控，接口依赖时间未提前确认 | |
| 对应差距编号 | G1、G2 | |
| 是否重复出现 | G1 是，上一迭代出现同类环境准备延迟 | |
| 四、改进动作与责任 | 改进动作 | 迭代启动前完成测试环境与外部接口依赖清单确认，纳入迭代准入检查 |
| 负责人 | 迭代负责人 | |
| 完成时间 | 3 月 21 日 | |
| 验证方式 | 下一迭代启动会上核对依赖清单，环境准备延迟不超过 1 天 | |
| 五、未完成工作重新评估 | 未完成事项 | 原路退回环节及 3 项未通过验收项 |
| 处置结论 | 拆解后转入下一迭代 | |
| 评估依据 | 外部接口文档已到位，剩余工作量约 4 人天，下一迭代容量可容纳 | |
| 确认人 | 产品负责人 |
示例中每条差距都有编号，原因和改进动作引用同一编号；未完成工作没有默认带入下一迭代，而是经过工作量和依赖评估后给出“拆解后转入”的结论。填写自己的记录时，保持同样的对应关系即可。
当复盘记录需要长期留存并跟踪改进动作时，可以把记录沉淀在 ONES Wiki 中形成团队知识库，并利用文档关联任务、插入工作项列表的能力，把改进动作挂到具体工作项上；迭代进度和偏差可结合 ONES Project 的看板、燃尽图和报表数据核对。这样记录与动作留在同一处，下次复盘可以直接回看上一轮的改进是否生效。
模板的调整与维护方法
模板需要随团队节奏调整，但调整应有依据，避免每次复盘都换一套字段，导致历史记录无法比较。
裁剪字段按团队规模和迭代长度决定。人数少、迭代周期短的团队，可以省略参与人、目标优先级等辅助字段，保留目标、结果、差距、原因、改进动作和未完成处置这条主线。迭代周期较长或跨团队协作较多时，建议保留承诺范围、差距影响和验证方式，用于区分范围变更和责任边界。裁剪的原则是：删掉字段后仍能回答“目标是什么、差在哪、为什么、接下来谁做什么、未完成工作去哪了”。
新增字段需要满足两个条件：一是该字段在最近几次复盘中反复被口头讨论但无处记录；二是新增后能对应一个具体的判断或动作。仅为了记录更全面而增加的字段，容易变成填写负担。新增字段先在一个迭代中试用，确认有人填写、有人使用后再固定下来。
模板版本与变更记录建议在文档末尾维护一张小表，记录版本号、变更日期、变更内容和变更原因。字段增删、选项调整都记入变更记录，历史复盘记录保留原版本，不回溯修改，保证前后可比。
复盘后的动作跟踪与模板迭代要衔接起来。每次复盘开始时，先核对上一轮改进动作的完成情况和验证结果，把核对结论写入本次记录的原因或改进动作区；连续两个迭代未落地的改进动作，应在复盘中重新评估其必要性和责任人。模板本身也按同样节奏检查：如果某个必填字段连续多次填写为空或流于形式，考虑调整字段定义或降为选填，而不是继续保留一个无人使用的空项。
常见问题
迭代目标未达成时，复盘记录和普通迭代回顾会议记录有什么区别？
普通回顾会议记录通常按讨论顺序记录发言和结论，重点在会议过程；复盘记录模板围绕目标达成情况组织，先固定迭代目标与衡量口径，再对照实际结果列出差距，原因和改进动作都挂到具体差距上。目标未达成时，这种结构能直接回答“差在哪、为什么、接下来谁做什么”，也便于下次复盘核对上一轮改进是否生效。
如果团队已有回顾会议纪要，可以把模板作为纪要的结论部分使用，会议讨论过程另行记录，避免两类内容混在一张表里。
未完成的工作可以直接结转到下一迭代吗？
建议逐项重新评估后再决定去向，模板中对应“未完成工作重新评估”区块，处置结论有四个选项：转入下一迭代、拆解后转入、退回待办池、取消。评估时至少看三点：剩余工作量是否在下一迭代容量内、外部依赖是否已经具备、这项工作对当前目标是否仍然必要。
直接默认结转会让下一迭代范围被动膨胀，也容易掩盖原迭代目标未达成的事实。把评估依据和确认人写进记录，下一迭代规划时就有据可查。
小团队迭代周期短，模板字段可以精简到什么程度？
可以省略参与人、目标优先级、差距影响、是否重复出现等辅助字段，保留一条主线：目标描述、衡量口径、实际结果、达成状态、差距描述、直接原因、改进动作、负责人、完成时间、未完成事项与处置结论。精简后仍要能回答“目标是什么、差在哪、为什么、接下来谁做什么、未完成工作去哪了”。
迭代周期较长或跨团队协作较多时，建议保留承诺范围、差距影响和验证方式，用于区分范围变更与责任边界。裁剪结果记入模板变更记录，避免不同迭代之间字段口径不一致。
改进动作写进复盘记录后，怎么保证下次复盘能核对？
每条改进动作都要有负责人、完成时间和验证方式。验证方式写成可观察的判断，例如“下一迭代同类联调耗时不超过 2 天”，下次复盘时直接对照。复盘开始时先核对上一轮改进动作的完成情况和验证结果，把结论写入本次记录；连续两个迭代未落地的动作，重新评估必要性和责任人。
如果团队使用 ONES，可以把复盘记录沉淀在 ONES Wiki 中形成团队知识库，利用文档关联任务、插入工作项列表的能力把改进动作挂到具体工作项上，迭代进度和偏差结合 ONES Project 的看板、燃尽图和报表数据核对，下次复盘直接回看上一轮改进是否生效。
复盘记录里的原因分析写到什么颗粒度才算合格？
写到可观察的层面，例如“接口联调比计划多耗 3 天”“测试环境支付渠道配置延迟 3 天”，避免“沟通不畅”“资源不足”这类笼统判断。每条原因标注可控或不可控：可控指团队调整做法能改变，不可控指外部依赖、政策变化等。改进动作主要针对可控原因提出；不可控原因也要记录，用于后续规划时预留缓冲。
同一原因在多个迭代重复出现时，在“是否重复出现”字段标注，并在改进动作中给出更具体的验证方式，便于识别系统性问题。
