任务依赖规则示例：四种依赖类型的填写与排期

任务依赖规则示例的价值，在于把“这条任务被谁卡住、卡到什么程度”写成一条可执行的记录。本文用一次版本发布前的假设情景，完整填写前置任务、依赖类型、滞后时间和解除条件，并逐项解释FS、SS、FF、SF四类依赖的选用理由与排期影响，帮助读者迁移到自己的任务安排中。文中示例为演示情景，非真实客户案例。

要点总览（TL;DR）

• 任务依赖规则示例需要填出五个字段：前置任务、依赖类型、滞后时间、解除条件、责任人，缺一项排期判断就会含糊。
• FS用于“前一件事做完、后一件事才能开始”的默认场景；SS用于允许并行启动；FF用于结束点必须对齐；SF用于新旧交接，使用频率最低。
• 滞后时间用正数表示等待、零表示紧接、负数表示允许重叠，每个数字都要写明依据，否则会变成隐藏缓冲。
• 可迁移的填写顺序是：先定交付物再定依赖，默认用FS，按真实约束改用其他类型，控制依赖数量，为每条依赖写可验证的解除条件。
• 这套填法适用于任务粒度足够细、责任明确的场景；跨项目整体进度协调和人员容量冲突分别归项目进度管理与资源管理处理。

示例要解决什么：一条依赖规则该填出哪些信息

一条可执行的依赖规则，目标是让另一个接手排期的人不用追问就能判断：这条任务什么时候可以开始、被什么条件挡住、挡住的时间有多长。示例要展示的正是这个填写过程，从识别前置任务到写出解除条件，形成一条完整记录。

依赖规则至少需要五个字段，缺一项都会让排期判断变得含糊：

• 前置任务：当前任务等待的是哪一个具体工作项，写到任务编号或明确名称，避免写成“等开发完成”这类指向模糊的表述。
• 依赖类型：说明前置任务的哪个时间点约束当前任务的哪个时间点，常用完成—开始（FS）、开始—开始（SS）、完成—完成（FF）、开始—完成（SF）四类。
• 滞后时间：两个时间点之间需要等待或允许重叠的时长，用正数、零或负数表达。
• 解除条件：依赖被满足的可验证状态，例如“接口联调报告已评审通过”，而非“差不多可以了”。
• 责任人：谁负责推进前置任务、谁确认解除条件达成，出现延期时找谁对齐。

本文只处理工作项之间的依赖安排。项目整体进度与里程碑规划属于项目进度管理的范围，人员容量冲突与资源负载分配属于资源管理的范围，这两类问题会涉及依赖，但不在本文的填写示例内展开。

完整示例：一次版本发布前的任务依赖填写

以下为演示情景，非真实客户案例。某产品团队计划发布一个版本，涉及需求确认、接口开发、前端页面、联调测试、发布说明撰写和上线检查六项任务。团队按依赖规则逐条填写，得到如下结果：

任务	前置任务	依赖类型	滞后时间	解除条件	责任人
T1 需求确认	无	—	—	需求文档评审通过	产品负责人
T2 接口开发	T1 需求确认	FS	0天	需求评审纪要归档，开发任务已领取	后端负责人
T3 前端页面开发	T1 需求确认	SS	+2天	需求评审通过后第2天启动，接口契约已确认	前端负责人
T4 联调测试	T2 接口开发、T3 前端页面开发	FS	+1天	接口与页面均提交测试环境，冒烟用例通过	测试负责人
T5 发布说明撰写	T4 联调测试	SS	+1天	联调进入第2天，功能范围已冻结	产品负责人
T6 上线检查	T4 联调测试、T5 发布说明撰写	FF	0天	测试报告签署，发布说明定稿	发布经理

依赖关系在排期上的体现是具体的：T2在T1完成后当天即可启动；T3不必等T1全部完成，而是在T1完成后第2天与T2并行推进，这正是SS加正滞后时间的作用；T4要等T2和T3都完成，再留1天准备测试环境，因此它的开始时间被推到两条前置任务中较晚完成者的次日；T5在T4开始后第2天启动，与测试并行撰写说明；T6采用FF，要求测试报告与发布说明都完成才放行上线检查。整个链条中，T4是被推迟最明显的任务，推迟量来自T3的并行安排和1天环境准备。

逐项解释：每条依赖为什么这样填

