依赖冲突怎么做？项目成员实操方法：任务依赖从0到1

去年第三季度，我带的 8 人小组接了一个看起来很小的需求：给后台加一个数据导出功能。排期 5 天，实际交付用了 16 天。复盘时我发现，真正花在写代码上的时间只有 2 天，剩下的 14 天全部消耗在"等"，等接口字段确认、等测试环境释放、等上游的数据清洗任务跑完、等另一个组的同学把手上的紧急故障处理完。那 14 天里，项目没有任何一个人偷懒，所有人都在积极沟通，但项目就是不动。这次延期让我彻底改变了对"任务依赖"的理解：依赖冲突从来不是执行力问题，它是一个排序问题、一个缓冲问题、一个可见性问题。

这篇文章就是我们团队从 0 到 1 建立任务依赖管理方法的完整过程，包括踩过的坑、试过的模板、以及后来在一个 120 人研发组织里验证过的数据。

一、先把结论摆出来：依赖冲突不是靠"催"能解决的

如果你现在正在经历依赖冲突，最想做的事情大概是去催那个卡住你的人。但我用一年半的时间验证了一件事：催只能压缩一次等待，不能解决依赖冲突本身。催完之后，下一个依赖节点还会以同样的方式卡住你。

真正的解法由三个动作组成：排序（搞清楚谁必须先动）、缓冲（在交接点上留出可吸收波动的时间）、可见性（让依赖关系不再藏在某个人脑子里）。这三件事都不需要额外的管理权限，任何一个项目成员都能在自己负责的范围内启动。

1. 依赖冲突的三种形态，处理成本差 3 倍以上

我把团队过去 18 个月记录在案的 214 次依赖阻塞做了分类，发现它们并不是同一种东西。第一种是真依赖，也就是技术或业务上客观存在的先后顺序，比如后端接口没定义完，前端就真的写不了。第二种是假依赖，顺序是人为设定的，比如"设计稿必须全部定稿，前端才能开工"，实际上前端完全可以先把框架搭起来。第三种是隐性依赖，双方都不知道它存在，直到撞上了才发现，比如两个任务同时用一套测试数据，互相覆盖。

三者的处理成本差距非常大。真依赖你能做的是压缩交接周期，假依赖你能做的是直接取消顺序，而隐性依赖你必须先让它浮出水面才能处理。我们统计下来，隐性依赖的单次平均等待时长是假依赖的 2.3 倍，因为它被发现的时候，通常已经晚了。

2. 一个可以直接用来排优先级的判断公式

在资源有限的情况下，你不可能同时处理所有依赖冲突。我给团队用的排序公式是这样的：依赖冲突成本 = 平均等待时长 × 受影响下游任务数 × 返工概率。这个公式不需要精确计算，只需要相对比较。

按照刚才那张图的数据代入，隐性依赖的成本指数是 4.2 × 5.6 × 0.34 ≈ 7.99，真依赖是 2.5 × 3.1 × 0.18 ≈ 1.40，假依赖是 1.8 × 1.4 × 0.06 ≈ 0.15。也就是说，解决一个隐性依赖的收益，相当于解决 5.7 个真依赖，或者 53 个假依赖。

这个结论指导了我们团队的所有后续动作：每周花 30 分钟做一次"隐性依赖排查"，优先级高于任何一次排期调整。

3. 从 0 到 1 的四个动作，顺序不能颠倒

很多团队一上来就想上工具、建看板、定流程，结果三天就放弃了。我们的经验是，动作顺序必须遵循认知规律：

1. 画图：先把当前迭代所有任务画成一张依赖关系图，只画箭头，先不标类型。这一步解决的问题是"可见性"。
2. 定性：给每条箭头标注是真依赖、假依赖还是疑似隐性依赖。这一步解决的问题是"排序"。
3. 定缓冲：在真依赖的交接点上设置缓冲时间，在疑似隐性依赖上加一次对齐动作。这一步解决的问题是"抗波动"。
4. 定同步节奏：把依赖状态的同步嵌入每日站会，用固定话术，不用额外开会。这一步解决的问题是"可持续"。

顺序颠倒会怎样？先上工具再画图，你会得到一张漂亮的看板，但每条线背后的依赖关系依然是错的；先定同步节奏再定性，你会每天花 15 分钟同步一堆本来不该存在的依赖。

二、真实场景：14 天等待是怎么一层层堆出来的

回到开头那个导出功能的需求。我把 16 天的实际耗时拆开看，才发现延误不是一次性发生的，而是被四层依赖一层层放大出来的。

