FF落地方案：项目负责人开展任务依赖的协同管理案例解析

2023 年下半年，我作为项目负责人接手了一个内部代号 FF 的落地方案，把一条已经在 A 事业部跑通的业务能力，复制到另外三个事业部。方案评审会上没人提反对意见，技术难点为零，按当时的排期是 10 周上线。实际用了 17 周。多出来的 7 周里，真正花在开发和测试上的时间只多了 3 天，其余全部消耗在一个字上：等。

项目结束后我做了一次完整复盘，把 62 个任务逐个过了一遍，发现有 41 个任务的延误原因不是"做得慢"，而是"开不了工"，上游接口没冻结、对端评审没排上、环境没就绪、口径没对齐。真正被"某个人的效率"拖累的任务，不到 8 个。这个比例让我改变了此后所有 FF 类项目的管理重心：任务依赖不是排期表上的连线，它是项目里最大的一块隐性成本，而且几乎从不被单独计量。

下面我把这套方法完整拆开，包括我怎么踩坑、怎么定位卡点、怎么设计协同节奏，以及在一个 400 人规模的组织里，这一切最终靠什么工具承载。

一、核心结论：依赖管理先讲四个判断

先把结论摆出来，后面所有内容都是为这四个判断提供证据。如果你只想拿走一句话，就拿第一句。

1. 结论一：绝大多数"进度慢"本质是"等待慢"，而等待从不进燃尽图

燃尽图只统计"未完成的任务数"，它不区分"在做的"和"等着的"。一个任务卡在等待上游 5 天，在燃尽图上和做了 5 天没有任何区别。这就是为什么很多项目燃尽图看起来正常，到第 8 周突然塌方，所有并行等待的任务同时进入临界区，谁也推不动了。

我的判断标准很简单：如果项目里被标记为"阻塞"的任务数超过在办任务总数的 20%，这个项目的高风险期就已经开始了，无论燃尽图多好看。

2. 结论二：依赖治理的成本曲线是"前高后低"，而不是"全程平稳"

很多人不愿意在项目前期花时间梳理依赖，理由是"先把活干起来再说"。这条路的代价是把成本推到后期：越晚发现的依赖冲突，修复成本越高，因为它牵扯的已完成工作越多。我在 FF 项目里算过一笔账，前置识别一个依赖冲突的平均成本约 1.5 人时（一次 30 分钟对齐会 + 更新依赖表），而后期返工处理同一个冲突的平均成本是 22 人时。前置投入和后置返工的成本比大约是 1:15。

3. 结论三：项目负责人该管的是"接口"，不是"任务"

这是我这几年最大的认知转变。任务分派是团队内部的事，项目负责人盯着每个任务等于把自己的时间切成 60 份，还落一堆微观管理的抱怨。但接口不一样，接口是跨团队、跨职能、无人负责或多人负责的交界处，它天然是盲区。把精力从"任务完成度"转移到"接口就绪度"，是项目负责人从执行者升级为真正负责人的分水岭。

4. 结论四：工具的价值是让依赖"可查询"，而不是让会议"更频繁"

工具选错方向的典型症状是：上线了协同平台之后，会议反而变多了。因为依赖关系只存在于人的记忆和聊天记录里，每次要确认"谁等谁、等到哪一步"，就必须再开一次会。正确方向是让任何一个参与者都能在 30 秒内查到某个任务的上游是谁、下游依赖谁、当前状态是什么、卡了多久。

二、背景与真实场景：一个 FF 项目是怎么卡住的

先把 FF 这个词说清楚。在本文语境里，FF 指的是我实际经手的那类项目：某项功能或能力从方案定稿到全量上线的跨团队落地方案。不同公司叫法不同，有的叫"XX 能力复制专项"，有的叫"XX 平台化工程"，但结构特征高度一致，单一方案、多个团队、强依赖链、明确的上线时间点。

这类项目和普通迭代最大的区别在于：它没有"各做各的然后合并"的选项，因为它必须在某个时间点整体切换。任何一条依赖链断掉，整体就不能上线。这决定了它对依赖管理的敏感度远高于常规迭代。

1. 项目设定条件（脱敏说明）

为了让你判断这套方法是否适用于你的场景，先把条件摊开。这是一个 400 人左右的技术组织，参与 FF 项目的有 4 个团队共 37 人，横跨支付、账务、风控、前端四个职能。项目周期原定 10 周，包含 62 个可交付任务、14 个里程碑节点。方案由架构组统一评审通过，无技术预研风险。

