任务排期冲突往往不是某个人排错了日期，而是工作项之间的前后置依赖没有被完整登记或正确表达。排查时应先把冲突落到具体任务上，判断它属于显性依赖失效、隐性依赖还是循环依赖，再沿依赖链逐层核对、修正并重排，最后用时间关系和依赖链结构验证冲突是否真正消除。
要点总览（TL;DR）
- 排期冲突先落到具体工作项：前置未完成而后置已排期、后置开始早于前置完成、多任务互相等待、同一交付物被多处依赖，都是依赖层面的可观察信号。
- 按成因分三类排查：显性依赖失效看依赖是否登记、方向是否正确、完成标准是否可交接；隐性依赖看口头约定、共享交付物与共享评审环境；循环依赖看依赖链是否成环或存在双向依赖。
- 排查顺序从冲突任务出发：锁定直接前后置任务，核对依赖登记与方向，沿链路向上追溯隐性依赖，检查是否成环，再补齐或修正依赖并重排受影响任务。
- 调整依赖前先确认交付物状态，涉及已开始任务时明确停止点与回退方式，避免重排引发新的空等或返工。
- 修复后用三项检查验证：后置开始不早于前置完成、依赖链无环、关键路径无空等；并把依赖登记与完成标准纳入任务创建和评审以防复发。
排期冲突在依赖层面有哪些表现
依赖层面的排期冲突有几个可观察的信号。最直接的是前置任务尚未完成，后置任务已经进入排期甚至已经开始；其次是后置任务的计划开始日期早于前置任务的计划完成日期，两个日期在时间轴上出现重叠；还有一种是多个任务互相等待，谁也无法先启动；同一份交付物被多个下游任务同时依赖，也会让排期相互牵制。这些信号都指向工作项之间的衔接关系，而不是整体进度偏差或人员忙闲。
按成因可以把症状归为三类。显性依赖失效指依赖关系本应登记却没有登记、登记方向反了，或者前置任务的完成标准含糊，导致后置任务误以为可以开始。隐性依赖指依赖客观存在，但没有写进工作项，例如口头约定的交付、共享的评审环节、同一套测试环境或同一份设计稿。循环依赖指依赖链首尾相接，A 等 B、B 等 C、C 又等 A，或者两个任务之间形成双向依赖，排期上表现为互相等待、谁都排不出开始时间。
需要说明本文的处理范围：这里只讨论工作项安排层面的前后置依赖问题。项目整体进度是否延误、里程碑如何调整，属于项目进度管理的范畴；人员是否超负荷、资源如何调配，属于资源负载与冲突管理。这两类问题可能与依赖冲突同时出现，但排查路径不同，本文不展开。
三类依赖问题的原因假设与排除证据
排查依赖问题要先提出假设，再用证据确认或排除，避免看到日期重叠就直接改排期。下面按三类问题列出常见原因假设和对应的验证证据，逐条核对后再下结论。
| 问题类型 | 原因假设 | 验证证据 |
|---|---|---|
| 显性依赖失效 | 依赖关系未登记，后置任务被当作独立任务排期 | 查看工作项的依赖字段或关联记录，确认是否存在指向前置任务的条目 |
| 显性依赖失效 | 依赖方向登记反了，把前置写成了后置 | 对照任务的实际交付顺序，检查依赖字段中“前置/后置”的方向标注 |
| 显性依赖失效 | 前置任务完成标准含糊，实际交付物尚不可用 | 核对完成标准描述与交付物状态，确认后置任务所需输入是否已经具备 |
| 显性依赖失效 | 前置任务被拆分后，新拆出的子任务未同步依赖 | 对比拆分前后的任务清单，检查新增子任务是否保留原有依赖关系 |
| 隐性依赖 | 依赖来自口头约定，未写入工作项 | 访谈相关执行人，核对会议记录或沟通记录中的交付承诺 |
| 隐性依赖 | 多个任务共享同一交付物、评审或环境 | 梳理各任务的输入清单，找出被重复引用的交付物、评审节点或环境资源 |
| 循环依赖 | 任务之间形成 A→B→C→A 的等待链 | 绘制依赖链路图，沿箭头方向追踪是否回到起点 |
| 循环依赖 | 两个任务之间存在双向依赖 | 检查依赖记录中是否同时存在 A 依赖 B 和 B 依赖 A |
使用这张表时，证据要来自记录而非印象。依赖字段和关联记录能证明依赖是否登记、方向是否正确；计划完成时间与实际完成时间的对比能暴露时间上的矛盾；依赖链路图能直观呈现是否存在环；交付物交接记录则能判断前置成果是否真的可以交给下游使用。某条假设找不到对应证据时，应继续追查而不是直接采信。
按什么顺序排查依赖问题
排查从出现冲突的任务出发，沿依赖链逐层向外核对，顺序如下。
第一步，锁定冲突任务及其直接前后置任务。先明确哪个任务的排期出了问题，再列出它直接依赖的前置任务和被它影响的后置任务。范围控制在直接相邻的一层，避免一开始就铺开整张任务网络。
第二步，核对依赖登记是否完整、方向是否正确。逐个检查这些相邻任务的依赖字段和关联记录，确认该登记的依赖都已登记，前置与后置的方向没有写反。这一步能排除大部分显性依赖失效的情况。
第三步，沿链路向上追溯，识别未登记的隐性依赖。从直接前置任务继续往上游查，同时对照交付物清单、评审安排和共享资源，找出没有写进工作项但实际存在的约束。隐性依赖往往在这一步暴露，例如两个任务都要等同一份设计评审通过。
第四步，检查依赖链是否成环并定位环上的任务。把已确认的依赖关系连成链路图，看是否存在回到起点的路径或双向依赖。发现环后，标出环上的全部任务，判断哪一处依赖是可以通过调整交付顺序解除的。
第五步，补齐或修正依赖后重排受影响任务。根据前四步的结论补登缺失依赖、改正方向错误、拆解循环依赖，然后重新安排受影响任务的开始与完成时间，让后置任务的排期落在前置任务完成之后。
调整依赖存在风险，操作前需要设好边界。先确认前置任务的交付物当前处于什么状态：如果交付物已经完成，只需修正登记；如果仍在进行中，重排时要为它留出实际所需时间，避免把后置任务排得过紧。涉及已经开始的任务时，要明确停止点，例如在某个检查节点前暂停下游工作，并约定回退方式，比如恢复到调整前的排期版本，防止重排引发新的空等或返工。
如何验证冲突已消除并防止复发
重排完成后，用三项检查确认冲突是否真正消除。第一，逐条核对后置任务的计划开始时间不早于前置任务的计划完成时间，时间轴上不再出现依赖倒挂。第二，重新检查依赖链路，确认不存在环，也没有遗留的双向依赖。第三，沿关键路径检查任务之间是否存在空等，即某个任务已经具备开始条件却仍被排在后面，或前置已完成而后置迟迟未启动。
验证通过后，把依赖登记变成日常动作才能防止复发。在任务创建时就要求填写前后置依赖，而不是等到排期冲突出现再补；完成标准要写明可交接的具体交付物，让下游能判断输入是否具备；在迭代评审或计划评审中定期检查依赖链，重点看新增任务是否带入依赖、拆分任务是否保留依赖、共享交付物是否被多处引用。这些检查可以做成简短的核对清单，在每次排期评审时过一遍。
在 ONES 中，可以用工作项关联与依赖字段记录任务之间的前后置关系，配合迭代视图核对排期，把依赖登记和完成标准纳入任务创建与评审环节。具体字段配置与视图展示方式，以团队实际使用的产品版本和官方文档为准。
常见问题
前置任务已经完成，后置任务却还排不进去，问题可能出在哪？
这种情况通常不属于依赖失效，而是依赖登记与实际状态脱节。先核对后置任务是否仍挂着一条指向已完成前置任务的依赖记录，如果依赖没有随前置完成而解除，排期工具会继续把它当作等待状态。其次检查前置任务的完成标准：如果完成标准写的是“开发完成”，而后置任务实际需要的是“提测通过”，那么前置在系统里显示完成，交付物却还不可用。处理方式是补齐完成标准中可交接的交付物描述，并在前置真正交付后更新依赖状态，再重排后置任务。
隐性依赖没有登记，排查时怎么把它找出来？
隐性依赖不会出现在依赖字段里，需要从输入侧反查。梳理冲突任务及其上下游任务各自需要哪些输入，找出被多个任务重复引用的交付物、评审节点、测试环境或设计稿；再对照会议记录和沟通记录，确认是否存在口头约定的交付承诺。访谈执行人时重点问“你在等什么才能开始”，往往能直接暴露未登记的约束。找到后把它补登为正式依赖，或拆成独立的前置任务，避免下次排期再次遗漏。
发现循环依赖后，一定要拆掉其中一个任务吗？
不一定。循环依赖的成因可能是任务粒度太粗，也可能是交付顺序本身可以调整。先标出环上的全部任务，判断哪一处依赖是真正必要的、哪一处只是流程惯性。常见解法有三种：把环上的某个任务拆成前后两段，让其中一段先交付可用成果；调整交付顺序，把双向依赖改成单向；或者把互相等待的部分合并为一个任务统一推进。只有在业务上确实无法拆分时，才需要考虑重新定义任务边界。调整后要重新检查链路，确认没有残留的双向依赖。
重排受影响任务时，怎么控制对已开始任务的影响？
先区分已开始任务和未开始任务。对未开始的后置任务，直接按前置的新完成时间重排即可；对已经开始的任务，需要设定明确的停止点，例如在下一个检查节点前暂停下游工作，等前置交付物到位再继续。同时约定回退方式，比如保留调整前的排期版本，一旦重排导致新的空等或返工，可以恢复到原方案。重排前还要确认前置任务的交付物当前状态：已完成只需修正登记，仍在进行中则要为它留出实际所需时间，避免把后置任务排得过紧。
依赖登记怎么纳入日常流程，避免排期冲突反复出现？
把依赖登记前移到任务创建环节，新建任务时要求填写前后置依赖，而不是等冲突出现再补。完成标准要写明可交接的具体交付物，让下游能判断输入是否具备。在迭代评审或计划评审中固定检查依赖链，重点看三类情况：新增任务是否带入依赖、拆分任务是否保留原有依赖、共享交付物是否被多处引用。这些检查可以做成简短清单，每次排期评审过一遍。在 ONES 中可以用工作项关联与依赖字段记录前后置关系，配合迭代视图核对排期，具体字段配置以团队实际使用的产品版本和官方文档为准。
