项目管理系统的任务依赖，FS、SS、FF、SF四种关系别凭感觉连

项目排期里最容易被低估的动作，是给两条任务拉一条线。线拉对了，日期能自动推演；线拉错了，甘特图看起来完整，实际却会掩盖等待、并行和收尾的失真。FS、SS、FF、SF不是四种画法，而是四种约束语义。搞清它们，项目管理系统里的任务依赖才不会变成凭感觉连线。

一、任务依赖约束的是两个时间点

1. 前置任务与后置任务

一条依赖关系只有两个角色：前置任务和后置任务。前置任务是约束的发出方，后置任务是承受方。箭头从前置指向后置，表示后置任务的时间点不能越过前置任务的状态。方向画反，后面所有日期都会跟着反。

2. 四个字母的读法

FS、SS、FF、SF的字母顺序固定：前一个字母指前置任务到达的状态，后一个字母指后置任务被约束的时间点。F是完成，S是开始。所以FS就是前置完成、后置才能开始；SF则是前置开始、后置才能完成。先读前置状态，再读后置动作，比死记中文全称更不容易混。

依赖类型回答谁等谁，提前量和滞后量回答等多久。两者混在一起，是大多数误连的源头。

二、FS、SS、FF、SF分别管什么

四种关系，差别都在开始和完成两个时间点。

1. FS：完成到开始，最常用也最容易被滥用

FS（Finish-to-Start）表示前置任务完成后，后置任务才能开始。需求评审结束再进入开发、接口联调完成再做验收，都是FS。FS适合有明确交付物交接的场景，但不适合所有任务。把没有交付关系的任务也连成FS，会拉长工期，掩盖可并行的部分。

2. SS：开始到开始，解决并行推进

SS（Start-to-Start）表示前置任务开始后，后置任务才能开始。它不要求两者同时开始。开发开始3天后，测试用例编写再启动，可以用SS加3天滞后量表达。SS允许并行，但前提是写清后置任务需要前置任务先产出什么。只连SS不设滞后量，后置任务容易缺输入而停滞。

3. FF：完成到完成，约束的是收尾

FF（Finish-to-Finish）表示前置任务完成后，后置任务才能完成。它常出现在同一批交付物的收尾环节，例如全部模块开发完成后，集成测试才能结束。FF要求后置任务不早于前置任务完成，不要求两者同时完成。前置任务的完成标准不清，后置任务的完成时间就会被不断推迟。

4. SF：开始到完成，少见但并非无用

SF（Start-to-Finish）表示前置任务开始后，后置任务才能完成。它最少见，典型场景是值班交接，接班人开始值班，交班人才能结束值班。SF适用面窄，不能拿它代替FS。把普通先后顺序写成SF，排期逻辑会反过来。

图1：四种依赖关系的箭头方向

三、提前量和滞后量，别用来替代逻辑

类型选对，还要处理等多久。

1. 滞后量是等待，提前量是提前介入

滞后量是在依赖关系上增加等待时间，通常记为正值。比如FS加2天，表示前置任务完成后还要等2天。提前量相反，表示后置任务可以提前介入，很多工具用负的滞后量记录。比如FS减2天，表示前置任务完成前2天，后置任务就能开始。

滞后量和提前量都必须有可解释的依据。等待审批回执、等待材料到货，可以用滞后量；文档评审提前介入，可以用提前量。写不出依据的天数，往往只是凭经验估的。

2. 先有逻辑，再谈天数

PMI在2017年发布的《项目管理知识体系指南（PMBOK指南）》第六版中明确，提前量和滞后量用来更准确地表达逻辑关系，不能替代依赖关系本身。没有真实约束，不该靠加几天滞后量强行连接；有真实约束，先把类型选对，再补时间偏移。

更稳妥的做法是把天数换成可验证的触发条件。与其写SS加3天，不如写前置任务开始且接口文档冻结后，后置任务启动。可验证的触发条件，比固定天数更能防止依赖失效。

图2：滞后量形成等待区，提前量形成重叠区

四、四种高频误连，问题都出在把约束当成习惯

类型和时间量都写了，仍然可能连错，因为有些线从一开始就不该存在。

1. 四类误连及其修正

其中最常见的是全连FS。它会让甘特图看起来很有秩序，实际却把可并行的工作排成了串行。

2. 资源冲突不是任务依赖

两个人不能同时做两件事，这是资源约束，不是任务依赖。把它写成FS，会掩盖资源不足。资源冲突应该通过资源平衡、调整优先级或增派人手解决。依赖表达技术或业务上的先后，资源问题要单独管理。

3. 循环依赖和漏连要先排除

循环依赖是A等B、B等C、C又等A，排期无法计算；漏连则让本该等待的任务提前开始，制造虚假浮动时间。两者都会让项目管理系统给出的日期失真。漏连还会让关键路径频繁跳变。连完必须做一次环路和异常孤立任务检查。

五、一套可执行的连线校验法

减少误连，可以把连线拆成固定步骤。

1. 用三问确定关系类型

第一问：后置任务被约束的是开始还是完成？第二问：前置任务要到达开始还是完成，后置任务才被允许？第三问：这个约束来自技术、合同还是业务规则？三问的答案分别对应后置时间点、前置状态和依赖性质，能排除大部分凭感觉的连线。

2. 连完之后做四项检查

一看方向，箭头是否从前置指向后置；二看类型，FS、SS、FF、SF是否与三问答案一致；三看时间量，滞后量和提前量是否说得清依据；四看结构，是否有环路、异常孤立任务或没有交付物的依赖。

建议在计划评审时留下一张依赖清单，写清前置任务、后置任务、关系类型、时间偏移和约束依据。依赖清单让排期在人员变动后仍然可解释。

图3：从两个时间点出发判断依赖类型

六、常见问题

1. FS和SS可以同时用在同一对任务上吗？

一般不建议。保留一条主约束更清晰；确有多个约束，拆成两个节点或用里程碑表达。

2. 任务依赖是不是越多越严谨？

不是。依赖只表达真实约束，多余的连线会制造并不存在的关键路径，降低并行度。

3. 敏捷迭代里还需要设置依赖吗？

需要，但粒度可以更粗。迭代内保留必要的任务依赖，跨团队用交付物或里程碑对齐。

4. 依赖关系设错后，最先出现什么信号？

常见信号是日期顺序不合逻辑、成员反复等待前置条件、关键路径频繁变化。发现后先查方向和类型，再查时间量，别急着改项目管理系统里的日期。