四类依赖在示例中各有明确用途，选择依据是“前置任务的哪个时间点真正约束了当前任务”。

FS：默认的先后关系

T2对T1、T4对T2和T3都用了FS。需求没确认，接口开发缺少输入；接口和页面没提交测试环境，联调无法开始。这类“前一件事做完，后一件事才能开始”的关系最直观，也最容易在排期上自动顺延，因此作为默认选择。T4的滞后时间填+1天，是因为提交测试环境后还需要部署和准备数据，这1天是实际等待，不是缓冲。

SS：允许并行启动

T3对T1用SS加2天滞后。前端页面开发不必等需求文档全部收尾，需求评审通过后第2天，接口契约确认即可动工。如果这里误填FS，前端要等整个需求确认任务关闭才能开始，排期会凭空多出数天。T5对T4同样用SS加1天，发布说明在联调进入第2天、功能范围冻结后开始撰写，与测试并行，缩短整体周期。

FF：同时收尾才放行

T6对T4和T5用FF，含义是上线检查要等测试报告和发布说明都完成才能结束。上线检查本身可以提前准备检查项，但放行结论必须建立在两份交付物齐备的基础上。FF适合这种“结束点对齐”的场景，如果改成FS，上线检查要等两份文档都完成才开始，反而拉长尾段时间。

SF：示例中未使用的原因

SF表示前置任务开始后当前任务才能完成，典型场景是新旧系统切换：新流程启动后，旧流程的收尾任务才能结束。本次版本发布没有这类交接关系，因此不填。SF在四类中使用频率最低，填写时应确认确实存在“新的开始解锁旧的结束”的约束，避免为了凑类型而使用。

滞后时间的正、零、负

正数表示需要等待，如T4的+1天环境准备；零表示紧接，如T2在T1完成后当天启动；负数表示允许重叠，例如若T4填-1天，意味着联调可以在接口完成前1天就开始准备，适用于测试脚本可提前编写的场景。滞后时间要写出依据，是部署耗时、评审周期还是并行窗口，没有依据的滞后时间会变成隐藏缓冲。

解除条件要可验证

示例中每条解除条件都指向一个可检查的状态：评审通过、提交测试环境、报告签署。写成“开发差不多了”“等测试反馈”这类描述，依赖是否解除只能靠口头确认，排期更新就会滞后。可验证的解除条件同时明确了由谁确认，减少交接时的扯皮。

方向填错的后果

如果把T2和T1的依赖方向填反，系统会认为需求确认要等接口开发完成，排期上需求任务被推到开发之后，整个链条顺序颠倒。方向错误在单条记录上不易察觉，但会让后续任务的开始时间整体错位，且随着依赖链变长，偏差会累积。填写后应回读一遍：前置任务确实是当前任务的输入方。

当这些依赖记录进入日常工作项管理时，ONES支持在工作项上建立关联关系并随状态变化更新进度视图，团队可以把前置任务、责任人和解除条件放在同一条记录里，评审时直接对照状态确认依赖是否解除。具体字段配置以团队实际使用的工作项类型为准。

可迁移规律：换一个项目怎么套用这套填法

把上面的示例抽象成步骤，换到其他项目时可以按顺序执行：

1. 先定交付物，再定依赖。列出每个任务要产出的东西，只有当一个任务的输入确实来自另一个任务的产出时，才建立依赖。这样能避免给每个任务都挂前置，把排期图变成一团线。
2. 默认用FS，按真实约束改用其他类型。先问“前一件事做完，后一件事才能开始吗”，答案是肯定的就用FS；只有存在并行窗口时才考虑SS，只有结束点必须对齐时才用FF，只有新旧交接场景才用SF。
3. 滞后时间按实际等待或重叠估算，并写明依据。部署要多久、评审要几天、可以提前几天启动，把数字和理由一起记录，方便后续复盘时判断这个数字是否合理。
4. 控制依赖数量，只保留会改变排期的依赖。信息参考关系、同一负责人内部的先后习惯，不必都写成依赖。判断标准是：删掉这条依赖，后续任务的开始或结束时间是否会变化。不会变化的，用备注说明即可。
5. 为每条依赖写解除条件和确认人。填写完成后通读一遍，确认每条解除条件都能被第三方验证。

这套顺序的核心是先判断约束是否真实存在，再选择表达方式。依赖规则的作用是让排期可计算、可追踪，记录过多或过少都会削弱这个作用。

