FF怎么做？项目负责人风险控制：任务依赖从0到1

2024 年 3 月，我负责的一个 0→1 项目在上线前 72 小时被叫停。测试报告全绿，代码已冻结，运维演练跑了两轮。卡住我们的是合规评审，法务要求的数据出境说明还没签字。任务看板上，"功能测试"和"合规评审"是两条并排的柱子，中间什么连线都没有。所有人都以为这两件事互不相干，直到发布窗口被一刀砍掉。

那次复盘我发现一件事：项目延期的真正原因，很少是某个任务做慢了，而是任务之间那条本该存在、却没人画的线。在项目管理里，这条线叫依赖关系；而在依赖关系的四种类型中，被误解最深、被使用最少、出事后代价最大的，是 FF，Finish-to-Finish，完成-完成依赖。

这篇文章不打算再讲一遍"在软件里怎么拖一条线"。我更想回答三个问题：FF 到底是什么、在 0→1 阶段哪些地方必须用它、以及作为对结果负责的那个人，你怎么用它来做风险控制。下面所有数据，除特别标注外，都来自我近五年经手的项目复盘记录（个人样本，非行业统计），我会尽量把口径写清楚。

一、先把结论说完：FF 是收尾对齐，不是顺序约束

如果你时间有限，只看这一节也可以。FF 依赖的核心结论有四条，我把它们按重要性排序。

1. FF 约束的是"什么时候能结束"，不是"什么时候能开始"

项目管理知识体系（PMBOK）对依赖关系的定义中，FF 指的是：后继任务的完成时间不能早于前置任务的完成时间。注意这句话的两个关键词，"完成"和"不能早于"。

它没有说后继任务不能提前开工。恰恰相反，FF 允许后继任务提前启动、提前做完 90% 的工作量，只是不允许它提前宣布结束。这和 FS（完成-开始）的约束方向完全不同：FS 卡的是起点，FF 卡的是终点。

很多人的误区就在这里。他们把 FF 理解成"A 做完，B 才能收尾"，这没错，但由此推论出"所以 B 只能等 A 做完才能开始"，这就错了。一旦你把 FF 当成 FS 用，会白白浪费大量并行时间。

2. 0→1 项目里，FF 是唯一能表达"同步收尾"的语法

FS 能表达先后，SS（开始-开始）能表达并行启动，但只有 FF 能表达"两件事必须同时关门"。而 0→1 阶段最典型的失败模式，恰恰是"每件事都做完了，但收尾时刻没对齐"。

产品文档写完了，但评审没通过；代码开发完了，但安全扫描没跑完；功能上线了，但数据迁移校验没确认。这些都不是"任务没做完"，而是一条任务链的终点比另一条早到了，导致整体无法交付。

3. 依赖控制的四步闭环里，90% 的团队只做了第一步

风险控制的通用框架是：识别 → 评估 → 应对 → 监控。放到依赖管理上，就是：找出依赖 → 判断类型和强度 → 准备断链预案 → 持续监控漂移。

我在自己的项目记录里做过一次统计：如果把"给任务连上依赖线"算作第一步，那么能走完四步的团队，在 100 人以上组织里大概只有 8% 到 12%。绝大多数团队停在了"线连上了，剩下的靠开会"。

4. 工具只能承载依赖，不能替你判断依赖

这是我做项目负责人这些年最硬的一条经验。软件能把依赖画出来、算关键路径、算浮动时间，但它不知道两个任务之间该不该有依赖、这条依赖是硬的还是软的、断了以后业务上能不能接受。这些判断只能由对结果负责的人来做。

二、真实场景：0→1 阶段的依赖为什么必然失控

要理解 FF 的价值，得先理解 0→1 项目和成熟项目的根本差异。这不是"内容不一样"，而是"依赖结构的物理性质不一样"。

1. 需求在动，依赖关系就是流沙

1→N 的阶段，需求是收敛的。你知道要做哪些功能、走哪些流程、过哪些审批，依赖关系一旦搭好，基本上可以复用三五个版本。

0→1 完全相反。第一个月确定的技术方案，第三个月可能整个推翻；第一周拍板的合作方，第五周可能换人。每一次范围变更，都会让一批依赖关系失效或者新增。在 0→1 项目里，依赖不是"搭一次用半年"的静态结构，而是每周都在重写的动态结构。

我统计过自己经手的 6 个 0→1 项目：依赖关系的月均变更率在 28% 到 41% 之间，而同期的 1→N 维护型项目只有 6% 到 12%。也就是说，0→1 项目的依赖维护成本，是成熟项目的 3 到 4 倍。

