FF管理方法大全：跨部门团队任务依赖数据分析落地清单

2024 年春天，我接手过一个已经延期两次的跨部门项目。市场部、产品部、研发部、测试部的周报都是绿的，各部门任务的按时完成率分别是 96%、93%、91%、89%，但项目整体交付日还是比原计划晚了 23 天。

复盘会上，所有人都在说"沟通不够、协同不到位"。只有测试负责人说了一句话：验收用例的定稿，其实一直卡在市场部的上线合规清单上，而这份清单从来没有被登记成任何一个任务的前置依赖。

那一刻我意识到，问题不在执行力，也不在沟通态度，而在于跨部门依赖从来没有被当成一份可以被登记、被确认、被跟踪的数据。它只存在于某些人的脑子里，或者某次会后闲聊里。项目延期，只是这份隐形依赖最终以时间的形式被结算出来。

这篇文章要回答的就是这件事：FF（Finish-to-Finish，完成到完成）这类依赖关系，在跨部门团队里到底怎么识别、怎么建模、怎么用数据分析、怎么落到一份能勾选的清单上。

一、先给结论：依赖管理管不好，通常不是沟通问题，而是依赖没有被建模

我把话说得更直接一点：大多数跨部门项目的延期，不是"配合不积极"，而是依赖关系从来没有进入项目的正式数据结构。它既不在任务表里，也不在里程碑里，只存在于口口相传的"我以为你知道"里。

1. 三个部门都按时交付，项目却延期了 23 天

回到开头那个项目。我后来把四个部门的任务清单导出来，做了逐条比对，发现真实情况是这样的：

• 研发部有 14 个任务在等测试环境的准备，而测试环境准备依赖运维的资源排期，这条依赖没有出现在任何一个计划表里；
• 市场部的上线合规清单发布日推迟了 6 天，但下游 9 个任务的计划日期没有任何调整；
• 测试部的验收用例定稿，在流程上标的是 4 月 20 日完成，实际是 4 月 26 日，中间 6 天没有人发出过任何预警。

这三条加起来的净影响是 19 天，加上周末和一次审批排队，正好解释那 23 天的延期。每一环都很努力，但努力的成果在依赖上是断开的。

2. 依赖管理的瓶颈不是沟通意愿，是依赖数据的可见性

很多人会本能地把这个问题归到"沟通"上，于是去开更多的会、拉更多的群、写更长的周报。但沟通解决的是信息传递效率，解决不了信息本身不存在的问题。

如果一个依赖从来没有被记录下来，无论开多少会，它都不会出现在任何一份看板里。而看不见的依赖，就不可能被排期、被预留缓冲、被监控。可见性是依赖管理的第一性问题，沟通只是第二性问题。

我后来做过一次小范围的统计：在一次跨部门项目的依赖清点中，团队"认为存在"的依赖有 37 条，"实际存在"的依赖是 62 条。也就是说，大约四成的跨部门依赖处于集体盲区。这个数字不一定适用于所有组织，但方向是稳定的。

3. 一份最小可用的依赖记录应该长什么样

我说的"建模"，不是什么高大上的东西，就是把依赖变成一条有字段的记录。下面是我在项目里实际用过的一个最小结构，字段不多，但每一个都解决一个具体的判断问题。

{
"dependency_id": "DEP-2024-0417",

"upstream_deliverable": "市场部-上线合规清单 v1.0",

"downstream_task": "测试-验收用例定稿",

"relation_type": "FS", // FS / SS / FF / SF

"upstream_owner": "市场部-李",

"downstream_owner": "测试-王",

"confirmed_by": "项目经理", // 谁确认过这条依赖真实存在

"planned_ready_date": "2024-04-20",

"actual_ready_date": "2024-04-26",

"buffer_days": 3, // 下游预留的缓冲

"blocking_hours": 44, // 实际造成的下游等待

"impact_scope": 9, // 这条依赖变更会波及相关任务数

"status": "closed" // open / tracking / at_risk / closed

}

这份结构里有三个字段是大多数团队会漏掉的：confirmed_by、buffer_days、impact_scope。没有确认人，依赖就只是单方面声明；没有缓冲天数，依赖一旦延期就直接传导到交付日；没有影响面，就没法判断一条依赖变更到底值不值得升级处理。

二、背景与真实场景：为什么跨部门团队只登记 FS，漏掉 FF

要讲清楚 FF 为什么容易被漏掉，得先回到四种依赖关系在真实跨部门场景里分别长什么样。定义本身不复杂，难的是把它们对应到具体交付物上。

