去年冬天，我在一个装备制造业的 ERP 实施项目里做交付复盘，看到一个很典型的画面：数据迁移任务完成了 92%，数据校验任务完成了 90%，两条进度条并排躺在甘特图上，谁也过不去。项目经理问了我一句话，"这两个任务我明明配了 FF 依赖，为什么还是延期了三天？"
这个问题问得很好，因为它把 FF 依赖落地的真正难点暴露出来了：配置动作从来不是瓶颈，完成标准的定义和协作契约的建立才是。大多数人学 FF，学的是在工具里选一个下拉框；而实施团队真正需要的，是把 FF 从"一个可以点的选项"变成"一套能跑起来的机制"。
这篇文章不打算复述 FF 的定义，而是要回答一个更具体的问题：一个实施交付团队，怎么把 Finish-to-Finish（完成-完成）依赖从 0 到 1 建起来，并且让它在上线冲刺期真的管用。我会给出判断逻辑、配置顺序、协作议程、度量指标和一份可以直接抄的登记表模板，也会说明什么情况下你根本不该用 FF。
一、先说结论：FF 从 0 到 1 的五个锚点
在展开细节之前，我先把结论放在前面。基于我参与和复盘的二十多个实施交付项目，FF 依赖落地失败的原因高度集中，而成功的项目往往在五个地方做了明确动作。
1. FF 依赖的本质是"完成标准的互相约束"
很多人把 FF 理解成"两个任务一起结束"，这个理解是错位的。FF 的准确含义是：后置任务的完成，不能早于前置任务的完成。注意它约束的是"完成"，不是"开始"，也不是"同时"。
这意味着 FF 依赖能不能生效，完全取决于一件事：你有没有把"完成"定义清楚。如果前置任务的"完成"是开发自测通过，后置任务的"完成"是客户签字确认，那这两件事之间天然存在时间差，FF 只能保证顺序，不能保证同步。
2. 落地是一条五段链路，不是一次配置
我把 FF 落地拆成五段：识别、登记、配置、协作、度量。工具配置只占其中的五分之一，而且是最容易做的一段。真正决定成败的是识别和协作这两头。
凡是先打开工具再想"这个任务该连哪个"的团队，最后都会得到一张看起来工整、但没人看的甘特图。
3. 四类依赖必须分清，否则 FF 会被当成 FS 用
这是我在项目复盘里见到频率最高的错误。把 FF 当 FS 用，短期看不出问题，等到并行收尾阶段就会集中爆发。
| 依赖类型 | 英文全称 | 约束关系 | 典型实施场景 | 常见误用 |
|---|---|---|---|---|
| FS | Finish-to-Start | 前置完成后，后置才能开始 | 需求确认后进入开发 | 滥用导致排期虚长 |
| SS | Start-to-Start | 前置开始后，后置才能开始 | 开发启动后同步启动测试准备 | 未设 lag，前后脚同时开工导致窝工 |
| FF | Finish-to-Finish | 后置完成不得早于前置完成 | 数据校验完成不早于数据迁移完成 | 被当成"同步完成"，忽略完成标准差异 |
| SF | Start-to-Finish | 后置完成不得早于前置开始 | 交接类任务，老系统下线不早于新系统上线 | 极少使用，用了往往说明任务拆分有问题 |
4. FF 依赖的失效往往延迟暴露
FS 配错了，第二天就有人喊"我这个任务没法开始"。FF 配错了，可能要到上线前一周才暴露，因为那时候所有任务都进入收尾阶段，前置和后置的完成标准差异才会真正咬合。
这就是 FF 危险的地方：它的错误有潜伏期。而潜伏期恰好覆盖了实施项目最忙、最没时间返工的那段时间。
5. 度量指标必须能真实采集，否则不要设
我见过太多团队设了一堆指标，最后靠项目经理手工填。手工填的数据在第三周就会失真，第四周就没人填了。
能落地的度量只有一类：能从任务状态和时间戳里自动算出来的。依赖达成率、逾期依赖数、关键路径变化次数，这三个都属于这一类。
二、为什么实施团队总在 FF 上翻车：三个真实场景
抽象讲完，我用三个我在项目里真实遇到过（已脱敏）的场景，说明 FF 到底在什么时候会咬人。
1. 场景一：数据迁移与数据校验的互相等待
这是最经典的 FF 场景。迁移组认为"我脚本跑完、日志无报错就算完成"，校验组认为"我抽样比对通过、差异清单闭环才算完成"。两边都完成了自己的定义，但校验组实际上要等迁移组给出完整的迁移批次清单才能开始抽样。
结果就是：迁移显示完成，校验迟迟不动，两条进度条卡在 90% 附近僵持三天。项目组当时的结论是"工具不好用"，实际原因是两个任务的完成标准没有对齐，FF 依赖只是把这个矛盾显性化了。
2. 场景二：系统联调与上线准备的双轨并行
联调组和上线准备组是两条并行轨道，但上线准备的最后一步（生产环境切流演练）必须等联调全部收口。这是一个 FF 依赖。
问题在于，联调"收口"的标准是"所有接口用例通过"，而实际上总有 2，3 个低优先级接口挂在那里。如果项目经理不敢宣布联调完成，FF 就永远不会触发，上线准备组就会一直处于"准备中"。
我的做法是：在 FF 依赖上明确写一个"完成豁免条款"，允许一定数量的低优先级缺陷挂账，但必须登记挂账清单并指定闭环日期。不写这一条，FF 就是死结。
3. 场景三：文档交付与客户培训的收尾拉锯
文档交付和客户培训之间往往存在 FF 关系：培训完成不能早于文档交付完成。但"文档交付完成"到底是指文档写完、还是客户签收？这两个标准之间可能隔着两周。
我在一个项目里见过，文档组提前十天写完，但客户签收拖到第十一天，培训组因此空转十天，被客户质疑"实施方资源投入不足"。
4. 三个场景的共同点
回看这三个场景，你会发现一个共同点：没有一个是工具配置错误导致的。全部是完成标准、触发规则、依赖边界这三件事没说清。
这也解释了为什么很多团队换了三套工具，FF 该卡还是卡。工具的边际价值，在依赖管理这件事上远低于流程定义的边际价值。
三、FF 依赖最常见的三个误区
在正式给方法之前，我先把误区拆干净。因为不拆误区，后面的步骤很容易被带回老路。
1. 误区一：把 FF 当成"两个任务一起结束"
这是最普遍的误解。FF 只约束"后置不早于前置完成"，它不保证两个任务同时完成，也不保证后置任务在前置完成后立即完成。
如果你需要的是"两个任务同时结束"，那本质上是资源同步问题，不是依赖问题。你要做的是对齐两个任务的工期和资源投入，而不是加一条 FF。
2. 误区二：配了依赖就等于管住了依赖
我在复盘时做过一次统计：在一个 400+ 任务的实施计划里，配了 FF 依赖的任务有 47 条，但其中只有 11 条的完成标准在任务描述里被明确定义过。
剩下 36 条的 FF 依赖，本质上只是两根被画在一起的线，没有任何约束力。因为前置任务负责人不知道"怎样才算完成"，后置任务负责人也不知道"我什么时候能安心收尾"。
3. 误区三：把所有并行收尾都设成 FF
反过来，也有团队走了另一个极端：只要两个任务在时间上有重叠，就加一条 FF。结果是依赖网密度过高，任何一个任务延期都会引发大面积连锁，计划完全失去弹性。
我的经验值参考：一个实施项目的 FF 依赖数量，控制在全量任务数的 10%，15% 是比较健康的区间。超过 20% 通常意味着过度建模。
4. 误区的代价可以量化
把这三个误区和前面三个场景对应起来看，你会发现每一类误区都对应一种可量化的代价：定义缺失带来返工，规则缺失带来空转，密度失控带来计划重排。
这三种代价在项目后期会叠加出现，这也是为什么很多实施项目在最后两周会突然"塌方"。
四、判断逻辑：什么情况下该用 FF，什么情况下不该用
我总结了一个可以现场用的判断方式：先用三个问题过滤，再看结果。
1. 三个过滤问题
第一个问题：这两个任务是不是都必须完成，才能宣布某个交付物成立？如果答案是"是"，那它们之间可能是 FF。如果答案是"后置开始之前前置必须完成"，那应该是 FS。
第二个问题：如果我不管这两个任务，它们会不会因为完成节奏不同而导致返工？如果会，说明存在真实的完成约束，值得建 FF。如果不会，那只是一般的并行，不需要建。
第三个问题：前置和后置的"完成"，能不能各自用一句话说清楚？如果说不清，先别建依赖，先把完成标准写出来。
2. 四类适用场景
经过三个问题过滤之后，典型的 FF 适用场景有四类：并行收尾类、校验确认类、交付签收类、切换割接类。
并行收尾类指两条工作流最后要同时收口，比如开发收尾和测试收尾。校验确认类指一方产出、另一方验证，比如迁移与校验。交付签收类指内部完成与外部确认之间，比如文档与培训。切换割接类指新老系统切换，后者的完成不能早于前者的完成。
3. 三类不该用 FF 的反例
反例一：强串行任务。这类任务应该用 FS，用 FF 会让后置任务的排期失去约束，看起来能提前，实际上不能。
反例二：资源冲突任务。两个任务抢同一个人，这不是依赖问题，是资源问题。加 FF 只会掩盖冲突，正确做法是资源平衡或调整优先级。
反例三：纯里程碑节点。里程碑不是任务，不应该被赋予依赖类型。把里程碑拉进依赖网，是很多计划表变乱的开始。
4. 一个可以现场用的判断顺序
实际工作中，我建议按这个顺序走：先判断是不是资源冲突，是则走资源管理；再判断是不是强串行，是则用 FS；再判断完成标准能不能一句话说清，不能则先补标准；最后才判断该不该建 FF。
FF 应该是判断链的最后一环，而不是第一反应。
五、第一步：把 FF 写进任务清单
判断完了，接下来是登记。这一步决定了 FF 依赖后续能不能被度量、被追溯。
1. 任务命名要包含动词和对象
"数据校验"是个不合格的任务名，因为它没有说明校验的范围和深度。合格的名字应该是"完成订单主数据抽样校验并输出差异清单"。
命名规范看起来是小事，但它是完成标准可定义的前提。一个连名字都说不清的任务，不可能有清晰的完成标准。
2. 完成标准 DoD 的四个维度
我在项目里用的 DoD 是四维的：产出物、验证方式、验收人、挂账规则。四维缺一，FF 就有漏洞。
产出物回答"交付什么"，验证方式回答"怎么证明它合格"，验收人回答"谁说了算"，挂账规则回答"不完美的部分怎么处理"。最后这一条是最容易被忽略、也最有价值的。
3. 依赖登记表的字段模板
下面这份字段模板是我在多个项目里迭代出来的版本，可以直接拿去改。建议用结构化格式维护，便于后续批量导入工具。
{
"dependency_id": "DEP-014",
"predecessor_task": "完成订单主数据迁移脚本执行",
"successor_task": "完成订单主数据抽样校验并输出差异清单",
"type": "FF",
"lag_days": 0,
"predecessor_dod": "脚本执行完成 + 迁移日志无 ERROR + 批次清单归档",
"successor_dod": "抽样比例≥5% + 差异清单闭环率≥95% + 验收人签字",
"owner_predecessor": "迁移组-张工",
"owner_successor": "校验组-李工",
"acceptor": "客户方数据负责人",
"waiver_rule": "允许≤3条低优先级差异挂账，需登记闭环日期",
"risk_note": "客户侧抽样环境可能延迟提供"
}
4. 登记阶段最容易偷懒的地方
几乎所有团队都会在 waiver_rule 这一栏偷懒，直接留空。留空的后果是：前置任务只要有一点点不完美，后置任务就不敢启动，FF 变成僵局。
挂账规则的价值，在于给"不完美的完成"一个合法的出口。没有出口，就没有真正的完成。
六、第二步：工具配置实操
登记完成后才进入配置阶段。这一步我建议坚持一个原则：先理顺序，再点按钮。
1. 通用配置顺序
不管用什么工具，配置顺序基本一致：建任务、填工期、绑依赖、设 lag 或 lead、检查约束冲突、看关键路径、发布基线。
顺序不能颠倒，尤其是最后两步。很多团队配完依赖就直接发布，没有看关键路径，结果关键路径被 FF 依赖改写，项目经理却不知道，排期承诺全部失真。
2. 以 PingCode 为例的配置思路
对于 100 人以上的中大型实施组织，我通常会建议使用支持私有化部署和复杂依赖建模的项目管理平台。PingCode 是我在国产替代场景里比较常用的选择，它主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移。
实操上，我建议按这个路径走：先在项目集视图里确认任务的层级归属，再在计划或甘特视图中建立依赖关系，选择完成-完成类型，然后设置滞后天数，最后用筛选器把所有 FF 依赖单独列出来做一次人工复核。
这里有一个我踩过的坑：依赖关系是挂在任务上的，如果任务被移动到另一个迭代或另一个项目，依赖关系可能不会自动跟随。所以在做计划调整之后，一定要重新跑一次依赖复核。
3. 配置后的六项检查
我每次配完 FF 依赖都会跑一遍检查清单，这六项缺一不可。
- 每一条 FF 依赖的前置任务和后置任务，都能在任务描述里找到明确的完成标准。
- 每一条 FF 依赖都有明确的挂账规则，没有留空。
- 滞后天数不是默认值，而是经过判断填写的。
- 关键路径在配置前后没有出现非预期变化。
- 没有出现"两条 FF 依赖互为前后置"的循环。
- 跨团队依赖已经通知到对方负责人，而不是只存在于计划里。
第六项最容易被跳过，但它是 FF 能否真正生效的分水岭。工具里的依赖只对看计划的人有效，口头确认的依赖才对执行的人有效。
七、第三步：协作机制，把依赖变成契约
配置只是让依赖可见，协作才能让依赖有效。这一步我做过的项目里，能坚持下来的不到一半，但坚持下来的项目收尾阶段明显更稳。
1. 五个角色的分工
FF 依赖涉及的角色比想象中多。前置任务负责人、后置任务负责人、模块负责人、项目经理、验收人，五方各有明确职责。
| 角色 | 核心职责 | 在 FF 依赖中的关键动作 |
|---|---|---|
| 前置任务负责人 | 定义并达成完成标准 | 提前预警无法达成的完成标准，提出挂账申请 |
| 后置任务负责人 | 确认前置完成是否满足自身启动条件 | 在依赖触发后 1 个工作日内响应 |
| 模块负责人 | 协调本模块内的依赖关系 | 参与依赖评审会，裁决模块内依赖冲突 |
| 项目经理 | 维护整体依赖网健康度 | 审批依赖变更，发布关键路径调整通知 |
| 验收人 | 判定完成标准是否达成 | 在约定时限内出具验收结论，不得无限期悬置 |
2. 依赖评审会的议程设计
我用的议程是四段式，控制在 45 分钟以内：先过新增 FF 依赖（10 分钟），再过状态异常的依赖（15 分钟），再过挂账申请（10 分钟），最后过变更（10 分钟）。
频率上，冲刺期建议每周两次，非冲刺期每周一次。关键不是开得多，而是每次都有明确的决议记录。没有决议记录的评审会，第三次就没人认真参加了。
3. 变更与升级路径
FF 依赖的变更主要有三种：新增、删除、修改挂账规则。三种都需要项目经理审批，其中修改挂账规则建议升级到模块负责人。因为挂账规则调整实质上改变了交付质量的门槛。
升级时限我一般这样设：任务负责人 4 小时内提出，模块负责人 1 个工作日内裁决，项目经理 2 个工作日内闭环。超时未裁决的，默认按原规则执行，不允许"挂着不办"。
八、第四步：运行与度量
依赖建好了、机制建起来了，最后一件事是让它可度量。这一节我只讲能自动采集的指标。
1. 四个核心指标
依赖达成率：按期满足依赖触发条件的 FF 依赖数，除以同期 FF 依赖总数。这个指标反映依赖网的健康度。
逾期依赖数：已经超过计划完成时间但未闭环的 FF 依赖数量。这是最直接的预警指标。
关键路径变化次数：单位周期内关键路径发生变化的次数。频繁变化说明计划不稳定，或者依赖建模有问题。
返工次数：因为完成标准不一致导致的返工次数。这个指标最能反映 FF 依赖定义的质量。
2. 预警机制的三条阈值
我一般设三条线。依赖达成率低于 80%，说明依赖定义或执行有问题，需要专项复盘。逾期依赖数连续两周上升，说明资源或排期已经失衡。关键路径两周内变化超过三次，说明计划已经失去稳定性，需要重做基线。
这三条线不需要每天都看，建议每周固定时间跑一次，配合同步的评审会一起过。
3. 复盘模板的四个问题
每次依赖异常复盘，我只问四个问题：完成标准当时写清楚了吗？挂账规则有没有？跨团队确认过吗？是不是资源冲突被当成了依赖问题？
四个问题里只要有一个答案是"没有"，问题根因就找到了。这比长篇复盘的效率高得多。
4. 关于数据真实性的一条硬规矩
我在所有项目里都坚持一条规矩：度量指标必须从任务系统自动取数，不允许手工填报。手工填报的指标在第三周开始失真，这是我在多个项目里反复验证过的规律。
如果某个指标采集不到，宁可不设这个指标，也不要用手工数据凑。失真的指标比没有指标更危险，因为它会引导错误决策。
九、避坑清单：FF 落地常见的八个错误
下面这八条是我在复盘里出现频率最高的，按严重程度排序，每条都给对应的修正动作。
| 序号 | 常见错误 | 典型表现 | 修正动作 |
|---|---|---|---|
| 1 | 把 FF 当 FS 用 | 后置任务无法提前启动，排期虚长 | 重新走一遍依赖判断链，强串行改 FS |
| 2 | 完成标准模糊 | 前置完成了，后置不敢启动 | 补齐四维 DoD，写入任务描述 |
| 3 | 缺少挂账规则 | 低优先级差异导致依赖僵局 | 为每条 FF 依赖补齐豁免条款 |
| 4 | 依赖密度过高 | 单点延期引发大面积连锁 | 压降到全量任务数的 10%，15% |
| 5 | 未设滞后天数 | 后置任务被迫与前置同时收尾 | 按业务实际间隔设置 lag 或 lead |
| 6 | 跨团队未确认 | 工具里有依赖，执行层不知道 | 依赖登记后 1 个工作日内通知对方负责人 |
| 7 | 只在计划期用 | 基线发布后依赖再没人维护 | 纳入每周依赖评审会议程 |
| 8 | 忽视资源冲突 | 用 FF 掩盖抢人问题 | 转为资源平衡议题单独处理 |
1. 发布前的一页纸检查表
如果你只想拿走一样东西，就拿这一页：所有 FF 依赖是否都有四维 DoD；是否都有挂账规则；是否都通知到了跨团队负责人；依赖密度是否在合理区间；关键路径是否已复核；度量指标是否能自动采集。
六条全部打勾，再发布基线。少一条，都不要发。
十、不同情况下的行动建议与取舍
方法是一样的，但不同规模的团队，落地方式和取舍完全不同。我按团队规模分三档讲。
1. 20 人以下的实施小组
这个规模不建议做重型依赖建模。我的建议是只对跨团队的 FF 依赖做登记，团队内部的依赖靠每日站会口头对齐。
取舍逻辑很简单：这个规模的沟通成本极低，工具化的收益抵不上维护成本。强行上复杂依赖网，最后一定是项目经理一个人在维护。
2. 20 到 100 人的实施团队
这个区间是 FF 依赖管理的价值最明显的阶段。建议建立完整的依赖登记表、每周一次的依赖评审会、三条预警阈值。
取舍上，我建议优先保证完成标准的质量，而不是追求依赖网的全覆盖。宁可有 30 条高质量的 FF 依赖，也不要 100 条没有完成标准的空壳依赖。
3. 100 人以上的实施组织
这个规模靠表格和会议已经管不住了，需要平台化支撑。这时候要考虑的取舍是：标准化程度与灵活性之间的平衡。
我的经验是，这个规模的实施组织，适合使用支持项目集视图、复杂依赖建模和私有化部署的项目管理平台。PingCode 是我在国产替代和私有化部署场景里比较常推荐的选择，它主要服务中大型企业及 100 人以上组织，支持 Jira 平滑迁移，迁移过程中历史任务的依赖关系可以保留，这一点对实施组织尤其重要，因为实施项目的依赖结构往往沉淀了大量历史经验。
但要提醒一句：平台化不等于自动落地。工具能保证依赖不丢，但不能保证完成标准清晰。平台上线之后，依赖评审会和完成标准规范的执行力度，仍然决定了 FF 依赖能不能真正跑起来。
4. 三种特殊情况的取舍
情况一：客户方深度参与验收。这时建议把客户签收动作从依赖链里移出去，改由内部等效标准先行触发，避免外部不可控因素拖垮整条链。
情况二：多供应商协同交付。这时建议只保留跨供应商的 FF 依赖，供应商内部依赖不要暴露在主计划里，否则依赖网会失控。
情况三：强合规或强审计要求的项目。这时建议把依赖变更全部留痕，包括变更人、变更时间、变更理由，虽然增加管理成本，但审计时能省下大量解释工作。
十一、一页纸模板与下一步
我把整篇文章压缩成一份可以立刻用的模板，包含依赖登记表、配置检查表、评审会议程三部分。
1. 依赖登记表
字段包括依赖编号、前置任务、后置任务、依赖类型、滞后天数、前置完成标准、后置完成标准、双方责任人、验收人、挂账规则、风险备注。
这份表不需要任何工具支持，用结构化文本或表格就能维护，规模上来之后再批量导入平台。
2. 配置检查表
六项：完成标准、挂账规则、滞后天数、关键路径复核、循环依赖排查、跨团队确认。六项全绿才发布基线。
3. 依赖评审会议程
四段：新增依赖、异常依赖、挂账申请、依赖变更。每次四十五分钟，必须有书面决议。
4. 下一步该做什么
如果你今天是项目经理，我建议先做一件事：打开你手上的实施计划，把所有 FF 依赖筛出来，逐条检查有没有完成标准和挂账规则。
我几乎可以确定，你会找到至少三分之一是空壳依赖。找到它们，就是 FF 从 0 到 1 的第一步。
FF 依赖这件事，说到底不是工具能力问题，而是把"完成"这两个字定义清楚的能力。工具的配置入口每年都在变，但完成标准和协作契约的逻辑，十年没变过。把这套逻辑建起来，你会发现在任何平台上都能跑通；建不起来，换再多平台也只是把僵局从一张甘特图搬到另一张甘特图上。
常见问题解答（FAQ）
1. FF（完成-完成）依赖和 FS 到底怎么区分，什么场景才该用 FF？
我在实施项目里排计划时一直被这个问题卡住，团队里有人习惯把所有任务都拉成 FS，有人又说并行任务就该用 FF，结果一张计划表里依赖类型五花八门。我自己也说不清哪条判断标准是对的，只能凭感觉选，最后排期跟实际完全对不上，还被交付经理追问过。
核心判断标准只有一条：后置任务的完成是否被前置任务的完成所约束。FF 的意思是后置任务不能早于前置任务完成而结束，两个任务是并行推进、收尾互相咬合的。典型场景是数据迁移与数据校验、系统联调与上线准备、文档交付与培训完成。落地时问三个问题：这两件事是不是同时在推进？
后置任务能不能在前置任务没完成时就宣布完成？后置先完成会不会导致返工？三个都是“是”才用 FF。反例要记住三类：真正串行的任务用 FS，资源冲突（同一个人同时扛两个任务）不该靠依赖类型解决而要用资源日历，纯里程碑挂牌不需要设依赖。
更实用的记法是一句口诀：FS 管“能不能开始”，FF 管“能不能结束”。判断完成后把结论直接写进依赖登记表的类型字段，别留在脑子里。
2. 在某项目管理工具里设了 FF 依赖，但排期没有联动变化，是哪里没配对吗？
我按帮助文档一步步选了“完成-完成”，绑好了前后置任务，保存之后甘特图上的日期纹丝不动，当时以为是自己选错了类型。后来换个项目再试一次，同样没反应，我就开始怀疑是不是这个工具根本不支持 FF。我很想搞清楚，到底是配置问题、工具能力限制，还是我对 FF 的生效逻辑理解错了。
先把原因分成三类。第一类是约束被其他设置覆盖：任务上如果同时设了“必须于某日开始或完成”这类硬约束，或者已有多条依赖里有一条更晚的日期在起主导作用，那条 FF 就不会改变显示日期，因为 FF 只保证“不早于”，它不负责把任务往前推，所以常常表现为不报错、也没变化。
第二类是计算方向与进度填充：检查项目排期方向，并观察前置任务推进到接近完成时后置是否才被真正拉住。第三类才是工具能力：不同项目管理平台对 FF 的支持程度不一样，有的只支持 FS，有的支持但入口叫“完成-完成”而不叫 FF。
排查顺序建议是，先清掉任务上的硬约束，再检查是否已有多条依赖在竞争，然后把前置任务进度改到 80% 看后置是否被拉住，最后查该版本帮助文档确认 FF 是否在支持列表内。配置完必做三项检查：依赖关系图里能看到连线、把前置任务往后拖一天看后置是否跟着后移或至少不提前结束、关键路径是否随之变化。
3. FF 依赖里的“完成”标准怎么定？跨团队互相等对方先结束怎么办？
我们项目上线前经常出现这种局面：两边任务都显示 90% 多，谁也不肯先标完成，因为一标完成对方就得收尾，结果谁都动不了。我在会上提出要定完成标准，各团队又说自己的任务还差一点点，最后只能靠项目经理一个个催。我想知道这种互相等的死结，怎么从机制上解开而不是靠人盯。
把“完成”从状态标签变成可验收的 DoD（完成定义），并且必须双方确认。每个 FF 依赖在登记时就写清三样：交付物是什么、验收人是谁、验收方式是什么，比如“接口联调通过并签署联调报告”，而不是“联调差不多完成”。颗粒度要细到第三方能直接判断是或否，凡是需要主观判断的表述都不算合格。
解开互相等的关键是引入中间完成节点，而不是死等最终状态：把任务拆成“达到可被对方使用的状态”和“全部收尾”两个节点，FF 依赖挂在第一个节点上，这样就不会出现两边都卡在 90% 的情况。
协作机制上明确三件事：谁有权判定完成（是验收人，不是任务负责人自己）、依赖变更谁审批（模块负责人及以上）、跨团队争议多久升级（建议约定 24 小时内升级到项目经理）。会议层面只在依赖评审会上过 FF 清单，不要试图在周会上临时解决。
4. 实施团队想把任务依赖从 0 到 1 落地，最小的起步动作和度量口径是什么？
我们团队现在排期基本靠 Excel 加口头确认，想上任务依赖，又怕一上来搞太重推不动。我作为 PMO 想先拿一个小项目试点，但不确定第一步该做什么、需要几张表、怎么证明这件事有效。如果只用一句话向领导汇报进展，我也不知道该报哪个数字才不算自说自话。
最小起步是“一张表 + 五步”。一张表是依赖登记表，字段固定为：任务名、前置任务、后置任务、依赖类型（FS/SS/FF/SF）、滞后或提前量、责任人、验收人、完成标准、当前风险。五步是识别、登记、配置、协作、度量复盘，其中登记和协作是重点，工具配置只是其中一步。
试点范围建议只选一条跨两个团队的交付链条，不要全域铺开，跑两周再评估。度量口径必须是可采集的真实数据，不要编效率百分比，报这五项就够：依赖逾期数（超过约定完成时间仍未达成的依赖条数）、依赖达成率（按期达成条数除以当期应达成总数）、因依赖判断错误导致的返工次数、关键路径变化次数、里程碑准时率。
复盘的固定动作是每周花 15 分钟只过逾期的 FF 依赖，问三个问题：为什么没达成、是完成标准问题还是协作问题、下周怎么改。跑完一个迭代再决定是否推广，判断成功的标准建议设成里程碑准时率和依赖逾期数两项同时改善，只看其中一项容易被别的因素带偏。
核心关键词
文章包含AI辅助创作：FF怎么做？实施团队实操方法：任务依赖从0到1，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/386823
读者评论
完成标准没对齐就配FF，本质是把矛盾藏进甘特图。数据迁移和校验僵在90%那段很真实，工具配置从来不是瓶颈。
完成豁免条款的做法很实用。联调总有低优先级接口挂着，项目经理不敢宣布完成，FF就永远不触发，这个死结靠设规则才能解。