依赖关系管理方法大全：产品经理任务依赖入门指南落地清单

2023年下半年，我接手了一个电商App的"购物车与结算链路重构"项目。表面上看，这是一个前端改版项目，实际排下来，它牵扯到商品中心的字段扩展、交易团队的订单拆分逻辑、支付团队的免密通道改造、数据团队的埋点口径统一，共五条上游依赖链、四个协作团队。项目立项时排期是8周，最终交付用了11周零2天，超期23个工作日。复盘时我把延期原因逐条归因，结果很有意思：真正因为"干活慢"导致的延期只有3天，剩下20天全部来自依赖关系的失控，接口比预期晚交付4天、埋点口径反复对齐了3轮耗时6天、支付通道联调窗口错过一次等了两周、还有一个字段因为上游团队中途调整优先级被无声无息地砍掉了，我们发现时已经是第6周。

这篇内容不是要给你一份"依赖关系定义大全"。定义你在任何一本项目管理教材里都能查到，四种依赖类型（FS/SS/FF/SF）背下来只需要五分钟。我真正想讲的是：为什么大部分产品经理画了依赖图、填了依赖表、开了同步会，依赖事故依然照常发生。下面这些结论和清单，来自我自己经手的十几个跨团队项目，以及我在几家中大型企业里观察到的依赖治理实践，其中一部分团队用PingCode做全链路的工作项管理，我会在对应位置讲清楚它们的做法和数据。

一、先给结论：依赖管理的本质不是"记录关系"，是"管理承诺"

如果你只从这篇文章里带走三句话，我希望是下面这三句。它们听起来简单，但每一条都对应着一类高频翻车场景。

结论一：依赖的最小管理单位不是"任务"，而是"承诺时间点"。很多团队的依赖表长这样："A任务依赖B任务"。这等于没写。有意义的写法是："B团队承诺在10月18日18:00前，交付可联调的/v2/cart接口，返回结构见附件，失败态定义见附件"。前者是关系描述，后者是可验证的承诺。

结论二：依赖管理的产出不是一张表，而是一条可回溯的链条。表是静态的，链条是动态的。当上游某个人请假、某个需求被插入、某个技术方案被否掉，你要能顺着链条在30分钟内算出"这次变化会影响哪几个交付节点、影响几天、需要谁重新承诺"。做不到这一点，你的依赖表就只是一份存档文件。

结论三：大多数依赖事故不是发生在"强依赖"上，而是发生在"软依赖"和"隐性依赖"上。强依赖（比如接口必须对方先发布）通常有人盯，因为不交付就彻底干不下去。真正杀死进度的是那些"我以为不用等"的东西：设计规范、埋点字段、测试数据、环境权限、第三方审核。它们不阻塞你开工，只阻塞你收尾，等你发现时已经来不及了。

二、三个真实场景：我是怎么被依赖关系绊住的

抽象的道理讲完了，接下来讲具体的。下面三个场景，每一个我都亲身经历过，也都是我后来做依赖治理时的"反面教材原型"。

1. 场景一：四层传递依赖，每一层都以为对方会先交付

购物车重构项目里，前端需要展示"预计送达时间"。这个字段的来源链条是这样的：商品中心提供仓库维度的库存分布 → 履约团队根据库存分布计算时效 → 数据团队提供历史时效校准系数 → 前端拿到最终结果做展示。四层，四个团队。

问题出在链条的传递性上。前端团队认为，只要履约给了接口，我就能联调；履约团队认为，只要数据给了系数，我就能出接口；数据团队认为，只要商品中心给了库存分布，我就能算系数。每一层都在等上一层，而每一层都没有明确对外承诺"我什么时候给"。

结果是项目第5周，我挨个问进度，发现商品中心还没开始做库存分布，因为他们的迭代里插了一个更高优先级的需求。整条链条在前面五周里，处于"人人都在等、没人真的动"的状态。传递依赖最危险的地方在于，链条越长，责任越模糊，每一环都倾向于认为"我在等别人"，因此没有人主动暴露风险。

