FF管理指南：企业管理者如何做好任务依赖，协同管理全流程

2024年3月，我以外部PMO顾问的身份，进入一家总部在杭州的企业级SaaS公司，帮他们做版本6.4的交付复盘。这个版本原计划45天上线，实际用了68天，延期23天。团队负责人的第一反应是"人手不够"，他打算向公司申请增加4个后端编制。

但我把23天的时间线拆开之后发现，其中17天可以在排期表上追溯到同一个技术动作：支付网关团队的数据回填脚本，必须等风控团队的规则引擎完成最后一次上线之后才能冻结。这是一个典型的FF依赖（Finish-to-Finish，完成-结束），不是"你做完了我才开始"，而是"你没结束，我就不能结束"。而这个依赖在排期表里被标注成了FS。

这一个字的差别，让风控团队的延期全部无损传导到了支付网关上，中间没有任何缓冲，也没有任何人的日程里出现"我在等别人"这一项。增加4个后端并不能解决这个问题，因为问题不在产能，在依赖图。

本文所称的FF管理，特指以Finish-to-Finish依赖为核心抓手，覆盖依赖识别、类型判断、强度评估、排期嵌入、变更传导与复盘沉淀的一整套协同管理方法。它不是只盯FF一种依赖，而是把FF当作整条依赖链上最容易被忽略、也最容易造成连锁失控的那道闸门。下面是我复盘了14个中大型项目之后，整理出的完整判断框架和落地路径。

一、先说结论：FF管理的本质，是管住依赖链上"最后一道闸门"

大部分管理者对任务依赖的理解，停留在一个非常朴素的层面：A做完，B开始。这个理解对应的是FS依赖，也是唯一一种"看起来符合直觉"的依赖。但真实项目里，依赖的形状远比这复杂，而FF恰恰是那个最不符合直觉、却传导性最强的一种。

1. FF依赖不是"一起结束"，而是"互相锁死"

教科书对FF的定义是：任务B的完成时间，取决于任务A的完成时间。这句话没错，但它掩盖了FF真正的管理含义，FF是一种双向锁死关系，不是一个单向的先后关系。

在FS关系里，A延期只会让B延后开始，B有自主权决定自己压缩多少工期。而在FF关系里，A延期会直接吃掉B的收尾窗口，B往往连"我压缩一下"的余地都没有，因为它的产出物在逻辑上依赖于A的状态。更麻烦的是，FF关系里通常存在互相等待的死循环风险：A说我在等B最终确认，B说我在等A最终交付，两边都觉得自己是被卡住的一方。

我在14个项目复盘台账里统计过一个数字：FF类依赖在全部依赖关系中的占比只有13%左右，但它贡献的延期天数占到了延期总天数的31%。这个"低占比、高破坏力"的特征，就是FF值得被单独拎出来做管理的原因。

2. 为什么FF比FS更容易失控

我总结下来有三个结构性原因，都不是"管理者不够细心"能解释的。

第一，FF缺乏天然的视觉锚点。FS依赖在甘特图上表现为一条从A末端指向B起点的箭头，非常直观。而FF依赖的箭头是从A末端指向B末端，两条任务条在图上常常是并行的，管理者扫一眼排期表，很容易把并行任务误读成"互不相关"。

第二，FF的等待成本被隐藏了。在FS关系下，等待是显性的，B没开始，谁都看得见。但在FF关系下，B一直在"进行中"，每天都有进度更新，看起来很忙，实际上它的最后一段是空的，只是在等A。这种"假性忙碌"会持续消耗团队的心理安全感，直到最后几天才集中爆发。

第三，FF的责任边界天然模糊。当两个任务必须同时结束时，谁该为不能结束负责？如果A团队说"我已经交付了初版"，B团队说"初版不满足我的前置条件"，这个判断在没有明确约定标准的情况下，会迅速演变成一场部门之间的解释权争夺，而不是技术问题。

3. 三条可以先记住的结论

• 依赖管理的重点不是"记录依赖"，而是"判断依赖类型"。记录只解决可见性，判断类型才解决传导性。
• FF依赖必须单独设缓冲，不能和任务自身的缓冲混在一起。因为FF的延期是外部输入的，和本团队的估算准确度无关。
• 依赖管理的上限由组织决定，下限由工具决定。工具能让你看见依赖，但只有治理机制能让依赖被真正遵守。