适用边界与常见误填

这套填法适用于任务粒度足够细、依赖双方责任明确的场景。任务粒度粗到“整个开发阶段”时，依赖类型和滞后时间都难以准确表达；双方责任人不清晰时，解除条件无人确认，依赖记录会停留在初始状态。跨项目的整体进度协调、多团队共享人员导致的容量冲突，需要进度管理和资源管理的方法处理，单靠工作项依赖规则无法解决。

常见误填可以对照下表检查：

误填类型	表现	后果	修正方式
把关联当依赖	两个任务只是内容相关，也建了FS	排期被不必要的约束拉长，关键路径失真	删掉依赖，改为备注或关联说明
循环依赖	A等B完成，B又等A完成	两条任务都无法进入可开始状态，排期计算失效	拆出真正的输入方，或把其中一条改为SS并明确启动条件
依赖不写解除条件	只填前置任务，解除条件留空或写“完成后”	依赖是否满足靠口头判断，状态更新滞后	补写可验证状态和确认人
滞后时间无依据	统一填+3天作为缓冲	缓冲被当成真实约束，掩盖实际等待时间	按部署、评审等实际耗时填写，并注明依据
依赖方向填反	前置任务与当前任务颠倒	整条依赖链顺序错位，偏差随链条累积	回读确认前置任务是输入方

填写完成后做一次整体检查：每条依赖是否有明确的前置任务、类型、滞后时间依据和可验证的解除条件，依赖链中是否存在环，删除某条依赖后排期是否真的不变。通过这三项检查，依赖规则就能支撑起可执行的排期安排。

常见问题

滞后时间填负数在实际排期中怎么理解，什么情况下可以用？

负数表示两个任务的时间点允许重叠。以完成—开始（FS）依赖为例，当前置任务完成前，后续任务就可以提前若干天开始准备。它适合后续任务存在可提前开展的准备工作，例如测试脚本编写、环境搭建、数据准备。使用负滞后时间的前提是这部分准备工作不依赖前置任务的最终产出，否则提前启动会返工。填写时把重叠的天数和可提前开展的具体工作一起写明，方便后续判断这个负数是否仍然成立。

一条依赖链里出现循环，排期会怎样，应该先改哪一条？

循环依赖意味着两条或多条任务互相等待，任何一条都无法进入可开始状态，排期计算会失效或给出异常结果。处理时先找出循环中真正提供输入的那条任务，把它改为无前置，或把其中一条依赖改为开始—开始（SS）并写清启动条件，让链条有一个明确的起点。改完后回读整条链，确认每个任务都只有一个方向上的输入来源。循环往往来自把协作关系误写成依赖，拆分时优先检查这一点。

任务粒度多细才适合填写依赖类型和滞后时间？

判断标准是这条任务能否对应一个可交付的产出物，以及它的开始和结束时间能否被单独观察。能对应具体产出、有明确责任人的任务，依赖类型和滞后时间才有意义；粒度粗到“整个开发阶段”时，内部包含多个先后环节，用一条依赖表达会失真。实际操作中可以先按交付物拆分，再对拆分后的任务判断是否需要依赖。粒度调整后，原有的滞后时间依据也要重新核对。

依赖已经填好，前置任务延期时排期应该怎么更新？

前置任务延期后，先确认延期影响的是哪个时间点：完成时间推迟会影响FS和FF依赖，开始时间推迟会影响SS和SF依赖。然后按依赖类型顺延后续任务，并检查滞后时间的依据是否仍然成立，例如环境准备时间是否因延期被压缩。更新时同步修改解除条件的预期达成时间，让依赖记录和实际状态保持一致。如果延期导致某条依赖不再成立，例如功能范围调整后不再需要等待，应及时删除该依赖，避免排期被无效约束拖长。

只靠工作项依赖规则，能解决跨团队的整体进度协调吗？

工作项依赖规则处理的是任务之间的先后与等待关系，能让单条依赖链的排期可计算、可追踪。跨团队的整体进度协调涉及多个项目的里程碑对齐、交付节奏和优先级取舍，需要项目进度管理的方法来处理；多团队共享人员造成的容量冲突，需要资源负载与冲突管理的方法。两者都会用到依赖信息，但依赖规则本身不承担这些判断。实际工作中可以把依赖记录作为输入，交给对应的进度或资源管理环节使用。