发布日期不可行，往往在计划编制阶段就能通过几类信号看出来：关键路径剩余工作量超出可用时间、关键依赖迟迟未就绪、关键角色被并行任务占满。本文给出一条从识别症状、验证原因到按顺序重排计划、验证恢复效果的路径，帮助团队把“感觉来不及”转成可核对的数据，再决定压缩、调依赖、缩范围还是改期。文中涉及计划与依赖记录的部分，会说明 ONES 可承载的方式。
要点总览（TL;DR）
- 发布日期不可行通常表现为关键路径剩余工作量与剩余时间倒挂、关键依赖未按承诺就绪、关键角色被并行任务占满、联调与测试窗口被压缩；缺口能否被局部追赶消化，是区分单点延期与整体不可行的关键。
- 原因排查按关键路径、关键依赖、资源冲突的顺序推进，每类假设都要落到任务剩余工时、依赖承诺日期与实际状态、资源占用表、评审与测试队列等具体记录，没有证据的假设不进入处置。
- 重排按压缩、调整依赖、缩减范围、移动发布日期的顺序进行，每一步设定风险边界；压缩与依赖调整都无法消除缺口时停止，转入改期决策。
- 变更前留存原计划基线，范围裁剪经需求方确认，涉及对外承诺日期走审批；新日期基于重算后的关键路径确定。
- 重排后用关键路径里程碑达成率、依赖就绪率、剩余工作量与剩余时间的比值变化验证可行性，并在关键依赖交付日和联调开始前设置复核点。
发布日期不可行的典型症状与判断范围
判断发布日期是否不可行，先看信号是否集中在关键路径上。一般进度波动表现为个别任务延后、非关键路径上的工作有浮动时间可以吸收；发布日期不可行则表现为关键路径上的缺口无法在剩余时间内闭合。以下症状清单可用于逐项对照。
| 症状 | 可观察表现 | 指向 |
|---|---|---|
| 关键路径剩余工作量与剩余时间倒挂 | 关键路径任务剩余工时合计大于剩余可用工时，且无并行空间 | 整体日期存在缺口 |
| 关键依赖未就绪 | 上游交付物未按承诺日期提供，下游任务处于等待状态 | 缺口可能继续扩大 |
| 关键角色资源冲突 | 核心开发、测试或联调负责人同时承担其他版本或项目任务 | 关键路径实际可用人力不足 |
| 联调与测试窗口被压缩 | 开发延后挤占联调、回归测试时间，测试轮次减少 | 质量风险上升，日期可信度下降 |
区分单点延期与整体不可行，关键看缺口能否被局部追赶消化。单点延期通常有浮动时间或可替换资源，通过局部加班、调整任务顺序即可回到原计划；整体不可行则表现为多个关键路径任务同时延后、关键依赖连续未就绪，缺口在剩余时间内无法通过局部动作消除。此时继续按原日期推进，只会把压力转移到测试和发布环节。
判断范围限定在当前版本的发布计划：本版本要交付哪些需求、依赖哪些上游交付物、关键角色投入多少、联调与测试留出多少窗口。产品功能版本规划、制品本体与研发交付物管理不在本文讨论范围内，相关决策应在各自的规划流程中处理。
逐项验证原因：哪些假设有证据支撑
识别出症状后，常见的原因假设有四类：工作量低估、依赖方交付延迟、资源被并行任务占用、评审与测试环节排队。这些假设不能直接当作结论，需要逐项找到证据。排查顺序建议先关键路径、再关键依赖、再资源冲突，因为关键路径上的缺口对发布日期的影响最直接。
| 原因假设 | 验证证据 | 可判定不成立的情况 |
|---|---|---|
| 工作量低估 | 关键路径任务的剩余工时记录、已完成任务的实际耗时与估算对比 | 剩余工时合计小于剩余可用工时，且历史估算偏差在可接受范围内 |
| 依赖方交付延迟 | 依赖承诺日期、实际状态、依赖方给出的新预计日期 | 依赖已按承诺日期就绪，或延迟部分不在关键路径上且有浮动时间 |
| 资源被并行任务占用 | 资源占用表、关键角色在各项目上的投入比例与时间段 | 关键角色在本版本关键路径上的投入未被其他任务挤占 |
| 评审与测试环节排队 | 评审与测试队列长度、平均等待时间、当前待处理条目数 | 队列长度在正常范围，测试窗口足以覆盖计划轮次 |
排查时先看关键路径：把关键路径任务的剩余工时与剩余可用工时逐项对照，确认缺口是否真实存在。如果关键路径本身没有缺口，再看关键依赖是否按承诺日期就绪；依赖延迟但不在关键路径上，通常不构成发布日期不可行的直接原因。最后核对资源占用，确认关键角色在剩余时间内的实际可用投入。每一类原因都要落到具体记录，没有证据支撑的假设不进入处置环节。
排除证据的写法要具体。例如“依赖方交付延迟”不成立，应写明依赖已按承诺日期交付、下游任务已开始执行，而不是笼统地说“依赖没问题”。同样，“资源冲突”不成立，应写明关键角色在本版本关键路径上的投入比例未被其他任务占用。证据越具体，后续重排决策越有依据。
按顺序处置：从压缩到改期的重排步骤
确认缺口存在后，按压缩、调整依赖、缩减范围、移动发布日期的顺序推进。这个顺序的原则是优先用影响面较小的动作消除缺口，每一步都设定风险边界，前一步无法消除缺口时再进入下一步。
第一步：压缩。识别可并行、可裁剪的非关键路径工作，评估压缩后的质量风险。可并行的任务包括原本串行的开发与文档准备、部分联调准备工作；可裁剪的工作包括非必要的评审轮次、可延后的优化项。压缩的风险边界在于测试与联调窗口：如果压缩导致回归测试轮次不足，缺口只是从开发转移到了质量环节，并未真正消除。
第二步：调整依赖。与依赖方确认新的交付节点，明确未就绪时的替代方案。替代方案可以是使用临时接口、降级方案或分批联调。这一步的风险边界在于依赖方的新承诺是否可信：如果依赖方无法给出明确日期，或新日期仍晚于关键路径需要的时间，应视为依赖调整未能消除缺口。
第三步：缩减范围。列出可移出本版本的需求及其影响面，包括受影响的用户场景、关联需求、对外说明。范围裁剪需经需求方确认，涉及对外承诺的功能变更应同步相关方。风险边界在于裁剪后的版本是否仍构成一个可交付、可验证的完整版本。
第四步：移动发布日期。给出新的候选日期与需要同步的对象，包括依赖方、测试资源、发布相关方和对外承诺对象。新日期应基于重算后的关键路径，而不是在原日期上简单加几天。
破坏性操作前需要满足前置条件：变更前留存原计划基线，便于后续对比偏差；涉及范围裁剪需经需求方确认；涉及对外承诺日期需走审批。停止点设在压缩与依赖调整都无法消除缺口时，此时继续压缩只会累积质量风险，应转入改期决策。
重排后的验证与复发预防
新计划是否可行，需要用指标验证，而不是等到发布前再判断。建议跟踪三类指标：关键路径里程碑达成率，反映关键节点是否按新计划推进；依赖就绪率，反映上游交付物是否按新承诺日期到位；剩余工作量与剩余时间的比值变化，反映缺口是在缩小还是继续扩大。如果比值持续上升，说明新计划仍不可行，需要再次评估。
复核节点应设在关键依赖交付日和联调开始前。关键依赖交付日检查依赖是否就绪、替代方案是否启用；联调开始前检查开发完成度、测试环境与测试资源是否到位。每个复核节点给出明确的通过条件，未通过时触发对应的处置动作，而不是等到发布前集中暴露问题。
复发预防的重点在计划编制环节：发布计划编制时同步登记依赖承诺日期与资源占用，保留计划基线用于偏差对比。这样下次出现类似信号时，可以直接对照基线判断是估算偏差、依赖延迟还是资源冲突，缩短诊断时间。
在 ONES 中，工作项状态、里程碑与计划基线可以承载上述核对与复核动作：关键路径任务的状态变化、依赖交付节点的里程碑、计划基线的留存，都能为症状识别和重排验证提供记录。ONES Assistant 可基于项目、缺陷与资源数据提前识别风险，并基于项目目标、范围和关键交付物生成结构化计划与里程碑，生成结果需人工复核后使用。具体功能范围以实际部署与套餐为准。
常见问题
关键路径上没有缺口，但依赖方一直未交付，需要重排发布日期吗？
先确认这条依赖是否在关键路径上。依赖延迟但不在关键路径上、且有浮动时间可以吸收时，通常不构成发布日期不可行的直接原因，按正常依赖跟踪处理即可。如果依赖位于关键路径，或延迟已经吃掉下游任务的浮动时间，就需要按重排步骤处理：先与依赖方确认新的交付节点和替代方案，替代方案仍无法满足关键路径需要的时间时，再考虑缩减范围或移动发布日期。
压缩和缩减范围都能消除缺口时，应该优先选哪个？
按影响面从小到大选择。压缩优先作用于可并行、可裁剪的非关键路径工作，影响面通常小于范围裁剪；但要检查压缩是否把缺口转移到测试与联调环节，如果回归测试轮次因此不足，缺口并未真正消除。范围裁剪涉及需求移出本版本，需要需求方确认并评估对用户场景和对外说明的影响。两类动作都能消除缺口时，优先选择对交付内容和质量承诺影响更小的那个，并把选择依据记录在计划变更中。
依赖方给不出明确的新交付日期，计划该怎么往下走？
把这种情况视为依赖调整未能消除缺口。可以要求依赖方给出分阶段的交付承诺，例如先提供可联调的临时接口或降级方案，让下游任务部分启动；同时评估该依赖对应的需求是否可以从本版本移出。如果依赖方在约定时间内仍无法给出可信日期，应进入改期决策，而不是继续按原日期推进。相关结论和依赖方的沟通记录一并留存，便于后续复盘。
新计划排出来后，怎么判断它是真的可行？
看三类指标的变化趋势：关键路径里程碑是否按新计划达成、依赖是否按新承诺日期就绪、剩余工作量与剩余时间的比值是否在收敛。比值持续上升说明缺口仍在扩大，新计划需要再次评估。复核点设在关键依赖交付日和联调开始前，每个点给出明确的通过条件，未通过时触发对应处置，避免问题集中到发布前才暴露。
改期涉及对外承诺的发布日期，内部需要走哪些确认？
对外承诺日期的变更通常需要走审批，并同步依赖方、测试资源、发布相关方和对外沟通对象。变更前留存原计划基线，记录改期原因、重算后的关键路径依据和新的候选日期，便于后续对比偏差。范围裁剪如果同时发生，还需经需求方确认，并评估裁剪后的版本是否仍是可交付、可验证的完整版本。