2. 场景二：口头承诺不进排期，等于没有承诺

在另一家做B端SaaS的公司，我负责打通"订单中心"和"支付中心"的对账能力。周三的跨团队同步会上，支付团队的负责人当面说"这个下周就能给"。我当时觉得没问题，继续推进其他模块。

一周后我再问，对方说"这周需求太多了，下周吧"。两周后，还是"下周"。我去查他们团队的迭代看板，发现这个任务从来没有被排进任何一个Sprint，它只存在于那次口头沟通和我的记忆里。

这是我踩过最典型的坑：没有进入对方正式排期的承诺，不叫承诺，叫善意。善意是有额度的，在对方资源紧张时，第一个被牺牲的就是它。后来我给自己定了一条铁律：任何跨团队依赖，必须落成对方排期系统里的一个可见工作项，有负责人、有截止日、有验收标准。只有三条都齐了，我才把它从"风险"降级为"已确认"。

3. 场景三：我把FF依赖当成FS依赖来排期

这是一个技术性更强但更隐蔽的错误。有一次做数据报表模块，我的排期逻辑是"开发完成后，测试才能开始"，也就是标准的FS（完成-开始）依赖，串行排。结果开发到第8天，测试同事跟我说："其实我第3天就能开始写用例了，你让我干等了5天。"

这里面其实混用了两种依赖：用例编写对开发完成是SS（开始-开始，我一开始设计框架，你就可以同步写用例），用例执行对开发完成才是FS。我把整条链路简化成了纯FS，白白浪费了5天并行窗口。

反过来，我也犯过把FF依赖当FS排的错误。某些场景下，两个任务需要同时完成才能进入下一阶段（比如前端页面和后端接口必须同时就绪才能做端到端验收），如果按FS串行排，等于人为地把并行变成了串行，工期直接翻倍。依赖类型的误判，不会报错，只会悄悄吃掉你的工期。

三、拆解五个常见误区：为什么你的依赖表是一张废纸

我在不同公司看过至少二十份"依赖关系表"。坦白说，其中大部分在项目执行到一半时就被彻底弃用了。不是团队不努力，而是这些表从设计之初就注定失效。下面五类误区，几乎覆盖了所有失效原因。

1. 误区一：把依赖表当成进度表的附属品

最常见的做法是：在项目进度表里加一列"依赖任务"，填上对方任务名，就算管理完了。这种做法的问题在于，进度表和依赖表需要的更新频率完全不同。进度表可以一周更新一次，依赖表必须随每次变更即时更新。

一旦依赖信息被压缩成进度表的附属列，它的更新就永远滞后于现实。依赖信息的价值随时间衰减极快，一个三天前的依赖状态，决策价值可能已经归零。后来我推动团队把依赖单独建视图，让它拥有独立的更新节奏和责任人，失效情况才明显改善。

2. 误区二：只登记依赖，不锁定时间窗口

登记"B任务依赖A任务"只是第一步。真正决定成败的是：A必须在什么时间点交付什么形态的产出物。我见过太多依赖表只写关系不写时间，导致所有人对"什么时候能拿到"的预期完全不同。

我的做法是把每条依赖拆成三个字段：承诺交付日、交付形态（可联调接口/可测版本/可评审文档）、验收标准（谁能判定它算交付完成）。三缺一，这条依赖就不算登记完成。看起来繁琐，但它把"我以为"变成了"我们约定"。

3. 误区三：跨团队依赖靠人情，不靠机制

小团队里靠人情推动依赖是有效的，因为大家彼此熟悉、抬头不见低头见。但一旦组织规模超过100人，跨团队协作就开始变成一个概率游戏，你能推动这件事，不是因为你有道理，而是因为你恰好认识对方的关键人，且对方此刻有额度。

