迭代结束时发现目标没达成，先别急着归因或把未完成项直接推到下一轮。更稳妥的做法是先把“未达成”拆成可核对的事实：哪些承诺范围、质量门槛或时间节点没达到，差多少，影响到谁。本文按“界定差距—验证原因—分类处置—验证恢复”的顺序给出一条可执行的处置路径，适用于单个迭代收尾后的诊断与安排。文中会说明如何借助ONES记录迭代工作项、状态与评审信息，便于逐项核对。
要点总览（TL;DR）
- 先把“未达成”拆成可核对的差距清单：区分承诺范围、质量门槛、时间节点，量化差距并确认影响面与决策人。
- 按五类假设逐项找证据：规划与容量、范围变更、执行阻塞、协作交接、验收口径，用证据决定成立、排除还是待查。
- 未完成工作逐项重新评估去向：回退、拆分或带入下轮，带入部分要计入下轮容量，质量返工与外部依赖阻塞分别设定返工范围与停止点。
- 用下一迭代的承诺完成率、阻塞解除时长、返工比例、验收一次通过情况验证恢复，并把改进项转成有负责人和检查时点的具体动作。
- 连续两轮出现同类差距或阻塞反复出现在同一依赖方时，升级到有决策权的层面处理结构性不匹配。
先界定差距：哪些目标没达成、差多少
处置的第一步是把笼统的“没做完”变成一份差距清单。清单要能回答三个问题：差在什么目标上、差了多少、影响了谁。没有这份清单，后续的原因排查容易变成各说各话，处置决定也缺少依据。
先区分目标类型。迭代目标通常混着三类内容：承诺范围（本迭代答应交付的需求或工作项）、质量门槛（验收标准、缺陷等级要求）、时间节点（对外发布时间、下游依赖的就绪时间）。三类目标的差距性质不同，承诺范围缺失是“少做了”，质量门槛未过是“做了但不合格”，时间节点延误是“节奏被打乱”，处置动作也不一样。
再做量化。可核对的口径包括：未完成的工作项数量及其占承诺范围的比例、验收未通过项数与主要不通过原因、关键节点延期天数。量化时以迭代开始时确认的承诺为基准，避免用迭代中途调整过的口径来对比，否则差距会被低估或高估。
然后确认影响面。逐项判断未达成项是否涉及对外承诺（客户交付、合同节点）、是否有下游团队或系统在等待、是否牵连本迭代之外的工作（如已排入下一轮的前置任务）。影响面决定处置的紧迫程度：影响对外承诺的项优先处理，纯内部项可以按价值重排。
最后明确处置边界与决策人。差距清单末尾应列出待决策问题，例如“某需求是回退还是拆分带入下轮”“质量返工是否挤占下轮容量”，并写明由谁拍板、什么时候拍板。边界清楚，后续动作才不会互相等待。
| 差距类型 | 核对口径 | 影响判断 |
|---|---|---|
| 承诺范围未完成 | 未完成工作项数、占承诺比例 | 是否涉及对外承诺、下游依赖 |
| 质量门槛未过 | 验收未通过项数、缺陷等级分布 | 返工工作量、是否阻塞发布 |
| 时间节点延误 | 关键节点延期天数 | 下游就绪时间、对外沟通窗口 |
在ONES中，迭代下的工作项及其状态、验收记录可以作为这份清单的数据来源：按迭代筛选未完成与验收未通过的工作项，逐项标注影响对象和待决策问题，形成一份团队可共同查看的差距清单，避免只存在于个别人的口头判断里。
原因假设与排除证据：五类常见成因怎么验证
差距清单出来后，下一步是找原因。常见误区是从最显眼的线索直接下结论，比如“这轮太忙”或“某人拖了进度”。更可靠的方式是先列出假设，再为每个假设找验证证据，用证据决定成立、排除还是待查。下面五类成因覆盖了多数迭代未达成的场景，可以逐项过一遍。
规划与容量假设
验证方向是：估算是否系统性偏低、可用人力是否被高估（请假、支援其他项目、会议占用）、并行任务是否过多导致切换损耗。证据可以取自本迭代实际投入人天与计划人天的对比、单个工作项实际耗时与估算的偏差、同期并行任务数量。若多数工作项的实际耗时普遍高于估算，或可用人力明显少于规划时假设，该假设成立。
范围变更假设
验证方向是：迭代中是否插入了新需求、验收标准是否中途变化。证据是迭代开始后的工作项新增记录、需求变更记录、验收标准的修改痕迹。注意区分“替换”（有进有出，总量未必增加）与“净增”（只进不出），后者对目标达成的影响更直接。
执行阻塞假设
验证方向是：外部依赖是否按时就绪、环境或权限问题是否造成等待、缺陷返工是否占用了计划外时间。证据包括阻塞项的持续时长、阻塞原因分类、返工工作项数量。若阻塞累计时长足以解释差距量，该假设成立；若阻塞零星且很快解除，则应排除或降权。
协作交接假设
验证方向是：跨角色等待（如开发等设计、测试等环境）、评审排队、信息不同步导致的重复劳动。证据是工作项在各状态间的停留时长，尤其是“待评审”“待验证”等交接状态的堆积情况。交接等待的特点是单个环节看起来都不慢，累计起来却吃掉大量时间。
验收口径假设
验证方向是：完成定义是否一致、验收人是否缺位或延迟。证据是验收环节的往返次数、验收意见的分歧点、验收人响应时间。若工作项“做完了却反复验收不过”，且分歧集中在标准理解而非质量问题，该假设成立。
| 假设 | 验证方式 | 证据来源 | 结论 |
|---|---|---|---|
| 规划与容量 | 对比计划与实际投入、估算偏差 | 工时记录、工作项耗时 | 成立/排除/待查 |
| 范围变更 | 核对迭代内新增与变更记录 | 需求变更记录、验收标准修改 | 成立/排除/待查 |
| 执行阻塞 | 统计阻塞时长与返工量 | 阻塞项记录、缺陷单 | 成立/排除/待查 |
| 协作交接 | 分析状态停留时长 | 工作项状态流转记录 | 成立/排除/待查 |
| 验收口径 | 检查验收往返与分歧点 | 验收意见、评审记录 | 成立/排除/待查 |
排查时允许多个假设同时成立，但应排出主次：能解释大部分差距量的假设是主因，其余作为叠加因素。结论栏写“待查”的项要注明还缺什么证据、由谁补充，避免排查表停在半途。ONES中工作项的状态流转与评审记录可以为交接时长、验收往返提供原始数据，减少凭印象归因的空间。
按差距类型处置：未完成工作如何重新安排
原因清楚后，处置的对象是每一项未完成工作，而不是整个迭代笼统“延期”。处置的核心判断是：这项工作还值不值得做、以什么形态做、什么时候做。默认自动结转到下一迭代会掩盖取舍，让下一轮容量从一开始就被挤占。
承诺范围未完成
逐项重新评估价值与优先级，再决定去向：回退（本迭代不再做，退回需求池等待重排）、拆分（保留核心部分带入下轮，次要部分延后）、带入下轮（整体顺延）。判断依据包括：该需求是否仍对当前业务目标有价值、是否阻塞其他工作、拆分后是否还能独立验收。带入下轮的工作要计入下轮容量，不能当作“额外赠送”。
质量未达标
先定返工范围与验收人，再排入计划。返工范围要具体到缺陷清单或验收不通过项，避免“整体再测一遍”式的模糊安排；验收人要在返工开始前确认，防止返工完成后再次因标准分歧卡住。返工工作量应显式占用下轮容量，并评估是否影响原定的发布节点。
外部依赖阻塞
明确责任人与最晚就绪时间，并设置停止点：到某个时间点依赖仍未就绪，就启动备选方案（降级交付、调整范围或推迟节点），而不是无限等待。停止点要写进处置决定，让等待有明确期限。
范围中途扩张
与提出方确认取舍：新增内容进入本迭代，就要有等量的内容移出，或明确接受目标调整。变更决定要记录在案，包括谁提出、谁同意、移出了什么。没有记录的变更，下一轮复盘时无法还原当时的取舍。
重新评估而非默认结转的依据
支持带入下轮的条件通常是：需求价值未变、拆分后可在下轮容量内完成、不阻塞更高优先级工作。支持回退或延后的条件通常是：需求价值已下降、依赖条件短期无法满足、带入后会挤占下轮承诺范围。无论哪种去向，都应在处置决定清单中写明理由，便于下轮复盘核对判断是否成立。
| 未完成项 | 去向 | 责任人 | 时间点 | 取舍理由 |
|---|---|---|---|---|
| 示例：某功能需求 | 拆分带入下轮 | 需求负责人 | 下轮规划会前 | 核心部分仍支撑当前目标，次要部分延后 |
| 示例：验收未通过项 | 返工并重验 | 开发与验收人 | 下轮第一周内 | 阻塞发布，需优先处理 |
（表中为演示情景，实际填写以团队真实工作项为准。）在ONES中，可以把每项未完成工作的去向、责任人与时间点直接更新到对应工作项的状态和字段上，让处置决定与工作项本身保持同步，下一轮规划时按状态筛选即可看到承接情况。
验证恢复与复发预防：下一迭代怎么确认已回到正轨
处置动作排完并不等于问题解决，需要用下一迭代的实际数据验证是否恢复。验证的关键是选几个能反映真实状态的信号，设定目标值，并在固定时点检查。
可用的验证信号包括：承诺完成率（下轮承诺范围内按时完成的比例）、阻塞解除时长（阻塞从出现到解除的平均时间）、返工比例（返工工作项占已完成项的比例）、验收一次通过情况（首次验收即通过的比例）。这些信号分别对应容量、阻塞、质量、验收口径四类成因，选择与本次主因相关的两三项即可，不必全部铺开。
复盘应聚焦可改的机制项，而不是停留在“下次注意”。可改的机制项通常包括：估算方法（是否引入历史数据校准）、容量预留（是否为支援、会议、返工留出缓冲）、变更入口（迭代中新增需求的审批与置换规则）、完成定义（验收标准是否在开始前明确到可检验）。每项改进要转成下一迭代可跟踪的具体动作，写明负责人和检查时点，例如“下轮规划会前，由迭代负责人用近三轮实际耗时校准估算，产出估算偏差表”。
复发预警需要提前设定。连续两轮出现同类差距（如连续两轮承诺完成率明显偏低），或阻塞反复出现在同一依赖方，说明单次处置没有触及机制层面，应升级处理：由更高层级的管理者介入协调依赖关系，或重新审视该团队的承诺范围与容量假设是否长期不匹配。升级不是追责，而是把超出团队自身能解决的结构性问题放到有决策权的层面处理。
| 验证信号 | 目标值 | 负责人 | 检查时点 |
|---|---|---|---|
| 承诺完成率 | 按团队基线设定 | 迭代负责人 | 下轮迭代结束 |
| 阻塞解除时长 | 较本轮缩短 | 阻塞项责任人 | 下轮迭代中段 |
| 返工比例 | 较本轮下降 | 质量负责人 | 下轮迭代结束 |
| 验收一次通过情况 | 较本轮提升 | 验收人 | 下轮迭代结束 |
目标值应基于团队自身的历史数据设定，没有基线时先记录一轮再定目标，避免拍脑袋定一个无法核对的数字。ONES中的迭代报告与工作项状态数据可以支撑这些信号的统计，把验证结果与处置决定放在同一处对照，下一轮复盘时能直接看到改进动作是否生效。
常见问题
迭代目标未达成，第一步应该做什么？
先把“未达成”转成一份差距清单，再谈原因和处置。清单要写清三件事：差在哪些目标上（承诺范围、质量门槛、时间节点分别列出）、差了多少（未完成工作项数及占承诺比例、验收未通过项数、关键节点延期天数）、影响到谁（对外承诺、下游依赖、本迭代之外的工作）。
量化时以迭代开始时确认的承诺为基准，避免用中途调整过的口径对比。清单末尾列出待决策问题和决策人，后续排查与处置才有共同依据。
怎么判断未达成的真实原因，避免凭感觉归因？
用假设—证据的方式排查，而不是从最显眼的线索直接下结论。把常见成因归为五类：规划与容量、范围变更、执行阻塞、协作交接、验收口径，为每类写出验证方式和证据来源。
例如容量假设看实际投入与计划投入的偏差、估算与实际耗时的偏差；交接假设看工作项在“待评审”“待验证”等状态的停留时长。多个假设可以同时成立，但要排出主次：能解释大部分差距量的是主因，其余作为叠加因素。结论写“待查”的项要注明缺什么证据、由谁补充。
未完成的工作能不能直接结转到下一迭代？
不建议默认结转。逐项重新评估后再定去向：回退到需求池等待重排、拆分后带入下轮、整体顺延。判断依据包括需求价值是否仍支撑当前目标、拆分后能否独立验收、是否阻塞更高优先级工作。
带入下轮的工作必须计入下轮容量，不能当作额外任务叠加，否则下一轮从一开始就超载。质量返工要明确返工范围与验收人，并显式占用容量；外部依赖阻塞要写明责任人和最晚就绪时间，并设置停止点，到期未就绪就启动备选方案。每项去向和取舍理由都记录下来，便于下轮复盘核对。
处置之后，怎么确认团队已经回到正轨？
用下一迭代的实际数据验证，选与本次主因相关的两三项信号即可：承诺完成率、阻塞解除时长、返工比例、验收一次通过情况。为每项设定目标值、负责人和检查时点。没有历史基线时，先记录一轮再定目标，避免设定无法核对的数字。
复盘聚焦可改的机制项，如估算方法、容量预留、变更入口、完成定义，并把每项改进转成下一迭代可跟踪的具体动作。若连续两轮出现同类差距，或阻塞反复出现在同一依赖方，说明单次处置未触及机制层面，应升级到有决策权的层面协调。
迭代中途插入需求导致目标偏移，处置时要注意什么？
先区分“替换”和“净增”：有进有出、总量未增的替换影响有限；只进不出的净增会直接挤压承诺范围。处置时与提出方确认取舍——新增内容进入本迭代，就要有等量内容移出，或明确接受目标调整。
变更决定要记录在案，包括谁提出、谁同意、移出了什么。没有记录的变更，复盘时无法还原当时的取舍，也容易让同类插入在下一轮重复发生。可以在迭代中设置变更入口规则，明确谁能批准插入、以什么为置换条件。
