任务依赖规则用“前置任务—依赖类型—后置任务”三要素表达执行顺序，常见类型有完成—开始（FS）、开始—开始（SS）、完成—完成（FF）、开始—完成（SF）四种。本文以一次版本发布准备为示例情景，给出一份可直接参照填写的依赖表，逐条解释类型选择、滞后量与硬软依赖的判断依据，并演示如何从依赖关系推演排期、识别冲突。
要点总览（TL;DR）
- 任务依赖规则用“前置任务—依赖类型—后置任务”三要素表达执行顺序，常见类型为FS、SS、FF、SF四种，分别约束后置任务的开始或完成时点。
- 一份完整的依赖表至少包含任务名称、计划开始与结束时间、前置任务、依赖类型、滞后量或提前量、依赖性质与备注，示例中四种类型各出现一次。
- 滞后量写在依赖关系上而非任务工期里，硬依赖先定、软依赖后补，可以避免可协商的安排掩盖真正的约束。
- 自查重点包括循环依赖、孤立任务、推演日期与计划日期冲突、依赖类型误用以及滞后量被当作工期。
- 依赖规则只管工作项层面的先后顺序；项目整体进度归项目进度管理，人员容量冲突归资源负载与冲突管理。
示例目标：用一张依赖表说清执行顺序
本示例设定一个演示情景：某产品团队准备一次版本发布，需要完成代码冻结、回归测试、发布说明撰写、上线审批、生产部署和发布公告等任务。任务名称与日期均为虚构，用于演示依赖规则的填写方法，不代表任何真实项目数据。
示例要演示的内容包括四项：四种依赖类型（FS、SS、FF、SF）各至少出现一次；滞后量与提前量如何写在依赖关系上；硬依赖与软依赖如何区分标注；以及如何从依赖表推演出各任务的开始与结束时间。
示例的完成标准有两条。第一，依赖表本身前后自洽，按依赖类型把前置任务的时间条件传递到后置任务，能够推演出每个任务的候选开始与结束日期。第二，推演结果与计划日期之间的冲突可以被识别出来，而不是被表格掩盖。达到这两条，这张表就可以作为填写模板使用。
完整示例：版本发布准备的任务依赖表
下表是示例情景的完整依赖表。字段包括任务名称、计划开始时间、计划结束时间、前置任务、依赖类型、滞后量或提前量、依赖性质与备注。日期以工作日为单位简写，D1 表示示例周期的第 1 天。
| 任务 | 计划开始 | 计划结束 | 前置任务 | 依赖类型 | 滞后量/提前量 | 依赖性质 | 备注 |
|---|---|---|---|---|---|---|---|
| T1 代码冻结 | D1 | D2 | — | — | — | — | 起点任务 |
| T2 回归测试 | D3 | D6 | T1 | FS | 滞后 1 天 | 硬依赖 | 冻结后留 1 天准备测试环境 |
| T3 发布说明撰写 | D2 | D5 | T1 | SS | 提前 1 天 | 软依赖 | 可与冻结收尾并行启动 |
| T4 上线审批 | D7 | D8 | T2 | FS | 无 | 硬依赖 | 测试通过后才能提交审批 |
| T5 生产部署 | D9 | D9 | T4 | FS | 无 | 硬依赖 | 审批通过后执行 |
| T6 发布公告定稿 | D8 | D9 | T3 | FF | 无 | 软依赖 | 说明定稿后公告才能定稿 |
| T7 发布公告发布 | D9 | D9 | T5 | FS | 无 | 硬依赖 | 部署完成后发布 |
| T8 值班安排确认 | D9 | D9 | T5 | SF | 无 | 软依赖 | 部署一开始即可确认值班，部署完成时值班必须就位 |
表中四种依赖类型均有出现：T2、T4、T5、T7 使用 FS；T3 使用 SS；T6 使用 FF；T8 使用 SF。滞后量出现在 T2，提前量出现在 T3，其余依赖不附加时间偏移。硬依赖集中在测试、审批、部署这条主链上，软依赖分布在文档与协作类任务上。
逐项解释：每条依赖为什么这样填
依赖类型的选型依据是“后置任务真正需要前置任务提供什么条件”。需要前置任务的结果才能启动，选 FS；只需要前置任务启动、不必等结果，选 SS；后置任务的完成必须以某个中间成果完成为前提，选 FF；后置任务的完成时点由前置任务的启动触发，选 SF。下面逐条说明。
FS：T2 回归测试依赖 T1 代码冻结
回归测试必须拿到冻结后的代码才能执行，这是工作本身的逻辑顺序，无法协商，因此标为硬依赖。冻结结束到测试开始之间需要一天准备测试环境，这一天的等待写在滞后量上，而不是把测试工期改长。推演时，T1 结束于 D2，加 1 天滞后，T2 最早 D3 开始，与其计划开始一致。
SS：T3 发布说明撰写依赖 T1 代码冻结
撰写发布说明只需要知道本次冻结包含哪些变更，冻结工作一开始，变更清单就基本确定，不必等冻结全部结束。因此选 SS，并允许提前 1 天启动，即 T1 开始（D1）后提前到 D2 启动撰写。这条依赖属于软依赖：如果变更清单尚未稳定，可以协商推迟撰写启动，不影响主链。
FF：T6 发布公告定稿依赖 T3 发布说明定稿
公告的内容以发布说明为准，公告定稿的时点不能早于说明定稿。这里约束的是完成时间而非开始时间，所以选 FF。T3 计划结束于 D5，T6 计划结束于 D9，满足“不早于”的条件。该依赖标为软依赖，因为公告可以先按草稿推进，说明定稿后再做最后校对，属于可协商的优化安排。
SF：T8 值班安排确认依赖 T5 生产部署
值班人员需要在部署启动时进入待命状态，部署完成时值班必须已经就位。后置任务的完成由前置任务的启动触发，因此选 SF。T5 于 D9 启动，T8 计划在 D9 完成，条件成立。这条依赖标为软依赖，值班安排可以提前沟通，SF 表达的是最晚完成约束。
滞后量与提前量的写法
滞后量表示在依赖条件满足后额外等待的时间，提前量表示允许比依赖条件更早行动的时间。填写时统一写在依赖关系上，用“滞后 N 天”“提前 N 天”标注，避免与任务工期混淆。T2 的滞后 1 天是等待测试环境，不是测试本身需要多一天；T3 的提前 1 天是允许并行启动，不是把撰写工期缩短。
硬依赖与软依赖的判断
判断依据是这条依赖能否协商调整。由工作逻辑或外部约束决定、调整就会导致返工或违规的，标为硬依赖，例如测试必须在冻结之后、部署必须在审批之后。基于并行优化或协作偏好、调整后只影响节奏不影响正确性的，标为软依赖，例如说明撰写与冻结并行、公告与说明的完成顺序。填写时先定硬依赖，再补软依赖，可以避免软依赖掩盖真正的约束。
由依赖推演出的日期与冲突点
按依赖类型传递时间条件：FS 传递前置结束时间，SS 传递前置开始时间，FF 与 SF 约束后置结束时间，再叠加滞后或提前量得到候选日期。推演结果与计划日期基本吻合，但存在一处需要关注的冲突：T6 依赖 T3 以 FF 方式约束完成时间，而 T7 发布公告又依赖 T5 部署完成，若 T3 因故延后到 D8 之后结束，T6 的完成条件被推迟，T7 在 D9 发布就会出现公告未定稿的风险。这一冲突在依赖表上可见，处理方式是将 T3 标为关键关注任务，或在 T6 与 T7 之间补充一条 FS 依赖。
可迁移规律：换一个项目怎么套用
把上面的示例迁移到其他项目，可以按固定顺序填写，再用一份清单自查。
填写顺序
- 先列出全部任务及其计划开始、结束时间，暂不填依赖。
- 识别硬依赖：逐条问“这个任务能否在前置任务未完成时正确开展”，不能的标为硬依赖并选定类型。
- 补充软依赖：找出可以并行或可协商顺序的任务，用 SS、FF 表达并行关系。
- 最后添加滞后量与提前量，只写在确有等待或允许提前的依赖上，并注明原因。
依赖类型的一般判断
- 需要前置成果才能启动：FS，最常见，适合交付物传递类关系。
- 只需前置启动即可并行：SS，适合准备、撰写、环境搭建等伴随性工作。
- 完成时点受前置完成约束：FF，适合校对、汇总、收口类工作。
- 完成时点由前置启动触发：SF，使用场景较少，适合待命、交接类安排。
滞后量的常见使用场景
等待审批流转、等待环境准备、等待外部供应商响应、等待冷却或观察期，都适合用滞后量表达。滞后量应写明原因，避免成为掩盖工期估算不准的缓冲。
依赖表自查清单
- 循环依赖：沿前置关系回溯，确认没有任务间接依赖自己。
- 孤立任务：除起点任务外，每个任务至少有一条入向依赖；没有入向依赖的任务要确认是否真的独立。
- 日期冲突：按依赖推演出的候选日期与计划日期是否一致，不一致处是否已说明理由。
- 类型误用：约束完成时间的场景是否误填为 FS，并行场景是否误填为 FS 导致排期虚长。
- 滞后量误用：滞后量是否被当作固定工期写进了任务时长。
在工具中落地时，这些规则对应到工作项的前后置依赖设置与排期字段。以 ONES 为例，可以在工作项上维护前置任务、依赖类型与计划时间，让依赖关系随任务状态变化被团队看到，评审时直接对照依赖表检查冲突，减少口头确认带来的遗漏。
适用边界：依赖规则管到哪里为止
依赖规则聚焦工作项层面的安排，回答的是“哪个任务在什么条件下可以开始或完成”。它能把单个任务的先后顺序表达清楚，并支撑局部的排期推演，但不承担项目层面的全部进度判断。
项目整体进度、里程碑达成与关键路径分析归项目进度管理。依赖表是这些工作的输入之一，不能替代进度计划本身的编制与跟踪。人员容量冲突、多人多任务的时间挤占归资源负载与冲突管理，依赖规则只能提示某个任务被推迟，无法判断是谁的资源不足。
此外，本文的任务名称、日期与推演结果均为演示情景，用于说明填写方法，不作为任何真实项目的排期依据。实际使用时，应以团队确认的任务清单、工期估算和约束条件替换示例数据，再按上述顺序重新推演。
常见问题
滞后量和提前量应该写在依赖上还是任务工期里？
写在依赖关系上。滞后量表示依赖条件满足后额外等待的时间，提前量表示允许比依赖条件更早行动的时间，二者描述的是两个任务之间的时间关系，与单个任务需要做多久是两回事。
示例中 T2 回归测试在代码冻结后滞后 1 天开始，这 1 天用于准备测试环境，测试本身的工期不变。如果把滞后量并进任务工期，任务看起来变长了，后续按工期做估算时容易失真。填写时统一标注“滞后 N 天”“提前 N 天”，并写明等待或提前的原因。
硬依赖和软依赖判断不一致时怎么处理？
先回到判断标准：这条依赖调整后是否会导致返工、违规或结果错误。会，就是硬依赖；只影响节奏、不影响正确性，就是软依赖。判断不一致通常是因为对“能否协商”的理解不同，可以让提出软依赖的一方说明调整后的补救措施，再决定是否降级。
实操上建议先定硬依赖、再补软依赖。硬依赖构成主链，软依赖用于并行优化，顺序反过来容易让可协商的安排挤占真正的约束。评审时优先复核被标为软依赖但位于主链上的关系。
依赖表推演出的日期和计划日期对不上，应该改哪个？
先判断差异来源，再决定改依赖还是改日期。如果推演结果显示后置任务可以更早开始，说明计划日期留了不必要的缓冲，可以收紧；如果推演结果显示后置任务无法按计划开始，说明计划日期与依赖条件矛盾，需要调整计划日期、缩短前置任务工期，或重新评估这条依赖是否真的必要。
无论改哪一边，都要在备注中写明理由，避免下次评审时无法还原判断过程。示例中 T6 与 T7 之间的风险就是通过推演发现的，处理方式是在两条任务之间补充一条 FS 依赖，或把 T3 标为关键关注任务。
任务数量很多时，依赖表要全部逐条填写吗？
不必。依赖表的作用是表达执行顺序和识别冲突，粒度应与排期风险匹配。对主链上的任务、跨团队交接的任务、有外部约束的任务，逐条填写依赖类型与性质；对同一负责人连续完成、顺序显而易见的小任务，可以合并为一个任务或只标一条 FS，减少维护成本。
判断标准是：这条依赖如果漏填，是否会导致排期推演出错或冲突被掩盖。会，就填；不会，可以简化。简化后仍需保留自查环节，确认没有因合并而丢失关键约束。
依赖规则能解决排期冲突吗？
能识别一部分，不能全部解决。依赖规则可以暴露“后置任务在前置条件未满足时被安排”这类顺序冲突，示例中公告定稿与发布时点的风险就属于这一类。它无法判断某个任务延后是因为人手不足还是因为优先级调整。
项目整体进度、里程碑达成归项目进度管理；人员容量冲突、多人多任务的时间挤占归资源负载与冲突管理。遇到排期冲突时，先用依赖表确认顺序是否成立，再判断是否属于资源问题，分别交给对应的管理动作处理。