2. 依赖数量会跨过一个"人工管理失效"的临界点

这条经验我吃过亏，所以记得很清楚。当项目总任务量在 200 条以内、依赖关系在 100 条以内时，一个有经验的项目负责人靠 Excel 加脑图，基本能管住。

但当任务量突破 500 条、依赖关系突破 400 条，情况会突然变化。不是因为难度线性增加了，而是因为依赖之间会产生二阶、三阶的传导效应：A 动了影响 B，B 动了影响 C，C 又反过来影响 A 的最晚开始时间。这种回路靠人脑是算不出来的。

我在一个 120 人规模的研发组织里见过最夸张的一次：一个 0→1 产品项目涉及 6 个团队、847 条任务、1,312 条依赖关系。当时团队用共享表格维护依赖清单，任何一次需求变更，需要人工排查的相关任务平均是 23 条，而实际被排查到的平均只有 9 条。漏掉的 14 条，就是后面所有延期的种子。

3. 依赖失控的三种典型表现

如果你在自己项目里观察到下面这三种现象，基本可以确认依赖管理已经失控了。

• 现象一：延期总是"突然发生"。周会上大家汇报都是绿的，某天早上突然发现整体要延期两周。这通常意味着关键路径上的依赖没有被正确连接，浮动时间被错误计算了。
• 现象二：同一个任务被反复"重新排期"。一周内某个任务的计划完成日期改了三次以上，说明它的上游依赖在漂移，而排期的人在被动追赶。
• 现象三：跨团队交接靠"喊"。A 团队做完了在群里 @ 一下 B 团队，B 团队才开始。这种口头交接意味着依赖关系只存在于人的记忆里，不在计划里。

三、拆解四个常见误区

讲完背景，我把这些年见过、也亲自犯过的四个误区摆出来。这四个误区有一个共同点：它们看起来都很"规范"，所以特别难被发现。

1. 误区一：把 FF 当成 FS 的同义词

最常见的表述是"A 任务完成后 B 任务才能开始，这就是 FF"。这句话描述的其实是 FS。问题在于，很多团队的项目模板里只有一种依赖类型，所有连线都是 FS，于是"依赖"这个词在团队内部就等于"先后顺序"。

后果是什么？当出现真正需要"同步收尾"的场景时，团队没有词汇去描述它。于是只能靠口头约定、靠周会强调、靠负责人盯人。而这些手段在项目顺利时看不出问题，一到冲刺期就会集体失效。

（1）一个判断方法

如果你的项目计划里，两条任务的依赖关系是"B 必须在 A 完成之后才算完成"，而不是"B 必须在 A 完成之后才能开始"，那它就是 FF，不是 FS。这一句话的差别，决定了排期能不能压缩。

2. 误区二：所有任务都设成强依赖

这是我早期最常犯的错误。为了让计划"看起来严谨"，我把能找到的关系全部设成硬依赖。结果整个计划变成一条几乎没有浮动时间的直线，任何一个任务延期，整个项目就跟着平移。

更糟的是，这种计划会摧毁团队的主动性。当每一件事都必须等前一件事做完，团队就失去了并行推进的动力，只剩下排队。

正确的做法是区分三种强度：硬依赖（业务或技术上的强制约束，不可协商）、软依赖（基于经验的优先顺序，可以协商调整）、假设依赖（基于某个尚未确认的前提，一旦前提变化就要重新判断）。我自己的经验是，硬依赖不应该超过全部依赖的 60%。

3. 误区三：把风险控制做成进度跟踪

很多挂着"风险控制"名头的项目管理文档，翻开来其实是进度跟踪表：谁负责、什么时候交付、完成度多少。进度跟踪回答的是"现在到哪了"，风险控制回答的是"可能会在哪里断、断了怎么办"。这是两个问题。

依赖维度的风险，至少有四类：依赖断裂风险（上游延期）、依赖过载风险（某个任务被过多下游依赖）、依赖隐性风险（没被记录的关系）、依赖僵化风险（结构过于刚性，没有调整空间）。只做进度跟踪的团队，对这四类风险一个都不会提前发现。

4. 误区四：把工具当判断

我见过不少团队，项目管理工具用得很熟练，甘特图、关键路径、基线对比全都配齐了，但项目照样延期。原因是他们把"工具能做什么"当成了"管理需要做什么"。