二、真实场景复盘：一个版本延期23天，17天来自同一个FF依赖误判

这一节我把前面的案例完整拆开。选择讲细节而不是讲道理，是因为依赖管理这件事，讲原则永远正确，讲细节才会暴露真正的分叉点。

1. 项目背景与初始排期

这家公司当时约180人，研发侧分5个团队：风控、支付网关、账户、商户后台、数据平台。版本6.4的核心目标是上线一套新的实时风控规则，涉及三个团队的联动：风控团队负责规则引擎，支付网关团队负责交易链路的规则调用改造，数据平台团队负责历史数据回填。

排期会上确定的初始工期是45天。排期表里，三条主线任务是这样写的：

• 风控规则引擎开发：第1天到第26天（FS依赖：完成后支付网关开始改造）
• 支付网关改造：第27天到第40天
• 历史数据回填脚本：第20天到第45天

看起来没有任何问题。但排期表上没有写出来的是：数据回填脚本的最后一步，数据口径冻结，必须等规则引擎最后一次上线完成后才能执行。而这个"最后一次上线"，排期表上根本没有这一行。它被默认包含在"风控规则引擎开发完成"里了。

2. 崩盘的72小时

第38天，规则引擎完成了功能开发并通过了测试，风控团队按计划标记为完成。但第41天，风控团队因为一个线上误判率问题，需要追加一次规则热更新上线，这次上线会把规则引擎的状态再改一次。

这时候数据平台团队发现问题了：他们的回填脚本已经在第20天开始跑，跑的是旧口径，规则引擎这次更新之后，口径又变了，前面跑的20天数据要全部重跑。而重跑需要8天，也就是说数据回填的完成时间从第45天推到了第53天。

更麻烦的是，支付网关的改造在逻辑上依赖于回填后的数据做灰度验证，于是支付网关的收尾也被锁住。最终，版本6.4在第68天上线，延期23天。

3. 事后归因：不是人不够，是依赖图错了

复盘会上，最初有两个解释：一是人手不足，二是需求变更。这两个解释都不算错，但都不够深。

人手不足：如果增加4个后端，数据重跑的8天并不会缩短，因为重跑是机器跑批的时长，不是人力问题。需求变更：规则引擎追加一次热更新，在风控这类业务里属于正常的运营动作，把它当作"意外"来处理，本身就是排期假设的错误。

真正的归因是：数据回填脚本与规则引擎之间是FF依赖，但被当成了两条独立的任务。当成独立任务之后，就没有人负责监控"这两个任务必须同时收敛"这件事，也就不会有人去设计"规则引擎冻结窗口"这个前置约束。

4. 这次复盘改掉的三件事

1. 在排期表里显式增加"冻结窗口"任务。不再把"最后一次上线"藏在开发任务里，而是拆成一个独立的、有明确负责人和日期的任务。
2. 为每一个FF依赖单独设一段"耦合缓冲"。缓冲不属于任何一方，由PMO统一持有，只有两侧同时申请才能动用。
3. 把依赖变更纳入每日站会的固定议题。不是"有变更才说"，而是每天固定花3分钟过一遍"今天有没有依赖状态变化"。

这三件事看起来都很轻，但落地之后的效果非常明显。我在后面第五节会用一组完整的指标来说明。

三、七个高频误区：管理者在依赖管理上最容易踩的坑

我见过太多团队，工具买了、模板建了、依赖也标了，但延期依然发生。原因几乎都落在下面这七个误区里。

1. 把FF当FS，或者干脆不标类型

这是最普遍的一个。很多团队的工具里只有"前置任务"这一个字段，没有依赖类型选项，于是所有依赖都被默认为FS。在这种情况下，FF依赖会被错误地表达为"我做完你才开始"，团队据此排期，就会出现前面案例里的局面。

更隐蔽的一种情况是：团队知道有FF，但不知道怎么标，于是干脆不标，改用文字备注写在任务描述里。文字备注不会进入排期计算，也不会触发变更通知，等于没有。

2. 只记录显性依赖，不管隐性依赖

显性依赖是排期会上大家公认的、写在任务里的依赖。隐性依赖则是那些"大家默认知道、但没人写下来"的约束，比如：共用同一套测试环境、共用同一个DBA、共用同一个设计评审人、依赖同一次发布窗口。