1. 一次 16 天交付的完整时间归因

第 1 天到第 2 天，团队在等产品确认导出字段的业务口径，这是信息依赖。第 3 天到第 5 天，前端在等后端定义接口结构，这是技术依赖。第 6 天到第 12 天，测试环境被另一个更高优先级的项目占用，这是资源依赖，而且这 7 天里，团队其实是可以做单元测试和本地验证的，但因为排期上写着"等待测试环境"，大家默认就停下来了。第 13 天到第 16 天，发现导出的大数据量场景没有走异步，需要重构，这是隐性依赖，因为数据量级的假设从来没有被明确写出来过。

你看，真正"被迫等待"的只有信息依赖和技术依赖那 5 天，剩下 9 天里有 7 天是资源依赖造成的可规避损失，2 天是隐性依赖造成的返工。这就是为什么我说依赖冲突的核心是排序，而不是催，如果重排一次，第 6 天到第 12 天完全可以用来做后端逻辑和本地验证。

2. 依赖的四个来源，隐蔽程度完全不同

在后续的项目里，我逐渐总结出依赖其实来自四个地方，它们的隐蔽程度、发生频率和修复成本差异非常大。搞清楚来源，比记住"FS、SS、FF、SF"这四种依赖类型更有用，后者是理论分类，前者才是你每天要面对的东西。

• 技术依赖：接口、数据结构、公共组件、环境。特征是显性、容易识别，但顺序客观存在，无法取消。
• 资源依赖：同一个人、同一台机器、同一套测试环境被多个任务占用。特征是高发，但很多人不把它当成"依赖"看。
• 信息依赖：等一个决策、等一次确认、等一份文档。特征是极易被忽视，因为它在任务列表上看起来"没什么可做的"。
• 审批依赖：等签字、等合规、等外部供应商。特征是低频但一旦发生就很难压缩。

如果只用一句话概括我的判断：技术依赖管顺序，资源依赖管排队，信息依赖管决策权归属，审批依赖管提前量。四类依赖需要的动作完全不同，混在一起处理必然低效。

3. 组内依赖反而比跨部门依赖更容易被忽略

一个反常识的观察：我们团队真正造成延期的依赖，70% 以上来自组内，而不是跨部门。跨部门依赖因为"隔着一层"，大家会主动去确认、去约时间、去发消息；组内依赖因为"抬头就能看见"，反而默认对方知道，默认不会被耽误。

我见过最典型的一次：两个开发同坐一排，A 需要 B 提供一个工具方法，B 需要 A 确认一个字段名，两个人各自以为对方会先动，卡了整整两天，最后还是站会上才发现的。跨部门依赖有天然的仪式感，组内依赖没有，这就是问题所在。

三、拆解五个误区：我踩过的坑，你大概率也在踩

在这一年半里，我把团队做错的判断记录下来，发现错误高度集中在五个误区上。每个误区都对应一段可量化的延期时间，加起来占了我们总延期的 60% 以上。

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

这是最普遍也最致命的误区。沟通问题是可以靠多说话解决的，依赖冲突不行。你和对方沟通十次，如果排期没变、优先级没调、缓冲没加，该等还是等。

我的判断标准很简单：如果一个依赖问题，开完会之后没有任何任务顺序或时间安排发生变化，那这次沟通就是无效的。它只是一次情绪安抚。判断一次依赖处理是否有效，看的是"依赖图有没有变"，而不是"大家有没有达成共识"。

2. 误区二：认为所有依赖都应该被解耦

"解耦"是个听起来很高级的词，但在项目管理语境里被滥用了。有些依赖拆开之后，沟通成本比等待成本还高。

我们曾经强行把一个大模块拆成三个独立小组并行开发，结果三个小组每天要花 1 小时对齐接口假设，一周下来 15 小时的沟通成本，换来的只是省掉了 2 天的串行等待。解耦的收益必须和沟通成本做对比，而不是无脑解耦。

我的经验阈值是：只有当串行等待超过 3 个工作日，或者该依赖在一个迭代内会重复阻塞 3 次以上时，才值得花精力去解耦。低于这个阈值，加一段缓冲更划算。

3. 误区三：缓冲时间平均分配到每个任务上

很多团队的做法是给每个任务统一加 20% 的缓冲，看起来很科学，实际上是浪费。因为依赖冲突不是均匀分布的，它高度集中在交接点上。