工具能告诉你：这条依赖断了会让项目整体推迟 6 天。工具不能告诉你：这 6 天业务上能不能接受、要不要为此调整发布范围、有没有替代方案。前者是计算问题，后者是决策问题，而决策永远属于项目负责人。

四、专业判断逻辑：依赖从 0 到 1 的四步搭建法

下面这套方法是把我踩过的坑重新排列后形成的，我把它叫"四步搭建法"。它的顺序很重要，因为顺序决定了你会不会在错误的地方花时间。

1. 第一步：从交付物倒推，而不是从任务正推

绝大多数团队的依赖搭建方式是：先列出要做的事，再想它们之间的先后关系。这个顺序是反的。

正确的起点是交付物清单：这个项目最终要交出哪几样东西？每一个交付物由谁验收？验收标准是什么？把交付物列清楚之后，你才会发现，很多任务之间的依赖其实是"因为它们共同支撑同一个交付物"。

0→1 阶段的交付物通常包括：可运行的产品、通过评审的设计文档、可复现的部署流程、明确的运营手册、合规或安全确认。这些交付物之间的依赖，才是真正需要重点管理的依赖。

2. 第二步：用"三问法"判定依赖类型

每识别出一条依赖，问三个问题，就能确定它该用哪种类型。

1. 问一：B 能不能在 A 之前就开始？不能，说明是 FS 或 SS。
2. 问二：B 的开始是否依赖于 A 的开始？是，说明是 SS。
3. 问三：B 的结束是否必须与 A 的结束对齐？是，说明是 FF。

这三个问题的顺序不能变。先判断起点约束，再判断终点约束。因为一个依赖关系可能同时包含起点和终点约束，但终点约束通常更隐蔽，需要专门去问。

（1）滞后的处理

判定完类型之后，还要判断滞后量（lag）。FS 依赖通常不需要滞后，SS 依赖几乎必须带滞后，FF 依赖的滞后量则要谨慎。我的经验是：FF 的滞后量一般设 0，除非你要表达"A 完成之后 B 还需要一段时间才能真正收尾"。比如"系统上线"完成后，"运行观察报告"还需要 3 天才能定稿，那就是 FF + 3d。

3. 第三步：给每条依赖标注不确定性

这一步是大多数团队完全跳过的，但它是区分"依赖清单"和"风险清单"的分界线。

我的做法是给每条依赖加三个字段：强度（硬/软/假设）、可信度（高/中/低）、断链影响（天数）。这三个字段填完之后，你就能一眼看出哪些依赖是真需要盯的。

举个真实例子：在一个 0→1 项目的依赖清单里，有一条依赖的可信度是"低"、断链影响是"15 天"。当时团队觉得它只是"设计评审"和"开发启动"之间的常规关系，没人在意。结果评审被推迟了两周，开发整体后移，最终延期 17 天。如果当时这条依赖被标成"低可信度"，它就会自动进入监控名单。

4. 第四步：把缓冲放在正确的位置

缓冲（buffer）不是随便多加几天，它的位置比大小更重要。常见的错误是把缓冲平摊到每个任务上，每个任务加 10%，看起来安全，实际上等于什么都没加，因为平摊的缓冲会被单任务吸收，不会传导到项目层面。

依赖管理的缓冲应该放在三个位置：

• 关键路径末端：项目级别的整体缓冲，用来吸收所有小偏差的累积。
• 高不确定性依赖之后：那些被标为"可信度低"的依赖，在其下游任务前加独立缓冲。
• 跨团队交接点：团队之间的交接天然存在沟通损耗，这里的缓冲不是浪费，是必要成本。

下面这段是我实际在用的依赖定义格式，把前面三步的字段都写进去了。你可以直接对照检查自己项目的依赖清单里缺了哪几个字段。

tasks:

id: T-101

name: 数据出境合规说明定稿

owner: 法务-李

duration: 5d

deliverable: 合规签署件

id: T-208

name: 生产环境正式发布

owner: 研发-王

duration: 1d

deliverable: 可对外访问的生产环境

deps:

target: T-101

五、具体案例与数据观察：一个 120 人组织的 0→1 项目

前面讲的是方法，这一节讲一个具体项目。这是我参与度最深、也是教训最贵的一次。

1. 项目背景与依赖盘点

项目是一个面向企业的 SaaS 产品从 0 到 1，团队规模约 120 人，涉及 6 个研发团队、1 个设计团队、1 个法务合规接口人。原计划周期 5.5 个月，上线前两个月我们做了一次完整的依赖盘点。