1. 四种依赖关系在跨部门场景里的真实形态

下面这张表是我在自己项目里做的对应，把四种关系分别落到具体的交付物上。FS 和 FF 的差别，在单部门内部不明显，在跨部门场景里差别巨大。

FF 的核心特征是：下游任务可以提前开始，但不能提前结束。正因为"能开始"，负责人的心理上就不觉得自己在等待，于是这条依赖不会被人主动上报。等到收尾阶段才发现上游还没完成，时间已经不够了。

2. 为什么大多数团队只登记 FS，漏掉 FF 的三个原因

我把过去几年在不同项目里观察到的原因归成三条，都是有具体触发场景的，不是抽象推理。

1. 工具默认值造成的惯性。绝大多数项目管理工具在创建依赖时默认就是 FS，用户不改就用默认。FS 是"最保险"的选择，于是 FF 和 SS 被系统性忽略。
2. "能开始"被误读为"不等待"。下游确实可以动工，于是负责人认为自己没有受阻，也就不会在站会上提出风险。
3. FF 的延期信号来得太晚。FS 的卡点在起点，一卡就暴露；FF 的卡点在终点，往往在验收或发布前一天才暴露，几乎没有补救空间。

第三条是最致命的。FS 的延期是"慢性的、可见的"，FF 的延期是"急性的、隐蔽的"。而跨部门项目里，愈靠近交付日的问题，修复成本愈高。

3. 依赖信息到底该从哪里来

很多人建了依赖表却填不出内容，根本原因是不知道从哪里采集。我的经验是，依赖信息有三个稳定的来源，按可靠性排序如下。

• 来源一：交付物清单。这是最可靠的。凡是"要交出去的东西"，就一定有接收方，接收方就是下游。把交付物一条条列出来，依赖自然浮现。
• 来源二：里程碑倒推。从每个里程碑往回推，问"这个节点要成立，必须已经发生了什么"，通常能捞出被忽略的 FF 依赖。
• 来源三：任务清单比对。可靠性最低，因为任务清单本身就没有依赖字段。它的价值在于交叉验证，而不是作为主来源。

我后来固定用第一种作为主入口。每次跨部门项目启动，先花两小时把交付物清单列出来，比事后开十次协调会都有效。

三、拆解四个常见误区：越努力，越容易踩进去

依赖管理这件事有个特点：错误做法往往看起来非常合理。下面四个误区我在不同团队里反复见到，而且每个都有"说得通"的外壳。

1. 误区一：把依赖管理当成沟通管理

最常见的做法是"加强沟通"：加群、加会、加周报。这套做法在依赖数量少的时候有效，一旦跨部门任务超过几十条，就完全失效。

原因是：沟通解决的是传递效率，依赖管理解决的是结构可见性。从 A 部门到 B 部门的信息传递效率再高，如果这条依赖从来没有被确认过，B 部门就不会为它预留缓冲。

我做过一次对照观察：一个项目把日会从 15 分钟拉长到 30 分钟，依赖相关问题的暴露时间从平均 2.9 天缩短到 2.1 天，改善有限；而当项目改为维护一份依赖登记表，同样的暴露时间下降到 0.6 天。结构性手段的收益远高于频率性手段。

2. 误区二：用甘特图代替依赖分析

甘特图能表达"什么时间做什么"，但不能表达"什么在等什么"。这两个是不同的问题。

把甘特图当作依赖管理工具，会掩盖三类问题：跨部门依赖没有被建模、FF 和 SS 关系被简化成 FS、依赖变更的影响面无法计算。甘特图上一条横条右移，你看得见；但那一条右移波及了多少下游任务，图上不会告诉你。

3. 误区三：只盯关键路径，忽略次生依赖

关键路径是传统项目管理里非常有效的工具，但它在跨部门场景里有个致命的盲点：跨部门的依赖往往不在一条关键路径上，而是分散在多条路径的交汇点。

我见过一个典型情况：主关键路径上的所有任务都被严格管理，进度稳定；但一个不起眼的合规审批任务，因为同时被 11 个下游任务依赖，本身不在关键路径上，却成了整条链路的实际瓶颈。

这类依赖我称之为"次生依赖"，单看每条路径都不关键，但它们共享同一个上游节点。判断它们的方法不是看路径长度，而是看依赖密度。

4. 误区四：背下 FF 定义就等于会管 FF

