FF最佳实践：项目负责人任务依赖实操方法，常见问题

前端（FF）依赖在项目管理里是个尴尬角色：几乎所有排期表上都有它，但很少有人真正为它负责。我复盘过自己参与过的十多个中大型项目，一个反复出现的现象是，甘特图上密密麻麻全是依赖线，项目负责人以为"连上了就安全了"，结果临到上线前最后一周，测试、文档、交付、验收四条线同时挤在一起，全员救火，而甘特图上那条 FF 依赖从头到尾没有变红过。问题不在于团队不努力，而在于 FF 依赖被当成了 FS 依赖用：它约束的是"结束点"，不是"开始点"，而后者才是大家习惯盯的东西。

先说清楚本文讨论的 FF 指的是什么。在任务依赖的标准分类里，FF 是 Finish-to-Finish，即"完成，完成"依赖：前置任务不完成，后置任务就不能结束。它和最常见的 FS（完成，开始）最本质的区别是，FF 不限制后置任务什么时候开始，只限制它什么时候最晚结束。这个差别看起来只是定义问题，实际决定了整个项目在收尾阶段的资源分布、风险传导方式和关键路径识别难度。

本文从项目负责人视角，讲 FF 依赖该在什么场景用、怎么设才有意义、最容易踩的六类坑，以及在 PingCode 这类平台上落地的具体做法。

一、核心结论：FF 依赖管的是终点，不是起点

如果你只记住一句话，我希望是这句：FF 依赖是一种"最晚完成"的约束，它不产生推动力，只产生天花板。很多项目负责人设完 FF 依赖就觉得"这条线被锁住了、会自动串起来"，这个直觉是错的。FF 不会让后置任务自动启动，也不会提醒责任人"你该动了"，它只在排期引擎里划出一条边界：你不能比它更晚结束。

1. FF 依赖的约束逻辑与 FS 的根本差异

我习惯用"推进"和"封口"来区分这两类依赖。FS 是推进型：前置完成了，后置才能开始，它把工作流从上游往下游推。FF 是封口型：后置可以早早启动、并行推进，但终点被前置锁住，它管的是"什么时候必须收口"。

这个差异带来三个直接后果。第一，FF 依赖下的两个任务通常是并行执行的，所以它们在甘特图上看起来"时间充裕"；第二，真正的时间压力全部集中在收尾阶段，而不是启动阶段；第三，如果前置任务延期，后置任务的开始时间不受影响，因此很多工具的风险提示不会优先亮起，延期在早期不显形，在末期集中爆发。

我见过最典型的一幕是：测试收尾（FF 依赖）卡在开发收尾上，开发到倒数第三天还在修 P1 缺陷，测试只能通宵跑回归，文档同步定稿，交付清单没人核对。整条链上每个人都"按计划在做事"，最终结果却是交付延期两天、上线后第一周缺陷率是平时的三倍。

2. FF 风险的分布特征：集中爆发而非均匀分摊

我把过去几年项目复盘的延期时间点做了归类，得到一个相对稳定的模式：FS 链上的延期通常出现在任务中段，因为有明确的"等待对手交付"环节，容易提前暴露；而 FF 链上的延期几乎全部集中在项目最后 15% 的时间窗口内。原因很简单，FF 允许下游任务一直"看起来在做"，直到前置任务结束那一刻，所有被压住的收尾工作才同时释放。

这意味着项目负责人在 FF 依赖上的监控窗口应该前移。你不能等到倒数第三天开始看测试进度，你要在前置任务完成度到 60% 的时候就开始反推：收尾工作需要多少人天、当前有多少人在做别的事、最后一周的资源峰值能不能撑住。

3. FF 依赖必须配"交付标准"才有约束力

这是我踩过最贵的一个坑。早期我在系统里设了一条 FF 依赖，从"开发缺陷修复"指向"测试回归收尾"，逻辑上完全正确，结果开发那边说"缺陷修完了"，测试那边说"还有 6 个用例跑不过"，两边对"完成"的定义不一致，FF 依赖形同虚设。

后来我形成一条硬规则：每一条 FF 依赖都必须绑定一个可验证的交付物，不能只连任务和任务。交付物可以是"缺陷关闭报告（P0/P1 归零）"、"封版通知单"、"验收签字记录"。没有交付物的 FF 依赖，本质上是一句口头承诺，它占用排期表一个位置，但不产生任何约束力。

