迭代目标未达成时，先别急着开复盘会追责，也别直接把未完成项拖进下一轮。更稳妥的顺序是：把“未达成”拆成可核对的事实，逐条验证原因假设，再决定每个未完成项的去向，最后用下一轮数据验证处置是否生效。本文按这四步展开，并在处置环节说明 ONES 可以承载哪些记录与跟踪动作。
要点总览（TL;DR）
- 先把“未达成”拆成事实清单：目标项、计划口径、当前状态、差距与影响，并区分目标项未完成、验收未通过、范围中途扩大三类情形。
- 原因分析用假设—证据—结论的方式逐条核对，标注已证实、已排除、待观察，避免凭感觉归因。
- 未完成项逐项判断去向：仍需做、需拆分、需重排优先级、应关闭；重新评估而非默认结转，避免遗留工作量挤占下一轮容量。
- 处置后在下一次迭代评审中用目标达成率、结转项占比、阻塞平均停留时长、范围变更次数四项指标对比验证。
- 把估算校准、阻塞清理节奏、变更准入规则写入迭代运行约定，并预设指标未改善时的再诊断触发条件。
先确认“未达成”具体指什么
“目标没达成”是一句感受，不能直接作为诊断起点。第一步要把它转成一份事实清单：本轮迭代设定了哪些目标项，每项的计划口径是什么，当前状态如何，差距有多大，对后续工作有什么影响。清单落到具体工作项上，后续的原因分析和处置才有共同对象。
实际操作中，“未达成”通常混着三类不同情形，需要分开记录：
- 目标项未完成：计划内的工作项仍处于进行中、待开始或已搁置状态，交付物没有产出。
- 验收未通过：工作项状态显示已完成，但评审或测试结论不通过，实际未达到迭代约定的验收标准。
- 范围中途扩大：迭代期间新增了需求或目标项，导致原定目标被稀释，完成情况需要按变更前后的口径分别统计。
三类情形的处置方向不同。第一类要判断工作本身是否还值得做；第二类要回到验收标准找分歧；第三类要先确认变更是否经过准入。混在一起统计，容易得出“团队产能不足”这类笼统结论。
事实清单建议包含五列：目标项、计划口径（项数、验收标准或关键结果）、当前状态、差距描述、影响范围。填写时注意两点：一是时间盒要写清楚，本轮迭代的起止日期和目标是哪个版本的口径；二是状态以系统记录为准，避免凭记忆补填。清单完成后，团队对“差多少”应能达成一致，再进入原因分析。
逐条验证原因假设，而不是先下结论
原因分析常见的失误是先有结论再找证据，比如直接认定“估算不准”或“需求变更太多”。更可靠的做法是先列出若干条原因假设，再为每条假设指定证据来源，逐条核对后标注已证实、已排除或待观察。下表给出一组常用假设与对应的验证证据。
| 原因假设 | 验证证据 | 数据来源 |
|---|---|---|
| 范围中途变更 | 迭代开始后新增或修改的目标项数量、变更是否经过确认 | 变更记录、迭代目标版本对比 |
| 估算偏乐观 | 计划工时或故事点与实际投入的偏差分布，是否集中在某类工作 | 工时日志、工作项完成时间 |
| 阻塞未及时清除 | 阻塞发生的时间点、持续时长、解除方式 | 阻塞记录、每日站会记录、看板状态流转 |
| 外部依赖延迟 | 依赖方的交付时间与原定时间的差距，影响的工作项范围 | 依赖事项记录、跨团队沟通结论 |
| 验收标准不清 | 评审中返工或争议的工作项数量，争议点是否集中在标准表述 | 评审结论、测试缺陷记录 |
核对时要注意区分主因与伴随现象。例如“迭代后期集中加班”往往是结果，背后可能是阻塞在中段堆积，也可能是范围在前期悄悄扩大。判断主因可以用一个简单标准：如果这条原因不成立，未达成是否仍然会发生？若答案是否定的，它更接近主因；若去掉它缺口依然存在，它更可能是伴随现象。
诊断结论应写成“假设—证据—结论”的形式，并保留待观察项。有些原因在本轮数据中证据不足，比如依赖延迟只影响了个别工作项，是否构成系统性问题需要下一轮继续观察。把待观察项带入下一轮，比强行给出确定结论更有价值。
在证据收集环节，工作项状态流转、看板上的进度与风险对齐、燃尽图反映的剩余工作量趋势，都是常用的核对材料。ONES 的敏捷研发管理方案中，团队通过敏捷看板管理任务状态，在每日站会中借助看板对齐进度与风险，燃尽图可用于评估当前研发效率；迭代回顾时还可以结合工时日志等报表复盘进度、质量和成本偏差。这些记录正好对应上表中的证据来源，前提是团队在日常运行中持续更新状态，而不是迭代结束后补录。
未完成工作的处置顺序与风险边界
诊断完成后，先冻结本轮结论：把未达成事实清单和原因诊断结论记录归档，明确本轮迭代不再追加目标，也不在结论未定时改动下一轮计划。冻结的目的是让后续处置有稳定依据，避免边分析边调整导致口径反复。
然后对每个未完成项逐项判断去向，常见结论有四类：
- 仍需做：工作本身仍有价值，验收标准不变，重新评估优先级后放入下一轮或后续迭代。
- 需拆分：原工作项粒度过大或包含多种交付物，拆成可独立验收的子项后再排期。
- 需重排优先级：业务价值或紧急程度已变化，调整在待办列表中的位置，可能延后。
- 应关闭：需求已失效、被其他方案覆盖或价值不再成立，走关闭流程并保留记录。
这里的关键判断是重新评估而非默认结转。默认结转会把未经确认的工作量原样带入下一轮，下一轮的目标容量被上一轮的遗留占满，目标达成率持续失真，团队也难以判断新目标的真实难度。重新评估的标准可以归纳为三条：这项工作现在是否仍有明确的业务价值；验收标准是否仍然清晰可验；下一轮是否有足够容量承接。三条都成立才进入下一轮，否则拆分、降级或关闭。
涉及关闭或降级已承诺的需求时，要交代风险边界：明确确认人，通常由需求提出方或产品负责人确认；保留原始工作项记录和关闭原因，不做物理删除；设定停止点，即在确认人未回复前不执行关闭，可先标记为待确认并单独列出。跨团队依赖的工作项，还需同步通知依赖方，避免对方按原计划等待交付。
处置清单建议逐项记录：工作项、诊断关联原因、处置结论、责任人、去向（下一轮、待办、已关闭）、确认状态。这份清单既是下一轮计划的输入，也是复盘时核对处置是否执行的依据。在 ONES 中，需求可按优先级规划至对应迭代，迭代计划会议上团队共同评审需求并对验收标准达成一致，未完成项的去向判断可以依托这套规划与评审动作完成；关闭或调整后的记录保留在工作项历史中，便于后续追溯。
下一轮如何验证恢复并防止复发
处置是否有效，不能靠“感觉这轮顺畅多了”来判断，需要在下一次迭代评审中用同一口径的指标对比。建议至少跟踪四项：
| 指标 | 计算口径 | 观察重点 |
|---|---|---|
| 目标达成率 | 本轮完成并通过验收的目标项数 ÷ 本轮目标项总数 | 与上一轮对比是否回升，缺口集中在哪类工作 |
| 结转项占比 | 从上一轮结转而来的工作项数 ÷ 本轮全部工作项数 | 占比是否下降，结转项是否挤占新目标容量 |
| 阻塞平均停留时长 | 各阻塞从发生到解除的平均时长 | 是否缩短，长尾阻塞是否减少 |
| 范围变更次数 | 迭代开始后经确认的目标项新增或修改次数 | 是否收敛，变更是否集中在迭代前期 |
复核放在下一轮迭代评审中进行，与本轮数据并列展示，重点看趋势而非单点数值。一轮数据好转不足以证明机制生效，连续两轮改善才更有说服力；若某项指标持平或恶化，回到原因假设表检查是否遗漏了未验证的解释。
复发预防要写进迭代运行约定，而不是停留在复盘会的口头共识。可落地的约定包括：估算校准，对偏差较大的工作类型在计划会上做对照参考，必要时拆小工作项；阻塞清理节奏，明确每日站会检查阻塞并在当天指定解除责任人；变更准入规则，迭代开始后的新增需求需经产品负责人确认并说明对原目标的影响。约定写成简短条目，附在迭代规则文档中，下一轮计划会开始时对照检查。
还需要预设回退条件：如果下一轮目标达成率没有改善、结转项占比继续上升，或阻塞停留时长明显拉长，应触发再诊断，重新走一遍事实核对与原因验证，而不是继续叠加新的改进措施。把触发条件提前写清楚，可以避免问题被“再观察一轮”拖延。迭代回顾中形成的经验，可以沉淀到团队知识库，供后续迭代直接引用。
常见问题
迭代目标未达成，复盘会应该先讨论什么？
复盘会先对齐事实，再讨论原因。开场时把本轮迭代的事实清单摆出来：目标项有哪些、每项的计划口径、当前状态、差距和影响范围，让团队对“差多少”先达成一致。事实口径统一后，再进入原因假设的逐条核对，避免会议一开始就陷入“是谁的问题”的争论。
如果事实清单本身有争议，比如某项工作算不算完成、验收标准怎么理解，应先解决口径分歧，把争议项单独列出并明确确认人，其余部分照常推进。
未完成的工作项直接结转到下一轮，会带来什么问题？
默认结转会把未经确认的工作量原样带入下一轮，下一轮的目标容量被上一轮遗留占满，目标达成率持续失真，团队也难以判断新目标的真实难度。更稳妥的做法是逐项重新评估：这项工作现在是否仍有明确的业务价值、验收标准是否仍然清晰可验、下一轮是否有足够容量承接。三条都成立才进入下一轮，否则拆分、降级或关闭。
关闭或降级已承诺的需求时，需要哪些确认？
涉及关闭或降级已承诺的需求，要明确确认人，通常由需求提出方或产品负责人确认；保留原始工作项记录和关闭原因，不做物理删除；设定停止点，即在确认人未回复前不执行关闭，可先标记为待确认并单独列出。跨团队依赖的工作项还需同步通知依赖方，避免对方按原计划等待交付。
下一轮指标改善了，是否就可以认为问题已经解决？
一轮数据好转不足以证明机制生效，建议连续两轮观察趋势。复核时把本轮与上一轮数据并列展示，重点看趋势而非单点数值。若某项指标持平或恶化，回到原因假设表检查是否遗漏了未验证的解释，必要时触发再诊断，重新走一遍事实核对与原因验证。
团队日常记录不完整，还能做原因诊断吗？
可以，但结论的确定性会下降。工作项状态流转、阻塞记录、变更记录、评审结论是主要证据来源，记录缺失时，可先用现有材料核对能验证的假设，把证据不足的解释标注为待观察，并在下一轮补齐记录习惯。ONES 的敏捷看板、燃尽图和工时日志等报表可作为日常记录的载体，前提是团队在迭代过程中持续更新，而不是结束后补录。