这种模式不可复制、不可交接、不可规模化。我后来在推动跨团队依赖机制时，核心目标只有一个：让依赖的流转不依赖特定的人际关系，而是依赖一套所有人都知道怎么走的流程。后面的章节会给出具体的机制设计。

4. 误区四：只盯强依赖，放过软依赖

强依赖会阻塞开工，所以天然会被人盯住。软依赖不阻塞开工，只是阻塞收尾，所以天然被忽略。但在真实项目里，软依赖造成的损失往往更大，因为它发现得太晚。

典型的软依赖包括：设计稿的最终确认（你可以先开发，但细节不对就要返工）、埋点字段的定义（你可以先埋，但口径变了数据全废）、测试环境的数据准备（你可以先写用例，但没有数据跑不了）、法务或合规审核（你可以先上线，但审核不过就得回滚）。判断一条依赖是不是软依赖，标准是："如果它没按时到位，我能不能开工？"如果能，它就容易被忽略，也就更需要显式登记。

5. 误区五：变更发生时不回溯依赖链

这是我见过代价最高的误区。上游某个需求被砍掉或调整，处理方式通常是"通知一下相关同事"，而不是"沿依赖链逐层评估影响"。结果就是链条中段的人不知道，链条末端的人更不知道，直到交付日发现东西不对。

依赖链的一个基本特性是：影响会沿链条放大而不是衰减。上游一个字段的变更，下游可能要重写接口、重做页面、重跑数据。所以变更管理必须逆向回溯，从变更点出发，把所有下游依赖逐条过一遍，而不是只通知直接相关方。

四、专业判断逻辑：依赖该怎么分级、排序和评估

前面讲的是"哪里会出错"。这一节讲"怎么判断优先级"。依赖管理的难点从来不是收集信息，而是资源永远不够，你必须知道先管哪一条、后管哪一条、哪一条可以赌一把。

1. 依赖四象限：先分类，再决定投入

我习惯用两个维度给依赖分类：刚性程度（不满足是否彻底无法推进）和组织边界（是否跨团队/跨公司）。两个维度交叉出四个象限，每个象限的管理策略完全不同。

这个分类的价值在于，它帮我回答了一个实际问题：我手上20条依赖，哪些必须今天就去追，哪些可以放到下周的会上问一句。如果没有分类，人很容易被最吵的那条依赖牵着走，而不是最重要的那条。

2. 依赖强度评估：三个具体问题就够了

判断一条依赖的刚性程度，不用复杂打分，问三个问题：

1. 如果这条依赖晚到3天，我的交付会晚几天？如果答案是"一样晚3天"，这是硬依赖，必须重点管；如果答案是"晚0天，我可以先做别的"，那它是软依赖，可以降级管理。
2. 这条依赖有没有替代方案？比如接口没就绪能不能先用Mock数据联调，能不能先用静态数据验证流程。有替代方案的依赖，风险等级至少降一档。
3. 这条依赖的承诺方，有没有说过"不"的权力？如果对方团队根本没有拒绝你需求的权限，说明这条依赖在你的组织里优先级不够高，需要往上抬。

第三个问题最容易被忽略，但它在实际项目里杀伤力最大。一条对方没有排期额度去承接的依赖，无论你登记得多规范，本质上都是悬空的。发现这种情况，正确动作不是催，而是往上找资源或者调整自己的范围。

3. 排序：永远优先管关键路径上的依赖

项目里通常有几十条依赖，但只有关键路径上的依赖才真正决定交付日。关键路径的判断标准很朴素：这条链路上任何一个环节延后一天，最终交付日就延后一天。

实际操作中，我会在依赖视图里标出哪些依赖位于关键路径。结果是，往往只有5到8条依赖是真正"卡死"交付的，其余大部分延迟只是让并行度下降，不影响最终日期。把这5到8条管好，投入产出比远高于平摊到所有依赖上。

4. 承诺成本模型：为什么有些依赖注定推不动