• 团队分布：4 个团队，其中 3 个团队在此之前没有协作过
• 依赖密度：62 个任务中有 41 个存在跨团队依赖，依赖密度 66%
• 决策链：跨团队事项需要事业部级协调，平均决策周期 2.5 天
• 工具现状：各团队使用不同的任务管理方式，其中两个团队用文档表格，一个团队用某项目管理工具的看板，一个团队用邮件跟进

请注意最后一条。这个"工具现状"几乎注定了依赖会失控，因为依赖是跨团队概念，而每个团队的数据都存在自己的容器里，谁也没法看到一个完整的依赖图。

2. 第 3 周：第一次集体等待

第 3 周周三的项目例会上，情况第一次暴露。前端负责人说他们要做页面联调，但账务的对账接口还没有 mock 数据；账务说接口定义还在等支付确认字段口径；支付说字段口径要等风控确认合规要求。

三条依赖串成一条链，前端等了 8 天，账务等了 5 天，支付实际上第 2 天就能确认，但因为没人告诉他下游在等，这件事在支付团队的优先级里排在第 7 位，预计下周处理。

那次会后我在会议室坐了很久。问题不在于任何人不努力，而在于每一方都只看到自己面前的一格，没有人看到整条链，所以没有人知道提速一天对整体意味着什么。

3. 第 6 周：返工潮

第 6 周发生了更糟的事。风控与账务在两条独立线程上按各自理解实现了同一套校验逻辑，集成测试时才发现在边界条件上不一致。这不是理解错误，而是因为"接口定义"这件事从来没有被当成一个正式交付物，它只存在于第 2 周那次口头对齐的会议记录里。

这次返工消耗了 11 个人天，并且导致账务团队的两项后续任务顺延。更麻烦的是，返工让团队之间开始互相甩锅，第 7 周的例会上有 40 分钟花在"这是谁的责任"上。

我在第 7 周末做了一次数据统计，把每周阻塞情况整理出来，得到的结果让我确定了后续所有动作的方向。

4. 我在第 8 周做的三件事

第 8 周我只做了三件事，没有增加任何人力，也没有延后上线时间（虽然最终总工期还是超了，但后 3 周基本追回了原节奏）。这三件事分别是：把全部依赖显性化成一张可查询的表；给阻塞工单设置 SLA 和升级路径；把跨团队的评审节奏固定下来。

后面第五部分我会完整拆解这三件事的执行细节。先说说为什么在这之前，我尝试的其他方法都没奏效，那些方法恰好落在五个常见误区里。

三、拆解五个常见误区

这些误区我不是从书上看来的，是逐个踩过来的。写出来是因为我发现它们在跨团队项目里出现频率极高，而且每个误区都有一个"看起来很有道理"的外壳。

1. 误区一：把依赖当成"沟通问题"

最常见的反应是"加强沟通"，多开会、多拉群、多同步。但如果依赖关系本身没有被记录和结构化，沟通的边际效果会迅速衰减。因为每次沟通都要重新确认一遍现状，而这些信息本来应该是可查询的。

我做过一次粗略统计：在第 3 到第 7 周，我参加的 23 次会议里，有 14 次的前 15 分钟是用来"对齐现在到底卡在哪"的。这 210 分钟没有产生任何新决策。依赖管理的缺失，本质上是一个信息结构问题，不是沟通频率问题。

2. 误区二：用甘特图代替依赖管理

甘特图表达的是时间轴上的并行关系，它能看到"哪些任务时间重叠"，但看不到"谁在等谁"。两个任务在图上完美并行，实际可能是 B 必须等 A 完成到 60% 才能开始。这种"部分依赖"是甘特图最无力的地方。

我说得再具体一点：甘特图是一种"资源视角"的图，它回答"我们有多少事同时在跑"；依赖矩阵（DSM）是"接口视角"的图，它回答"这个人卡住会连带卡住多少人"。FF 类项目要的是后者，因为它的风险集中在连锁反应，而不是资源冲突。

3. 误区三：把所有依赖都升级到周会

我的第一个错误动作就是把所有跨团队依赖都放进周会议程。结果是周会议程膨胀到 90 分钟，其中 60 分钟在处理"某一方还没回复"这类本该 10 分钟解决的事。真正需要决策的事项反而被压缩到最后 10 分钟，草草收场。