正确做法是把缓冲集中放在依赖交接点，而不是平摊到整个工期。一个 10 天工期的任务，如果它不依赖任何人也不被任何人依赖，它的缓冲可以很小；如果它处在关键路径的交接位置，缓冲就要给足。我们团队的实测数据是，把缓冲从"平摊"改成"集中在交接点"之后，同样的总缓冲天数，迭代准时率从 68% 提到了 84%。

4. 误区四：站会只问"昨天做了什么、今天做什么、有什么阻塞"

标准三问中的"有什么阻塞"，几乎永远得不到真实答案。因为大多数阻塞不是"我卡住了"，而是"我在等，但还能干点别的"，这种状态不太会被主动报告。

我改成第四问："你今天需要谁先完成什么？"这个问题把一个模糊的"阻塞"变成了一个具体的指向。它有两个作用，一是暴露隐性依赖，二是让被指向的人当场知道自己的优先级。

实测下来，加入这个问题后，我们站会上暴露出来的依赖条目从平均每场 0.7 个上升到 2.9 个，翻了 4 倍。这些依赖如果不在站会上暴露，大概率会在两三天后以"延期"的形式出现。

5. 误区五：依赖关系图只画一次

依赖关系是动态的，代码一变、优先级一调、人员一换，依赖就变了。只画一次的依赖图，价值衰减得非常快，大概三天之后就完全失真。

我们的做法是把依赖图变成每日更新的东西，而不是一份"迭代初期产出物"。维护成本其实很低：每天站会后，如果有依赖状态变化，就改一下那张表，两个人 3 分钟以内能完成。

四、专业判断逻辑：我怎么决定一个依赖要不要动

前面讲的是认知和误区，这一节讲判断。当你手上同时有三四个依赖冲突的时候，怎么决定先处理哪个、哪个直接放着不管？我用的是三步判断法，判断顺序不能颠倒。

1. 第一步：判断依赖强度

依赖强度决定了你对它的可控程度。我用三个问题快速分类：

• 能不能并行？如果下游任务可以先做 80%，剩下的 20% 等上游，那这是弱依赖，你需要的是拆任务，不是等。
• 能不能替代？上游如果换成另一个人、另一个方案、另一个数据源，能不能完成？能替代的叫可替代依赖，成本是切换成本，不是等待成本。
• 时间窗口有多宽？上游早一天晚一天，对整体结果的影响是线性的还是非线性的？影响非线性的才是真正需要死守的。

三个问题问完，依赖就能落到四象限里。不可替代 + 时间窗口窄 = 强依赖，必须重点保障；可替代 + 时间窗口宽 = 弱依赖，直接排在后面就行。

2. 第二步：找出关键路径上的依赖

不是所有强依赖都值得你花时间。真正决定项目整体工期的，只有关键路径上的那条依赖链。关键路径之外的任务，晚一天不影响交付；关键路径上的任务，晚一天就是整体晚一天。

完整的关键路径法（CPM）需要正推、逆推、浮动时间计算，听起来很重，但对于一个 20 个任务以内的迭代，你可以用口算简化版：

1. 把所有任务和工期列出来，只保留有依赖关系的任务。
2. 从最早能开始的任务出发，逐个累加工期，算出每个任务的最早完成时间。
3. 完成时间最晚的那条链路，就是关键路径。
4. 关键路径上每一个交接点，都是必须设缓冲的地方。

我用一段简单的代码演示这个计算过程，在实际复盘时挺好用的：

# 简化版关键路径计算（正推法）
tasks = {

"T1_需求确认":   {"duration": 2, "deps": []},

"T2_接口设计":   {"duration": 2, "deps": ["T1_需求确认"]},

"T3_后端开发":   {"duration": 5, "deps": ["T2_接口设计"]},

"T4_前端框架":   {"duration": 2, "deps": ["T2_接口设计"]},

"T5_前端联调":   {"duration": 3, "deps": ["T3_后端开发", "T4_前端框架"]},

"T6_测试":       {"duration": 3, "deps": ["T5_前端联调"]},

}

earliest_finish = {}

def calc(name):

if name in earliest_finish:

return earliest_finish[name]

t = tasks[name]

start = max([calc(d) for d in t["deps"]], default=0)

earliest_finish[name] = start + t["duration"]

return earliest_finish[name]

for name in tasks:

calc(name)

print(sorted(earliest_finish.items(), key=lambda x: x[1], reverse=True))