二、背景与真实场景：为什么中大型组织的排期越来越依赖 FF

FF 依赖不是新概念，但它在近几年的项目实践里出现得越来越频繁，原因和团队规模、交付模式的变化直接相关。理解这层背景，才能判断你所在的组织到底该用多少 FF 依赖。

1. 从瀑布到并行交付带来的依赖结构变化

传统的瀑布式排期以 FS 为主：需求完成才能设计，设计完成才能开发，开发完成才能测试。这种线性结构里 FF 很少见，因为任务天然串行。但现在的中大型组织普遍采用"多线并行、统一收口"的模式，固件和云端并行开发、硬件试产和软件联调并行、文档和功能并行编写，最后统一收口到一次发布或一次交付。

并行化的代价是收口阶段变得极其脆弱。所有并行线都必须"在同一个时间点之前完成"，而表达这种"共同终点"约束的唯一依赖类型就是 FF。组织越并行，FF 依赖就越多，收尾阶段就越需要精细的资源调度。

2. 一个典型的"最后一周"现场复盘

我参与过一个大约 300 人的智能硬件企业的固件发布项目（案例已脱敏，数据做区间化处理）。项目周期 14 周，涉及固件、云端、App、测试四条线。第 1 到 10 周一切正常，燃尽图基本贴合计划。

第 11 周开始出问题。固件线推迟了 4 天才完成回归，云端线因为接口变更又多花了 2 天，两条线都通过 FF 依赖指向"版本封版"，于是封版日期整体后移 5 天。但测试和文档两条线的资源计划没有跟着调整，测试组的回归窗口被压缩到 2 天，文档组要在一个通宵内完成 3 份交付文档的定稿。

结果是版本延后 2 天发布，发布后第一周的线上缺陷数是上一个版本的 2.8 倍。复盘时我们发现，根因不是任何单点的技术问题，而是FF 依赖变更后，没有任何机制触发下游资源计划的重新分配。依赖更新了，排期更新了，但人没动。

3. FF 依赖清单在真实项目里长什么样

我整理过一份典型发布项目的 FF 依赖清单，高频出现的大致是这几类：测试收尾依赖开发收尾、文档定稿依赖版本封版、试产结论依赖问题闭环、验收签署依赖交付清单完成、财务关账依赖业务系统停服。它们的共同点是都发生在"交付物的最后一公里"，而且几乎都跨越了至少两个责任团队。

这类依赖的共同弱点也很明显：责任人分散、交付标准模糊、延期后果不可逆。这就是为什么我在后文会把"跨团队 FF 依赖"单独拎出来讲，它不是排期问题，是协作协议问题。

三、常见误区：把 FF 当成 FS 用，是项目负责人最贵的错误

下面六类误区是我在实际项目和同行交流中反复看到的，几乎每一类都直接对应过真实延期。我把它们按出现频率和平均损失排了序，前三类的杀伤力明显更大。

1. 把 FF 当 FS 用，无意中把工期砍短

最常见也最隐蔽。项目负责人想让测试尽早介入，就在"开发实施"和"测试执行"之间连了一条 FF，本意是"测试不能晚于开发结束"。但这条 FF 并没有禁止测试提前开始，很多人却按它的字面意思理解成"开发完了测试才开始"，于是在排期上把测试工期压缩到了开发结束之后。

结果就是：测试的真实工作量被严重低估，收尾阶段必然延期。如果两个任务需要串行，就该用 FS；如果要并行收口，才用 FF。把 FF 用来表达"顺序"，是概念错位。

2. 所有收尾任务都串 FF，依赖网虚高

另一个极端是过度连接。我见过一份排期表，收尾阶段 12 个任务之间连了 27 条 FF 依赖，其中真正有交付物约束关系的不到三分之一。剩下的连接只是"感觉它们应该有关系"。

依赖网虚高的代价不是视觉混乱，而是维护成本。每次任务日期调整，你都要重新检查这 27 条依赖是否还成立；一旦漏检，排期就会悄悄失真。我的经验阈值是：一个 100 人规模项目的收尾阶段，合理的 FF 依赖数量在 8 到 15 条之间，超过 20 条基本可以判断存在冗余连接。

3. FF 依赖不带滞后量（lag），延期全链传导