"前置任务完成后，后续任务才能完成"，这句话谁都能背。但真正需要判断的是三个具体问题：

• 这个 FF 依赖里，下游到底"能开始多少"？能开始的部分是不是可以拆出来单独跟踪？
• 上游的"完成"标准是什么？是提交完成、评审完成，还是验收完成？口径不同，日期差好几天。
• 如果上游延期 3 天，下游是延 3 天还是延 1 天？这取决于下游有多少可并行的预备工作。

定义解决"它是什么"，这三个问题解决"怎么办"。我见过太多团队能准确说出 FF 的定义，却从没在依赖表里填过"完成口径"这个字段。

四、专业判断逻辑：依赖数据分析到底分析什么

很多文章讲"数据驱动"，实际上只是把任务列表打印出来看。真正的依赖数据分析至少要给出可量化口径，否则就是空话。下面五个指标是我在实际项目里长期使用的一组，每个都给出定义、计算方式和异常判断。

1. 依赖密度：一个任务被多少条依赖穿过

定义：某个任务的上游依赖数 + 下游被依赖数之和。

计算方式：依赖密度 = (上游依赖条数 + 下游被依赖条数) / 该任务总工期（天）。分母加上工期，是为了区分"绝对密集"和"单位时间密集"。

怎么看：密度高的任务不是坏事，但它必须配备更多的缓冲。真正危险的是密度高、缓冲为 0 的任务，这在跨部门项目里非常常见。

我在一个项目里做过统计，依赖密度超过 6 的任务，平均阻塞时长是密度为 1-2 的任务的 7 倍以上。这个倍数关系在不同项目里会变，但方向很稳定。

2. 阻塞时长：依赖未满足导致下游等待的时间

定义：从下游任务实际可以开始工作、到上游依赖真正满足之间的时间差。

计算方式：阻塞时长 = 依赖实际满足日期 − 下游最早可工作日期。注意不要用"计划日期"计算，计划日期会把问题掩盖掉。

怎么看：阻塞时长要看分布，不要只看平均值。我一般会把它拆成四段：审批等待、信息等待、资源等待、上游返工。拆开之后，改进方向才明确。

我所在的团队在治理前做的拆分是这样的：审批等待 9.2 小时/任务、信息等待 11.4 小时、资源等待 8.7 小时、上游返工 7.9 小时，另外还有 3.8 小时属于无依赖的排队（这部分不是依赖问题）。真正由依赖造成的部分是前三项加上返工，合计约 37 小时。

3. 关键路径依赖覆盖率：关键路径上有多少依赖被真正管理

定义：关键路径上已登记并确认的依赖数 / 关键路径上实际存在的依赖数。

怎么看：这个指标低于 70%，说明关键路径的估算基本不可信。甘特图看起来很完整，但支撑它的依赖数据是残缺的。

这个指标的好处是它把"排期"和"依赖"两件事绑在一起考核。很多团队排期排得很漂亮，但一问依赖覆盖率只有 40%，那这张排期表的可靠性也就只有 40%。

4. 变更影响面：一条依赖变更会波及多少任务

定义：某条依赖的日期变更后，需要调整计划日期的下游任务数量。

计算方式：从该依赖节点出发，沿依赖图向下遍历，统计所有日期需要变动的任务数。

怎么看：影响面大的依赖必须升级处理，哪怕它本身看起来很小。我在项目里设过一条硬规则：影响面超过 5 个任务的依赖变更，必须在 4 小时内通知到所有下游负责人。

5. 依赖闭环率与依赖健康度

定义：依赖闭环率 = 已记录实际完成日与阻塞时长的依赖数 / 全部依赖数。

这个指标看起来不起眼，但它决定了依赖管理能不能持续改进。没有闭环数据，下一轮项目估算还是靠猜。

我习惯把上面五个指标合成一个"依赖健康度"的综合分，用于跨部门项目的横向对比。权重可以根据组织特点调整，我常用的权重是：可见性 30%、阻塞时长 25%、关键路径覆盖 20%、变更影响面 15%、闭环率 10%。

6. 把指标落到一张周报上

指标堆在文档里没用，必须落到一张固定的周报上。我在项目里用的依赖周报只包含六行：

1. 本周新增依赖数 / 关闭依赖数
2. 当前处于 at_risk 状态的依赖清单（按影响面排序）
3. 平均阻塞时长及环比变化
4. 关键路径依赖覆盖率
5. 本周发生的依赖变更及其影响面
6. 阻塞时长最长的 3 个任务及其责任部门