跑出来的结果里，完成时间最晚的那条链就是关键路径。这个例子里，T1 到 T2 到 T3 到 T5 到 T6 是 15 天，而 T1 到 T2 到 T4 到 T5 到 T6 是 12 天。也就是说，T3 后端开发所在的链路是关键路径，T3 每延一天，整体就延一天，而 T4 有 3 天的浮动空间。T3 的交接点必须设缓冲，T4 可以不用。

3. 第三步：判断用什么缓冲

缓冲有三种类型，对应三种不同的风险，位置和作用完全不同。很多团队只用了第一种，导致缓冲设了但没用。

• 交接缓冲：放在两个任务的交接点上，吸收上游交付延迟。用于真依赖、强依赖。
• 资源缓冲：放在关键资源被占用之前，用来提前锁定档期或准备替代资源。用于资源依赖。
• 决策缓冲：放在需要决策的节点之前，用来推动决策提前发生。用于信息依赖。

我给出的经验值是：交接缓冲建议设为被依赖任务工期的 15%-25%，资源缓冲建议按关键资源每周 0.5 天的口径预留，决策缓冲建议至少提前 2 个工作日发起。这三个数字都是我们团队在交付型项目上跑出来的经验值，不同项目类型需要调整。

比如迭代型项目，因为周期短、反馈快，交接缓冲可以压到 10% 左右；如果是探索型项目，需求本身就不确定，交接缓冲反而要给到 30% 以上，因为上游交付的质量波动更大。

五、案例与数据观察：一个 120 人研发组织的依赖治理过程

前面讲的方法都是在我带的 8 人小组里磨出来的。真正让我确认这套方法有普适性的，是后来在一个 120 人规模的研发组织里做的一次依赖治理。这个组织有 9 个研发小组，横跨 4 条产品线，迭代节奏是两周一个 Sprint，流转的项目管理平台是 PingCode。

1. 治理前的状态：依赖冲突是"不可见"的

治理之前，这个组织的状态和我那个 8 人小组不太一样。小组的问题是依赖没人管，而 120 人组织的问题是依赖太多了，多到没人看得清。9 个小组之间互相有依赖，一个需求可能要跨 3 个小组才能交付，但依赖关系只存在于每个小组自己的排期表里，没有全局视图。

结果就是每个小组都觉得自己排得挺满，项目整体却一直在延期。我们统计了治理前 4 个迭代的数据：迭代准时率 63%，跨团队阻塞工单平均每个迭代 27 个，依赖相关等待平均 4.6 天/次。

PingCode 在这个阶段的作用是先让依赖"看得见"。因为它支持需求、任务、缺陷、测试的全链路关联，跨小组的依赖关系可以在同一个需求视图里直接呈现出来，而不是分散在 9 张 Excel 里。这一步的价值不是"管理"，而是"暴露"，很多依赖冲突之所以处理不了，是因为压根没人知道它存在。

2. 干预动作：三个动作 + 一个工具承载

我们在 6 周内做了三个动作，动作本身都不复杂，难的是坚持。

1. 建立跨小组依赖登记机制：任何跨小组的依赖，必须在依赖方的迭代看板上登记一条显性记录，标注依赖类型、期望交付日、缓冲天数、责任人。这条记录在设计上就是"可被搜索"的，避免只存在于聊天记录里。
2. 每周一次 30 分钟的跨组依赖对齐会：只讨论登记在册的依赖项，不讨论进度细节，每人发言不超过 2 分钟。会议产出的唯一结果就是更新依赖状态和缓冲天数。
3. 把关键路径的判定做成自动化视图：同一需求下的任务链路自动计算最早完成时间，路径最长的直接标红，避免每次靠人工判断。

工具层面，这个组织用的是 PingCode。它本身是中大型企业研发项目管理平台，主要服务 100 人以上的组织，所以 9 个小组的权限隔离、跨项目视图这些能力是现成的，不需要自己搭。它还支持私有化部署，对这个组织来说这是硬需求，因为涉及未公开发布的产品数据，不能放在公有云上。

另外他们之前有一部分历史项目跑在海外的项目管理工具上，迁移的时候用 PingCode 的 Jira 平滑迁移能力把历史数据和自定义字段一并搬了过来，没有出现常见的"迁移后字段丢失、看板重建"问题。这也是很多团队在考虑国产替代时最担心的一环：迁移的动作本身不难，难的是迁移之后团队的工作习惯不用重学一遍。

3. 数据观察：6 周后的指标变化

治理后我们对比了下一个 4 个迭代的数据。需要说明的是，这段时间内团队规模、产品范围和迭代长度都没有变化，所以指标变化基本可以归因到依赖治理本身。

