迭代目标未达成时，先别急着追问“谁没做好”。更有效的顺序是：把“未达成”换算成可核对的目标口径和差距数据，再按假设逐条找证据，确认主因和叠加因素，然后对未完成工作逐项重新评估，决定去向。处置结束后还要安排验证检查点和下一迭代的预防动作，避免同类差距重复出现。本文按这一路径展开，并说明 ONES 在迭代与工作项上承载差距核对、处置决策记录时可衔接的环节。
要点总览（TL;DR）
- 先把“未达成”换算成可核对的口径：区分承诺范围、质量门槛、时间节点和业务结果，统一完成定义，统计未完成条目数、剩余工作量和延期天数，并界定影响范围。
- 原因排查按假设—证据逐条验证：范围变更、估算偏乐观、阻塞未暴露、外部依赖延迟、验收标准不清各有对应证据，结论只写已证实、已排除或证据不足待观察。
- 未完成工作逐条重新评估，给出原样保留、拆分、重新估算、取消或降级四种去向，不默认原样带入下一迭代；涉及目标变更需相关角色确认并留痕。
- 处置后设置下一迭代前期、中期、结束三个检查点验证恢复，并把拆分大条目、阻塞检查时点、明确验收标准、控制范围变更等预防动作写入计划或复盘记录。
先确认“未达成”指什么：症状与范围界定
“目标没完成”是一句感受，排查原因前要先把它变成一组可核对的事实。第一步是确认这次迭代承诺的目标属于哪一类，因为不同目标类型的“达成”判断方式不同。
- 承诺范围：计划内要交付的需求条目是否全部完成，完成多少、剩多少。
- 质量门槛：约定的缺陷密度、通过率、性能指标等是否达到，未达标的具体项是什么。
- 时间节点：关键里程碑或发布窗口是否按期，延期了几天。
- 业务结果：上线后的转化、使用量等结果指标是否落在预期区间，这类目标通常需要更长观察周期。
目标类型不同，差距的计量单位也不同。把范围类目标和结果类目标混在一起统计，容易得出“完成了 80%”这类没有实际意义的数字。
核对完成定义与验收状态
统计差距前要统一“完成”的口径。开发提交代码、测试通过、产品验收、可上线，是四个不同状态。团队如果习惯把“已开发未验收”计入完成，迭代结束时的完成率会偏高，真实差距被掩盖。建议以迭代计划阶段约定的验收标准为准，逐条核对每个条目的当前状态，把处于“开发完成待验收”“验收中”“验收未通过”的条目单独列出，不计入已完成。
统计差距并界定影响范围
口径统一后，用三个数字描述差距：未完成条目数、剩余工作量（人天或故事点，与计划口径保持一致）、关键节点的延期天数。接着判断影响范围：未完成的内容是否卡住了下游环节，例如依赖该功能的联调、发布、运营活动；是否需要对客户、合作方或管理层做预期沟通。影响范围决定了后续处置的紧迫程度，也决定了目标调整需要谁参与确认。
这一步的交付物是一份迭代目标差距核对表，至少包含四列：目标口径、计划值、实际值、影响范围。表格完成后，团队对“差多少、差在哪、影响到谁”应有统一认识，再进入原因排查。
逐条验证原因假设：哪些因素真正造成了差距
差距确认后，常见做法是开一次会让大家凭印象说原因，结论往往是“需求变更太多”或“测试太慢”。这类结论把表面现象当成了原因。更可靠的方式是先列出假设，再为每个假设指定可查的证据，逐条验证。
常见假设与对应证据
| 原因假设 | 验证证据 | 证实后的典型表现 |
|---|---|---|
| 范围中途变更 | 迭代内的需求新增、删除、改口径记录；变更发生的时间点 | 迭代后期新增条目集中出现，原计划条目被挤占 |
| 估算偏乐观 | 计划估算与实际工时对比；同类条目历史偏差 | 多数条目实际耗时显著高于估算，且偏差方向一致 |
| 执行阻塞未及时暴露 | 条目在看板上的停留时长；阻塞被提出的时间与解除时间 | 个别条目长时间停在同一状态，直到迭代末才被关注 |
| 外部依赖延迟 | 依赖方的交付时间承诺与实际交付时间；等待天数 | 本团队工作已就绪，进度卡在接口、环境或第三方交付上 |
| 验收标准不清导致返工 | 验收未通过条目数；返工原因记录；验收标准在计划阶段是否明确 | 开发完成后反复修改，返工集中在需求理解分歧处 |
验证时按证据可得性排序，先查记录完整、结论明确的项，例如变更记录和依赖交付时间；再查需要比对分析的项，例如估算偏差。每个假设的结论只写三种：已证实、已排除、证据不足待观察。证据不足的假设不要强行下结论，可以标注需要在下一次迭代继续观察的具体指标。
区分主因与叠加因素
一次未达成往往由多个因素共同造成，但处置资源有限，需要分清主因和叠加因素。判断方法是看贡献度：如果移除某个因素，差距是否仍会显著存在。例如范围变更增加了 30% 的工作量，同时估算整体偏乐观 15%，那么范围变更是主因，估算是叠加因素。主因决定流程改进的重点，叠加因素决定是否需要补充估算校准动作。
同时要记录排除项。确认与本次差距无关的因素，例如“测试环境不稳定”经查只影响了半天且已恢复，就明确排除，避免在复盘时误改流程、增加不必要的管控。排除项本身也是排查成果，应写入原因假设与证据对照清单。
在迭代过程中，看板和燃尽图是支撑这类验证的常用数据来源。ONES 的敏捷研发管理方案支持团队通过敏捷看板管理任务状态，在每日站立会议中对齐进度与风险；燃尽图、工时日志等报表可在迭代回顾时用于复盘进度、质量和成本偏差。这些记录能让“阻塞停留多久”“工时偏差多少”有据可查，减少凭印象归因。
未完成工作的处置：重新评估而非默认结转
原因查清后，处理未完成条目。默认做法是把它们原样带入下一迭代，这会把本次的积压变成下次的起点，下一迭代的计划容量被挤占，目标再次落空的风险随之上升。正确做法是逐条重新评估，给出明确的处置结论。
逐条判断的四种去向
- 仍然必要，原样保留：需求价值未变、范围清晰，重新确认工作量后进入下一迭代。
- 需要拆分：条目过大或包含多个可独立交付的部分，拆成更小的条目分别排期，先交付能独立验收的部分。
- 需要重新估算：原估算明显偏离实际，按已验证的实际投入重新估算，并说明偏差原因。
- 取消或降级：需求价值下降、优先级被其他事项取代，或可缩小范围先满足核心场景。取消和降级同样需要记录理由，便于后续追溯。
每条结论都要落到具体条目上，写明处置结论、责任人和确认记录。责任人负责在下一迭代开始前完成拆分或重新估算；确认记录说明谁参与了决策、依据是什么。涉及目标变更时，例如承诺范围需要缩减或时间节点需要顺延，要明确沟通对象和确认方式：对内部依赖方说明影响和新的交付时间，对管理层说明差距原因与调整方案，对外部相关方按约定渠道同步。调整需经相关角色确认，避免单方面降低承诺。
在 ONES 中，需求和相关任务可规划至迭代并分配负责人，任务工时统计与持续时间估算可用于重新评估工作量；处置结论和确认记录可以随工作项一并留存，使下一迭代的计划有据可依。具体结转或迁移的操作方式以团队实际配置为准。
恢复验证与复发预防
处置动作做完不等于问题解决。需要设置检查点确认恢复，并在下一迭代建立可执行的预防动作。
验证恢复的检查点
- 下一迭代前期：检查重新评估后的条目是否按计划启动，拆分后的子条目是否被正确排期，积压是否在消化而不是继续累积。
- 下一迭代中期：对比燃尽趋势与计划线，观察是否出现新的阻塞停留或范围插入。
- 下一迭代结束：核对目标达成情况与上次差距的对比，确认趋势改善；若差距依旧，回到原因假设清单检查是否有未识别的因素。
复盘时回看本次的原因假设，逐条确认改进动作是否落地。例如“阻塞未及时暴露”被证实为主因，就检查下一迭代是否真的在阻塞出现当天被记录和上报，而不是只在复盘会上口头承诺。
下一迭代的预防动作
预防动作要具体到可检查的行为，避免写成“加强沟通”“提升估算准确性”这类无法验证的表述。可参考的做法包括：
- 把超过一定规模的需求在计划阶段拆分为可独立验收的条目，降低单条目的不确定性。
- 为进行中的条目设置阻塞检查时点，例如连续两个工作日无状态更新即在工作项上标注并上报。
- 在迭代计划会议上明确每个条目的验收标准，验收标准未达成一致的条目不进入承诺范围。
- 控制迭代内范围变更：新增需求需说明对当前目标的影响，经确认后决定替换还是顺延。
- 用历史工时数据校准估算，对偏差较大的条目类型单独记录偏差原因。
这些动作应写入下一迭代的计划或复盘记录，并指定检查人。风险边界同样要交代清楚：调整目标或范围必须经过确认并留痕，单方面降低承诺会让后续的差距核对失去基准。ONES 的迭代回顾环节可借助燃尽图、工时日志等报表复盘进度、质量和成本偏差，团队可以把本次验证结论与预防动作一并记录，作为下一迭代计划会议的输入。
常见问题
迭代目标未达成，未完成的工作可以直接结转到下一迭代吗？
不建议默认原样结转。原样带入会把本次积压变成下一迭代的起点，挤占计划容量，目标再次落空的风险随之上升。更稳妥的做法是逐条重新评估，给出明确去向：仍然必要且范围清晰的，重新确认工作量后进入下一迭代；条目过大的拆成可独立验收的小条目；原估算明显偏离实际的按已验证投入重新估算；价值下降或被更高优先级取代的取消或降级。每条结论写明处置结论、责任人和确认记录，涉及承诺范围缩减或时间顺延的，还需相关角色确认。
团队对“未达成”的差距各说各话，怎么先统一口径？
先确认这次迭代承诺的目标属于哪一类：承诺范围、质量门槛、时间节点还是业务结果，不同目标类型的计量单位不同。然后统一“完成”的口径，把“开发完成待验收”“验收中”“验收未通过”的条目单独列出，不计入已完成。口径统一后，用未完成条目数、剩余工作量、关键节点延期天数三个数字描述差距，再判断是否卡住下游联调、发布或运营活动，以及是否需要对外沟通。形成一份差距核对表后，团队对差多少、差在哪、影响到谁才有共同基准。
原因排查时证据不足怎么办，要不要先下结论？
证据不足的假设不要强行下结论。每个假设的结论只写三种：已证实、已排除、证据不足待观察。对证据不足的项，标注需要在下一次迭代继续观察的具体指标，例如某类条目的估算偏差率或阻塞平均停留时长，等数据积累后再判断。同时要记录排除项，确认与本次差距无关的因素明确排除，避免复盘时误改流程、增加不必要的管控。证据不足不等于该因素不存在，只是当前无法确认。
多个原因同时存在时，怎么决定先改哪个？
看贡献度：如果移除某个因素，差距是否仍会显著存在。例如范围变更增加了 30% 的工作量，估算整体偏乐观 15%，范围变更是主因，估算是叠加因素。主因决定流程改进的重点，叠加因素决定是否需要补充估算校准动作。处置资源有限时，优先针对主因设置预防动作，叠加因素可以安排较轻量的校准措施，并在下一迭代的检查点观察效果。
调整迭代目标或范围，需要谁确认、怎么留痕？
调整需经相关角色确认，避免单方面降低承诺。对内部依赖方说明影响和新的交付时间，对管理层说明差距原因与调整方案，对外部相关方按约定渠道同步。确认记录要写明谁参与决策、依据是什么、调整了哪些条目或节点。在 ONES 中，需求和相关任务可规划至迭代并分配负责人，处置结论和确认记录可以随工作项一并留存，使下一迭代的计划有据可依；具体结转或迁移的操作方式以团队实际配置为准。