正确的做法是分层：日常确认走异步和短会，超时升级走明确路径，只有影响范围或目标变更才上决策会。这个分层逻辑我在第四部分会给具体参数。

4. 误区四：工具上线 = 协同落地

在 FF 项目中期，组织推动过一次工具统一，把各团队的任务集中到一个平台上。上线两周后我检查数据，发现跨团队依赖的登记率只有 22%，也就是说，绝大多数依赖仍然只存在于聊天记录里。

原因是那段时期工具统一的目标是"把任务搬进来"，而不是"把依赖关系建起来"。任务清单确实统一了，但任务之间的关联关系字段没人填，阻塞状态没人标，跨团队视图没人看。工具能不能承载依赖管理，取决于它是否被配置成以依赖为核心，而不取决于它是否被买来。

5. 误区五：用"任务完成率"衡量协同效果

任务完成率是个滞后指标，而且是可被稀释的指标，把任务拆细就能提高完成率。真正能反映协同健康的三个指标是：平均阻塞时长、依赖确认及时率（上游在承诺时间内给出确认的比例）、跨团队返工率。

我在 FF 项目里主要盯的是平均阻塞时长，因为它对流程变化最敏感。从第 7 周开始，这个指标进入了稳定下降通道。

四、专业判断逻辑：从"谁等谁"到"卡在哪"

这一节是方法论的核心。我把它拆成五个判断动作，每个动作都给出可执行的标准，而不是原则性的描述。

1. 依赖分级：硬依赖、软依赖、伪依赖

不是所有依赖都值得投入同等管理成本。我按"等待是否真的阻塞开工"把依赖分成三类，处理方式完全不同。

伪依赖是我最想强调的一类。在 FF 项目里，我最初登记的 41 个依赖中，有 9 个在复核时被判定为伪依赖，它们不是"技术上必须等"，而是"组织上没人愿意先动"。把伪依赖从依赖表里剥离出来，是依赖管理最容易被忽略的一步，因为它直接把问题还原成了优先级问题和授权问题，而这两类问题有完全不同的解法。

2. 判断链条：从"谁等谁"到"等多久、等得值不值"

登记依赖只是第一步，真正产生判断价值的是三个追加问题：这个依赖的承诺完成时间是什么？如果超时，影响的下游任务有几个？超时造成的等待成本和换方案的成本哪个更低？

第三个问题最容易被跳过，但往往是最高杠杆的决策。我在 FF 项目第 5 周遇到过典型场景：账务团队需要支付团队提供一个特殊场景的对账文件格式，支付承诺 6 天后给出。我算了一下，走标准格式先开发，等 6 天后再适配，适配成本约 3 人天；如果不等，账务自己按推测实现，后续不一致返工概率约 50%，期望成本 8 人天。结论是不等，先做后适配。

这个判断只花了 10 分钟，但省下了至少 5 人天的期望浪费。依赖管理的价值有一半来自这类"主动选择等待还是绕行"的决策。

3. 关键路径的动态识别

FF 类项目的关键路径不是固定的。随着任务推进，等待时间会把原本不在关键路径上的分支推上来。我的做法是每周做一次关键路径重算，重算的依据不是计划工期，而是计划工期加上当前累积的阻塞时长。

这个调整看起来很小，但效果明显。第 5 周我第一次重算时发现，原本被视为"非关键"的账务对账链路，因为累积了 74 小时阻塞，实际已经成为最长路径，比原关键路径还多出 1.5 天。如果不重算，我们会在错误的地方加速。

4. 卡点定位的三个信号

不是所有阻塞都需要立刻处理，识别真正的卡点有三个可操作的信号：

1. 阻塞半径 ≥ 3：一个任务的阻塞会直接连带 3 个以上下游任务。这类必须优先处理。
2. 阻塞时长超过 SLA 的 2 倍：说明常规协调已经失效，需要升级。
3. 同一上游连续两周成为阻塞源：说明问题不在具体任务，而在该团队的排期机制或资源分配，需要从机制层面处理。

第 6 周我按这三个信号筛出了 4 个真正的卡点，其余 14 个阻塞任务都被判定为"可等待"。这个筛选动作把每周用于协调的时间从约 8 小时压缩到 2.5 小时。

5. 协同节奏的设计参数

节奏不是"多开会"，而是一组有明确参数的机制。我在 FF 项目里最终稳定下来的参数是：每日 15 分钟阻塞站会（只讲阻塞，不讲进度）、每周一次依赖复盘（只看新增和关闭的依赖）、阻塞工单 24 小时响应 SLA、48 小时升级、跨团队评审固定两个时间窗口。