这里有一个容易被误读的点：依赖平均等待时长从 4.6 天降到 1.9 天，并不是因为依赖变少了，而是因为依赖被提前暴露了。治理前很多依赖是在最后两天才爆发的，等待时间看起来长；治理后依赖在迭代第一天就被登记，可以提前处理，实际等待就被压缩了。

同理，跨团队阻塞工单从 27 个降到 9 个，也不是问题凭空消失，而是大部分依赖在变成"阻塞工单"之前就已经解决了。真正的改善在于问题解决的时机前移了。

4. 一个容易被忽略的副作用：依赖登记反而增加了短期工作量

我必须诚实地讲一个负面观察：治理的第一周，团队的抱怨明显增加了。因为登记依赖这件事本身要花时间，一个迭代下来大约每人多花 20 分钟。而且登记之后，原本"假装不存在"的依赖被迫摆到台面上，需要当场处理，短期看起来更累了。

这个阶段大概持续了 2 周。第 3 周开始，抱怨消失，因为大家发现登记之后不用再反复被追问"你什么时候能好"。依赖登记真正省下的，是那种"每隔两小时被问一次进度"的沟通成本。

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

这套方法不是所有人都要一步到位。我按团队规模和项目类型分成几种情况，给出不同的起步动作。原则是：先从成本最低、收益最明显的那一个动作开始，跑通之后再叠加。

1. 3-5 人小组：只做一件事，把依赖写在墙上

这个规模不需要任何工具，也不需要任何流程文档。你只需要在物理白板或共享文档上画一张依赖图，每周更新两次。

具体动作是：每人把自己这一周要做的事写便利贴贴在墙上，然后用箭头连出"谁等谁"。连完之后，重点看两类箭头：一是被三条以上箭头指向的人（这是瓶颈资源），二是箭头指向不明确的地方（这是隐性依赖）。

3-5 人小组最大的风险是依赖全在脑海里，不在纸上。人少的时候大家觉得"我抬头就能问"，但实际情况是两个人都以为对方知道，卡了两天。把依赖写在墙上是成本最低的解法。

2. 6-15 人单团队：建立依赖登记 + 站会第四问

这个规模靠白板开始吃力了，因为依赖关系超过 15 条之后人脑很难记住。建议做两件事：

• 建立一个依赖登记表，字段包括：任务、依赖对象、依赖类型（技术/资源/信息/审批）、期望交付日、缓冲天数、责任人。
• 每日站会加第四问："你今天需要谁先完成什么？"

这两件事加起来，每天增加的时间成本大约 5 分钟，但能把隐性依赖的发现时间从平均 3 天提前到当天。

3. 15 人以上或多团队：需要工具承载依赖关系

到这个规模，纯手工的依赖登记会迅速失真，因为跨团队依赖的状态变化太快，靠人肉同步一定滞后。这时候需要项目管理平台来承载。选型时我建议优先看三件事：能不能跨项目视图看依赖、能不能给依赖设置状态和提醒、能不能做权限隔离。

像 PingCode 这类面向中大型企业、服务 100 人以上组织的项目管理平台，在这三个维度上是有优势的：跨项目视图可以直接把 9 个小组的依赖关系聚到一张图上，权限隔离能满足不同产品线数据不互相可见的要求，而私有化部署能力则解决了数据合规问题。如果团队之前用的是 Jira，也可以考虑它的 Jira 平滑迁移能力，把历史数据和字段配置带过来，降低切换成本。

但我必须强调：工具只能承载依赖关系，不能替你判断依赖强度。我见过装了很贵的工具但依赖管理依然混乱的团队，原因是他们把工具当成了解决方案，而不是当成一个记录载体。先有判断逻辑，再选工具。

4. 敏捷迭代 vs 交付型项目：动作重心不同

同样是依赖管理，敏捷迭代和交付型项目的重心完全不一样。

敏捷迭代的周期短，通常是两周，依赖链也短。这时候重点是"高频暴露"，靠每日同步和迭代计划会来兜底，缓冲可以给得很薄，因为迭代结束就是一次自然的重置点。

交付型项目周期长、依赖链深，一旦某个环节延误，会在后续链条上层层放大。这时候重点是"提前锁定关键路径"，缓冲要给足，而且要把缓冲集中在交接点，而不是平摊。

我自己的经验是：迭代型项目靠节奏，交付型项目靠缓冲。用错方法就会出现两种典型症状，迭代型项目缓冲给太多，团队变得松散；交付型项目靠站会兜底，结果每次都在最后一周崩盘。

