发布计划编制时排不出可行日期，通常来自三类问题：同一角色被多个版本争用、关键依赖没有承诺日期、倒排日期与工作量明显不匹配。本文按识别症状、取证确认、分类调整、验证预防的顺序给出处置路径，并说明如何借助 ONES 的项目计划与资源管理能力把冲突和依赖状态放到同一处核对。
要点总览（TL;DR）
- 发布计划排不出可行日期，先拆成资源冲突、依赖未就绪、日期不可行三类，定位主因再决定调整顺序，避免同时改动范围、人员和日期。
- 改计划前先取证：资源冲突对齐人员占用表、版本时间窗与外部支持承诺；依赖逐条确认交付物、责任方、当前状态、承诺日期与验收方式，信息缺失先补信息再判断。
- 资源冲突按错峰、替换、缩减范围、调整窗口依次评估；依赖未就绪用拆分交付、前置里程碑与缓冲、明确准入条件与升级路径处理；日期不可行时优先保范围与质量，新日期留出验证点并书面确认。
- 调整后用依赖清单无空项、资源占用无重叠、关键路径有缓冲、准入检查可执行四项条件验证，仍不满足则暂停发布。
- 把依赖与资源检查前移到编制入口，形成固定检查项与升级机制，并记录本次调整原因供后续版本复盘。
先判断是资源冲突、依赖未就绪还是日期不可行
编制阶段遇到“排不出来”，先不要直接改日期或压缩测试时间。把问题拆成资源冲突、依赖未就绪、日期不可行三类，分别确认主因，再决定先动哪个变量。三类问题经常同时出现，例如关键依赖延期会挤占后续测试资源，资源不足又会反过来压缩依赖交付的时间窗。定位主因的意义在于：调整顺序有先后，避免同时改动范围、人员和日期，导致计划失去可追踪的基准。
需要区分“编制期发现”和“执行期暴露”。编制期发现的问题，此时计划尚未对外承诺，调整空间较大，重点是让计划回到可承诺状态；执行期暴露的问题涉及已启动的工作和对外承诺，处置方式不同。本文聚焦编制阶段的识别与调整。
| 症状表现 | 判断依据 | 初步处置方向 |
|---|---|---|
| 同一角色被多个版本占用，排期重叠 | 角色与人员占用表显示同一时间窗内投入超过可用工时 | 错峰、替换或缩减本版本范围 |
| 关键依赖没有责任方或承诺日期 | 依赖项清单中存在状态为空、日期为空或责任方未确认的条目 | 先补信息，再判断是否真正未就绪 |
| 倒排日期与工作量明显不匹配 | 按发布日期倒推，开发、测试、验证时间之和小于实际所需 | 在范围、资源、日期之间做取舍 |
| 依赖状态显示未完成，但无人能说明卡在哪 | 依赖项缺少当前状态说明与验收方式 | 先取证确认，不直接改期 |
三类问题的关联在于：依赖未就绪往往表现为资源空转，资源冲突又常被误判为日期太紧。先问“哪个变量最刚性”——对外承诺的日期、必须交付的范围、不可替代的人员——再决定从哪一类入手调整。
用证据确认冲突与依赖的真实状态
改计划之前，先把原因假设和证据分开。常见的错误是把“看起来排满了”当成资源确实不足，或把“依赖方没回消息”当成依赖一定延期。取证的目标是让每个冲突和每个依赖都有可核验的状态描述，再据此判断是否需要调整。
资源冲突的取证
资源冲突需要三份材料对齐：角色与人员占用表、各版本的时间窗、外部支持的承诺。占用表要能看到同一人员在每个时间窗内被哪些版本占用、各占多少工时；时间窗要明确各版本的开发、测试、验证起止；外部支持（如共享团队、第三方接口方）要有书面承诺的投入时间和响应周期。三者对齐后，冲突是“总量不足”还是“时间窗重叠”就能区分开，处置动作也不同。
依赖未就绪的取证
依赖项逐条确认四项信息：交付物是什么、责任方是谁、当前状态如何、承诺完成日期与验收方式是什么。缺少任何一项，都先归入“信息缺失”，而不是“确实未就绪”。信息缺失的依赖先补信息，补完后可能发现对方已接近完成，也可能发现根本没有排入对方计划，两种情况的处置完全不同。
排查顺序
- 先确认硬依赖与关键路径：哪些依赖一旦延期会直接推迟发布日期，哪些有替代方案或可并行绕行。
- 再看可调配资源：在关键路径确定后，评估哪些人员可以替换、哪些工作可以错峰。
- 最后评估日期弹性：前两步完成后，剩余的时间缺口才是真正需要靠日期或范围调整解决的部分。
| 待确认项 | 证据来源 | 责任方 | 确认结论 |
|---|---|---|---|
| 某角色在发布窗口内的可用工时 | 人员占用表、工时记录 | 资源经理或项目负责人 | 总量不足 / 时间窗重叠 / 充足 |
| 关键依赖的交付物与验收方式 | 依赖项清单、接口文档或交付说明 | 依赖提供方 | 已就绪 / 有承诺日期 / 信息缺失 |
| 外部支持的投入承诺 | 书面承诺、协作记录 | 外部团队接口人 | 已确认 / 待确认 / 无法承诺 |
| 关键路径上的缓冲余量 | 计划基线、历史同类版本数据 | 发布经理 | 充足 / 偏紧 / 无缓冲 |
取证完成后，把结论写回依赖清单和资源占用表，形成同一份事实基础。ONES Plan 提供多项目进度管控与资源管理，支持制定里程碑和甘特图、多时间跨度查看进度，并可通过资源报表反馈项目投入情况；ONES Resource 支持按工作数量和工时规模查看成员排期、筛选分组掌握成员在不同项目的投入比重。这些信息可以作为占用表和时间窗核对的载体，具体报表口径需结合实际配置确认。
按冲突类型调整计划的具体做法
取证确认主因后，按问题类型选择调整动作。每类动作都要标注影响面：对其他版本排期的影响、对对外承诺的影响、对测试与验证时间的影响。影响面写清楚，调整才可被评审和追踪。
资源冲突的调整
- 错峰排期：把非关键路径上的工作移出冲突时间窗，适用于工作之间没有严格先后依赖的情况。影响面主要是本版本内部顺序变化，对外承诺通常不变。
- 人员替换：替换前确认接替人员具备所需技能，并预留交接和熟悉时间。适用于冲突集中在个别角色、团队内有可替代人员的情况。影响面包括交接成本和短期产出下降。
- 缩减本版本范围：把非必须的功能移出本版本，适用于范围本身有弹性、发布日期刚性的情况。影响面是对外承诺的功能清单变化，需要同步告知相关方。
- 调整发布窗口：在范围不可缩减、人员无法替换时使用。影响面最大，涉及对外沟通和下游计划联动。
依赖未就绪的调整
- 拆分依赖交付：把一个大依赖拆成可分批交付的部分，先拿到满足本版本最低要求的部分，其余部分后续补齐。适用于依赖方整体交付周期长、但部分成果可提前使用的情况。
- 设置前置里程碑与缓冲：在依赖交付和本版本使用之间设置检查点和时间缓冲，缓冲长度参考历史同类依赖的延期幅度。
- 明确准入条件：写清依赖达到什么状态才算可用，包括验收方式和不满足时的处理方式，避免“差不多能用”就进入测试。
- 约定升级路径：依赖方在承诺日期前未交付时，由谁在多长时间内升级到哪一层决策，提前写进计划而不是临时找人。
日期不可行时的取舍
当范围、资源、日期三者无法同时满足时，按优先级取舍：优先保范围和质量的组合，再调整日期，最后才考虑压缩验证时间。给出可承诺的新日期时，要留出验证点——例如依赖到位后的联调检查、发布前的准入检查——而不是把新日期直接定在最后一个开发任务完成之后。新日期需要相关方书面确认，避免口头同意后在执行期反复。
| 问题类型 | 可选动作 | 适用条件 | 影响与风险 |
|---|---|---|---|
| 资源冲突 | 错峰排期 | 工作之间无严格先后依赖 | 本版本内部顺序变化，需重新核对关键路径 |
| 资源冲突 | 人员替换 | 团队内有具备相应技能的可替代人员 | 交接成本与短期产出下降 |
| 资源冲突 | 缩减范围 | 范围有弹性、日期刚性 | 对外功能承诺变化，需同步告知 |
| 资源冲突 | 调整发布窗口 | 范围与人员均无调整空间 | 影响对外承诺与下游计划 |
| 依赖未就绪 | 拆分交付 | 依赖方部分成果可提前使用 | 需明确分批验收标准 |
| 依赖未就绪 | 前置里程碑与缓冲 | 依赖交付周期存在不确定性 | 缓冲占用时间，需评估是否影响发布日期 |
| 依赖未就绪 | 明确准入条件与升级路径 | 依赖方为外部或跨部门团队 | 升级机制需提前获得双方确认 |
| 日期不可行 | 范围、资源、日期三者取舍 | 三者无法同时满足 | 优先保范围与质量，新日期需书面确认 |
调整动作确定后，把变化同步回计划：更新里程碑日期、资源占用和依赖清单状态。ONES Plan 的甘特图支持监控及规划 ONES Project 中相关项目和迭代，查看工作量和进度，可用于在调整后重新核对时间窗与工作量是否匹配；ONES Resource 支持拖拉拽完成项目排期，便于在错峰和替换方案确定后快速重排。排期调整的效果依赖工时与工作量数据的完整登记。
调整后的验证与复发预防
调整完成不等于计划可行。需要用一组可核验的条件确认计划已恢复，再决定是否对外承诺发布日期。验证不通过时，暂停发布并回到调整环节，避免带着未解决的冲突进入执行期。
验证检查表
- 依赖清单中每一项都有责任方、当前状态和承诺完成日期，没有空项。
- 资源占用表中同一人员在发布窗口内没有重叠占用，投入总量不超过可用工时。
- 关键路径上留有缓冲，缓冲长度有依据（历史延期数据或依赖方评估）。
- 发布准入检查可执行：准入条件明确、检查责任人和检查时间已排入计划。
- 调整涉及的范围变化、日期变化已获得相关方确认，并记录在计划中。
设置停止点与回退条件：调整后仍不满足上述准入条件时，暂停发布，而不是压缩测试或跳过验证。停止点要写进计划，明确由谁在什么时间判断是否继续。
复发预防
把本次暴露的冲突和依赖问题转成下一次编制的固定检查项：在编制入口就要求提交资源占用表和依赖清单，把“依赖是否有承诺日期”“关键角色是否被多版本占用”作为计划评审的必查项，并约定检查不通过时的升级机制。本次调整的原因、取舍依据和决策过程记录下来，供后续版本复盘时对照，判断哪些冲突是结构性的、哪些是一次性的。
ONES Resource 支持实时查看成员每日投入饱和明细、识别规划风险，并提供多种资源报表与工时日志导出，可用于在编制入口核对资源占用是否重叠；ONES Plan 的资源报表可反馈项目投入情况。把资源与依赖的核对固定在编制流程的前端，比在发布日期临近时再调整的代价更低。饱和度判断依赖成员工时登记的及时性和准确性，登记不完整时报表只能作为参考。
常见问题
依赖方口头说“下周能给”，但没给具体日期，这种情况算未就绪吗？
按本文的取证标准，这属于“信息缺失”，先补信息再判断，不要直接按延期处理，也不要直接按可用排期。需要向依赖方确认四项内容：交付物具体是什么、责任方是谁、承诺完成日期是哪天、以什么方式验收。补完后可能出现两种结果：对方已接近完成，只需在计划中加一个检查点；或者该依赖根本没有排入对方计划，需要走升级路径。两种情况的调整动作完全不同，提前改期反而可能白改。
资源冲突时优先替换人员还是优先缩减范围？
取决于两个条件。如果冲突集中在个别角色、团队内有具备相应技能的可替代人员，替换的代价主要是交接成本和短期产出下降，可以先评估替换。如果范围本身有弹性、发布日期刚性，缩减本版本范围对交付承诺的影响更可控。两种动作都要标注影响面：替换要预留交接和熟悉时间，缩减范围要同步告知相关方功能清单变化。范围与人员都没有调整空间时，才考虑调整发布窗口。
调整后新日期已经对外承诺，执行中依赖又延期了怎么办？
这正是需要在编制阶段就把升级路径写进计划的原因：约定依赖方在承诺日期前未交付时，由谁在多长时间内升级到哪一层决策。执行期再次延期时，按已约定的升级路径处理，同时回到范围、资源、日期三者取舍，优先保范围与质量，避免压缩测试或跳过验证。如果调整后仍不满足发布准入条件，应暂停发布而不是带病上线，停止点由计划中明确的责任人在约定时间判断。
资源占用表和依赖清单由谁维护，编制时才建来得及吗？
编制时才从零建表，往往要花大量时间补历史数据，还容易因工时登记不全导致占用表失真。更稳妥的做法是把这两份材料作为编制入口的必交项：资源占用表由资源经理或项目负责人维护，依赖清单由发布经理牵头、各依赖责任方确认。ONES Resource 支持实时查看成员每日投入饱和明细、识别规划风险，并提供资源报表与工时日志导出；ONES Plan 提供资源报表反馈项目投入情况。饱和度判断依赖工时登记的及时性和准确性，登记不完整时报表只能作为参考。
小团队人少，错峰和替换都做不了，还有别的调整空间吗？
人少时调整空间主要落在范围和时间窗上。可以先把非关键路径的工作移出冲突时间窗，再看本版本功能清单里哪些可以移到后续版本；如果范围不可缩减，就调整发布窗口，并同步下游计划。依赖侧可以尝试拆分交付，先拿到满足本版本最低要求的部分。无论选哪种，都要在计划中标注对其他版本和对外承诺的影响，并留出验证点，避免新日期直接定在最后一个开发任务完成之后。