这六行填满，跨部门的依赖状态基本就透明了。不要试图做很复杂的仪表盘，先把这六行稳定输出三个月。

五、案例与数据观察：一个 200 人研发组织的六个月依赖治理

下面这段是我参与过的一个相对完整的治理过程。组织规模约 200 人，涉及产品、研发、测试、市场、合规五个部门，常年同时跑 6-8 个跨部门项目。整个过程分三个阶段，前两个阶段都失败过。

1. 第一阶段：表格建起来了，没人填

最初我们做的事很标准：设计一张依赖登记表，包含依赖描述、上下游负责人、计划日期、状态，然后在项目启动会上宣讲了一遍，要求各负责人每周更新。

结果是：前三周填写率分别是 34%、21%、9%。第四周基本没人填了。

复盘原因有三条，我觉得非常典型：

• 没有强制触发点。填表是"额外工作"，和任何既有流程都不挂钩，自然被优先舍弃。
• 填了没有反馈。填完的依赖从来没有人回应，负责人会觉得"填了也没用"。
• 字段太多。第一版表格有 19 个字段，填完一条依赖要 3-5 分钟，成本太高。

这一阶段的教训很明确：依赖登记如果不能挂在一个已有的动作上（比如任务创建、交付物提交流程），它一定会死。

2. 第二阶段：把依赖挂到交付物上

第二阶段的改变只有一条：不再单独要求大家"填依赖表"，而是要求每个跨部门交付物在提交时必须声明"谁在等它"。

这条规则的效果立刻不同了。因为它挂在交付物的提交流程上，不声明就无法完成提交，形成了强制触发点。同时字段从 19 个压缩到 7 个，单条填写时间降到 40 秒左右。

三个月后，依赖登记完整率从 32% 提升到 71%，平均阻塞时长从 41 小时降到 28 小时。但这个阶段出现了新的瓶颈：依赖变更的同步还是靠人工通知，时延平均 2.8 天。

3. 第三阶段：用工具固化依赖登记与变更通知

第二阶段的瓶颈本质上是"人肉同步"撑不住。当依赖条数超过 200 条，靠群里喊、靠周会同步一定会漏。

我们在这个阶段引入了研发管理平台来做两件事：一是把依赖关系直接建在任务与交付物上，二是让依赖变更自动通知全部下游负责人。

在工具选型上，我们评估了几类方案。选择研发管理平台（比如 PingCode）而不是继续用电子表格的原因很具体：

• 依赖关系需要和任务本身绑定，而不是存在另一张表里。两套数据一旦分离，同步成本就会指数上升。
• 变更通知需要自动化。依赖日期一改，下游所有人的计划视图必须同步变化，这个靠人做不到。
• 需要支持私有化部署。我们有部分项目涉及内部数据，不能放在公有云上，这一点直接淘汰了几个候选方案。

PingCode 在这几个点上比较贴合：它主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，对已经在用海外工具、想要做国产替代的团队来说，迁移成本相对可控。我特别看重的是它把需求、任务、测试、缺陷放在一条链路上，这样依赖不是孤立存在的，而是天然挂在交付物上。

不过我要说清楚一件事：工具解决的是"登记成本"和"同步时效"，解决不了"没人确认"这个组织问题。我们在第三阶段同时加了一条硬规则：每条跨部门依赖必须有双方负责人确认，未经确认的依赖不计入关键路径覆盖率。这条规则是工具做不到的。

4. 六个月后的结果与两条意外发现

六个月后，几个核心数字的变化是：依赖登记完整率 32%→89%，关键路径依赖覆盖率 46%→93%，平均阻塞时长 41 小时→17 小时，依赖变更通知时延 2.8 天→5.5 小时，跨部门交付准时率 61%→84%，依赖闭环率 24%→78%。

另外有两条发现是意料之外的：

第一，会议上讨论依赖的时间反而减少了。周复盘会从平均 90 分钟压缩到 45 分钟，因为大部分依赖状态在会前就已透明，会议只需要处理 at_risk 项。

第二，任务工期估算开始变准。闭环数据积累三个月后，团队对带依赖任务的工期估算偏差从平均 38% 降到 19%。这条收益最初完全没被列入目标。

六、落地清单：从登记到复盘的完整检查项

下面这份清单是我从多个项目里筛出来的，每条都是可勾选的动作，不是原则。建议不要一次全上，按顺序分三批启用。

1. 依赖登记机制检查项（建议第一批启用）