盘点结果：847 条任务，1,312 条已记录依赖，另有我们后来补充出来的 276 条隐性依赖，这些依赖此前只存在于各个团队的负责人脑子里。隐性依赖占比约 17%，接近前面统计的 21% 的区间。

更值得注意的是这 276 条隐性依赖的分布：其中 41% 属于 FF 类型，也就是"必须同步收尾"的关系。这印证了一个判断：FF 依赖是最容易被忽略的依赖类型，因为它不影响开工，只影响收尾，而收尾前的那段时间恰恰是团队最忙、最不愿意重新梳理依赖的时候。

2. 我们在 FF 上踩的三个具体的坑

（1）坑一：把"上线"和"合规确认"当成了先后关系

原计划里，"生产环境上线"和"合规确认"是 FS 依赖，先合规确认，再上线。问题在于合规确认的周期我们完全无法控制，它取决于外部机构的反馈速度。结果是整个上线窗口被合规流程锁死，没有任何回旋空间。

后来改成 FF 依赖，情况完全不同了：上线动作可以提前完成（部署到生产环境、跑通流程、内部可用），只是"对外发布"这一收尾动作必须等到合规确认完成。同一个项目结构，换了依赖类型，就多出了将近两周的并行时间。

（2）坑二：把数据迁移校验漏在了依赖网络之外

数据迁移校验本来是独立的一条任务链，团队按自己的节奏推进，没有和主链建立任何依赖。结果主链开发完成、准备切换的当天，才发现校验环境里还有 3 张表的历史数据映射没确认。

这次延误是 4.5 天。如果当时建了 FF 依赖（"数据切换完成"与"校验通过"必须同步收尾），校验进度的滞后会在计划层面直接反映出来，而不是等到切换当天才暴露。

（3）坑三：依赖清单的更新严重滞后

这个坑最不显眼，但杀伤力最大。当时我们用共享表格维护依赖，每次需求变更后，需要人工排查相关任务。前面说过，平均应排查 23 条，实际排查 9 条。更严重的是时间滞后：一次依赖变更从发生到反映在清单上，平均滞后 3.5 天。

5 天意味着什么？意味着周会上看到的计划，是三天半以前的现实。以这个信息做决策，等于闭着眼睛调整方向。

3. 工具承载：什么时候表格一定不够用

我想在这里说一个不太"政治正确"的观点：依赖管理不是工具问题，但在某个规模之后，工具会变成瓶颈。

在上面这个项目里，当依赖条数在 300 条以内时，共享表格完全够用。问题是它很快就涨到了 1,300 条，而且每周有 30% 以上的变更。到那个阶段，表格的三个硬伤全部暴露：

• 无法自动重算。改一条依赖的日期，下游所有任务的日期要人工重排，一次重排要几小时。
• 无法算关键路径。哪些任务是关键路径、浮动时间还剩多少，全靠人推。
• 无法留痕。依赖是谁改的、什么时候改的、改了之后影响了谁，事后追溯不到。

这个项目在第二阶段做了一次工具切换。因为项目涉及政企客户的数据合规要求，同时团队此前一直在用 Jira，所以选型时我们重点考察了两点：能不能私有化部署、能不能平滑迁移历史数据。最终我们选了 PingCode。

PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，支持 Jira 平滑迁移。对我们这个场景来说，这三点刚好对上：私有化部署解决了客户对数据出境的硬性要求，Jira 平滑迁移让 800 多条历史任务和它们的依赖关系没有丢，而它面向中大型组织的定位，也符合我们 6 个团队、跨部门协作的实际复杂度。

切换到 PingCode 之后，变化最明显的不是"功能变多了"，而是三件具体的事：

1. 依赖变更的响应时间从 3.5 天压缩到当天。因为依赖关系在计划里是活的，改了上游，下游的日期和关键路径会自动重算，不需要人工维护清单。
2. 基线偏差变得可见。每次计划调整都会形成基线对比，哪些任务偏离了、偏离了多少，一眼能看到，而不是等周会汇报。
3. 跨团队交接有了记录。依赖不再靠群里 @ 一下，而是在计划里就存在，交接动作有据可查。

我需要说明的是：工具本身不解决判断问题。切到 PingCode 之后，我们依然要自己判断哪条依赖该是 FF、哪条该是软依赖、断链预案是什么。工具的价值在于，它让正确的判断能被持续执行，而不会被人工维护成本拖垮。

4. 切换前后的关键指标对比

下面这组数据来自项目第二阶段（后 3 个月）与第一阶段（前 2.5 个月）的对比。样本量不大，属于单项目观察，但因为前后团队、范围、技术栈都没变，可比性还是比较强的。

