前置任务延期后：顺延、拆分、调依赖还是缩范围

前置任务延期后，当前任务的截止日期往往已经不可行。顺延截止日期、拆分任务、调整依赖、缩减范围这四种做法分别改变日期、任务粒度、依赖关系和交付内容，适用条件不同。选择时先看日期能否协商，再看依赖是否刚性，最后看范围能否裁剪。多数情况需要组合使用，并留下可追溯的期限变更记录。ONES 可在工作项层面承载期限调整与依赖变更的记录。

要点总览（TL;DR）

• 四种做法改变的对象不同：顺延改日期，拆分改任务粒度，调整依赖改输入关系，缩减范围改交付内容，先看清各自的前提与代价再选。
• 判断顺序按改动成本排列：先确认截止日期是外部硬约束还是内部约定，再看依赖是否刚性，然后看任务能否分段交付，最后看范围能否裁剪。
• 单一做法常常不够用，对外发布日期固定时可拆分任务并调整依赖并行推进；前置成果返工时可先做不依赖部分、其余顺延；日期与依赖都动不了时缩减范围保核心交付。
• 无论选哪种做法，都要记录原截止日期、新截止日期、变更原因、选择依据、受影响的下游任务与已通知相关方、被缩减内容及后续安排，并与任务本身关联。
• ONES 的研发管理方案围绕需求、基线、版本和变更建立统一管理对象，数字线程可沿关联关系分析受影响的任务与交付内容，为期限变更追溯提供基础。

四种做法的适用条件与代价

四种做法解决的是不同问题，不能简单按“哪个更省事”来选。顺延截止日期改变的是时间承诺，拆分任务改变的是任务粒度，调整依赖改变的是任务之间的输入关系，缩减范围改变的是交付内容。先看清每种做法需要什么前提、付出什么代价，才能判断当前任务适合哪一种。

做法	改变的要素	前提条件	主要代价	典型适用场景
顺延截止日期	日期	截止日期是内部约定或可对外协商；延期成本低于改动内容	对外承诺变化，需要通知相关方；可能挤压后续任务的时间	前置任务延期时间明确，当前任务内容不宜拆动
拆分任务	任务粒度	任务能按交付物或阶段分成可独立验收的片段；部分片段不依赖前置成果	拆分与协调成本增加；片段之间的衔接需要额外管理	交付日期固定，需要让不依赖前置成果的部分先推进
调整依赖	依赖关系	当前任务对前置成果的依赖是部分依赖；可以并行、改用其他输入或调整先后顺序	协调成本上升；并行推进可能带来返工风险	依赖并非刚性，前置成果只影响任务的一部分
缩减范围	交付内容	范围中有明确的核心交付与可后置内容；日期和依赖都无法调整	交付完整性下降；被裁剪内容需要另行安排	日期与依赖均不可动，只能保核心交付

这四种做法并不互斥。一个任务可能既需要拆分，又需要调整依赖，还需要对剩余部分顺延。把选择理解成“四选一”容易漏掉更合适的组合。判断时先确认哪种约束最硬，再围绕这个约束组合其他做法。

按约束逐项判断：先看日期，再看依赖，最后看范围

把选择交给逐项核对，比凭直觉判断更稳定。判断顺序的依据是改动成本：越靠前的约束，改动涉及的外部承诺和协调范围越大，越应该先确认。

第一步：确认截止日期是外部硬约束还是内部约定

判定问题是：这个日期由谁提出、能否协商、延期会影响哪些对外承诺。如果日期来自合同、发布窗口或对外公告，顺延的空间很小；如果是团队内部约定的时间点，可以协商调整。这一步决定顺延是否在可选范围内。

第二步：确认对前置成果的依赖是全部依赖还是部分依赖

判定问题是：当前任务是否每个环节都必须等前置成果完成，还是只有部分环节需要。全部依赖意味着调整依赖的空间有限；部分依赖则可以把不依赖前置成果的部分提前，或改用其他输入并行推进。

第三步：确认任务能否按交付物或阶段拆成可独立验收的片段

判定问题是：任务能否拆出可以单独完成、单独验收的片段，每个片段的完成标志是什么。能拆出独立片段，就可以让部分工作先推进，降低对整体截止日期的冲击；拆不出来，拆分就不是可行选项。

第四步：确认范围中哪些是必须交付、哪些可以后置

判定问题是：本次交付中哪些内容缺了会影响核心目标，哪些可以放到下一批。这一步通常在前三步都无法保住日期时使用，用来确定缩减范围时保留什么、后置什么。

四步走完后，通常能确定一个主做法，再根据剩余约束补充辅助做法。判断结果应连同依据一起记录，方便后续复盘时解释为什么这样选。

组合场景示例：三种典型延期情形怎么处理

情形一：对外发布日期固定，前置任务延期两周

假设某功能对外发布日期已经公告，前置的接口开发延期两周。此时顺延不可行，依赖又是部分依赖：页面框架、文案和部分交互不依赖接口成果。处理方式是拆分任务，把不依赖接口的部分提前完成，同时调整依赖，让剩余部分在接口交付后并行推进。期限变更记录中写明原截止日期、新截止日期（如剩余部分需要）、拆分出的片段、调整后的依赖关系以及已通知的相关方。

情形二：前置成果质量未达标需返工