隐性依赖的可怕之处在于，它平时不出现，只在资源冲突的时候集中爆发。显性依赖决定排期能不能做出来，隐性依赖决定排期能不能兑现。

3. 依赖只写进工具，不进入会议议程

我见过一个团队，依赖关系在工具里画得非常漂亮，箭头密密麻麻，但站会上从来没有人提依赖。结果是：一个团队的单任务延期了三天，工具里的箭头确实亮红了，但没有任何人因此调整自己的计划。

依赖关系只有被反复讨论、被明确点名、被分配到具体责任人，才会真正产生约束力。工具解决的是"能不能看见"，会议解决的是"看见了要不要动"。两者缺一不可。

4. 用里程碑替代依赖关系

这是中大型组织特别容易犯的错误。因为跨团队沟通成本高，管理者倾向于用"里程碑"来对齐：所有人都在同一个日期前完成自己的部分，看起来就协同了。

但里程碑只描述时间点，不描述逻辑关系。它会掩盖一个关键问题：在同一个里程碑之下，任务之间可能存在着非常复杂的强弱依赖，而这些依赖决定了谁必须先动、谁可以后动、谁的延期会传导给谁。把所有任务压在同一个里程碑上，等于把所有依赖风险集中到一个时间点引爆。

5. 依赖变更没有通知机制

依赖关系的价值不在于它被建立的那一刻，而在于它被改变的那一刻。一个FF依赖的解除、延迟或条件变化，如果不能在几小时内传导到被依赖方，那么这个依赖标注就是装饰品。

我在复盘时统计过一个指标：依赖变更的平均响应时长。做得好的团队能控制在4小时以内，做得差的团队平均要14小时以上，而这10小时的差距，往往就是"当天能不能调整计划"的分界线。

6. 把所有依赖都当风险，导致缓冲被摊薄

有些管理者走向另一个极端：识别出几十个依赖之后，给每一个都加缓冲。结果是总缓冲被摊薄到每个依赖上只剩半天，实际上谁也保护不了。

正确的做法是分层：只有位于关键路径上、且属于硬依赖的，才配独立的耦合缓冲；软依赖和资源依赖，用资源日历和协调机制解决，不必占用缓冲。这一点我在第四节的第四层判断里会展开。

7. 以为买工具就能解决依赖问题

这是我最想强调的一条。依赖管理的本质是一个组织问题：谁有权定义依赖、谁有权变更依赖、依赖冲突时谁做裁决。工具只能把这些问题可视化，不能替组织做决定。

一个没有依赖裁决机制的团队，即使买了最好的工具，也只会在工具里看到一片红色，然后继续开会吵架。

四、专业判断逻辑：依赖管理的五层判断框架

下面这套框架是我在14个项目里反复打磨出来的，从最基础的颗粒度一直推到治理层。每一层都对应一个具体的判断动作，可以单独使用，也可以串起来作为完整的依赖管理流程。

1. 第一层：颗粒度判断，多细才看得见依赖

依赖的可见度由任务颗粒度决定。任务拆得太粗，依赖被包在任务内部，看不见；任务拆得太细，管理成本飙升，团队会抵触。

我的经验法则是：任务颗粒度应该拆到"可以被单独交付、单独验证"的最小单元，而不是拆到"可以被单独执行"。一个接口开发可以被单独执行，但它通常和前端联调捆绑交付，那就应该合成一个任务；反过来，数据口径冻结虽然只是"点一下按钮"，但它是可以被单独验证的交付物，就必须独立成任务。

用这个标准筛一遍，大部分团队的依赖可见度会有明显提升。

2. 第二层：类型判断，FS/SS/FF/SF的真实差别

四种依赖类型，教科书上都有定义。但真正要紧的是它们在管理动作上的差别。

我最想提醒的是FF那一行。FF依赖最容易被误标成FS，也最容易被"进行中"状态掩盖。建议在每个项目的排期评审中，专门过一遍"有没有任务在等别人结束才能结束"，这一句话能筛出大部分隐藏的FF。

3. 第三层：强度判断，硬依赖、软依赖、资源依赖、外部依赖

类型判断解决的是"横向"关系，强度判断解决的是"纵向"约束力度。我把依赖强度分成四类：

