迭代目标未达成，原因通常集中在目标设定、范围控制、执行阻塞、协作交接和验收口径五类，并且往往相互叠加。排查时先界定差距：差多少、差在哪类工作项、统计口径是否一致；再按“目标是否可衡量—范围是否中途膨胀—阻塞是否及时暴露—验收标准是否统一”的顺序找证据。本文给出一套从症状到验证的排查路径，涉及的工作项状态、迭代记录和复盘数据，可以在 ONES 的迭代与项目管理中集中查看。
要点总览（TL;DR）
- 迭代目标未达成通常由目标设定、范围控制、执行阻塞、协作交接和验收口径五类因素叠加造成，排查前先界定差距并统一统计口径。
- 原因判断要用证据支撑：工作项变更记录、阻塞记录、评审记录和验收结论分别对应不同类别的假设，逐项标记已证实、已排除或待验证。
- 排查按固定顺序推进：核对目标与完成定义、查范围变更、查阻塞与依赖、查评审与验收，每一步留下书面结论。
- 未完成工作逐项重新评估优先级和拆分后决定去向，不默认结转到下一迭代，避免下一轮承诺量虚高。
- 处置是否生效看下一迭代的阻塞解除时长、范围变更次数和验收一次通过率，并把完成定义、阻塞上报规则、变更审批条件写入团队约定。
先界定差距：目标未达成具体差在哪里
“目标没达成”是一个笼统结论，直接进入原因讨论容易各说各话。第一步是把结论拆成可观察的差距，让参与排查的人对“差在哪里”有共同口径。差距界定做不实，后面的原因分析很可能是在解释一个并不存在的问题。
先区分目标类型。迭代目标常见四类：交付范围（计划完成哪些需求或工作项）、质量门槛（缺陷数量、验收通过条件）、时间节点（发布或提测日期）、业务结果（上线后的指标变化）。不同类型的目标，差距的衡量方式不同，混在一起谈会掩盖真实问题。
再量化差距。把计划与实际并排放在同一张表里，逐项填写：计划完成多少工作项、实际完成多少、处于什么状态、验收结果如何。数量差距之外，还要看差距的分布——是集中在某几个大需求上，还是分散在大量小任务上，这直接影响后续对原因的判断。
统计口径必须提前确认。完成如何定义（开发完成、测试通过还是已上线）、由谁认定、统计截止到哪个时点，这三项不同，算出来的达成率可能相差很大。实践中常见的“假性未达成”，就是统计时点早于验收完成，或把未进入本轮范围的工作项计入了分母。
| 目标项 | 计划值 | 实际值 | 差距 | 统计口径 |
|---|---|---|---|---|
| 交付范围：本轮需求数 | 12 个需求 | 9 个通过验收 | 3 个未完成 | 以验收通过为准，截止迭代最后一天 |
| 质量门槛：遗留缺陷 | 严重缺陷 0 个 | 严重缺陷 2 个 | 超出 2 个 | 以测试结论为准，含已修复待验证 |
| 时间节点：提测日期 | 第 8 个工作日 | 第 11 个工作日 | 延迟 3 天 | 以首次完整提测时间为准 |
| 业务结果：功能使用率 | 上线两周达 30% | 上线两周为 18% | 低 12 个百分点 | 以埋点统计为准，剔除内部账号 |
这张表填完后，先做一次口径复核：数字是否来自同一数据源、统计时点是否一致、分母是否包含中途移出的工作项。口径误差排除后仍然存在的差距，才是需要进入原因排查的部分。
常见原因假设与对应的排除证据
原因排查最容易犯的错误，是把复盘会上第一个被提出的解释当成结论。更稳妥的做法是先按类别列出假设，再为每类假设指定可查的证据，用证据把假设标记为已证实、已排除或待验证。下面五类假设覆盖了迭代运行中最常见的原因来源。
目标设定类
典型表现是目标本身不可衡量，或目标与团队实际产能不匹配。验证证据包括：迭代开始时目标是否写明了可判断的完成条件；本轮承诺的工作量与此前几个迭代的实际完成量相比处于什么水平。如果连续几个迭代都只完成承诺量的七成左右，问题更可能出在承诺环节，而非执行环节。
范围类
迭代中途插入需求、需求拆分粒度过粗，都会让实际工作量超出计划。验证证据是工作项变更记录：本轮范围内新增了哪些工作项、何时加入、由谁提出；单个工作项的预估与实际耗时差异是否异常大。拆分过粗的需求往往在开发中后期才暴露复杂度，表现为某个工作项长期停留在进行中。
执行类
阻塞未及时上报、关键依赖等待、人力被抽调，属于执行层面的常见原因。验证证据是阻塞记录和状态停留时长：哪些工作项在某个状态停留明显超过预期、阻塞从发生到解除间隔多久、期间是否有成员被临时安排到其他项目。没有阻塞记录时，状态变更时间线本身也能提供线索。
协作类
交接不清、评审延迟、跨团队依赖未对齐，通常表现为工作项在角色之间来回流转。验证证据是评审记录和流转记录：提测到开始测试间隔多久、评审意见返回是否及时、跨团队依赖的对接人和时间点是否在迭代开始前明确。
验收类
完成定义不一致、验收标准中途变更，会让“做完了”和“验收通过”之间出现落差。验证证据是验收结论与标准变更记录：验收未通过的工作项，其不通过理由是否指向迭代初期未写明的条件；验收标准在本轮内是否被修改过、修改后是否同步给开发和测试。
| 原因类别 | 典型假设 | 验证证据 | 判定状态 |
|---|---|---|---|
| 目标设定 | 目标不可衡量或超出产能 | 目标描述、历史迭代完成量对比 | 待验证 |
| 范围 | 中途插入需求、拆分过粗 | 工作项变更记录、预估与实际耗时 | 待验证 |
| 执行 | 阻塞未上报、依赖等待、人力抽调 | 阻塞记录、状态停留时长、人员安排 | 待验证 |
| 协作 | 交接不清、评审延迟、依赖未对齐 | 评审记录、工作项流转记录 | 待验证 |
| 验收 | 完成定义不一致、标准中途变更 | 验收结论、标准变更记录 | 待验证 |
这张对照表的使用要点是：每条假设至少对应一条可查证据，证据指向哪里就标记到哪里。多个假设同时成立是常态，此时需要判断主次——造成差距最大的那一类，才是下一迭代优先调整的对象。
按顺序排查：从范围到验收的处置步骤
假设列全之后，按固定顺序逐项排查，可以避免在证据不足时反复拉扯。推荐顺序是：先确认差距真实存在，再查范围，再查阻塞与依赖，最后查评审与验收。这个顺序的依据是，越靠前的环节影响面越大，前面的问题没排除，后面的分析容易失真。
第一步：核对目标与完成定义
检查对象是迭代目标描述和团队对“完成”的约定。判断依据是：目标是否有可判断的完成条件，统计口径是否与约定一致。处置动作是修正口径、重新计算差距；如果口径修正后差距消失，排查到此结束，记录口径问题作为改进项。
第二步：查范围变更记录
检查对象是本轮工作项的新增、移出和拆分记录。判断依据是变更发生的时间点和数量：迭代前半段的小幅调整属于正常，后半段集中插入则很可能直接导致目标落空。处置动作包括：与提出方确认新增需求的优先级，能移出的移出；对拆分过粗的工作项补充拆分和预估。
第三步：查阻塞与依赖记录
检查对象是阻塞记录、状态停留时长和跨团队依赖清单。判断依据是等待时长和责任人是否明确：一个工作项阻塞三天以上且无明确解除时间，就应视为执行层面的确认原因。处置动作是明确解除责任人和时间点，对无法在本轮解除的依赖，评估是否调整该工作项的范围。
第四步：查评审与验收记录
检查对象是评审意见返回时间、验收结论和不通过理由。判断依据是不通过理由是否指向迭代初期未约定的条件。处置动作是补充完成定义、把验收标准前置到需求评审阶段确认；对因标准不一致而未通过的工作项，与验收方对齐后重新判定。
- 每一步都留下书面结论：检查了什么、看到什么证据、判定为已证实还是已排除。
- 涉及调整已承诺范围时，先与需求提出方和团队负责人确认，明确调整后的目标口径，再更新工作项状态。
- 关闭工作项需要满足停止条件：确认不再需要、或已由其他工作项覆盖，并记录关闭理由，避免事后无法追溯。
排查过程依赖工作项状态、变更和验收记录的可查性。在 ONES 中，产品负责人可以在迭代计划阶段把需求规划进迭代，并与团队就需求和验收标准达成一致，再拆成子任务跟踪；迭代过程中团队通过敏捷看板维护任务状态，在每日站立会议上对齐进度与风险；测试环节以验收标准为依据编写用例，未通过的用例可转为缺陷指派修复；迭代结束后可用燃尽图、工时日志等报表复盘进度与质量偏差。这些记录正好构成上述四步排查所需的证据链。
验证恢复与防止复发
处置动作是否生效，要看下一迭代的数据变化，而不是看复盘会上的表态。验证信号应选择与已确认原因直接对应的指标，并在迭代开始前就约定观察方式。
| 验证信号 | 观察方式 | 改善方向 |
|---|---|---|
| 同类阻塞的平均解除时长 | 对比本迭代与上一迭代的阻塞记录 | 缩短，且无超过约定时长的未解除阻塞 |
| 迭代内范围变更次数 | 统计新增和移出工作项的数量与发生阶段 | 减少，新增集中在迭代前半段 |
| 验收一次通过率 | 统计首次验收通过的工作项占比 | 上升，不通过理由不再指向标准缺失 |
| 承诺量与实际完成量比值 | 对比连续几个迭代的完成情况 | 趋于稳定，波动收窄 |
未完成工作的处理需要单独决策，不能默认结转到下一迭代。正确做法是逐项重新评估：仍然有价值的，重新排优先级并视情况拆分后纳入下一轮；价值已下降或已被替代的，走关闭流程并记录理由；依赖外部条件的，明确条件满足的时间点再安排。默认结转会让下一迭代的承诺量虚高，重复制造“目标未达成”。
复盘时把原因分为可控因素与外部因素两类。可控因素（承诺方式、拆分粒度、阻塞上报、验收标准）形成少量可执行的改进项，每项写明负责人和验证方式；外部因素（政策变化、第三方依赖延期）记录影响，用于后续承诺时预留缓冲。改进项控制在三到五项，过多则难以落实。
最后把机制固化到团队约定中：完成定义写清楚并由开发和验收方共同确认；阻塞上报规则明确上报时限和责任人；范围变更的审批条件写明谁能提出、何时截止、由谁确认。ONES Wiki 可用于沉淀这类团队约定和复盘结论，形成可查阅的知识库，让下一迭代的排查有据可依。
常见问题
迭代目标未达成，复盘会上各角色说法不一致怎么办？
分歧通常来自统计口径不同，而不是事实本身有争议。先把目标项、计划值、实际值、统计口径并排列出，确认完成如何定义、由谁认定、统计截止到哪个时点。口径统一后仍然存在的差距才进入原因讨论。如果口径修正后差距消失，把口径问题记为改进项即可，不必继续追查执行环节。
多个原因同时成立时，下一迭代应该先改哪一个？
按对差距的贡献大小排序，优先处理造成差距最大的那一类。可以用一个简单判断：如果该类原因被消除，差距能缩小多少。范围中途膨胀和承诺量超出产能往往影响面最大，阻塞上报和验收标准不一致则更容易在短期内改善。改进项控制在三到五项，每项写明负责人和验证方式，过多会分散执行。
迭代中途插入紧急需求，是否一定要调整迭代目标？
不一定，取决于插入需求的规模和剩余时间。先与提出方确认优先级，能移出的工作项移出，保持目标口径不变；如果新增工作量超出剩余产能，则需要与需求提出方和团队负责人确认调整后的目标，并更新工作项状态。关键是调整要显式记录，避免迭代结束时才发现范围已经变化而无人知晓。
未完成的工作项直接结转到下一迭代有什么问题？
默认结转会让下一迭代的承诺量虚高，重复制造目标未达成。更稳妥的做法是逐项重新评估：仍然有价值的重新排优先级，必要时拆分后纳入下一轮；价值下降或已被其他工作项覆盖的，走关闭流程并记录理由；依赖外部条件的，明确条件满足的时间点再安排。这样下一迭代的承诺量才反映真实产能。
在 ONES 中排查迭代目标未达成，可以查看哪些记录？
ONES 的迭代与项目管理中，迭代计划阶段的需求规划与验收标准确认、迭代过程中的敏捷看板任务状态、测试环节的用例执行与缺陷记录、迭代结束后的燃尽图和工时日志报表，可以分别对应范围、执行、验收和进度几类证据。团队还可以用 ONES Wiki 沉淀完成定义和复盘结论，供后续迭代查阅。
