前置任务延期后，当前任务的截止日期是否需要修改，取决于延期是否已经吃掉可用时间，以及下游承诺能否调整。改日期本身只是动作，关键在于选对处置方式，并把判断依据、影响范围和审批结果写成一条与工作项绑定的变更记录。下面按判断、选路径、写记录、定分工、看示例、做检查的顺序展开，并在记录留存环节说明ONES工作项如何承载期限变更历史与依赖关系。
要点总览（TL;DR）
- 前置任务延期后先核对三组输入：前置最新预计完成时间、当前任务剩余工作量、对下游的承诺时间，用最早可完成时间与原截止日期比较，区分缓冲被压缩和期限真正失效。
- 处置路径按依赖真实性、可拆分性、截止日期刚性和范围可裁剪程度依次判断：依赖设错先调依赖，有可先交付部分则拆分，日期刚性且范围可裁剪则缩范围，前置确定且下游可接受则顺延。
- 期限变更记录一次变更一条，必填任务标识、变更前后截止日期、可核对的原因、处置方式、影响范围、提出人、审批人和生效时间，原因要写明具体前置任务及延期天数。
- 变更由任务负责人提出、前置任务负责人确认事实、排期负责人审批、下游负责人确认影响，记录与工作项绑定，保证打开任务即可看到历次期限变更。
- 检查以记录完整、原因可核对、工作项日期与最新记录一致、下游已确认为通过标准；无原因、无审批、日期不一致为阻断项，需补充后再生效。
先判断原截止日期是否真的不可行
前置任务延期并不自动意味着当前任务要改期。先核对三组输入，再给出结论，可以避免把缓冲被压缩误判为期限失效。
- 前置任务的实际完成时间或最新预计完成时间：向该任务负责人确认，取有依据的日期，不用口头估计。
- 当前任务的剩余工作量：按剩余工作项或人天估算，明确从哪天开始可投入。
- 当前任务对下游的承诺时间：下游任务或外部交付方约定的时间点，决定改期的连带成本。
判断动作是把前置最新预计完成时间与当前任务剩余工作量相加，得到最早可完成时间，再与原截止日期比较。若最早可完成时间仍在原截止日期之前，说明延期只是压缩了缓冲，结论为维持原期；若超出原截止日期但下游承诺可协商，结论为需要处置；若超出且下游承诺刚性，结论为需要上报，由排期负责人决定是否调整下游安排。
| 任务 | 原截止日期 | 前置最新预计完成 | 剩余工作量 | 结论 | 依据 |
|---|---|---|---|---|---|
| 联调任务 | 3月20日 | 3月18日 | 3人天 | 维持原期 | 最早可完成3月21日，缓冲不足但可通过并行压缩 |
| 联调任务 | 3月20日 | 3月24日 | 3人天 | 需要处置 | 最早可完成3月27日，超出原期7天 |
| 联调任务 | 3月20日 | 3月24日 | 3人天 | 需要上报 | 下游验收固定在3月22日，无法顺延 |
结论要写明依据，并作为后续处置和记录的事实基础。判断结论为维持原期时，也建议在任务备注中说明缓冲已被压缩，便于后续复盘。
四条处置路径怎么选：顺延、拆分、调依赖、缩范围
确认需要处置后，在四条路径中选择一条或组合。选择依据集中在四个条件：截止日期是否刚性、下游承诺可调整程度、范围可裁剪程度、依赖关系是否真实。
| 路径 | 适用条件 | 代价与注意点 |
|---|---|---|
| 顺延截止日期 | 前置延期已确定，当前任务范围不变，下游可接受新时间 | 需要下游确认，可能连带调整后续排期 |
| 拆分任务 | 当前任务中有一部分不依赖延期前置，可以先交付 | 增加任务数量和交接成本，需明确拆分后的验收口径 |
| 调整依赖关系 | 依赖本身设错，如误设为强依赖、实际可并行或可提前介入 | 需要重新确认依赖真实性，避免为赶期而弱化必要约束 |
| 缩减范围 | 截止日期不可动，只能减少交付内容 | 需要范围决策人确认，并记录被移出的内容去向 |
建议的判断顺序是：先看依赖关系是否真实，若依赖设错，调整依赖即可解决，成本最低；再看当前任务能否拆分出可先交付的部分；若截止日期刚性且范围可裁剪，选择缩减范围；当前置延期确定、范围不变、下游可接受时，选择顺延。实际场景中常出现组合，例如拆分出可先做的部分，其余部分顺延，此时记录中要分别写明两条处置。
期限变更记录要写哪些字段
变更记录的价值在于让后来查看任务的人能还原这次改期的完整逻辑。一次变更写一条记录，不把多次改动合并成一条。
| 字段名 | 是否必填 | 填写说明 | 示例值 |
|---|---|---|---|
| 任务标识 | 必填 | 任务编号与名称 | PAY-128 支付联调 |
| 变更前截止日期 | 必填 | 原定日期 | 3月20日 |
| 变更后截止日期 | 必填 | 新日期，拆分或缩范围时写明对应部分 | 3月27日 |
| 变更原因 | 必填 | 关联具体前置任务及其延期事实，写到可核对 | 前置任务PAY-110接口开发由3月15日延至3月24日，延期9天 |
| 处置方式 | 必填 | 顺延、拆分、调依赖、缩范围之一或组合 | 拆分+顺延 |
| 影响范围 | 必填 | 受影响的下游任务、交付物或外部承诺 | 影响下游PAY-135回归测试，需同步顺延2天 |
| 提出人 | 必填 | 任务负责人 | 张三 |
| 审批人 | 必填 | 排期负责人或项目经理 | 李四 |
| 生效时间 | 必填 | 审批通过并更新工作项的时间 | 3月10日14:00 |
| 变更编号 | 辅助 | 同一任务多次变更时按序编号 | PAY-128-CR-02 |
| 关联依赖调整 | 辅助 | 本次是否同时调整了依赖关系 | 无 |
| 是否触发范围变更 | 辅助 | 缩范围时必填，写明移出内容 | 否 |
填写要求有两条：原因写到可核对的事实，写明哪个前置任务、延期多少天，避免“因进度原因”这类无法追溯的表述；一次变更一条记录，后续再次改期时新增记录，保留历史。
角色分工与记录流转
变更记录要真正被维护，需要明确谁提出、谁确认、谁审批、谁接收，以及记录存放在哪里。
| 角色 | 动作 | 产出 |
|---|---|---|
| 任务负责人 | 提出变更，填写原因与影响，给出新日期 | 变更记录草稿 |
| 前置任务负责人 | 确认延期事实与最新预计完成时间 | 可核对的前置日期 |
| 项目经理或排期负责人 | 审批是否接受新日期或改用其他处置方式 | 审批结论 |
| 下游任务负责人 | 接收影响通知，确认是否连带调整 | 下游确认结果 |
流转顺序为：任务负责人发起并填写记录，前置任务负责人确认延期事实，排期负责人审批处置方式，审批通过后更新工作项截止日期并记录生效时间，最后通知下游任务负责人确认。记录位置应与工作项绑定，保证任何人打开该任务都能看到历次期限变更，而不是散落在聊天记录或单独表格中。
ONES 的 ALM 研发管理方案围绕需求、基线、版本和变更建立统一管理对象，支撑变更影响分析与过程状态追踪；其数字线程连接需求、开发、测试、变更和发布等环节，需求变化时可沿关联关系分析受影响的任务与交付内容，并保留过程追踪和审计依据。对于工作项层面的期限变更，可将变更原因、影响范围和审批结论作为工作项记录留存，使期限调整与依赖关系在同一任务上下文中可查。具体记录字段与依赖配置方式以实际使用版本为准。
示例：一次前置延期引发的期限变更
以下为演示情景。支付联调任务PAY-128原定3月20日截止，其前置任务PAY-110接口开发原定3月15日完成，实际延至3月24日。任务负责人核对后确认：联调剩余工作量3人天，最早可完成3月27日，超出原截止日期7天；下游PAY-135回归测试原定3月22日开始。
判断结论为需要处置。由于联调中支付回调部分不依赖PAY-110，可先于3月18日完成，剩余部分需等接口就绪，因此选择拆分加顺延：拆分出PAY-128A先行交付，PAY-128B顺延至3月27日。下游回归测试相应顺延2天，经下游负责人确认接受。
| 字段 | 填写内容 |
|---|---|
| 任务标识 | PAY-128 支付联调 |
| 变更前截止日期 | 3月20日 |
| 变更后截止日期 | PAY-128A：3月18日；PAY-128B：3月27日 |
| 变更原因 | 前置任务PAY-110接口开发由3月15日延至3月24日，延期9天，联调最早可完成3月27日 |
| 处置方式 | 拆分+顺延 |
| 影响范围 | 下游PAY-135回归测试由3月22日顺延至3月24日，已确认 |
| 提出人 | 张三 |
| 审批人 | 李四 |
| 生效时间 | 3月10日14:00 |
| 变更编号 | PAY-128-CR-02 |
| 关联依赖调整 | 无 |
| 是否触发范围变更 | 否 |
该示例的可迁移之处在于：判断阶段用最早可完成时间与原截止日期比较，处置阶段按依赖真实性优先考虑拆分，记录阶段把前置延期天数、拆分结果和下游确认写进同一条记录。
完成检查：变更记录是否合格
变更生效后，用以下清单逐项核对，可作为自查或评审依据。
- 记录完整性：必填字段齐全，变更前后日期、原因、处置方式、影响范围、提出人、审批人、生效时间均有内容。
- 原因可核对性：能追溯到具体前置任务及其延期天数，不出现笼统表述。
- 一致性：工作项当前截止日期与最新一条变更记录中的新日期一致。
- 影响闭环：受影响的下游任务负责人已确认，连带调整已记录。
- 历史可查：同一任务的历次变更按编号排列，可看到改过几次、每次为什么改。
以下情况视为阻断项，需退回补充后再生效：无变更原因或原因无法核对；无审批人确认；工作项当前日期与最新变更记录不一致。阻断项处理完成后，再更新任务状态并通知相关方。
常见问题
前置任务延期后，原截止日期一定要改吗？
不一定。先算最早可完成时间：把前置任务最新预计完成时间与当前任务剩余工作量相加，再与原截止日期比较。若仍在原截止日期之前，说明延期只是压缩了缓冲，可以维持原期，并在任务备注中说明缓冲已被压缩。只有超出原截止日期，才进入处置环节；若超出且下游承诺刚性，则需要上报排期负责人决定下游安排。
拆分任务和顺延截止日期可以同时用吗？
可以，实际场景中常见组合。当前任务中有一部分不依赖延期前置、可以先交付时，把这部分拆出来按原期或更早交付，其余部分顺延到新日期。此时变更记录要分别写明两条处置：拆分出的部分对应哪个截止日期，顺延的部分对应哪个截止日期，避免只写一个笼统的新日期导致后续核对困难。
变更记录里原因怎么写才算可核对？
写到能对应到具体事实的程度：哪个前置任务、原定何时完成、实际或最新预计何时完成、延期多少天，以及由此推算出的当前任务最早可完成时间。例如“前置任务PAY-110接口开发由3月15日延至3月24日，延期9天，联调最早可完成3月27日”。避免“因进度原因”“因依赖延期”这类无法追溯的表述，否则评审时无法判断处置是否合理。
同一任务多次改期，记录怎么处理？
一次变更一条记录，后续再次改期时新增记录，不覆盖也不合并历史。可以用变更编号按序标识，例如同一任务第二次变更记为CR-02。这样查看任务时能看到改过几次、每次为什么改、当时谁审批。检查时以最新一条记录中的新日期与工作项当前截止日期比对，两者一致才算记录生效。
下游任务负责人不确认影响，变更能生效吗？
建议把下游确认作为生效前提之一。期限变更往往连带影响下游排期或外部承诺，下游未确认就更新日期，容易出现工作项日期已改、下游仍按旧时间安排的情况。流程上可在审批通过后先通知下游负责人确认连带调整，确认结果写入影响范围字段，再更新工作项截止日期并记录生效时间。