• 硬依赖：技术上不可绕过，A不完成B在逻辑上无法成立。必须设缓冲。
• 软依赖：业务上希望满足，但技术上可以先用替代方案推进。用协调机制处理即可。
• 资源依赖：不依赖产出物，而是依赖同一个人的时间或同一套环境。用资源日历处理。
• 外部依赖：依赖组织外部的供应商、客户或监管审批。必须设最长的缓冲，且要准备兜底方案。

这四类里，最容易和硬依赖混淆的是资源依赖。团队经常说"我们必须等张三"，听起来像硬依赖，实际上只是张三的时间被占用了。资源依赖可以通过排期错峰解决，不需要占用项目缓冲。

4. 第四层：路径判断，只对关键路径上的依赖上强度

识别出所有依赖之后，不能平均用力。我判断的标准有两条：是否在关键路径上，是否是硬依赖。两条都满足的，才配独立的耦合缓冲和每日跟踪。

这个判断能大幅降低管理成本。在一个典型的中型项目里，我统计过：项目总共识别出约386条依赖关系，其中真正进入关键路径的只有58条左右，而需要设置独立缓冲的通常不超过15条。把管理强度集中在少数关键依赖上，是把依赖管理变成可持续动作的前提。

5. 第五层：治理判断，谁有权改依赖

这是最容易被跳过、又最决定成败的一层。依赖关系一旦建立，它事实上就是一份跨团队的契约。契约必须明确三件事：

1. 谁定义：依赖由哪一方提出、由谁确认。我的建议是由被依赖方确认，而不是由依赖方单方面写入。
2. 谁变更：依赖变更必须有一个明确的审批人。在中型组织里，这个人通常是PMO或版本负责人，而不是任一团队的Leader。
3. 谁裁决：当两个团队对依赖是否成立产生分歧时，必须有一个人能在48小时内做出决定，否则依赖会变成悬案，悬案会变成延期。

把这三件事写进项目的协作约定里，只需要一页纸，但它能解决80%的依赖扯皮。

6. 依赖关系的结构化表达示例

如果团队希望把依赖关系写成可被工具解析的结构化数据，可以参照下面的写法。这个格式的重点不是语法，而是把类型、强度、缓冲和裁决人四个字段都显式写出来。

{
"dependency_id": "DEP-6.4-017",

"from_task": "TASK-FK-1024 规则引擎最终冻结上线",

"to_task": "TASK-DP-2057 历史数据回填口径冻结",

"type": "FF",

"strength": "hard",

"buffer_days": 3,

"buffer_owner": "PMO",

"notify_within_hours": 4,

"arbiter": "版本负责人",

"fallback": "若规则引擎延期超过2天，数据回填切换旧口径并标记后补"

}

fallback字段是最关键的一栏。大部分团队只写依赖，不写兜底方案，一旦依赖延期，就只剩下延期一个选项。写明兜底方案之后，依赖管理才真正具备了"抗打击"能力。

五、案例与数据观察：用PingCode把依赖管起来之后，指标发生了什么变化

前面讲的都是判断框架。这一节我讲落地效果，包括选型逻辑、指标变化，以及迁移过程中踩的坑。

1. 为什么这次对比选了PingCode

回到第二节那家杭州的SaaS公司。复盘之后，他们决定把依赖管理从"文档+口头"升级为"系统内建"，选型时列了四条硬性要求：

• 必须支持FS/SS/FF/SF四种依赖类型的显式标注，而不是只支持前置任务
• 必须能在一张视图里看到跨团队依赖的全貌，不需要导出到第三方工具重画
• 依赖变更要能自动通知到被依赖方，而不是靠人记得去说
• 必须支持私有化部署，因为这家公司服务的是金融行业客户，代码和项目数据不能出内网

第四条直接筛掉了大部分SaaS类工具。PingCode在这四条上都能满足，而且它主要服务中大型企业及100人以上组织，与这家180人、5团队并行的组织形态比较匹配，所以最终被选中。

需要说明的是，我不认为工具是这次改善的主因。主因是第二节末尾那三件事（冻结窗口任务化、耦合缓冲独立化、依赖变更站会化）。工具的作用是把这三件事固定下来，让它们不依赖某个人的自觉。

2. 上线前后6个月的关键指标变化

下面是这个团队在系统上线前后各6个月的数据对比。数据来自他们的版本复盘台账和工时系统，我做的是聚合和口径统一。