六、不同情况下的行动建议

方法不能一刀切。我按团队规模和项目阶段分四种情况，给出可以直接执行的动作。

1. 10 人以下的小团队：别上重型依赖管理

这个规模下，任务总数通常在 100 条以内，依赖关系在 50 条以内，而且所有人都在一个群里，沟通成本极低。此时建立完整的依赖体系的收益，远小于维护成本。

我的建议是只做三件事：

• 列出项目的 5 到 8 个关键交付物，不要列任务，就列交付物。
• 只给交付物之间画依赖，并明确标出其中的 FF 依赖（通常 2 到 3 条，比如"发布"和"合规确认"）。
• 每周花 15 分钟检查一次这三条 FF 依赖的两端是否对齐。

这个规模下最忌讳的是引入复杂的依赖字段和审批流。小团队的优势就是决策快，用流程把它锁死是自废武功。

2. 30 到 100 人的中型团队：要建立依赖清单，但保持轻量

这个规模是"人工管理开始吃力、但还没到必须上重型平台"的区间。任务是 200 到 500 条，依赖 100 到 400 条，跨团队协作开始出现。

建议做四件事：

1. 建立一份独立的依赖清单，和任务清单分开维护。依赖清单要包含：前置任务、后置任务、类型、强度、断链影响天数。
2. 每周做一次依赖漂移检查，重点看"低可信度"的依赖有没有变化。
3. 把 FF 依赖单独拉一张表出来，这类依赖数量少，但每一条都要有人负责盯。
4. 关键路径末端的项目级缓冲，明确写出来并公示，让所有人知道还剩多少余量。

3. 100 人以上的中大型组织：工具是必要的，不是可选的

这个规模下，任务量普遍超过 500 条，依赖超过 400 条，跨 3 个以上团队。人工维护依赖的成本会迅速超过收益，而且因为滞后严重，维护出来的清单本身就是失真的。

这个阶段的核心动作是把依赖管理从"人维护"转成"系统维护"：依赖关系在平台里是活的，变更自动传导，关键路径和基线偏差自动呈现。团队把省下来的时间用在判断上，而不是抄写和核对上。

选择平台时，中大型组织需要额外关注三点：

• 部署方式。涉及敏感数据或政企客户的，私有化部署通常是硬性要求，不是偏好问题。
• 迁移能力。如果此前用了 Jira，历史任务和依赖关系的迁移质量，直接决定了切换是"升级"还是"重来"。PingCode 支持 Jira 平滑迁移，这一点对存量 Jira 用户的实际价值很高。
• 权限与审计。6 个团队意味着依赖的读写权限需要分层，谁改了什么必须有记录。

4. 已经在用成熟流程、准备迁移的团队：先迁移依赖，再迁移任务

如果你的团队已经在用某套成熟流程和工具，准备做迁移，我的建议是调整迁移顺序：先迁移依赖关系，再迁移任务内容。

多数团队的默认做法是把任务一条条搬过去，依赖关系顺手重建。但依赖关系是项目里最难重建的部分，它依赖大量隐性知识，而任务内容反而是可以从文档、代码仓库、会议记录里还原的。

我的做法是：迁移前先做一次依赖盘点，把隐性依赖显性化，把 FF 依赖单独标记出来，然后原样迁过去。这次盘点本身就是迁移最大的价值，比换个工具重要得多。

七、不同情况下的取舍

前面给的是"该怎么做"，这一节讲"什么情况下该放弃什么"。项目管理没有最优解，只有取舍，把取舍想清楚，比背方法更重要。

1. 精确 vs 敏捷：要不要设那么多依赖

依赖设得越细，计划的精确度越高，但维护成本也越高，而且会削弱响应变化的能力。这是个真实的矛盾。

我的判断标准是看变更频率：如果一个模块的需求月变更率超过 30%，就不要给它设细颗粒度的依赖，设了也白设，一周就过期。这类模块应该用"里程碑级依赖"（只看关键交付物之间的对齐），而不是"任务级依赖"。

反过来，如果某个模块的需求已经完全冻结（比如合规、安全、硬件对接），就应该设到最细，因为此时精确度带来的收益大于维护成本。

（1）一个具体的分界线

我自己的经验阈值是：需求冻结程度在 80% 以上的模块，依赖设到任务级；冻结程度低于 50% 的模块，依赖设到里程碑级。中间地带用"关键节点依赖 + 每周复核"过渡。

2. 强约束 vs 弹性：硬依赖到底该占多少