• 每个跨部门交付物都有一个明确的接收方（可以是部门，也可以是人）
• 每条依赖都记录了关系类型（FS / SS / FF / SF），没有默认全部填 FS
• 每条依赖都写明了"上游完成的判定口径"（提交完成 / 评审完成 / 验收完成）
• 每条 FF 依赖都拆出了"下游可以并行开始的部分"
• 每条依赖至少指定一名依赖确认人，且此人为上游负责人本人
• 每条依赖都记录了计划满足日期和下游预留缓冲天数
• 依赖登记挂在一个已有的强制动作上（如交付物提交、任务创建），不是独立表单
• 单条依赖的填写时间控制在 60 秒以内，字段不超过 10 个

2. 每周依赖复盘会检查项（建议第二批启用）

• 会议前 24 小时已输出依赖状态清单，会议只讨论 at_risk 项
• 会议开场先看依赖健康度五项指标，而不是从任务逐条过
• 所有变更过的依赖都列出影响面任务数，按影响面从大到小讨论
• 每条 at_risk 依赖都有明确的处理动作和责任人，不接受"继续跟进"
• 会议时长控制在 45 分钟以内，超时的依赖转为线下专项
• 会议结束前确认下周需要新增的依赖条数
• 每周固定更新六行依赖周报

3. 依赖变更同步流程检查项（建议第二批启用）

• 定义变更分级标准，例如影响面≤2 个人处理、3-5 个部门内通知、≥6 个升级到项目级
• 影响面 ≥5 个任务的依赖变更，4 小时内通知全部下游负责人
• 变更通知必须附带新的计划日期，不只是"延期了"
• 变更后下游任务的缓冲天数自动重算，缓冲被吃光必须升级
• 每次变更都记录到依赖的 change_log，形成可追溯记录
• 每周统计变更平均通知时延，超过 1 个工作日就要查流程

4. 工具选型的最低要求检查项（建议第三批启用）

• 依赖关系能直接建在任务或交付物上，不需要维护第二张独立的表
• 支持 FS / SS / FF / SF 四种关系类型，且创建时不会默认锁死为 FS
• 依赖日期变更后，下游任务的计划视图自动同步更新
• 能按依赖密度、阻塞时长等口径筛选和排序
• 支持批量导出依赖数据，能自己做二次分析
• 如果涉及内部数据，评估是否支持私有化部署
• 如果在用海外工具，评估迁移路径是否平滑、历史数据能否保留

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

依赖治理没有通用解法，组织规模不同，起点和动作差别很大。下面按规模分四档给建议，你可以直接对号入座。

1. 20 人以下团队：先不要上工具

这个规模下，依赖总数通常不超过 30 条，靠一张共享表格加每周一次对齐就够了。此时引入工具的收益低于学习成本。

你唯一需要做的事是：把"跨部门交付物必须声明谁在等它"变成一条硬规则。就这一条，能解决这个规模下绝大部分依赖问题。

2. 20-50 人、以单部门为主的团队：重点是 FF 和 SS 的识别

这个阶段最常见的问题是只登记 FS。建议做一次专项清点：把最近一个项目的所有跨部门交付物列出来，逐条判断关系类型，看看有多少被写成了 FS 实际上是 SS 或 FF。

我在一个 40 人左右的团队里做过这个清点，结果是有 11 条依赖被错误标注为 FS，其中 7 条实际是 FF。纠正之后，同一个项目的估计工期缩短了 4 天，而且不是因为加快执行，只是不再制造虚假的等待。

3. 50-200 人的多部门团队：需要固定节奏和指标

这个规模是依赖问题最容易失控的区间：部门墙已经形成，但还没有专门的 PMO 来管流程。建议做三件事。

1. 建立依赖登记机制，挂在交付物提交流程上，字段控制在 10 个以内。
2. 固定每周一次的依赖复盘，只看 at_risk 项，控制在 45 分钟。
3. 选定 3-5 个核心指标（推荐依赖密度、阻塞时长、关键路径覆盖率），每月回顾一次趋势。

如果团队已经在用某个研发管理平台，优先把依赖登记和变更通知放到平台上，避免表格和工具两套数据并存。

4. 200 人以上的多部门组织：需要指标体系和工具支撑

这个规模下靠人力同步一定失效，必须依赖工具和指标体系。建议按前面第五部分的案例路径推进：先做登记，再做变更同步，最后做数据分析。