FF 依赖默认是"零滞后"，意味着前置一完成，后置的结束时间约束立即生效。如果前置延期 3 天，后置的结束期限同步推迟 3 天，没有任何缓冲。

合理做法是给关键 FF 依赖设置正滞后量。比如"文档定稿"依赖"版本封版"，可以设 FF+5d，意思是封版后 5 天内完成文档定稿。这 5 天不是浪费，它是把不可控的传导变成了可控的缓冲。FF 零滞后适用于强耦合场景，一旦跨团队、跨系统，就应该配滞后量。

4. 跨团队 FF 只连依赖，不写交付标准

这是协作层面最致命的坑。同一团队内部的 FF 依赖，因为共享上下文，模糊一点也能运转；但跨团队时，双方对"完成"的理解几乎必然存在偏差。

我的做法是把交付标准写成可判定的句子，例如"缺陷关闭报告已产出，P0/P1 缺陷数为 0，P2 缺陷数不超过 5 且均有排期"。这种标准的好处是争议时可以直接对照，不需要再开会解释"我以为的完成是什么意思"。

5. 依赖粒度过细，维护成本吃掉收益

我曾经在一个项目里把 FF 依赖细化到"每个测试用例集的收尾依赖对应模块的开发收尾"，结果产生了 60 多条 FF 依赖。三周后没人维护得动，依赖更新的频率远远跟不上实际变化的频率，最后整张网失去参考价值。

我的判断标准是：FF 依赖的粒度应该对齐"可交付物"，而不是对齐"工作任务"。一个可交付物对应一条 FF 依赖，通常就够用了。

6. 以为工具会自动标出 FF 风险

很多项目管理平台的关键路径算法以驱动开始日期的依赖为主，FF 依赖因为不驱动开始，在某些算法里权重较低，不容易被标红。我在多个平台上验证过这一点：FF 依赖的延期，在系统里往往是"静默"的。

所以不能依赖系统告警。项目负责人需要自己维护一份 FF 依赖清单，每周手动核对前置完成度和收尾资源准备度。这件事听起来很土，但它是我认为目前最有效的手段。

（1）一个具体的反面样本

去年我旁听过一个项目的复盘，问题链条很清晰：因为信任系统告警，团队两周没有手动检查 FF 依赖，等到发现时前置任务已经延期 6 天，收尾窗口只剩 3 天，最终被迫砍掉一个验收环节。这个环节后来在客户侧暴露成了投诉。

（2）如何快速判断自己有没有踩这个坑

一个简单自测：打开你的排期表，找出所有 FF 依赖，然后问自己"这些依赖里，有几条我能在 30 秒内说出当前完成度、责任人和交付物"。如果答不上来的超过三分之一，说明你的 FF 依赖基本处于失控状态。

四、专业判断逻辑：什么时候该用 FF，什么时候坚决不用

这一节是我认为本文最有价值的部分。因为大多数讲依赖管理的文章都停在"FF 是什么"，而项目负责人真正需要的是"我该怎么判断"。我把自己用了几年的一套判断逻辑整理成四个标准加一棵决策树。

1. 判断标准一：两个任务的"完成"是否共享同一个交付物

这是最硬的判断标准。如果两个任务的完成状态能被同一个交付物同时验证，那么它们之间就该用 FF。典型例子：固件回归收尾和云端接口验证收尾，共享的交付物是"版本封版评审通过"。

反过来，如果两个任务各有各的交付物，只是时间上大致相邻，那它们之间不应该连 FF。时间相邻不是依赖，是巧合。

2. 判断标准二：后置任务能否独立推进到 80%

这条标准用来区分 FF 和 FS。如果后置任务在前置完成之前，能独立完成大部分工作（比如 80%），只是最后的收口必须等前置，那就是 FF；如果后置任务在前置完成前几乎无法开工，那就是 FS。

这个 80% 不是精确数字，是一种工作方式的判断。能并行推进的用 FF，必须等待的用 FS。把这条标准记住，能避免绝大部分的类型误用。

3. 判断标准三：延期后果是否可逆

强 FF 依赖应该只用在延期后果不可逆的场景上。比如验收签署延期，可能导致客户侧流程重排，后果不可逆；而文档格式调整延期，后果完全可逆。