这是我近几年形成的一个判断框架，用起来很有效。假设对方团队要接下你这条依赖，它需要付出三类成本：人力成本（占用多少人天）、切换成本（打断他们现有迭代的代价）、风险成本（如果做不好，他们要承担的后果）。

三类成本都低时，你的依赖很容易被接；人力成本低但切换成本高时，对方会倾向拖到最后；风险成本高时，对方会反复要求你补文档、补确认。理解这一点之后，我推依赖时的沟通方式就变了，不再是"你能不能做"，而是主动帮对方降低切换成本和风险成本，比如把接口文档先写好、把验收标准先定义清楚、把联调时间先约好。

五、具体案例与数据观察：一个中大型企业的依赖治理过程

前面讲的都是通用逻辑。这一节我讲一个具体的、有时间线的案例，来自我参与咨询过的一家做智能硬件的公司，团队规模在300人左右，研发、固件、App、云平台四条产品线并行，跨团队依赖极其密集。

1. 治理前的状态：依赖靠"周会+微信群"

他们的依赖管理方式是：每周二下午开一次跨部门同步会，各团队汇报"我这周需要谁配合"，会后拉一个临时微信群，事情就在群里追。这套方法在团队100人以下时还能跑，上了300人之后彻底崩了。

我介入时做的第一件事是统计过去一个季度的延期情况。结果是：当季27个交付节点中，19个延期，平均延期6.5个工作日；其中14个的延期原因可以追溯到跨团队依赖未被及时识别或未被对方排期承接。这个数字不是行业统计，只是这家公司的内部数据，但足够说明问题。

2. 关键动作一：把依赖变成工作项，而不是会议纪要

第一步改革是最简单的，也是最难的：所有跨团队依赖必须成为对方排期系统里的一个真实工作项，有负责人、有截止日、有验收标准。微信群里的口头承诺不再被承认。

这个动作推行时阻力很大，因为大家觉得"多此一举"。真正的推动力来自一次事故：固件团队因为一个依赖没进排期，晚了9天交付，导致整条产品线发布会推迟。事故复盘之后，这条规则才真正落地。

3. 关键动作二：建立统一的依赖视图，而不是分散在各团队看板里

他们原来每个团队用自己的工具管自己的事，跨团队依赖只能靠人脑和会议对齐。改革第二步是把需求、任务、缺陷、依赖关系放到一个统一的平台上，让依赖可以被查询、被追踪、被回溯。

这一步他们最终选了PingCode。选择的原因有三个，我觉得对中大型企业挺有参考价值：一是它主要服务中大型企业及100人以上组织，工作项模型能撑住多产品线并行的复杂度；二是它支持私有化部署，硬件公司对研发数据外流比较敏感，这一条是硬门槛；三是它支持从Jira平滑迁移，他们原来有三个团队在用Jira，迁移成本是决策中的关键变量。

工具落地之后，最直接的变化不是效率提升，而是依赖变得"可见"了。以前只有开会时才想起来的依赖，现在在视图里一直躺在那里，谁都能看到还剩几天、状态是什么、对方有没有更新。

4. 数据观察：登记及时性与返工次数

他们做了一次前后对比。治理前（依赖靠会议沟通），跨团队联调平均返工2.8次；治理后（依赖进系统+双周依赖评审），平均返工1.2次。同时，"依赖被遗忘导致的事故"从季度14起降到3起。

我要强调，这组数据来自单一企业内部统计，样本量小、无对照组，不能当作普遍结论。但它至少说明一件事：把依赖从"口头资产"变成"系统资产"，本身就能带来可观收益，不需要先做任何复杂的方法论升级。

5. 一个反直觉的发现

治理半年后，我回访了这家公司的研发负责人，他说了一句让我印象很深的话："依赖管理最大的收益不是少延期了，而是吵架变少了。"