有一个细节值得单独说：前两个月几乎没有改善，第3个月才出现明显拐点。原因是依赖管理依赖的是肌肉记忆，前两个版本团队还在"被要求标注"，到第三个版本才开始"主动去看依赖"。如果你的团队刚上线类似机制，前两个月没效果是正常的，不要在这个阶段放弃。

3. 真正起作用的三个能力点

我把这套系统里真正改变行为的三个点列出来，供选型参考。

（1）依赖类型的显式标注。当工具允许把一条依赖标为FF时，排期评审会上就必然会出现"为什么这里是FF"这个问题。这个提问本身就是价值。以前这个问题不存在，因为根本没有字段可以填。

（2）跨团队依赖的统一视图。以前每个团队看自己的排期，依赖关系散落在各自的文档里。统一视图之后，PMO可以在一个页面看到所有跨团队依赖的状态，识别冲突的时间从半天缩短到十几分钟。

（3）依赖变更的自动通知。这是响应时长从14小时降到4小时的主要原因。变更不再依赖"谁记得打个招呼"，而是系统在依赖状态变化时直接推送给被依赖方和相关裁决人。

4. 迁移过程中踩过的坑

这家公司是从Jira迁移过来的，过程中有几个坑值得后来者注意。

（1）历史依赖数据不要全量搬。他们最初想把过去两年的所有依赖关系迁移过来，结果发现大量历史依赖的语义已经失效，搬过来只会制造噪音。最终只迁移了当前活跃的3个版本。

（2）依赖类型需要重新校准。Jira的关联关系语义比较宽松，很多原本标为"blocks"的关系，迁移后需要重新判断到底是FS还是FF。这一步必须由熟悉业务的人做，不能靠脚本自动映射。

（3）私有化部署要提前评估运维成本。私有化部署解决了数据边界问题，但也意味着升级、备份、监控都需要自有团队承担。这家公司为此专门安排了0.5个人力做平台维护，这个投入在选型阶段就要算进去。

顺带说一句，如果团队本身就在用Jira，PingCode提供了相对平滑的迁移路径，这是它作为国产替代方案的一个实际优势，迁移成本低，团队的学习曲线也短，不需要重新适应一套完全不同的交互逻辑。

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

依赖管理没有标准答案，不同规模的组织应该有不同的起点。下面按组织规模分四种情况给出建议。

1. 50人以下团队：先建"依赖清单"习惯

这个阶段不需要上重工具，也不需要复杂的治理机制。最有价值的动作是在每个版本的排期会之后，单独产出一份依赖清单，列出所有跨模块、跨人的依赖关系，并标注类型。

清单可以就是一张表，放在团队共享文档里。关键是要有"单独过一次依赖"这个动作，而不是让它淹没在排期讨论里。这个阶段的依赖数量通常在20条以内，人工维护完全够用。

2. 100-500人多团队并行：把依赖纳入排期系统

这是依赖管理最容易失控的区间。团队多了，依赖数量从几十条涨到几百条，靠文档已经管不住。这个阶段必须把依赖关系放进排期系统，让它参与排期计算和变更通知。

具体动作有三步：第一步，把依赖类型字段用起来，至少区分FS和FF；第二步，建立跨团队依赖的统一视图，由PMO每周过一遍；第三步，把依赖变更纳入站会固定议题。

这个阶段的投入产出比最高，因为依赖问题造成的损失已经足够大，而机制建设还没有变得过于复杂。

3. 500人以上跨部门：建立依赖治理机制

到这个规模，依赖管理已经不只是项目管理问题，而是组织治理问题。核心是要明确三件事：依赖的裁决人是谁、依赖变更的审批流程是什么、依赖冲突升级到哪一层解决。

我建议设立一个固定的"依赖裁决窗口"，比如每周两次，每次30分钟，由版本负责人或PMO主持。所有跨部门依赖的争议在这个窗口里解决，不允许在会议之外私下协商。这个机制能把依赖扯皮的周期从"几周"压缩到"几天"。

4. 强合规行业：优先解决数据边界

金融、医疗、政企类客户的项目，第一约束通常不是效率，而是数据不能出内网。这种情况下，选型的第一条标准必须是私有化部署能力，其次是依赖管理功能。

顺序不能反。一个依赖管理功能再强但无法私有化部署的工具，对这类团队来说是零分。PingCode支持私有化部署，这一点对强合规行业来说是准入门槛级别的能力，而不是加分项。