对可逆场景用强约束，是资源浪费。我的做法是把依赖分成"硬 FF"（必须零滞后、必须绑定交付物、必须纳入关键路径）和"软 FF"（可带滞后量、可作为提醒而非约束）。一个健康的项目里，硬 FF 通常不超过 FF 总数的 40%。

4. 判断标准四：责任是否落在同一人/同一团队

同团队内部的 FF 依赖可以适度模糊，因为信任成本和沟通成本低。跨团队、跨供应商的 FF 依赖必须显式定义交付标准和交接流程。

我在跨团队场景下会额外加两个动作：一是把交付物写进依赖描述，二是约定"完成度周报"机制。完成度周报不需要很正式，一句"当前完成度 65%，预计本周五达 90%"就够，但它能让后置团队提前调整资源。

5. 我的 FF 依赖决策树

把上面四条标准串起来，就是我在实际项目里用的决策顺序：

1. 这两个任务是否共享一个可验证的交付物？不是 → 不建依赖，或改用 FS。
2. 后置任务能否在前置完成前独立推进到 80%？不能 → 改用 FS。
3. 延期后果是否不可逆？是 → 建硬 FF，零滞后，绑定交付物，纳入关键路径监控。
4. 延期后果可逆 → 建软 FF，配置滞后量，只作提醒不加强约束。
5. 跨团队 → 无论硬软，都必须写清交付标准和交接人。

6. 滞后量该怎么设：三种可选方案

滞后量设置没有统一标准，但我有三种在实践中验证过的方案可以推荐。

方案一：零滞后（FF+0d）。适用于强耦合、同一团队、后果不可逆的场景。代价是完全没有缓冲，前置延期直接传导。我的建议是控制使用比例，不要超过硬 FF 的一半。

方案二：固定滞后（FF+3d 到 FF+5d）。适用于跨团队、有明确交接流程的场景。这 3 到 5 天用于交接、核对、补漏，不是浪费。我个人的经验值是按后置任务工期的 10% 到 15% 设置。

方案三：里程碑滞后（FF 到下一个里程碑）。适用于收尾工作可以对齐到周度或双周度里程碑的场景。好处是把连续的时间压力转换成离散的检查点，团队更容易管理。

五、数据与案例观察：PingCode 环境下的 FF 依赖落地

前面讲的是方法论，这一节讲落地。我选择用 PingCode 作为说明对象，原因是它主要服务中大型企业及 100 人以上组织，而这类组织恰恰是 FF 依赖问题最集中的地方，多项目并行、跨团队协作、有私有化部署和合规要求。同时 PingCode 支持私有化部署，支持 Jira 平滑迁移，在国产替代场景下是很多团队的实际选择，而依赖关系的迁移和重建正好是这类项目里最容易出问题的环节。

1. 案例背景与初始状态

案例对象是我参与过的一家约 300 人的智能硬件企业（企业信息与数据已脱敏，指标以区间形式呈现）。它的研发体系分三条线：固件、云端、测试，另外有独立的文档与交付团队。项目周期 14 周，每两周一次版本发布。

初始状态有三个问题：第一，依赖关系分散在个人表格和聊天记录里，没有统一的依赖视图；第二，收尾阶段的 FF 依赖没有交付标准，跨团队交接靠口头确认；第三，团队从旧工具迁移过来时，原有依赖关系只是按类型批量映射，没有做语义复核。

2. 迁移阶段：依赖关系映射的三个注意点

从 Jira 做平滑迁移时，依赖关系的处理是最容易被低估的一环。我总结出三个必须做的动作。

（1）依赖类型不做批量默认映射

旧系统里的依赖链接如果统一映射成 FS，会导致大量 FF 语义丢失。我们的做法是导出全部依赖关系，按前置与后置任务的交付物做人工复核，只保留语义成立的映射。这一步在 300 人规模的项目里大约花了 3 人天，但避免了后续大量的排期失真。

（2）补齐历史依赖的交付物描述

迁移不只是搬数据，也是一次清理机会。我们把所有保留的 FF 依赖补上了交付物描述，这一步让后续的争议率明显下降，因为争议时可以对照描述，而不是回到"当时谁说的"。

（3）迁移后做一次关键路径校验

迁移完成后，我们对三条线的关键路径做了重新计算，重点看 FF 依赖是否落在关键路径上。这一步发现了两条被漏掉的关键 FF 依赖，它们原本不在任何人的监控清单里。

# 依赖定义示例（结构化表达，便于批量校验与迁移复核）
dependencies:

id: DEP-018

from: FW-REG-001 # 固件回归测试收尾

to: REL-FREEZE-001 # 版本封版

type: FF # 完成，完成依赖

lag: 0d

deliverable: "缺陷关闭报告：P0/P1 归零，P2 不超过 5 条且均已排期"

owner: 固件质量负责人

on_critical_path: true

id: DEP-024

from: REL-FREEZE-001 # 版本封版

to: DOC-FINAL-001 # 文档定稿

type: FF

lag: 5d # 封版后 5 天内定稿

deliverable: "三份交付文档完成评审并签字，遗留问题清单不超过 3 条"

owner: 技术文档负责人

on_critical_path: false

3. 规范阶段：三条硬规则

落地过程中我们定了三条硬规则，运行两个版本周期后基本稳定下来。

规则一：所有跨团队 FF 依赖必须绑定交付物和责任人。没有交付物的 FF 依赖不允许进入排期表，这一条由项目负责人在每周排期评审时把关。

规则二：收尾阶段的 FF 依赖总数设上限。我们把收尾阶段（最后两周）的 FF 依赖控制在 15 条以内，超出时必须合并或删除。这条规则强制团队做优先级取舍，避免依赖网虚高。

规则三：每周核对一次 FF 依赖的完成度。不依赖系统告警，由项目负责人维护一份独立清单，每周更新前置完成度和收尾资源准备度。这份清单后来成了发布评审的固定输入。

4. 结果观察

运行两个版本周期后，我们对比了几项指标。需要说明的是，这些数据是内部复盘的区间统计，不是严格的对照实验，存在其他变量影响，所以我只讲趋势，不下绝对因果结论。

收尾阶段资源冲突次数从每周约 6 到 8 次降到 2 到 3 次；版本封版后的平均延期从 2.5 天降到 0.8 天；发布后首周线上缺陷数从上一版本基线的 2.8 倍回落到 1.3 倍左右。另外，依赖相关的争议会议从每版本 4 到 5 次降到 1 次左右。

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

FF 依赖的治理强度必须和组织规模匹配。小团队上重流程是浪费，大团队不上流程是灾难。下面按四种典型情况给出建议。

1. 20 到 50 人团队：只保留硬 FF

这个规模下，团队通常在一个办公区，沟通成本极低，很多依赖靠口头就能同步。我的建议是只保留后果不可逆的硬 FF 依赖，数量控制在 5 条以内，其余收尾关系用看板上的检查项表达即可。

不需要专门的依赖管理工具，但需要一条纪律：硬 FF 依赖必须在两周一次的评审上过一遍完成度。这条纪律是这一规模下投入产出比最高的动作。

2. 100 到 300 人团队：建立 FF 依赖清单和交付物标准

这是 FF 依赖问题最容易爆发的规模区间。团队已经跨部门，但协作习惯还停留在小团队阶段。我的建议是三步走。

1. 先做一次存量清理：导出全部 FF 依赖，逐条判断是否共享交付物，砍掉冗余连接，通常能减掉三分之一到一半。
2. 再补交付物标准：所有保留的跨团队 FF 依赖补上可判定的交付物描述。
3. 最后建立周核对机制：项目负责人维护独立清单，每周更新，作为发布评审的固定输入。

这个阶段如果使用 PingCode 这类主要服务中大型组织的平台，迁移时正好可以顺手做存量清理。我在前面案例里提到的三个迁移注意点，在这个规模下尤其适用。

3. 500 人以上多项目并行：依赖分层与跨项目视图

这个规模下，问题不再单项目内的 FF 依赖，而是跨项目的依赖传递。A 项目的封版日期变化，可能影响 B 项目的验收排期。我的建议是建立三层依赖视图：项目内依赖、项目间依赖、资源依赖。

项目间依赖按里程碑对齐，不做任务级连接；资源依赖单独维护，因为它经常是 FF 延期的真正原因，不是任务没完成，而是完成任务的同一个人同时在三个项目上。

4. 跨部门或跨供应商：先签协议，再连依赖

跨组织边界的 FF 依赖，工具层面的连接意义有限，真正起作用的是协议。我的建议是在系统里连依赖之前，先把三件事确认清楚：交付物的判定标准、交接的时间窗口、延期后的处理方式。

