迭代回顾开完，会议记录里写了几条改进项，到了下一次回顾却没人说得清做到哪一步——问题通常不在团队执行力，而在行动项本身无法被检查：没有负责人、没有截止时间、没有可观察的完成标志，也没有固定的核对环节。本文按“写清楚—跟踪住—逐条查—定责任—看机制”的顺序，给出从本轮回顾结束到下一轮回顾核对的完整做法，并说明行动项增多后如何借助工作项系统承载跟踪。
要点总览（TL;DR）
- 行动项要写到可检查的程度：负责人、截止时间、完成标志、验证方式四项齐全，换一个没参会的人也能独立判断是否完成。
- 两次回顾之间靠登记、更新、提醒、状态流转四个动作维持跟踪，状态统一为待开始、进行中、已完成、已关闭、重新评估五种。
- 下次回顾把检查环节固定在议程开头，按同一份清单逐条核对，先看证据再判定，结果分为已完成、未完成、不再需要三类。
- 未完成行动项必须经过一次重新评估，结论只能是继续、调整范围或关闭，连续两轮未完成应升级到团队负责人处理。
- 判断闭环是否有效，看四项字段是否齐全、检查是否逐条留结论、未完成项是否重新评估、行动项数量是否可控，以及迭代中途状态是否持续更新。
行动项要写到什么程度才能被检查
一条行动项能否在下次回顾时被判定完成，取决于它是否写成了可观察、可取证的结果。判断标准很简单：换一个没参加本次回顾的同事来看这条记录，他能否独立判断“做完了没有”。如果答案是否定的，这条行动项就需要重写。
建议每条行动项至少包含四个字段，缺一项就会在检查时产生争议：
| 字段 | 写什么 | 不合格示例 | 合格示例 |
|---|---|---|---|
| 负责人 | 一个具体的人，而非“前端组”“大家” | 团队共同推进 | 张明（后端） |
| 截止时间 | 具体日期，落在下次回顾之前 | 尽快、本迭代内 | 3月14日 |
| 完成标志 | 可观察的产物或状态变化 | 提升代码质量 | 合并请求模板上线，含自检清单五项 |
| 验证方式 | 下次回顾时看什么证据 | 看效果 | 查看仓库模板文件，并抽查最近5个合并请求的填写情况 |
模糊表述的根源往往是行动项写成了愿望。下面几组改写可以直接对照使用：
- “加强前后端沟通”改为“每周二、周四各安排一次15分钟接口对齐会，负责人李婷，下次回顾时提供两次会议记录”。
- “提高测试覆盖率”改为“为订单模块补充单元测试，覆盖率从当前基线提升到60%，负责人王凯，下次回顾时展示测试报告截图”。
- “减少需求变更”改为“需求进入迭代后变更需经产品负责人书面确认，负责人陈璐，下次回顾时统计本迭代变更次数及确认记录”。
行动项数量需要控制。一个两到三周的迭代，团队能真正推动的改进通常不超过三条；超过这个数量，负责人精力分散，检查时会出现大面积未完成。取舍时优先保留影响当前迭代交付的问题，把次要想法记入待办池，留到后续迭代再评估，而不是一次性全部立项。每条行动项还应标注优先级或“本轮必须完成／可延后”的标记，方便下次回顾区分处理。
从回顾结束到下次回顾的跟踪流程
行动项在两次回顾之间需要有明确的存放位置和更新节奏，否则它会停留在会议记录里，直到下次回顾才被想起。流程可以按四个动作组织：登记、更新、提醒、状态流转。
登记发生在回顾结束前最后十分钟。主持人逐条复述行动项，负责人当场确认字段完整，记录人把行动项登记到团队共用的跟踪清单或工作项系统中。登记完成的标志是：每条行动项都有负责人、截止时间、完成标志和验证方式，且负责人本人确认。只写在会议纪要文档里的行动项，视为未登记。
更新由负责人完成，频率与团队站会节奏一致。每次站会用一分钟说明行动项进展：当前状态、是否遇到阻塞。遇到阻塞时，负责人在跟踪清单上标注阻塞原因并@相关人，由团队负责人在站会后协调资源。更新不需要写长文，一句话加状态变更即可。
提醒在截止时间前两到三天触发。可以由团队负责人每周固定查看一次跟踪清单，对临近截止且状态仍为“待开始”或“进行中”的行动项，在团队频道提醒负责人。截止时间已过仍未完成的，标记为逾期并在下次回顾中优先讨论，而不是悄悄改期。
状态取值建议统一为五种，避免各人写法不一：
| 状态 | 含义 | 由谁更新 |
|---|---|---|
| 待开始 | 已登记，尚未动手 | 负责人 |
| 进行中 | 已开始执行，未到完成标志 | 负责人 |
| 已完成 | 完成标志达成，证据已附 | 负责人 |
| 已关闭 | 经回顾确认不再需要，或已由其他方式解决 | 回顾主持人 |
| 重新评估 | 到期未完成或条件变化，待下次回顾决定去留 | 负责人或主持人 |
状态流转的规则是：负责人只能把行动项推进到“已完成”并附证据；改为“已关闭”或“重新评估”需要经过回顾会议确认。这样既保证负责人有推进权，也避免行动项被单方面悄悄关掉。
下次回顾中逐条检查的会议环节怎么开
检查环节应固定放在回顾议程的开头，而不是结尾。放在开头有两个好处：一是团队先看清上一轮承诺的兑现情况，再讨论新问题，避免新议题挤占检查时间；二是未完成项可以直接进入本轮讨论，不必另开一次会。建议时长控制在回顾总时长的四分之一左右，例如一小时的回顾留十五分钟。
逐条核对按跟踪清单的原始顺序进行，不按负责人分组，也不跳着看。每条行动项的处理分三步：负责人用一句话说明结果，展示约定的证据，团队据此判定。证据以登记时写明的验证方式为准，例如模板文件、会议记录、测试报告、变更统计。没有证据的口头说明，不能判定为已完成。
判定结果分三类，处理方式各不相同：
- 已完成：证据与完成标志一致，状态改为“已完成”，在回顾记录中注明验证人和日期。若完成效果值得保留，可考虑写入团队约定。
- 未完成：负责人说明原因，团队判断是继续、调整范围还是关闭。继续的行动项必须重写截止时间和完成标志，不能沿用原字段直接顺延。
- 不再需要：因需求变化、问题已由其他方式解决等原因失去意义，状态改为“已关闭”，并记录关闭理由，便于后续追溯。
这里的关键原则是：未完成行动项不默认自动结转到下一轮。自动结转会让行动项变成永久挂账，负责人失去紧迫感，检查环节也失去意义。每条未完成项都要经过一次明确的重新评估，评估结论只有三种——以新条件继续、缩小范围后继续、关闭。连续两轮未完成的行动项，应升级到团队负责人层面处理，判断是资源不足、目标不合理还是负责人需要更换。
角色分工与各自交付物
行动项无人跟进，常见原因是“大家都觉得有人在管”。把登记、跟踪、检查三个节点的责任落到具体角色上，并明确每个节点的交付物，跟进才有抓手。
| 角色 | 登记节点 | 跟踪节点 | 检查节点 |
|---|---|---|---|
| 行动项负责人 | 当场确认字段完整并接受任务 | 按站会节奏更新状态，阻塞时上报 | 说明结果、出示证据 |
| 回顾主持人 | 逐条复述，确保每条可检查 | 不直接推进，关注整体进度 | 主持逐条核对，记录判定结论 |
| 团队负责人（Scrum Master 或项目经理） | 确认行动项数量合理、与迭代目标相关 | 每周查看清单，提醒临近截止项，协调阻塞 | 对连续未完成项做出升级处理决定 |
三个角色的交付物分别是：负责人交付“带证据的完成结果或带原因的未完成说明”；主持人交付“字段完整的行动项清单和带判定结论的回顾记录”；团队负责人交付“每周跟踪记录和升级处理决定”。交付物不必复杂，但要能在下次回顾时被直接调取。
负责人缺席或离队时，交接必须显式完成。规则可以定为：负责人预计缺席下次回顾的，需在缺席前把行动项状态和证据更新到清单，并指定一名临时接手人；负责人离队的，由团队负责人在一周内重新指派负责人，新负责人重新确认截止时间和完成标志，必要时调整范围。没有完成交接的行动项，在下次回顾中按“重新评估”处理，而不是默认继续挂在前负责人名下。
示例：一个三人团队的两轮回顾闭环
以下为演示情景，用于说明前述方法的连贯运用。某三人小组负责一个内部工具模块，迭代周期两周。
第一轮回顾中，团队发现联调阶段反复出现接口字段不一致，讨论后产出两条行动项，按字段清单登记：
- 行动项A：整理订单与支付接口的字段对照表，负责人小林，截止3月12日，完成标志为对照表发布到团队文档并通知前后端，验证方式为下次回顾查看文档链接及通知记录。
- 行动项B：联调前增加一次接口评审，负责人小周，截止3月14日，完成标志为本次迭代至少执行一次评审并留下记录，验证方式为查看评审记录。
另有一条“优化日志格式”的想法，因与本迭代交付关系不大，记入待办池，未立项。
迭代进行中，小林在第二次站会更新行动项A为“进行中”；小周在迭代第七天完成接口评审，附上记录，状态改为“已完成”。小林在截止日前一天仍为“进行中”，团队负责人查看清单后在频道提醒；小林说明因支付侧接口文档缺失导致延误，团队负责人协调支付侧同事当天提供文档。截止日当天，对照表完成发布，小林补充文档链接和通知截图，状态改为“已完成”。
第二轮回顾开头十五分钟进入检查环节。行动项A：小林出示文档链接和通知记录，与完成标志一致，判定已完成。行动项B：小周出示评审记录，判定已完成。团队随后讨论本轮新问题，其中“联调环境不稳定”形成新行动项，负责人小陈，截止时间定在下轮回顾前，完成标志为环境问题清单及处理结果。上一轮记入待办池的“优化日志格式”被重新提起，团队评估后认为优先级仍低，继续留在待办池并注明原因。
这个示例的可迁移之处在于：行动项在登记时就写好了证据形式，检查时不需要临场回忆；一次延误通过提醒和协调解决，而不是拖到回顾会上才暴露；未立项的想法有明确去处，不会混入行动项清单造成数量膨胀。
用工作项系统承载行动项跟踪
当团队只有两三条行动项时，一张共享表格足够。当行动项跨迭代积累、涉及多个负责人，或者回顾记录需要长期留存时，用工作项系统承载会更稳妥：状态变更、截止时间、负责人和证据附件都能集中在一处，下次回顾前按条件筛选即可得到待检查清单。
配置思路可以分四步。第一步，为行动项设置独立的工作项类型或标签，字段至少包括负责人、截止时间、完成标志（文本）、证据（附件或链接）、来源迭代，状态沿用前文的五种取值。第二步，把回顾记录作为文档保存，在文档中插入行动项工作项列表，使会议结论与待办事项互相对应。第三步，下次回顾前一天，按“状态不为已完成和已关闭”加“截止时间早于下次回顾日期”筛选，生成待检查清单。第四步，在回顾会议中直接打开清单逐条核对，查看证据附件，当场更新状态并记录判定结论。
ONES 在迭代回顾场景中提供了可衔接的能力：迭代完成并发布后，团队可以召开回顾会，借助燃尽图、工时日志、持续集成报告等数据报表复盘进度、质量和成本偏差；回顾经验可以用 ONES Wiki 沉淀为团队知识库。ONES Wiki 支持文档关联任务，并可插入 ONES Project 的工作项列表，回顾记录与行动项工作项因此可以放在同一处查看。ONES Project 支持自定义状态与多种属性，可将工作项规划至迭代并分配负责人，便于为行动项设置负责人、截止时间和状态字段。具体字段配置、筛选方式和提醒能力以实际版本为准，团队在落地前可先用一条真实行动项走通登记、筛选、核对三个动作。
完成检查：这套闭环是否真的运转起来
机制建立后，需要定期判断它是否在起作用。以下清单可在每次回顾结束后由主持人花几分钟核对，也可每月做一次整体检查：
| 检查项 | 合格标准 | 不合格时的处理 |
|---|---|---|
| 每条行动项是否具备负责人、截止时间、完成标志、验证方式 | 四项齐全，负责人为具体个人 | 退回重写，未补齐不进入跟踪清单 |
| 下次回顾是否逐条核对并留下结论 | 每条行动项都有判定结果和记录人 | 检查环节固定进议程开头，主持人提前准备清单 |
| 未完成行动项是否经过重新评估 | 每条未完成项有继续、调整或关闭的明确结论 | 禁止默认结转，未评估项在下次回顾优先处理 |
| 连续多轮未完成的行动项是否有升级处理 | 连续两轮未完成即进入团队负责人处理流程 | 由团队负责人判断资源、目标或负责人是否需要调整 |
| 行动项数量是否可控 | 每轮新增行动项不超过三条，待办池有定期回顾 | 压缩立项数量，次要想法留在待办池 |
除清单外，还有两个可观察的信号：一是行动项在迭代中途的状态更新是否持续发生，如果清单在两次回顾之间几乎无人改动，说明跟踪环节形同虚设；二是回顾会上检查环节的耗时是否稳定，如果逐条核对经常超时或出现证据缺失的争论，说明登记时的完成标志和验证方式写得不够具体。把这两个信号与清单结合看，就能判断闭环是在真实运转，还是只维持了形式。
常见问题
行动项负责人中途离队或长期缺席，原来的行动项怎么处理？
交接要显式完成，不能默认继续挂在原负责人名下。负责人预计缺席下次回顾的，应在缺席前把状态和证据更新到清单，并指定一名临时接手人；负责人离队的，由团队负责人在一周内重新指派，新负责人重新确认截止时间和完成标志，必要时缩小范围。没有完成交接的行动项，在下次回顾中按“重新评估”处理。
行动项到期没完成，能不能直接改个截止时间顺延到下一轮？
不建议直接顺延。顺延会让行动项变成永久挂账，负责人失去紧迫感，检查环节也失去意义。正确做法是在下次回顾中重新评估，结论只有三种：以新条件继续、缩小范围后继续、关闭。选择继续的，必须重写截止时间和完成标志，不能沿用原字段。连续两轮未完成的，升级到团队负责人层面判断是资源不足、目标不合理还是负责人需要更换。
团队行动项不多，用共享表格跟踪够用吗，什么时候需要换成工作项系统？
只有两三条行动项、且都在同一迭代内闭环时，一张共享表格足够。出现以下情况时，用工作项系统承载会更稳妥：行动项跨迭代积累、涉及多个负责人、回顾记录需要长期留存、需要在回顾前按状态和截止时间快速筛出待检查项。工作项系统能把状态变更、截止时间、负责人和证据附件集中在一处，减少临场翻找记录的时间。
回顾会上检查行动项经常超时、争论证据算不算数，问题出在哪？
多数情况是登记时完成标志和验证方式写得不够具体。检查时只能靠临场解释，自然容易争论。改进方向是回到登记环节：每条行动项写明下次回顾看什么证据，例如文档链接、会议记录、测试报告或变更统计，并确保证据形式是团队能直接调取的。检查环节本身也应控制在回顾总时长的四分之一左右，按清单原始顺序逐条过，不按负责人分组、不跳着看。
用 ONES 承载行动项跟踪时，回顾记录和行动项怎么放在一起看？
ONES Wiki 支持文档关联任务，并可插入 ONES Project 的工作项列表，因此可以把回顾记录作为文档保存，在文档中嵌入行动项工作项列表，会议结论与待办事项互相对应。ONES Project 支持自定义状态与多种属性，可将工作项规划至迭代并分配负责人，便于为行动项设置负责人、截止时间和状态字段。具体字段配置、筛选方式和提醒能力以实际版本为准，落地前建议先用一条真实行动项走通登记、筛选、核对三个动作。
