迭代评审发现目标没达成时，先别急着讨论“下次怎么补”，而要把“没达成”拆成可判断的事实：是目标值没到、范围没做完、验收标准没满足，还是需求理解有偏差、评审中又冒出新的反馈。分类清楚之后，再按“确认差距—归因取证—重新评估未完成项—形成带负责人和验收标准的行动项—纳入下一次迭代输入”的顺序推进，并在下一次评审回看行动项是否生效。本文聚焦迭代运行层面的处置动作，ONES 可作为行动项与评审记录的承载工具。
要点总览（TL;DR）
- 评审发现目标没达成时，先把“没达成”归入目标值未达成、范围未完成、验收标准未满足、需求理解偏差或评审新增反馈五类情形，再进入归因。
- 归因按“先口径与理解、再执行与依赖”的顺序排查，每类原因假设都要有对应证据；证据不足的标记为待验证，不写成确定原因。
- 未完成工作逐项重新评估业务价值、需求清晰度、是否被新反馈替代和拆分粒度，再决定保留重排、拆分保留、退回需求池或关闭记录，不默认自动结转。
- 行动项要写清具体动作、负责人、完成时限、验收标准和关联目标，并同时安排纠正动作与改进动作；反馈分歧记录分歧点、指定裁决人、约定复核时点。
- 在下一次评审回看行动项完成情况与目标达成情况，验证不通过则重新归因、调整行动项；涉及范围调整或目标变更需经相应角色确认。
先界定症状：目标没达成的几种典型情形
评审现场最容易出现的低效讨论，是所有人都在说“没达成”，但各自指的不是同一件事。产品负责人说的是目标值，开发说的是范围没做完，测试说的是验收没过，业务方说的是“这不是我想要的”。如果不先分类，后续行动就会各说各话。建议在评审开始的前十分钟，把本次差距归入下面五类情形之一，并写明判断依据。
| 情形 | 判断依据 | 典型表现 | 处置归属 |
|---|---|---|---|
| 目标值未达成 | 迭代目标中约定的量化口径与统计结果 | 目标写的是“转化率提升 5%”，实际只提升 2% | 本次迭代内可确认差距，原因需进一步取证 |
| 范围未完成 | 迭代范围清单与完成定义 | 计划内的需求有若干条仍处于开发或测试中 | 本次迭代内确认，未完成项进入重新评估 |
| 验收标准未满足 | 验收记录、验收人反馈 | 功能已交付，但验收条件中的边界场景未通过 | 本次迭代内可判定，需决定返工或调整 |
| 需求理解偏差 | 需求澄清记录与交付物对照 | 交付内容与需求方预期不一致，双方对描述理解不同 | 需重新澄清后进入下一迭代输入 |
| 评审中新增反馈 | 反馈来源、提出人与提出时点 | 评审过程中业务方提出新的使用场景或约束 | 不属本次差距，登记后进入下一迭代输入 |
这五类情形中，前四类与本次迭代直接相关，需要在评审现场给出初步判断；第五类新增反馈不改变本次结论，但要登记来源，避免在后续讨论中被误当成“没达成的原因”。范围未完成和验收未满足通常可以在本次迭代内处置，而需求理解偏差往往需要重新澄清，属于下一迭代输入。分类的目的不是贴标签，而是让后续归因和处置有明确对象。
原因假设与排除证据：差距出在哪一环
分类之后进入归因。归因最常见的错误，是把会上第一个听起来合理的解释直接写进行动项。更稳妥的做法是先列出原因假设，再为每个假设找对应证据，证据不足的标记为待验证，不写成确定原因。
常见的原因假设可以归为五类：目标设定偏高、需求理解偏差、依赖阻塞、估算偏差、验收标准不清。每类假设都有相对明确的取证方式：
- 目标设定偏高：对照历史同类迭代的实际达成情况与目标制定时的假设条件，看目标是否建立在未经验证的乐观预期上。
- 需求理解偏差：调取需求澄清记录、评审纪要与交付物，比对双方对范围与验收的理解是否一致。
- 依赖阻塞：查看阻塞记录、等待时长与外部依赖的响应时间，确认阻塞发生在哪个环节、持续多久。
- 估算偏差：对照任务工时统计与实际耗时，看偏差集中在个别任务还是普遍存在。
- 验收标准不清：检查验收条件是否可验证、是否存在“体验良好”这类无法判定的表述。
排查顺序建议先口径、后执行：先排除目标口径与需求理解问题，再看执行过程与外部依赖。原因是口径问题会放大执行层面的偏差，如果先查执行，容易把本属于定义不清的问题误判为团队效率问题。执行与依赖的排查可以借助迭代过程中的进度数据，例如看板状态流转、燃尽图走势与工时记录，判断偏差是逐步累积还是在某个节点突然出现。
证据不足时，处理方式要明确：在评审记录中写“待验证”，并指定验证人和验证时点，而不是用“可能是……”“估计是……”的表述写进结论。待验证事项可以作为下一迭代的改进动作之一，但不能作为本次差距的定论。
未完成工作的重新评估与处置
未完成工作的处理是评审后最容易产生惯性动作的环节。默认全部结转到下一迭代，会让下一迭代的范围在开始前就超载，也会让一些已经失去价值的需求继续占用资源。正确做法是逐项重新评估，每项给出处置结论和理由。
逐项评估可以围绕四个维度展开：业务价值是否仍然成立；需求是否需要重新澄清；是否已被评审中的新反馈替代；拆分粒度是否合适，是否需要拆小后再排期。四个维度都过一遍，再选择处置选项：
| 处置选项 | 适用条件 | 记录要求 |
|---|---|---|
| 保留并重新排期 | 价值成立、需求清晰、粒度合适 | 记录新排期与责任人 |
| 拆分后部分保留 | 整体价值成立但粒度过大，或部分子项可独立交付 | 记录拆分结果与保留部分 |
| 退回需求池重新评估 | 需求需重新澄清，或价值判断依赖更多信息 | 记录退回原因与澄清责任人 |
| 关闭并记录原因 | 价值已不成立，或被新反馈替代 | 记录关闭理由，保留追溯信息 |
需要强调的是，未完成工作不默认自动结转。结转本身是一个决策，需要经过上述评估并留下理由与责任人。评审记录中应能回答“这一项为什么保留、为什么关闭、由谁负责推进”，这样下一次评审回看时才有依据。对于退回需求池的条目，应同步更新需求状态，避免它继续以“迭代内未完成”的身份出现在报表里，造成统计口径混乱。
把结论转成后续行动项与下一次迭代输入
评审结论如果只停留在会议纪要里，很难被执行。有效的做法是把结论转成结构化的行动项，每个行动项至少包含五个字段：具体动作、负责人、完成时限、验收标准、关联目标。具体动作要写到可执行的程度，例如“补充支付失败场景的验收条件并组织业务方确认”，而不是“完善验收标准”。
行动项按性质分为两类。纠正动作针对本次差距本身，例如补做未完成的测试、返工未通过验收的功能；改进动作针对产生差距的机制，例如调整目标口径的制定方式、补充需求澄清的前置动作、在迭代计划中增加依赖确认环节。两类动作都要有，只做纠正动作，同类问题容易在下个迭代重演；只做改进动作，本次差距可能无人收尾。
评审中出现反馈分歧时，处理方式要写进记录：记录分歧点、指定裁决人、约定复核时点。分歧不应在评审现场以“先按多数意见”草草结束，也不应留到下次会议再议而不决。裁决人可以是产品负责人或业务方代表，复核时点可以放在下一次评审或专门的澄清会上。
下一次迭代输入由三部分组成：重新评估后的未完成项、评审中登记的新增反馈、本次形成的改进动作。三部分在进入迭代规划前应统一过一遍优先级，避免改进动作因为“不是需求”而被挤掉。在工具层面，ONES Project 支持建立需求池、规划迭代，将需求和相关任务规划至迭代并分配负责人，行动项可以作为工作项纳入同一套状态流转，评审记录与结论则可通过文档方式留存，便于下一次评审回看时对照。
验证与复发预防
行动项是否生效，要在下一次评审中回看，而不是等到季度复盘。回看内容包括两项：行动项本身的完成情况，以及对应目标在下一迭代的达成情况。前者看动作有没有做，后者看做了之后有没有效果。两项都通过，才能认为本次处置闭环。
验证不通过时，处理路径是重新归因、调整行动项，而不是简单追加一条“加强执行”的新动作。如果纠正动作完成了但目标仍未改善，说明原因假设可能有误，需要回到证据层面重新排查；如果改进动作完成了但同类差距再次出现，说明改进动作的力度或范围不够，需要扩大适用范围或调整检查点。
复发预防可以从三个检查点入手：
- 目标设定检查：目标是否写明量化口径、统计方式与假设条件，是否与历史数据对照过。
- 验收标准检查：验收条件是否可验证，是否存在无法判定的模糊表述，是否在迭代计划阶段与需求方确认过。
- 依赖风险检查：外部依赖是否在迭代计划阶段识别，是否有明确的响应时限与升级路径。
需要守住的风险边界是：涉及范围调整或目标变更时，需经产品负责人或相应决策角色确认，避免在评审现场单方面改口径，把“没达成”改写成“目标调整”。口径变更应作为改进动作记录在案，说明调整依据，而不是让本次差距在记录中消失。这样下一次评审回看时，团队看到的是一条完整的处置链路，而不是一份被修饰过的结论。
常见问题
评审现场时间有限，五类情形必须全部走完吗？
不必。评审现场至少要把与本次迭代直接相关的情形判断清楚：目标值未达成、范围未完成、验收标准未满足、需求理解偏差。评审中新增的反馈单独登记来源和提出人即可，它不改变本次结论，可以留到会后处理。如果现场对某一类的判断依据拿不准，先记为待确认并指定核对人，比在会上反复争论更有效。
未完成的工作直接结转到下一迭代，会带来什么问题？
直接结转会让下一迭代在开始前就带上上一迭代的存量范围，规划时容易超载；一些价值已经变化或需要重新澄清的条目也会继续占用资源。更稳妥的做法是逐项评估后再决定去留，结转本身作为一次决策留下理由和责任人。这样下一次评审回看时，能说清每一项为什么还在、由谁推进。
评审中业务方和产品负责人对目标口径有分歧，当场怎么处理？
把分歧点写进记录，指定裁决人和复核时点，不在现场用“先按多数意见”草草结束。裁决人可以是产品负责人或业务方代表，复核时点可以放在下一次评审或专门的澄清会上。涉及范围调整或目标变更时，需经相应决策角色确认，口径变更作为改进动作记录在案并说明依据，避免本次差距在记录中消失。
行动项在下一次评审回看时没完成，应该怎么处理？
先区分是动作没做还是做了没效果。动作没做，要确认是负责人变更、时限不合理还是被更高优先级挤占，再调整负责人或时限；动作做了但目标仍未改善，说明原因假设可能有误，需要回到证据层面重新排查，而不是追加一条“加强执行”的新动作。回看结论同样要记录，作为下一轮改进动作的输入。
用工具承载评审记录和行动项时，重点看什么？
重点看三件事：行动项能否作为工作项纳入统一的状态流转并分配负责人；评审记录与结论能否留存，便于下一次评审对照回看；未完成项的状态变更能否同步到需求侧，避免统计口径混乱。ONES Project 支持建立需求池、规划迭代，将需求和相关任务规划至迭代并分配负责人，评审记录与结论可通过文档方式留存。