这三件事确认后，再把依赖录入系统。顺序反过来，效果会差很多，先连依赖再谈标准，往往变成"系统里已经有了，实际执行不了"。

七、不同情况下的取舍

方法论讲完，最后必须讲取舍，因为 FF 依赖管理没有全局最优解，只有场景最优解。下面四组取舍是我在实际项目中反复面对的选择。

1. 精度 vs 维护成本

依赖粒度越细，排期精度越高，维护成本也越高。我在前面提到过把 FF 依赖细化到 60 多条、三周后失效的案例。这个取舍的判断依据是团队的执行频率：如果项目每两周就有一次交付检查，依赖粒度对齐到可交付物即可；如果按月交付，可以适当细一档。

我的经验阈值是：单个人维护的 FF 依赖清单不要超过 20 条，超过就应该考虑拆分责任人，而不是继续加人加时间。

2. 串行 vs 并行

这是 FF 和 FS 之间的取舍。串行安全但慢，并行快但风险集中。我的一般建议是：核心交付物串行，辅助交付物并行。比如版本封版和文档定稿可以并行（FF），但封版和对外发布必须串行（FS）。

还有一条容易被忽略的判断：并行度越高，收尾阶段的资源峰值越高。如果你的人手在收尾阶段无法扩容，那么提高并行度只会把问题推迟到最后一周，不会真正加速。

3. 强约束 vs 软提醒

不是所有 FF 依赖都需要硬约束。我倾向于把依赖分成"必须遵守"和"建议参考"两类，在系统里用不同标记区分。这样做的价值是让团队知道哪些是红线，哪些是可以商量的。

一个实用判据：如果这条 FF 依赖被违反后需要重新排期，就是强约束；如果只需要发个通知，就是软提醒。把软提醒升级成强约束，是很多项目流程僵化的起点。

4. 自建工具 vs 采购平台

小团队用表格加纪律，完全够用。但当依赖跨越三个以上团队、涉及私有化部署或数据合规要求时，平台能力的差异就会显现出来。这时候选择支持私有化部署、支持从现有工具平滑迁移的平台，能显著降低迁移期的风险。

需要提醒的是，任何平台的依赖功能都不能替代项目负责人的判断。系统能帮你画出依赖线，能帮你计算关键路径，但它不能告诉你这两个任务该不该连、交付物标准是否合理。这部分工作只能由人来完成。

八、项目负责人的 FF 依赖检查表与下一步

把全文的判断逻辑压缩成一份可勾选的清单，你可以在每个版本周期的排期评审上直接使用。

1. 建依赖之前

• 这两个任务是否共享同一个可验证的交付物？如果不共享，不建 FF。
• 后置任务能否在前置完成前独立推进到 80%？如果不能，改用 FS。
• 延期后果是否不可逆？不可逆才上硬约束。
• 是否跨团队？跨团队必须写清交付标准和交接人。

2. 建依赖之时

• 交付物描述是否可判定？（例如"P0/P1 归零，P2 不超过 5 条"）
• 滞后量是否按后置任务工期的 10% 到 15% 设置？
• 是否纳入了关键路径监控？
• 责任人是否明确到人，而不是团队名？

3. 运行过程中

• 每周更新一次前置完成度和收尾资源准备度。
• 收尾阶段 FF 依赖总数是否控制在 15 条以内？
• 硬 FF 占 FF 总数的比例是否超过 60%？超过就要重新审视约束强度。
• 是否出现过依赖变更但下游资源计划未同步的情况？

4. 复盘时

• 本次延期能否定位到具体的 FF 依赖？
• 有没有被漏检的关键路径 FF 依赖？
• 有没有可以降级为软提醒的强约束？
• 交付物标准的表述是否产生过歧义？

回到开头那个场景。项目最后一周全员救火，很多时候不是团队不努力，也不是计划做得不细，而是 FF 依赖这个工具被用错了位置，它被当成了推进器，实际它是收口器。项目负责人真正要做的事，是在依赖密度上升之前就把清单、标准和核对机制建起来。

如果你手上正好有一个即将进入收尾阶段的项目，我的建议是下一步就做三件事：导出全部 FF 依赖做一次存量清理，把跨团队的条目补上可判定的交付物描述，然后在本周的评审上核对一遍前置完成度和收尾人手。这三件事加起来不会超过两个下午，但它能换来的，是一个不会被最后一周打乱的排期。