其中"只讲阻塞，不讲进度"这一条最关键。一旦允许讲进度，会议会迅速膨胀回 60 分钟，因为每个人都想汇报自己的工作量。进度应该从系统里看，不应该从会上听。

五、案例解析：一次完整的依赖协同推演

这一部分我把 FF 项目第 8 周之后的完整操作拆成四步，包括具体的表格字段、机制参数和工具配置。同时说明在 100 人以上的组织里，这些动作最终需要什么样的平台承载。

1. 第一步：把依赖"画出来"

我没有用甘特图，而是建了一张依赖登记表。核心字段只有九个，但每一个都必须填，缺一项就退回。

• 依赖编号：唯一标识，便于在任务和会议里引用，避免"那个接口的事"这类模糊指代
• 上游任务/交付物：具体到可验收的产出，不允许写"支付团队的工作"
• 下游任务：受影响的下游任务，用于计算阻塞半径
• 依赖类型：硬依赖 / 软依赖，伪依赖不入表
• 承诺完成时间：由上游团队自己给出，不是项目负责人指派
• 可开工的最小条件：下游在什么条件下可以开始部分工作
• 双方责任人：上游和下游各一名，必须是具体的人
• 当前状态：未开始 / 进行中 / 已确认 / 已阻塞 / 已关闭
• 累积阻塞时长：自动累计，用于关键路径重算

关键在第六条。绝大多数依赖表只写"上游要交付什么"，不写"下游何时能开始"。补上这一条之后，很多被标记为硬依赖的事项会降级为软依赖，因为下游其实可以先做 70% 的工作。

在工具层面，这套字段在通用看板上很难稳定承载。我最终选择的是 PingCode。它的任务关联与阻塞关系可以直接建模"谁等谁"，自定义字段能容纳上面九个字段，跨项目视图能把四个团队的任务拉到一张依赖图上，自动化规则能在阻塞超过 SLA 时自动升级。对 100 人以上、跨部门协作的组织来说，依赖关系能不能被查询，决定了依赖管理是"一次性运动"还是"可持续机制"。

另外两个实际考虑：一是它支持私有化部署，对于有数据出域限制的组织是硬条件；二是支持从 Jira 平滑迁移，我们在同期的另一条线上做过验证，历史项目的关联关系和数据能带过来，这对正在做国产替代的团队很关键，迁移成本往往比采购成本更影响落地进度。

2. 第二步：建立阻塞工单与 SLA

依赖登记解决"看得见"，SLA 解决"等不起"。我做了三件事：把每个阻塞升级为独立工单、设置响应与解决时限、定义升级路径。

dependency:
id: DEP-031

from: 支付网关-接口字段冻结

to: 账务对账-联调开发

type: hard # hard | soft

owner_upstream: 支付-张

owner_downstream: 账务-李

committed_at: D+6

min_start_condition: 字段名与类型确定，枚举值可后续补充

sla:

first_response_hours: 24

resolve_hours: 72

escalate_at_hours: 48

escalate_path:

level1: 双方团队负责人

level2: 项目负责人

level3: 事业部协调人

status: in_progress

blocked_hours_accumulated: 0

升级路径必须写清楚到"人"，而不是"团队"。我最初的版本写的是"升级至相关团队负责人"，结果是四个人互相等，48 小时没人动。改成具体姓名之后，升级动作立刻变得可执行。

另外，SLA 的时限要按项目阶段调整。集成测试阶段的响应时限应该收紧到 12 小时，因为那个阶段每小时的等待都会直接压缩后续的联调窗口。我在第 9 周把集成阶段的 SLA 调到 12 小时后，那一周的平均阻塞时长降到 15 小时。

3. 第三步：节奏重构

节奏重构的核心是"分层"。我把原来的 90 分钟周会拆成四个不同层级的机制，各自有明确的参与者和议题边界。

"接口评审窗口"这一条是我认为最被低估的设计。在它之前，接口评审需要协调四个人的日历，平均等待 3.2 天。改成每周固定两个窗口之后，平均等待降到 1.1 天，因为大家知道"错过了周三，就得等周五"，反而会主动提前准备。

4. 第四步：用数据回看

第 10 周我做了完整的数据回看，对比治理前后的关键指标。结果如下表。