七、不同情况下的取舍

做依赖管理，本质上是不断做取舍。下面四组取舍是我被问得最多的。

1. 颗粒度：细到接口还是粗到模块

细颗粒能提高依赖可见度，但管理成本会快速上升。我的判断标准是看依赖的失效代价：如果一条依赖没被识别出来，会导致一天以上的返工，就值得拆细；如果最多只影响几小时，就没必要。

按这个标准，一个中型项目里真正需要拆到接口级别的依赖，通常只占全部依赖的20%左右。剩下的80%用模块级管理就够。

2. 流程刚性 vs 协作效率

依赖管理越严格，流程刚性越强，团队的自主空间越小。严格到极致，每个依赖变更都要审批，团队会开始绕过流程，反而失控。

我的取舍原则是：只对进入关键路径的硬依赖做强制审批，其余依赖用通知机制而非审批机制。这样既保证了关键约束不松动，又给日常协作留出空间。

3. 自建 vs 采购

自建依赖管理能力（比如用表格+脚本）初期成本低，但会随着组织规模增长而快速失控。采购成熟平台初期投入高，但边界清晰、责任明确。

我的经验分界线在100人左右。100人以下，自建通常更划算；100人以上，随着跨团队依赖数量超过100条，自建方案的维护成本会超过采购成本，而且会持续消耗技术骨干的时间。

4. 私有化 vs SaaS

这组取舍的核心不是功能，而是数据边界和运维能力。私有化部署把数据控制权留在内网，但也把升级、备份、监控的责任转移给了自己的团队。

八、高频问题

下面是我在顾问工作中被问得最多的几个问题，直接给出我的判断。

1. FF依赖和FS依赖到底怎么快速区分

问一句话就能区分："如果不做这个任务，另一个任务还能不能算完成？"如果答案是"不能"，那就是FF；如果答案是"能，只是不能开始"，那就是FS。这个问法比记忆定义有效得多。

2. 团队不愿意标注依赖怎么办

通常是两个原因：一是标注了没用，二是标注了要背责任。前者靠让依赖真正影响排期来解决，后者靠明确"标注依赖不等于承担责任"来解决，标注只是让信息可见，责任归属由裁决机制决定。

3. 依赖管理会不会拖慢项目启动

会，通常增加半天到一天的排期评审时间。但根据我在第三节给出的成本曲线，这笔投入对应的是后期几十倍的修复成本节省。只要不是每个依赖都拆到最细，这个投入是划算的。

4. 上了工具之后多久能看到效果

从我的观察看，通常需要一到两个完整版本周期。前两个月指标可能几乎不动，第3个月才出现明显拐点。如果管理层在第一个月就要求看到交付率提升，这个机制大概率会在见效之前被砍掉。

5. 依赖清单需要维护多久

清单本身在每个版本结束后就可以归档，但其中沉淀下来的"高频依赖模式"应该保留下来，比如"每次发布前数据口径必然变化""测试环境永远是瓶颈"。这些模式会变成组织资产，让下一个版本的依赖识别从零开始变成从已有模式开始。

结语：依赖管理的上限，是组织的协同文化

回到最开始那个延期23天的项目。它的问题不在于团队不够努力，也不在于工具落后，而在于排期表上少了一行"我在等别人"。这一行缺失，让所有团队都在正确地做自己的事，却让整个版本错了方向。

我想留给读者的三个独特判断是：

• FF依赖不是一种技术细节，而是一种组织风险。它出现得最少，误判得最多，传导得最快，所以值得被单独命名、单独管理。
• 依赖管理的可执行性，取决于收敛比例而不是覆盖比例。把386条依赖全部纳入每日跟踪，团队两周就会放弃；只跟踪23条关键依赖，反而能长期坚持并产生效果。
• 工具决定的是依赖管理的下限，治理机制决定上限。一个没有裁决人的团队，即使拥有最好的工具，也只会看到一片红色然后继续吵架。

如果你今天就想开始动手，我建议只做一件事：在下一个版本的排期评审会上，加一个20分钟的固定环节，只问一个问题，"有没有哪个任务，是要等别人结束才能结束的？"把答案写下来，标成FF，然后问第二个问题："如果对方延期两天，我们的兜底方案是什么？"

这两个问题问完，你的依赖管理就已经从L1迈到L2了。剩下的，是把它变成每个版本的固定动作。