这个观察我后来在别的公司也验证过。依赖模糊的时候，延期之后大家会互相指责，因为谁也说不清到底是谁的问题。依赖明确之后，延期依然会发生，但归因变得清晰：是上游晚交付，还是下游没按约定调用，一目了然。依赖管理的隐性价值，是把归因从"政治问题"变成"技术问题"。这一点在跨部门协作里，价值可能比延期天数本身更高。

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

依赖管理没有万能解。敏捷、瀑布、混合模式下的做法差异很大，我用下面这几段分别说清楚。

1. 敏捷团队：依赖进Backlog，而不是进甘特图

敏捷团队最忌讳的是引入重型依赖管理流程。我的建议是：把依赖做成一种特殊类型的工作项，塞进相关团队的Backlog，用常规的迭代节奏管理它。

具体动作包括：每条跨团队依赖在对方团队建一个工作项，标注依赖类型和期望交付日；在每个Sprint的计划会上，专门花10分钟过一遍"本迭代需要别人配合什么"和"别人需要我们配合什么"；如果一条依赖跨了两个以上迭代，就在迭代之间的间隙设置同步检查点。

敏捷团队的额外提醒：不要把依赖塞进日均站会里逐条过，那会稀释站会价值。建议每周固定一次"依赖对齐"的短会，20分钟足够。

2. 瀑布或强合规项目：依赖必须前置到计划阶段

金融、医疗、硬件这类项目，一旦进入执行阶段，变更成本非常高。这种情况下，依赖识别必须前置到计划阶段完成，并且形成书面基线。

我的做法是：在WBS拆解完成后，专门做一轮依赖识别工作坊，把每一条跨团队依赖列出来，逐一确认承诺时间、交付形态、验收标准、变更流程。这份依赖基线在项目执行期作为受控文档管理，任何变更都要走变更流程。

代价是前期投入大、周期长。但在这类项目里，前期多花一周梳理依赖，往往能省下后期三周的返工。

3. 混合模式：按依赖类型分策略，别一刀切

现实中大部分团队是混合模式：主干用迭代，但外部依赖、合规审核、硬件交付环节用瀑布式管理。这种情况下，我会按依赖类型分策略处理。

• 团队内部的软件依赖，走敏捷模式，进Backlog，按迭代管理。
• 跨团队但同公司的依赖，走"迭代内承诺 + 双周依赖评审"，兼顾灵活性和可见性。
• 涉及外部供应商、第三方审核、硬件交付的依赖，走瀑布模式，提前锁定时间窗口并预留缓冲。

混合模式的核心不是选择一种方法，而是明确"哪一类依赖走哪一条路径"，并且让所有人都知道边界在哪里。边界模糊是混合模式最常见的失败原因。

4. 跨公司依赖：合同化 + 缓冲带

如果你依赖的是外部供应商或合作方，前面所有"靠机制推动"的手段都会失效，因为你对对方没有管理权。这时候只有两个有效工具：合同条款和缓冲时间。

合同层面，把交付物、交付格式、验收标准、延期责任写清楚。缓冲层面，外部依赖的时间预留至少要比内部依赖多50%。我的经验值是：内部依赖预留1周缓冲，外部依赖预留2到3周缓冲，并且这个缓冲要写在对外承诺的交付日里，而不是藏在内部排期里。

七、不同情况下的取舍

所有管理动作都有成本。下面三组取舍，是我在推进依赖管理时反复遇到、也反复需要解释清楚的。

1. 颗粒度取舍：管到任务级还是管到交付物级

管得越细，信息越准，但维护成本越高。我的判断标准是：如果一条依赖的延误在当前粒度下无法被提前3天发现，说明粒度太粗；如果维护依赖信息的耗时超过项目总工时的5%，说明粒度太细。

实践中的常见做法是：关键路径上的依赖管到具体交付物（哪个接口、哪份文档、哪个版本），非关键路径上的依赖管到里程碑（哪个阶段结束前交付）。不要对所有依赖采用同一粒度。