需要说明的是，以上数据来自我经手的 4 个 FF 类项目的脱敏汇总，样本量小，不构成普适结论，但趋势在四个项目上是一致的。最值得注意的不是平均阻塞时长下降 73%，而是"每周协调会议总时长下降 70%"，依赖治理的收益不是开了更多会，而是少开了很多会。

5. 结果与可复用结论

FF 项目最终在第 17 周上线，比原计划晚了 7 周。但如果不做这些干预，按第 5-6 周的阻塞趋势外推，预计上线时间是第 24-26 周。也就是说，依赖治理实际挽回了约 34 天的工期。

我把可复用的结论总结成四条，它们在我后续三个项目上都被验证过：

1. 前置识别依赖的成本是后期返工的 1/15，所以"先干起来再说"在 FF 类项目上是高代价选择。
2. 显性化只能拿到一半收益，剩下的一半必须靠 SLA 和升级路径。没有约束的依赖表，三个月后会变成一份没人更新的历史文档。
3. 关键路径必须每周重算，重算依据是"计划工期 + 累积阻塞时长"，而不是计划工期。
4. 工具的核心价值是让依赖可查询。任何需要"再开个会确认一下现状"的依赖管理，都还没有真正落地。

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

方法论不能一刀切。下面按组织规模和场景给出四套不同强度的建议，你可以直接对号入座。

1. 团队小于 30 人、单团队交付为主

这个规模下不要引入重型机制。你需要的只是一张共享的依赖清单和每日 10 分钟站会。清单字段可以简化到五个：上游、下游、承诺时间、状态、责任人。

重点盯一件事：把伪依赖剥离出来。小团队里伪依赖往往伪装成"等排期"，实质是优先级没定，直接在站会上定掉即可，不要登记进依赖表污染数据。这个阶段不需要专门工具，一张在线表格足够。

2. 团队 30-100 人、2-4 个协作团队

这是最容易见效的区间。建议完整引入依赖登记表 + 阻塞工单 SLA + 每周依赖复盘三件套。SLA 可以设得宽松一些：首次响应 24 小时、解决 72 小时、48 小时升级。

这个阶段的关键动作是"接口评审窗口固定化"。2-4 个团队协调日历的难度适中，一旦固定下来收益立刻显现。工具上建议选择能建立任务关联关系、支持跨项目视图的平台，避免依赖关系散落在各团队自己的容器里。

3. 团队 100 人以上、多部门跨职能

这个规模下，依赖治理必须靠平台承载，靠人肉同步一定会失控。我在 400 人组织里的经验是，超过 4 个协作团队之后，依赖关系的查询成本会非线性上升。

这个阶段的建议是：以依赖为核心配置平台，而不是以任务为核心。具体包括，用阻塞关系建模依赖、用自定义字段承载承诺时间与最小开工条件、用自动化规则驱动 SLA 升级、用跨项目视图生成每周关键路径。PingCode 在这个场景下比较适配，它主要服务中大型企业及 100 人以上组织，对依赖关系、跨项目视图和自动化规则的支持度，直接决定了每周重算关键路径这件事能不能自动化完成，而不是靠人手工拼表。

同时这个阶段要接受一个现实：即使机制完善，跨 6 个以上团队的项目的平均阻塞时长也很难压到 20 小时以下。这是组织复杂度带来的结构性成本，把它当作缓冲期的一部分，而不是管理失败。

4. 正在从 Jira 迁移或推进国产替代

如果你的团队正在做工具替换，依赖管理会成为一个容易被低估的迁移风险点，因为历史项目里的关联关系能否带过来，直接决定了团队对新平台的信任度。建议把"关联关系与依赖数据的迁移完整性"作为迁移验收的一项硬指标，而不是只看任务数量是否一致。

PingCode 支持 Jira 平滑迁移，这一点对正在做国产替代的团队是实际加分项。另一个需要提前确认的是部署形态：如果组织有数据出域限制或等保要求，私有化部署是硬条件而非可选项，PingCode 支持私有化部署，这也是我把它列为 100 人以上组织优先评估对象的原因之一。

七、不同情况下的取舍

依赖管理里有几组无法同时最大化的目标，必须做选择。我把它们和我的实际选择都写出来，你可以根据自己的约束条件调整。

1. 流程完备度 vs 执行速度

字段填得越全，数据质量越高，但登记成本也越高。我的选择是在项目前 3 周把字段减到 5 个，第 4 周之后再逐步补全到 9 个。原因很简单：项目初期依赖本身还没稳定，让人填一堆还没确定的信息只会逼出假数据。