硬依赖设得越多，计划越刚性，抗风险能力越差；设得越少，计划越容易被随意调整，失去指导意义。

我给出的参考区间是硬依赖占全部依赖的 50% 到 60%。低于 50%，计划就失去了约束力，变成一张愿望清单；高于 70%，计划会变得极其脆弱，一次变更就能引发全局重排。

需要说明的是，这个比例不是拍出来的。我在自己的项目里做过对比：硬依赖占比 85% 的那个项目，整个周期内发生了 4 次全局重排，每次耗时约两天；硬依赖占比 55% 的项目，同样的变更量只引发了 1 次局部调整。

3. 自建 vs 采购：什么情况下值得自己搭

有些团队会选择自建依赖管理系统，理由是"我们的流程特殊"。这个理由有时候成立，有时候不成立。

成立的情况：流程涉及独特的行业约束（比如军工、医疗的特殊合规审计），现成工具确实无法满足，且团队有稳定的工程资源能持续维护。

不成立的情况：所谓"流程特殊"，实际只是"习惯了某种表格格式"。这种情况下自建系统最终会变成一个没人维护的内部工具，两三年后连原开发者都找不到。

我的判断标准很朴素：如果现成工具需要你改的是"使用习惯"，那就采购；如果现成工具需要你改的是"合规底线"，那就自建。

4. 私有化部署 vs SaaS：这是个什么性质的决定

很多团队把这个问题当成技术选型，其实它是合规选型。

如果你的客户或行业主管部门对数据存储位置有明确要求，私有化部署就不是一个可选项，而是前置条件。这种情况下讨论"私有化部署运维成本高"没有意义，因为不用私有化部署，项目压根立不起来。

如果没有这类硬性要求，那就看数据敏感度和团队运维能力。中大型组织里，运维能力通常不是瓶颈，数据敏感度才是决定因素。所以中大型企业选型时，把"是否支持私有化部署"作为第一道筛选条件，能省掉后面大量的纠结。

5. 迁移成本 vs 长期收益：什么时候该换

换工具的短期成本是真实的：迁移工作量、团队学习成本、流程适配期的效率下降。这三项加起来，在一个 100 人以上的组织里，通常是 4 到 8 周的时间投入。

判断该不该换，我建议算一笔简单的账：把当前依赖管理方式的月人工投入，乘以你预计还要用这套工具的年数，再和迁移成本比。如果前者是后者的 5 倍以上，换。

回到前面的数据：100 人以上组织的人工协调投入是 180 小时/月，年化 2,160 小时；迁移成本按 6 周、涉及 10 个人算，大约 2,400 小时。看起来差不太多。但这里漏算了一项：延迟发现的依赖冲突带来的返工。前面第 3 节的数据里，依赖冲突平均 12 天才被发现，这类返工在一个中大型项目里通常是几十到上百人天。把这一项算进去，账就很容易算了。

八、写在最后：给负责人的三条判断

这篇文章从头到尾其实只想说三件事。

第一，FF 依赖的价值在于它管的是收尾，而收尾才是最贵的。开工晚几天，多数项目还能追回来；收尾对不齐，往往意味着整个交付窗口被锁死。0→1 项目里，越是那些"看起来只是走流程"的收尾环节，越需要显式的 FF 依赖来兜底。

第二，依赖管理的失败不是"线画错了"，而是"线没画"和"线过期了"。我见过的所有延期案例里，绝大多数不是因为依赖关系设置错误，而是因为依赖根本没被识别出来，或者识别出来之后三个月没更新。前者靠方法解决，后者靠机制解决。

第三，负责人的核心能力是判断"这条依赖断了会怎样"，而不是"这条线该怎么连"。连线是执行动作，断链预判才是风险控制。这也是为什么我在前面反复强调 fallback 字段，它是从依赖记录走向依赖管理的那一步。

如果你读到这里，我建议你今天就做一件事：打开你正在负责的项目计划，找出所有"必须同步收尾"的任务对，看看它们之间的依赖有没有被显式写出来。大概率你会发现，至少有 3 到 5 条关键依赖目前只存在于你的记忆里。把它们写下来，标上强度和断链影响，这是成本最低、回报最高的一次风险控制动作。

至于工具，它是第三步而不是第一步。先想清楚你的项目里哪些依赖是真正要命的，再去判断你的管理方式能不能承载它。10 人以下用一张清单就够，100 人以上需要系统化承载，中间地带按变更频率和冻结程度来定。顺序别搞反，先判断，再选型。