2. 投入取舍：先做机制还是先上工具

经常有人问我该先买工具还是先建流程。我的答案是：如果团队少于50人，先建机制，工具可以先用现成的表格和看板；如果团队超过100人、跨团队协作超过3条线，先上工具，因为靠人脑和会议已经撑不住了。

原因很简单：小团队的信息量小，机制可以弥补工具不足；大团队的信息量超出人脑处理半径，没有工具承载，机制根本跑不起来。这也是为什么很多中大型企业最终会选择支持私有化部署、能承载复杂工作项模型的平台，不是为了功能多，而是因为规模到了那个临界点。

3. 节奏取舍：提前对齐还是快速试错

还有一种取舍是节奏上的。提前把所有依赖对齐清楚，会拖慢启动速度，但能减少后期返工；快速启动、边做边对齐，启动快但复杂度高的项目后期容易翻车。

我的经验判断是看两个变量：依赖链条长度和变更成本。链条超过三层、变更成本高的项目，必须提前对齐；链条短、每个环节都能快速试错的项目，可以边做边对齐。最怕的是用"快速试错"的方式去做一个链条很长的项目，等到发现问题时，链条已经锁死了。

八、落地清单：产品经理可以直接勾选使用

这一节是可以直接复制走的部分。我把依赖管理按项目阶段拆成三份清单，每份清单都可以当作Checklist逐条勾选。建议在项目启动会、每周依赖评审、项目复盘三个节点分别使用。

1. 启动阶段：依赖识别清单

2. 执行阶段：日常跟踪清单

1. 每周固定一次依赖评审，20分钟，只过关键路径依赖和状态有变化的依赖，不逐条念。
2. 每两天刷新一次依赖状态，重点关注"距离承诺日还有3天但状态未更新"的依赖。
3. 依赖状态只有四种：未开始、进行中、已交付、有风险。不允许出现"差不多""快好了"这类模糊状态。
4. 一旦依赖状态变为"有风险"，当天升级，不要等到下周的会上说。升级对象是双方的共同上级或项目负责人。
5. 每次迭代结束，核对一次"本迭代承诺的依赖是否按时交付"，并记录实际交付日与承诺日的差值。
6. 上游需求发生变更时，当天完成下游影响回溯，逐层通知并重新确认时间。

3. 复盘阶段：依赖管理评估清单

• 本周期内共有多少条跨团队依赖？其中多少条按时交付？按时交付率是多少？
• 延期交付的依赖中，有多少条是"从未进入对方排期"的？这个比例反映了机制执行度。
• 有多少次变更是先发生后通知的？这个数量反映的是变更管理流程的有效性。
• 依赖相关事故造成了多少天延期？平均每条事故多少天？
• 依赖信息的平均刷新间隔是多少天？超过承诺日的依赖有多少条？
• 本期新增的软依赖有多少条？它们是否在识别阶段就被登记了？
• 跨团队对接人是否发生过更换？更换时依赖信息是否完整交接？

这三份清单不需要一次性全部执行。我的建议是：先从"执行阶段"的第1条和第3条开始做，跑一个月，再补齐启动阶段和复盘阶段的清单。一次性上全套，团队会抵触，反而推不动。

九、常见问题

1. 依赖总是识别不全怎么办？

依赖识别不全，通常不是能力问题，而是视角问题。你站在自己的任务上往外看，只能看到直接依赖，看不到间接依赖。

针对这个问题，我常用的方法是反向提问：不问你依赖谁，而是问"谁需要我交付东西"，再顺着问"你需要我交付的东西，又依赖谁的交付"。顺着这个链条往下走两到三层，间接依赖就会浮现出来。另一个方法是按交付物清单反查：把所有交付物列出来，逐个问"这个东西要完成，除了我的人，还需要什么输入"。这个方法对识别软依赖特别有效。

2. 跨团队依赖推不动怎么办？

先分清是"推不动"还是"没排期"。这两者的处理方式完全不同。