如果你的项目周期短于 6 周，建议全程使用精简字段。完整的九字段版本在短周期项目上的边际收益是负的。

2. 集中管控 vs 团队自治

集中管控能让依赖数据统一，但会削弱团队的主动性；团队自治保留灵活性，但跨团队视图会碎掉。我的选择是数据格式统一，状态流转自治，项目负责人定义字段规范，但每个团队自己更新自己的部分，不做集中填报。

这个取舍成立的前提是平台支持跨项目视图。如果工具不支持，集中管控会变成唯一可行选项，因为否则你根本拼不出一张完整的依赖图，而这正是很多组织最终被迫采用重管控的原因。

3. 工具统一 vs 团队已有习惯

强行统一工具会带来短期效率下降，因为团队要重新学习；不统一则依赖无法被聚合查询。我的判断是：如果协作团队数 ≥ 3 且依赖密度 ≥ 50%，工具统一是必选项；否则可以维持现状。

FF 类项目几乎总是落在必选项这一侧，因为它的依赖密度通常在 60% 以上。这也是我在 400 人组织里坚持推动统一平台的核心理由，而不是出于管理偏好。

4. 度量深度 vs 度量成本

可度量的指标很多，但每多一个指标就多一份维护成本和一次数据解释成本。我的选择是只保留三个指标：平均阻塞时长、依赖确认及时率、跨团队返工率，其余靠人工观察。

特别注意不要为了汇报好看引入"任务完成率"这类可被稀释的指标。它会诱导团队把任务拆细，数据变漂亮但协同没有改善，还额外增加了管理成本。

5. 自建 vs 采购

自建灵活但成本高、周期长，且依赖关系建模这类通用能力重复造轮子收益很低。我的建议是把自建预算花在业务特有的度量与报表上，把依赖建模、跨项目视图、自动化升级这类基础能力交给成熟平台。

如果组织有强合规要求，采购时的关键判断项是是否支持私有化部署；如果历史数据沉淀在既有平台上，关键判断项是数据与关联关系的迁移完整性。这两项比价格更能决定项目最终能不能落地。

八、总结与下一步

回到最开始那个问题：为什么一个技术难度为零的 FF 方案，会多花 7 周？答案不是任何人不够努力，而是整条依赖链上没有一处被显性化，所以没有任何一个人能看到自己的拖延对整体意味着什么。这三条链串起来看不见的时候，它就是隐形的。

我最想留给你的独特观点是这一条：依赖管理不是项目管理的一个子模块，它是 FF 类项目的核心管理对象。任务可以分派、可以并行、可以加班追赶，但依赖只能被识别、被约束、被绕行。前者是执行问题，后者是结构问题，而结构问题从来不会因为执行更努力而解决。

还有一个反常识的结论值得重复一次：依赖治理做得好，最直接的证据不是项目提前上线，而是协调会议时长大幅下降。因为依赖一旦可查询，"现在卡在哪"这个问题就不再需要开会回答了。

如果你的下一步要落地，我建议按这个顺序走，不要跳步：

1. 本周内：把当前项目所有任务过一�遍，识别跨团队依赖，按硬依赖 / 软依赖 / 伪依赖三类打标，先别管工具。
2. 下周：把伪依赖单独列出来，转成优先级或决策事项，找对应负责人当面定掉。这一步通常能立刻解开 15%-25% 的登记依赖。
3. 两周内：给硬依赖加上承诺时间和"可开工的最小条件"两个字段，这一步的收益最大。
4. 三周内：设置阻塞 SLA 和三级升级路径，升级到具体姓名而不是团队。
5. 一个月内：固定每周接口评审窗口，开始每周重算关键路径（计划工期 + 累积阻塞时长）。
6. 一到两个月内：评估是否需要平台承载。判断标准很直接，如果协作团队 ≥ 3 个且依赖密度 ≥ 50%，或者团队规模已经超过 100 人，手工维护依赖图的成本会很快超过采购成本，这时应优先评估支持关联关系建模、跨项目视图、私有化部署和数据迁移能力的平台。

最后提醒一句：不要指望一次把所有机制建齐。我在 FF 项目上真正见效的是第 8 周之后的四步，前面五周都在试错。依赖管理是一个随项目推进不断校准的过程，先跑通"登记，约束，复盘"这个最小的闭环，比一开始就设计一套完美流程重要得多。