七、不同情况下的取舍

依赖管理本质上是一系列取舍，没有全都对的选择。我把最常遇到的四个取舍列出来，给出我自己的判断倾向。这些判断都带前提，不是绝对规则。

1. 解耦 vs 保留依赖：什么时候该忍

解耦的收益是减少等待，成本是增加沟通。我的取舍标准是看依赖的重复次数。

如果这个依赖只是一次性的，比如某个接口只需要对接一次，那加缓冲更划算，不要去动架构。如果这个依赖在一个迭代内会重复阻塞 3 次以上，那就是耦合过紧了，值得花时间解耦。

还有一个隐含条件：解耦的收益往往在第二个迭代才显现，第一个迭代因为要额外对齐接口，反而会更慢。如果团队连一个迭代的耐心都没有，就不要启动解耦。

2. 加缓冲 vs 加人：什么时候加人无用

这是最经典的取舍。我的判断依据还是关键路径：如果延误发生在关键路径上，加人能加速；如果延误发生在关键路径之外，加人只是增加沟通成本。

更具体一点：如果任务本身是可拆分的（比如一个模块的多个独立页面），加人能缩短工期；如果任务是不可拆分的（比如一个人负责的核心算法），加人反而会因为沟通而拖慢。我见过最典型的反面案例是在一个串行依赖链上加了两个人，结果工期从 10 天变成了 13 天。

3. 工具投入 vs 手工维护：什么时候不值得上工具

工具的价值在于降低跨团队的同步成本。如果团队在 10 人以内、依赖关系不超过 20 条，手工维护一张表完全够用，上工具反而会增加学习成本和维护负担。

15 人以上、多团队协作的时候，手工维护会迅速失效，因为依赖状态变化的速度超过了人工同步的速度。判断的临界点不是人数，而是"依赖状态每周变化次数"。如果这个数字超过 30 次/周，手工维护就开始跟不上了。

4. 高频同步 vs 会议成本：站会该开多久

同步频率越高，隐性依赖暴露越早，但会议成本也越高。我的取舍是：把同步做进已有的会议上，而不是新开会议。

每日站会加一个第四问，成本是 5 分钟；新开一个"依赖对齐会"，成本至少是 30 分钟，而且因为它是新增的，出席率会逐渐下降。我们团队最后保留的形式只有一个：每日站会的第四问，加上每周一次的跨组依赖复盘。

5. 我的整体取舍倾向

如果只能给一条总结性的建议，我会说：优先做那些"不增加会议、不增加角色、不增加工具"的动作。因为依赖管理这件事最大的敌人不是方法不对，而是坚持不下去。任何需要额外投入的机制，都会在第三周被悄悄放弃。

从这个角度看，最值得先做的三件事是：站会加第四问、在关键交接点设缓冲、把依赖关系画出来。这三件事都不需要获批，也不需要预算，任何一个项目成员今天就能开始。

八、今天就能做的三件事

我把整篇文章的方法压缩成三个具体动作，你今天、本周、本月各做一件就行，不需要等任何审批。

1. 今天：画一张依赖图，只画箭头

找一张白纸或者一个共享文档，把你手上正在做的任务和它依赖的任务列出来，用箭头连起来。不要标注类型，不要试图一次画全，先把你知道的连上。

画完之后看两个地方：一是被最多箭头指向的那个任务，那是你的瓶颈；二是有没有哪个任务是"我一直在等但从来没写下来过"的，那就是隐性依赖。

2. 本周：在关键交接点上设一次缓冲

从依赖图里挑出最长的那条链路，找到这条链路上的第一个交接点，给它加一段缓冲。经验值是上游任务工期的 15%-25%，先按 20% 试。

加完之后告诉上下游双方：缓冲已经留出来了，上游按原计划交付即可，不需要提前。缓冲的意义不是让上游放松，而是让下游不用天天担心。

3. 本月：把站会第四问固化下来

在每日站会最后加一句话："你今天需要谁先完成什么？"问完之后，把答案记在依赖图上，形成一个闭环。

坚持两周之后，统计一下站会上暴露的依赖条目数量。如果从 0 变成了 2-3 个，说明这个动作生效了；如果还是 0，说明团队还没有把真实的等待说出来，这时候需要你先带头示范，第一个说出"我在等某某某"。依赖管理的起点，永远是有人先承认自己在等。

最后回到开头那句话：依赖冲突不是执行力问题，是排序问题、缓冲问题、可见性问题。而这三个问题，没有一个需要通过"催"来解决。