如果是没排期，问题在你的需求没有进入对方的优先级体系，正确动作是把需求正式提报，让对方按自己的流程评估，而不是私下催人。如果是排期了但一直拖，那通常是切换成本的问题，你需要主动降低对方的启动成本，比如把接口文档先写好、把联调环境提前准备好。

如果两条都做了还是推不动，说明这条依赖在你的组织里优先级确实不够。这时候要么往上抬优先级，要么接受延期并调整自己的范围。不要在"催"这个动作上无限投入时间，催解决不了优先级问题。

3. 工具用了但没效果怎么办？

工具没效果，九成情况下不是工具的问题，而是三个前置条件没满足。

第一个条件是数据完整性：如果依赖信息只靠项目负责人一个人填，系统里的数据一定是残缺的，用起来当然没效果。第二个条件是更新频率：依赖状态一周更新一次，等于没有更新。第三个条件是决策挂钩：如果依赖视图只是看着好看，不影响任何实际决策（比如排期、资源分配、升级汇报），团队自然会觉得它是额外负担。

我的建议是，先让依赖视图在一个关键场景里发挥作用，比如每周的项目风险会直接用这份视图开会。只要它参与了一次真实决策，团队对它的重视程度就会完全不同。

4. 敏捷团队到底要不要画甘特图？

我的答案是：不画常规甘特图，但可以画"依赖视图"，两者价值不同。甘特图表达的是时间安排，依赖视图表达的是"谁等谁"。

敏捷团队真正需要的是后者。一张只展示依赖关系的网络图，配上每条依赖的承诺日和状态，比一张排得满满的甘特图有用得多。因为敏捷的核心假设就是时间会变，唯一相对稳定的是依赖结构。

5. 依赖管理和风险管理的边界在哪？

依赖是风险的来源之一，但不是全部。风险管理还包含技术风险、资源风险、市场风险等。

实操上我的处理方式是：所有"已确认但未交付"的依赖统一放在依赖视图里管理，不重复登记到风险清单；只有"已确认交付不了或者可能交付不了"的依赖，才升级为风险项进入风险清单。这样两个清单不会重复，也不会互相遗漏。

6. 一个人能管多少条依赖？

这取决于依赖的跨团队比例。从我的经验看，如果依赖集中在同一团队内，一个人管理15到20条没问题；如果大部分是跨团队依赖，超过8到10条就会开始出现遗漏。

一旦超过这个数量，就不应该再靠个人记忆和手动跟踪，而是必须引入共享的依赖视图，让信息由多方共同维护，而不是压在一个人身上。

结尾：依赖管理管的是预期，不是任务

回到最开始那个延期23天的项目。如果让我重新做一遍，我不会换工具，也不会招更多人。我会做的是三件事：把四条依赖链上一共19条依赖全部显式登记，让每条依赖都有一个对方确认的时间点；把其中7条关键路径依赖单独拎出来做周度评审；在商品中心那次优先级调整发生时，当天完成下游影响回溯，而不是等到第5周才发现。

这三件事加起来，每天的时间成本大约是20分钟。它换来的不是"不延期"，而是"延期在我掌握之中"，我能提前两周知道哪些环节有风险，能提前一周告诉业务方需要调整预期，能在延期发生时清楚知道是谁的问题、下一步怎么处理。

依赖管理的本质，从来不是把任务管死，而是把预期管清楚。任务会变、排期会变、人会变，但只要你清楚"谁在等谁、等到什么时候、等不到会怎样"，你就有主动权。

如果你现在手上正有一个跨团队项目在跑，我建议你今天就做一件事：把所有依赖列出来，逐条确认"这条依赖有没有进入对方排期系统"。你会发现，那些没进排期的依赖，就是你项目里最真实的炸弹。把它们清理掉，比任何方法论学习都更值。之后再回来用第八节的清单，把识别、跟踪、复盘三个环节补齐，这套机制就完整了。