有两个容易被忽略的点：一是要设立依赖确认人制度，否则依赖表会变成单方面声明；二是要把依赖健康度纳入项目评审，否则没有人有动力维护数据质量。

5. 正在从海外工具迁移的团队：先迁数据，再调流程

我见过几次迁移失败，共同点都是"先换工具，再想流程"。正确的顺序是反过来的。

建议先做两件事：把现有的依赖关系完整导出一份，看看实际有多少条、分布在哪些项目；然后再评估哪个平台能在导入后保留这些关系和历史记录。PingCode 这类支持 Jira 平滑迁移的国产平台，在保留历史数据和关系结构上的兼容性相对好一些，迁移时的工作量主要集中在字段映射和流程调整，而不是从头重建。

八、不同情况下的取舍

依赖治理不是"做得越多越好"，下面四组取舍我在项目里都实际纠结过，结论不一定适合所有人，但判断逻辑可以复用。

1. 自建表格 vs 上工具

自建表格的优势是零成本、字段自由、随时可改。适合依赖条数少、变更不频繁、团队规模小的场景。

自建表格的代价是变更通知靠人、数据一致性靠自觉、无法自动关联任务。当依赖条数超过 150 条时，这个代价会急剧上升。

我的判断线是：如果每周发生的依赖变更超过 20 次，就该考虑工具了。因为此时人工通知的漏报率会超过 15%，漏掉的每一条都可能变成一次交付延期。

2. 全量登记 vs 只登记关键依赖

全量登记的好处是数据完整，坏处是成本高、容易半途而废。只登记关键依赖的好处是启动快，坏处是"关键"的判断本身可能出错。

我倾向于一个折中方案：先全量识别、后重点登记。识别阶段把交付物清单全部列出来，不做筛选；登记阶段只录入满足以下任一条件的依赖：跨部门、涉及资源排期、或者下游有 3 个以上任务在等待。

用这套筛选标准，登记量通常能压到识别量的 40% 左右，但覆盖了大部分实际影响交付的依赖。

3. 每日同步 vs 每周复盘

每日同步的好处是暴露快，坏处是成本高、容易疲劳。每周复盘的好处是成本低，坏处是 at_risk 项可能等到下周才被发现。

我的建议是按项目阶段区分：在交付前 2-3 周的高风险期用每日同步，其余阶段用每周复盘。因为 FF 依赖的风险集中在收尾阶段，把频率资源投在那里收益最高。

4. 私有化部署 vs SaaS

这个取舍在中大型组织里几乎一定会遇到。SaaS 的优势是上线快、维护成本低；私有化部署的优势是数据可控、可对接内部系统。

我的判断标准是：如果项目涉及内部数据、客户数据或合规要求，优先选支持私有化部署的方案，因为数据合规问题一旦出现，代价远超工具部署的额外成本。如果项目完全是内部协作、无外部数据，SaaS 的性价比更高。

需要提醒的是，私有化部署不只是"装个软件"，还包括版本升级、备份、账号体系和运维人力。评估时一定要把这部分成本算进去，很多团队只算了软件成本，上线后才发现运维压力被低估了。

结语：依赖管理的终点，是让等待变得可见

写到这里，我想回到最开始的那个判断：跨部门项目延期，绝大多数不是因为有人偷懒，而是因为等待从来没有人看见。每个部门都在做自己的事，做得都不错，但连接他们之间的那条线是隐形的。

FF 关系之所以值得单独拿出来讲，是因为它最能代表这种隐形：下游明明已经开始工作，从数据上看毫无异常，但它其实一直在等一个从未被记录的上游。等到验收前一天才发现，补救的时间已经没有了。

如果你只从这篇文章里带走一个观点，我希望是这个：把依赖当成数据来管，而不是当成沟通来处理。数据可以被登记、被确认、被计算、被追踪；沟通只能提高传递效率，不能创造可见性。

你的下一步动作可以很小，但一定要具体。我建议就从这一件事开始：

1. 打开你当前最让你头疼的那个跨部门项目；
2. 列出本周需要交付的 3 个跨部门交付物；
3. 对每一个交付物，写下"谁在等它"和"它在等谁"；
4. 对写出来的依赖，逐条标注关系类型，特别检查有没有被漏掉的 FF；
5. 把这几条记录下来，下周同一时间再更新一次。

坚持四周，你会得到一份属于自己的第一版依赖数据。它可能很粗糙，但它已经比绝大多数团队的现状好，因为那些团队，连一条依赖都没有登记过。