假设前置成果需要返工，返工时间尚不确定。当前任务中有一部分可以直接基于已有材料推进，另一部分必须等返工完成。处理方式是先做不依赖返工成果的部分，其余部分顺延，并注明顺延取决于返工完成时间。记录中写明返工事项、受影响的任务片段、暂定新日期及其前提条件。

情形三：日期与依赖均不可动

假设截止日期由外部固定，前置成果也无法替代或并行。此时只能缩减范围，保留核心交付，把可后置内容移出本次交付。记录中写明被裁剪的具体内容、裁剪原因、后续安排（如放入下一批次）以及已通知的相关方。

三种情形对应的变更记录字段可以统一为：原截止日期、新截止日期、变更原因、选择的做法及依据、受影响的下游任务、已通知相关方、被缩减内容及后续安排。字段统一后，不同任务的变更记录可以放在同一口径下比较和复盘。

期限变更记录怎么写才可追溯

期限变更记录的作用是让后续复盘和对外解释有据可查。记录不完整，事后很难说清为什么改期、改了哪些内容、影响了谁。以下字段建议在每次期限变更时填写。

字段	填写要点
原截止日期	填写变更前的日期，保留原始承诺，便于对比
新截止日期	填写调整后的日期；若日期尚未确定，注明暂定及确定条件
变更原因	具体到触发事件，如前置任务延期两周、前置成果返工
选择的做法及依据	写明采用了顺延、拆分、调整依赖或缩减范围中的哪些，以及由哪个约束决定
受影响的下游任务	列出因本次变更需要同步调整的后置任务
已通知的相关方	记录通知对象与通知时间，避免信息断层
被缩减的范围内容及后续安排	写明裁剪了什么、计划何时补回或转入哪个批次

填写时注意两点：一是变更原因写到可核对的事实，避免只写“进度原因”；二是记录与任务本身关联，让查看任务的人能直接看到变更历史，而不必到别处查找。

用ONES承载期限变更与依赖调整

前面的判断和记录最终要落到工作项上。ONES 的研发管理方案围绕需求、基线、版本和变更建立统一管理对象，支撑需求变更影响分析、过程状态追踪和交付结果回溯；数字线程用于连接需求、开发、测试、变更和发布等环节，某个需求发生变化时，可以沿关联关系分析受影响的任务、测试和交付内容，并保留过程追踪和审计依据。这些能力为期限变更的追溯提供了基础。

在实际操作路径上，可以按以下方式承载本文的判断与记录动作：

• 在工作项上更新截止日期，并在任务描述或评论中写明原日期、新日期和变更原因，使变更与任务本身关联。
• 用任务拆分或子工作项表达分段交付，每个片段有独立的完成标志，对应拆分任务后的验收安排。
• 用依赖关系表达前置与后置任务，调整依赖时同步更新关联关系，让下游任务看到最新的输入条件。
• 在任务描述或评论中记录选择的做法、依据、受影响的下游任务和已通知相关方，形成可追溯的变更记录。

具体字段名称和操作入口以实际使用的 ONES 版本为准。把判断顺序和记录字段固定下来，再借助工作项的关联关系追踪影响范围，期限变更就能从一次临时沟通变成可复盘的管理动作。

常见问题

前置任务延期时间还不确定，新截止日期该怎么填？

返工或延期时长尚未确定时，新截止日期可以先填暂定日期，并在变更记录中注明“暂定”以及确定条件，例如“待前置成果返工验收后三个工作日内确认”。同时把当前任务中不依赖前置成果的部分先推进，让暂定日期只约束剩余片段。日期确定后补一次记录，保留暂定与确认两个时间点，后续复盘时能看清判断依据。

拆分任务后，子任务之间还需要保留依赖关系吗？

需要。拆分解决的是任务粒度，依赖关系描述的是片段之间的输入顺序。拆出的片段如果存在先后输入关系，仍应保留前置与后置的关联，否则并行推进时容易在衔接处返工。拆分与调整依赖通常一起使用：把不依赖前置成果的片段提前，把依赖部分挂在调整后的关联关系上，下游任务才能看到最新的输入条件。

缩减范围时，被裁掉的内容怎么安排才不至于丢失？

被裁剪的内容要在变更记录中写明具体条目、裁剪原因和后续安排，例如放入下一批次、转入独立需求或另行排期。只写“范围缩减”无法支撑后续补回。如果裁剪内容涉及对外承诺，还需同步通知相关方，说明本次交付包含什么、不包含什么，避免交付验收时产生分歧。

期限变更记录放在任务描述里还是单独文档里？

优先与任务本身关联，让查看任务的人能直接看到变更历史，不必到别处查找。可以在任务描述或评论中记录关键字段，也可以借助工作项的关联关系追踪受影响的下游任务。单独文档适合做阶段性汇总复盘，但不宜作为唯一记录位置，否则任务与变更原因之间会脱节。

四种做法可以同时用在一个任务上吗？

可以，而且多数情况需要组合。常见组合是拆分任务加调整依赖：把不依赖前置成果的片段提前，剩余部分在依赖解除后并行推进。另一种组合是先做不依赖部分、其余顺延，适用于前置成果返工时间不确定的情形。组合时先确定一个主做法解决最硬的约束，再用辅助做法处理剩余部分，并把组合方式写进变更记录的依据字段。