前置任务延期后，原截止日期是否还成立需要先核对事实再决定。本文围绕工作项层面的期限变更，说明如何判断日期可行性、在顺延截止日期、拆分任务、调整依赖关系、缩减范围之间选择处置方式，并把变更前后日期、原因、影响和决策人记录在同一工作项上，形成可追溯的期限变更链。
要点总览（TL;DR）
- 前置任务延期后先核对新的完成时间与剩余工作量，判断原截止日期是否仍可行，再决定是否改期。
- 处置方式按约束条件选择：日期可动且下游能接受时顺延；部分工作可先交付时拆分；依赖可并行或可替换时调整依赖；日期不可动时缩减范围，组合使用需分别记录。
- 期限变更记录至少包含变更前后日期、触发事件与原因、处置方式与决策依据、影响范围、决策人与确认时间、生效时间与关联方式。
- 记录挂在原工作项上并关联前置与下游任务，下游确认知悉、自身安排同步更新后，变更才算闭环。
先判断原截止日期是否还成立
收到前置任务延期的消息后，第一步是核对事实，直接修改日期会把判断依据一起丢掉。判断的目标只有一个：在当前剩余工作量和新的前置完成时间下，原截止日期是否仍然可行。判断范围限定在当前这个工作项，不扩展到项目整体排期。
核对分三件事。第一，确认前置任务的实际完成时间或新的预计完成时间，向该任务负责人取得明确答复，避免使用“大概还要几天”这类模糊信息。第二，盘点当前工作项的剩余工作量，区分尚未开始的部分和已完成待验证的部分。第三，把新的前置完成时间加上剩余工作量所需时间，与原截止日期比较。
比较结果通常落在三种结论上：
- 原日期可行：前置延期被剩余时间吸收，或当前任务有可压缩的等待时间，截止日期不变，只需在记录中注明本次核对结论。
- 需调整：按新起点推算后原日期无法满足，需要进入处置选择。
- 需重新评估：剩余工作量本身尚不清楚，或前置任务的新完成时间仍不确定，先补清信息再判断，不急于改日期。
判断结论应当写下来，哪怕结论是“日期不变”。这份结论是后续处置和留痕的起点，也是日后回溯“为什么改、为什么没改”的依据。
四种处置方式怎么选
确认原截止日期不可行后，处置不只有“往后挪”一种。顺延截止日期、拆分任务、调整依赖关系、缩减范围分别对应不同的约束条件，选择时先看哪个约束最硬：日期能不能动、交付内容能不能压缩、依赖能不能改。
| 处置方式 | 适用条件 | 主要代价 | 对下游的影响 |
|---|---|---|---|
| 顺延截止日期 | 后续工作可以整体后移，下游对时间有一定容忍度 | 交付时间推迟，可能挤压后续任务窗口 | 下游任务需同步顺延，里程碑可能受影响 |
| 拆分任务 | 部分工作可以先完成并交付，剩余部分依赖前置结果 | 需要额外定义拆分边界和交付标准 | 下游可先接收部分成果，联调或验收分两批进行 |
| 调整依赖关系 | 依赖可以改为并行，或存在可替换的前置来源 | 并行可能增加返工风险，换前置需要确认新来源可靠 | 下游时间基本不变，但需确认并行部分的一致性 |
| 缩减范围 | 截止日期不可动，交付内容可以压缩 | 交付完整度下降，需明确砍掉什么、保留什么 | 下游按缩减后的范围安排测试和验收 |
选择顺序建议从约束最硬的一端开始：日期不可动时优先考虑缩减范围或调整依赖；日期可动但下游连锁影响大时，优先拆分任务保住部分交付；只有整体后移代价最小、下游也能接受时，才选择顺延截止日期。实际场景中组合使用很常见，例如“拆分任务 + 部分顺延”：先交付不依赖前置结果的部分，剩余部分按新日期排。组合时要在记录中分别写清每一部分对应的处置和日期。
期限变更记录要写哪些字段
变更记录的作用是让任何人在事后都能还原这次改期的来龙去脉。字段不必多，但每一项都要能回答一个具体问题。下表给出可直接套用的字段清单。
| 字段 | 必填 | 填写说明 |
|---|---|---|
| 变更前截止日期 | 是 | 原工作项上的截止日期，精确到日 |
| 变更后截止日期 | 是 | 调整后的日期；拆分或缩减范围时按部分分别列出 |
| 触发事件与原因 | 是 | 写明哪个前置任务延期、延期多久、信息来源 |
| 处置方式与决策依据 | 是 | 说明选择了顺延、拆分、调整依赖还是缩减范围，以及为什么这样选 |
| 影响范围 | 是 | 列出受影响的下游任务、交付物和里程碑 |
| 决策人 | 是 | 对本次变更负责的人，通常是项目或计划负责人 |
| 确认时间 | 是 | 决策人确认的日期时间 |
| 生效时间 | 是 | 新日期从何时开始执行，与确认时间区分开 |
| 关联方式 | 是 | 记录挂在原工作项上，注明关联的前置任务和下游任务 |
| 知会对象 | 建议 | 已通知的下游接收方及其确认情况 |
填写时有两个常见疏漏。一是只写“因前置延期调整”，没有写延期几天、新完成时间是什么，导致原因无法复核。二是把确认时间和生效时间混为一谈，实际上决策可能在周五确认、下周一才生效，两者需要分开记录。记录应挂回原工作项，而不是单独放在聊天记录或邮件里，这样期限变更链才能沿同一工作项连续查看。
按步骤完成一次期限变更
把判断、处置和记录串起来，一次完整的期限变更可以按以下步骤执行。每一步都明确输入、动作和输出，便于交接和复核。
- 收集延期事实。输入：前置任务负责人的延期说明。动作：确认新的完成时间并记录来源。输出：一条可引用的延期事实。
- 盘点剩余工作量。输入：当前工作项的已完成部分和待完成部分。动作：估算剩余工作所需时间。输出：剩余工作量估算。
- 判断日期可行性。输入：延期事实和剩余工作量。动作：推算新起点下的完成时间并与原截止日期比较。输出：可行、需调整或需重新评估的结论。
- 选择处置方式。输入：可行性结论和下游依赖清单。动作：按约束条件在四种处置中选择一种或组合。输出：处置方案。
- 更新工作项。输入：处置方案。动作：修改截止日期，必要时拆分工作项或调整依赖关系。输出：更新后的工作项。
- 填写变更记录。输入：前述各步的结论。动作：按字段表逐项填写并挂到原工作项。输出：一条完整的期限变更记录。
- 知会下游并确认。输入：变更记录和下游清单。动作：通知下游接收方，请其确认知悉并更新自身安排。输出：下游确认回执。
完成标志是：工作项上的日期已更新，变更记录可查，且下游接收方已明确知悉。三项缺一，这次变更就还没有闭环。
在工具层面，这类操作依赖工作项本身承载日期、依赖和变更信息。ONES Project 用于标准化需求、任务、缺陷和计划执行，工作项可以作为期限变更的记录载体；ONES 的数字线程连接需求、开发、测试、变更和发布等环节，需求或任务发生变化时可以沿关联关系分析受影响的任务、测试和交付内容，并保留过程追踪和审计依据。将变更记录挂回原工作项、把下游任务纳入关联关系，正是让这条追踪链成立的做法。具体字段和历史记录的展示形式以实际部署与配置为准。
角色分工与交接
期限变更涉及四个角色，各自的动作和交付物不同，交接清楚才能避免“改了日期没人知道”。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 任务负责人 | 发现日期不可行，提出变更，填写变更记录 | 可行性判断结论、变更记录 |
| 前置任务负责人 | 提供延期事实和新的完成时间 | 延期说明及新完成时间 |
| 项目或计划负责人 | 确认影响范围，批准处置方案 | 决策意见、确认时间 |
| 下游接收方 | 确认知悉，更新自身任务安排 | 知悉确认、调整后的下游计划 |
交接的关键节点有两个：一是任务负责人把可行性判断和处置建议交给项目或计划负责人确认，此时记录尚未生效；二是确认后由任务负责人知会下游，下游确认知悉后变更才算完成。前置任务负责人提供的信息应尽量具体，避免下游在模糊信息上反复调整。
一个完整示例：接口联调被前置开发延期拖后
以下为演示情景。某工作项“订单接口联调”原截止日期为 3 月 14 日，其前置任务“订单服务开发”由另一位开发负责。3 月 10 日，前置任务负责人告知开发延期五天，预计 3 月 17 日才能提供可联调版本。
判断过程：联调本身需要约三天，原计划 3 月 11 日开始、14 日结束。前置完成时间推到 17 日后，按三天联调推算最早 19 日结束，原截止日期不可行，结论为“需调整”。下游还有一个“订单功能测试”任务，原计划 3 月 15 日开始。
处置选择：日期可以后移，但测试窗口不能被完全挤掉，因此采用“顺延截止日期 + 拆分任务”的组合。联调中不依赖订单服务的部分（如鉴权接口联调）按原计划先做，订单服务相关部分顺延至 3 月 17 日开始、19 日结束。下游测试相应拆为两批，鉴权部分按原时间，订单部分顺延至 20 日开始。
填好的变更记录示例：
| 字段 | 填写内容 |
|---|---|
| 变更前截止日期 | 3 月 14 日 |
| 变更后截止日期 | 订单服务相关部分 3 月 19 日；鉴权部分维持 3 月 14 日 |
| 触发事件与原因 | 前置任务“订单服务开发”延期五天，3 月 10 日由前置任务负责人告知，可联调版本预计 3 月 17 日提供 |
| 处置方式与决策依据 | 顺延 + 拆分。订单服务依赖部分顺延，不依赖部分先做，避免测试窗口整体后移 |
| 影响范围 | 下游“订单功能测试”拆为两批，订单部分顺延至 3 月 20 日开始；3 月下旬里程碑需复核 |
| 决策人 | 项目负责人 |
| 确认时间 | 3 月 10 日 16:00 |
| 生效时间 | 3 月 11 日起执行 |
| 关联方式 | 记录挂在“订单接口联调”工作项，关联前置任务“订单服务开发”和下游任务“订单功能测试” |
| 知会对象 | 测试负责人，已于 3 月 10 日确认知悉 |
下游测试任务的同步调整是这次变更的一部分：测试负责人确认后，将订单相关用例的排期改为 3 月 20 日开始，鉴权用例维持原排期，并在测试任务上注明调整原因指向本次变更记录。
完成检查：变更记录是否合格
变更完成后，用以下清单逐项核对，全部通过才算闭环。
- 变更前后截止日期都已填写，拆分或缩减范围时各部分日期分别列出。
- 触发事件写明了具体前置任务、延期时长和信息来源。
- 处置方式与决策依据可读，能看出为什么这样选。
- 影响范围覆盖了下游任务、交付物和里程碑。
- 决策人和确认时间齐全，生效时间与确认时间分开记录。
- 记录挂在原工作项上，并关联了前置任务和下游任务。
- 下游接收方已确认知悉，其自身安排已同步更新。
- 检查是否存在未记录的二次改动，例如确认后又临时调整日期却未补充记录。
最后一项容易被忽略。期限变更往往不是一次完成的，确认后如果下游又提出新的时间要求，需要再走一次记录，而不是在原记录上悄悄改数字。保持每次改动都有对应记录，期限变更链才真正可追溯。
常见问题
前置任务延期后，原截止日期其实还能完成，还需要写变更记录吗？
建议写一条核对结论。日期没有变化，但“为什么没改”同样是日后回溯的依据。记录中可以只写触发事件、核对过程和“原日期可行”的结论，不必填写变更后日期。这样当后续有人质疑排期时，能直接看到当时已经评估过延期影响，而不是遗漏了这次变化。
拆分任务后，变更记录应该挂在原工作项上还是新建的子任务上？
建议挂在原工作项上，并在记录中列出拆分出的各部分及其对应日期。子任务可以各自承载自己的截止日期，但期限变更的来龙去脉属于原工作项，挂回原处才能沿同一工作项连续查看。如果拆分后子任务又发生日期调整，应在子任务上补充记录，并注明其来源是原工作项的哪次变更。
决策人确认后，下游又提出新的时间要求，需要重新走一遍流程吗？
需要。确认后的再次调整属于新的变更，应重新判断可行性、选择处置并补充记录，不能直接在原记录上改数字。实际操作中可以简化：如果只是下游时间微调、不影响当前工作项日期，记录一条知会与确认即可；如果反过来影响当前工作项日期，则按完整步骤再走一次。
期限变更记录放在聊天记录或邮件里，算不算留好了？
不算。聊天记录和邮件分散在不同会话中，难以与工作项对应，也无法形成连续的变更链。记录应挂回原工作项，聊天和邮件只作为通知渠道。这样任何人打开工作项就能看到历次日期调整、原因和决策人，不必再去翻找历史消息。
缩减范围时，变更记录里要写清楚砍掉了什么吗？
要写。只写“缩减范围”无法让下游判断验收标准。记录中应列出保留的交付内容和移除或推迟的部分，并说明决策依据，例如截止日期由外部约束固定。下游据此调整测试和验收安排，后续若恢复被砍掉的内容，也能追溯到这次变更的上下文。
