任务排期冲突通常表现为日期重叠、前后置依赖被违反，或执行顺序与截止日期互相矛盾。排查时先把冲突工作项的开始结束时间、依赖关系和负责人列出来，逐条核对属于哪类冲突，再按调整日期、修正依赖、拆分工作项、明确交接顺序处置，并回看下游任务。人员容量不足引起的冲突不在本文范围，应转到资源负载管理处理。
要点总览（TL;DR）
- 任务排期冲突主要有三类：日期真实重叠、前后置依赖倒挂、执行顺序与截止日期互相矛盾，排查时先看依赖关系，再看日期，最后看截止日期。
- 每条原因假设都要有验证证据：日期重叠核对时间区间与执行主体，依赖倒挂核对前置完成时间与后置开始时间，顺序矛盾核对依赖链上截止日期是否随执行顺序递增。
- 处置按类型推进：时间重叠先判断能否并行，再调日期、拆分工作项、明确交接点；依赖倒挂先核对依赖关系是否录错，再调整顺序或日期；顺序与截止日期矛盾则重排顺序或重新确认截止日期。
- 调整后要沿依赖链回看下游任务，确认没有产生新的重叠或倒挂，并核对依赖关系与日期一致、截止日期单调递增。
- 减少复发靠日常动作：每周固定检查依赖与日期一致性、临近截止日期的前置完成情况、跨团队交接点是否双方确认。
排期冲突的典型症状与影响范围
判断是否遇到任务排期冲突，可以先看工作项之间是否存在三种可观察的症状。只要出现其中一种，并且涉及两个及以上工作项，就应当纳入排查范围。
- 时间重叠：两个工作项的计划开始结束时间存在交集，而它们需要同一负责人投入，或共享同一交付物、同一环境、同一评审窗口。时间重叠本身是中性信号，需要结合执行主体和交付物判断是否构成真实冲突。
- 依赖倒挂：后置任务的计划开始时间早于前置任务的计划完成时间，或者前置任务尚未完成，后置任务已经进入执行。表现为下游工作项“等米下锅”，上游工作项却还在进行中。
- 截止日期与执行顺序矛盾：按依赖关系必须先做的工作项，其截止日期反而晚于依赖它的工作项；或者关键路径上的任务被排在非关键任务之后，导致截止日期无法满足。
界定影响范围时，从冲突工作项出发做两层扩展。第一层是直接相关方：冲突工作项的负责人、协作者、评审人，以及共享同一交付物的其他工作项。第二层是下游任务：所有直接或间接依赖冲突工作项的任务，都需要检查其计划日期是否仍然成立。范围记录建议包含工作项名称、负责人、计划开始与结束时间、前置与后置关系、当前状态五项信息，形成一份可逐条核对的冲突清单。
需要与两类相邻问题区分开。人员容量冲突表现为同一个人被安排了超出可用工时的工作量，即使日期不重叠也可能发生，处置方式是调整负载或增补人手，属于资源负载管理范畴。项目整体进度问题表现为里程碑整体延后、关键路径拉长，涉及范围、资源和目标的重新平衡，属于项目进度管理范畴。本文聚焦单个或一组工作项之间的日期、依赖与顺序矛盾，排查对象是工作项层面的排期数据。
逐项排查：冲突原因假设与验证证据
排查的核心是把“猜测的原因”变成“有证据确认的原因”。对每个疑似冲突的工作项，先提出原因假设，再找到能证实或排除该假设的具体证据，避免把第一眼看到的日期重叠直接当成结论。
| 原因假设 | 验证证据 | 确认标准 |
|---|---|---|
| 日期真实重叠 | 两个工作项的计划开始、结束时间；负责人是否相同；是否共享交付物或环境 | 时间区间存在交集，且执行主体或交付物存在竞争 |
| 依赖倒挂 | 前置任务的计划完成时间与实际完成时间；后置任务的计划开始时间；依赖关系记录 | 后置任务开始时间早于前置任务完成时间，或前置未完成而后置已启动 |
| 顺序与截止日期矛盾 | 依赖链上的执行顺序；各工作项的截止日期；关键路径上的任务排列 | 必须先完成的任务截止日期晚于依赖它的任务，或顺序安排使截止日期不可达 |
排查顺序建议从依赖关系入手，再看日期，最后看截止日期。原因是依赖倒挂往往会连带造成日期重叠的假象：两个任务看起来时间冲突，实际是前置任务延期导致后置任务被迫压缩。先确认依赖关系是否成立，可以避免在错误的前提上调整日期。
验证依赖倒挂时，需要区分计划数据和实际数据。计划层面的倒挂看计划完成时间与计划开始时间；执行层面的倒挂看前置任务的实际进度与后置任务的实际启动时间。两者可能只出现一个，处置方式不同：计划倒挂修正排期，执行倒挂需要先处理前置任务的阻塞。验证顺序与截止日期矛盾时，把依赖链上的工作项按执行顺序排列，逐个比对截止日期是否单调递增，出现递减的位置就是矛盾点。
每条假设的排查结果都应留下记录：假设内容、核对的数据、结论是确认还是排除、排除的理由。这份记录在后续处置和复盘时是判断依据，也能防止同一冲突被反复讨论。
按冲突类型处置排期
处置前先确认影响范围和停止点。影响范围包括冲突工作项本身、直接下游任务和共享同一交付物的其他工作项；停止点是处置动作的边界，例如涉及已对外承诺的交付日期、已冻结的里程碑或跨团队交接点时，调整前需要与相关方确认，不能单方面改期。确认完成后，按冲突类型选择处置动作。
时间重叠的处置
优先判断重叠是否真实需要串行。如果两个工作项可以并行且互不争抢同一负责人和交付物，保留原日期即可，只需在计划中标注并行关系。确需串行时，按以下顺序处理：先调整其中一个工作项的日期，把重叠区间错开；如果日期无法调整，考虑拆分工作项，把可以提前的部分拆出先行执行，把依赖后续输入的部分保留在原位；最后明确交接点，写清前置部分交付什么、由谁接收、接收后后置部分何时启动。
依赖倒挂的处置
先核对依赖关系本身是否正确。有些倒挂源于依赖关系录错，例如把本可并行的工作项误设为前后置，修正关系后冲突自然消失。依赖关系确认无误时，调整执行顺序：把前置任务提前启动或压缩其工期，使完成时间早于后置任务的开始时间；或者把后置任务的开始时间后移。两种方式都会影响下游，需要同步更新受影响任务的日期。涉及外部交付或跨团队交接的依赖，调整前要与对方确认新的时间点。
截止日期与顺序矛盾的处置
这类冲突通常需要二选一：重排执行顺序，或重新确认截止日期。重排顺序适用于截止日期刚性、顺序可调的情况，把关键路径上的任务前移，非关键任务后移或并行。重新确认截止日期适用于顺序由业务逻辑锁定、无法调整的情况，此时需要与需求方沟通日期的可行性，并说明调整依据。两种处置都要避免只改一个日期而不检查整条依赖链，否则容易把冲突转移到下游。
处置动作的风险边界需要明确：拆分工作项会增加交接成本和管理颗粒度，适合跨度较大、阶段清晰的任务；压缩前置任务工期可能带来质量风险，需要评估是否增加评审或验收环节；调整已承诺的截止日期属于对外变更，应走变更确认流程。任何处置完成后，都要记录改了什么、为什么改、影响了哪些工作项。
验证恢复与防止再次冲突
调整完成后，排期是否真正恢复需要用检查清单逐项确认，不能只看被修改的那几个工作项。
- 回看下游任务：沿依赖链向下检查所有受影响工作项，确认新的开始结束时间没有与它们的其他前置任务产生新的重叠或倒挂。
- 核对依赖与日期一致：逐个确认每条前后置关系的两端日期满足“前置完成不晚于后置开始”，计划数据与依赖记录保持一致。
- 核对截止日期单调性：沿依赖链检查截止日期是否随执行顺序递增，确认没有新的顺序与截止日期矛盾。
- 确认负责人与交接点：检查调整后的工作项负责人是否明确，拆分产生的交接点是否有接收人和交接内容。
- 记录变更：把本次调整的日期、依赖和顺序变化写入变更记录，便于后续追溯。
减少复发依靠日常动作而非一次性检查。可以在每周的排期例会上固定检查三项内容：新增或变更的依赖关系是否与日期一致，临近截止日期的工作项是否存在前置未完成的情况，跨团队交接点是否双方确认。把依赖关系和截止日期作为工作项的必填字段维护，避免口头约定代替记录。对于频繁出现倒挂的依赖链，考虑在计划阶段就把前置任务的缓冲时间显式写入排期。
在工具层面，工作项的开始结束时间、截止日期和前后置依赖需要作为结构化字段维护，调整时同步更新，才能让上述检查有据可依。ONES 支持在工作项中记录计划时间与依赖关系，排期调整后可在同一处回看下游工作项的日期与状态，便于完成验证清单中的逐项核对；具体的依赖校验与视图呈现方式以实际使用配置为准。把排查记录、处置变更和验证结果留在工作项或相关文档中，也能为下一次冲突排查提供参照。
常见问题
两个任务日期重叠，但负责人不同，算不算排期冲突？
日期重叠本身是中性信号，是否构成冲突要看执行主体和交付物。如果两个工作项由不同负责人执行，也不共享交付物、环境或评审窗口，通常可以并行，只需在计划中标注并行关系，不必强行错开日期。需要关注的是重叠区间内是否存在资源争抢或交付物依赖，例如同一份文档需要两人先后修改，或同一测试环境只能串行使用。这类情况即使负责人不同，也应按时间重叠处置。
前置任务已经延期，后置任务还没开始，应该改哪个日期？
先判断后置任务的开始时间是否还有压缩空间。如果后置任务可以后移，优先调整后置任务的开始时间，保持前置任务按实际进度推进，这样对上游的干扰最小。如果后置任务的截止日期刚性、无法后移，则需要压缩前置任务的剩余工期，或把后置任务中不依赖前置输出的部分拆出来先行启动。两种方式都会影响下游，调整后要沿依赖链检查后续任务是否产生新的倒挂。
拆分工作项解决排期冲突，什么情况下不适合用？
拆分适合跨度较大、阶段清晰、存在自然交付点的任务。如果任务本身颗粒度已经很细，或拆分后各部分仍需同一人连续投入、交接成本高于收益，拆分反而会增加管理负担。另外，拆分产生的新工作项需要明确负责人、交接内容和接收标准，缺少这些信息时，拆分只是把冲突从日期层面转移到交接层面。拆分前先确认是否存在更简单的处置方式，例如调整日期或修正依赖关系。
调整排期涉及已对外承诺的交付日期，应该怎么处理？
已对外承诺的交付日期、已冻结的里程碑和跨团队交接点属于处置的停止点，不能单方面改期。调整前先与相关方确认新的时间点，说明调整原因和影响范围，走变更确认流程后再更新排期。内部工作项的日期调整可以自主完成，但涉及外部依赖的部分同样需要与对方同步，避免一方改期后另一方仍按原计划执行，形成新的依赖倒挂。
排期调整完成后，怎么确认没有把冲突转移到下游？
沿依赖链向下逐项检查受影响的工作项，确认三件事：新的开始结束时间没有与它们的其他前置任务产生重叠或倒挂；每条前后置关系两端的日期满足前置完成不晚于后置开始；截止日期随执行顺序递增。同时确认拆分产生的交接点有明确接收人，调整内容已写入变更记录。只检查被修改的几个工作项不够，冲突经常在下一层依赖中才显现。
