依赖冲突管理指南：项目成员如何做好任务依赖，最佳实践全流程

去年 Q3，我带的 12 人项目组在冲刺结束前 4 天发现测试环境里堆了 17 个待验证的提测包。不是测试没人，而是其中 11 个包依赖的上游接口改了字段，下游三个模块谁都没收到通知。那次冲刺最终延期 9 天，复盘会上所有人的第一反应都是"沟通不到位"，但这个归因是错的，真正的问题是这 11 条依赖关系从头到尾就没被写下来过。

这篇《依赖冲突管理指南：项目成员如何做好任务依赖，最佳实践全流程》，要回答的不是"依赖管理有多重要"这类正确但无用的废话，而是一个更具体的问题：作为一个普通的项目成员，你手上的任务依赖到底该怎么识别、怎么记录、怎么协调、怎么监控、怎么复盘。我会把过去几年在十几个项目里踩过的坑、验证过的模板和判断标准全部摊开讲。

核心结论：依赖管理的第一责任人，是每个任务的交付者

先把结论摆在前面。如果你只记得住三段话，记住这三段就够了。

结论一：依赖冲突的本质是"契约未定义"，不是"关系不好"

我见过太多团队把依赖冲突归结为沟通不畅，然后开更多的会、拉更多的群。但真实情况是：依赖的双方从来没有对"交付什么、什么标准、什么时候、变化了怎么通知"达成过明确一致。

没有契约的沟通，本质上是随机事件。今天对方心情好、手头空，你的事就被顺手处理了；明天对方被上级拉去救火，你的依赖就自动沉底。你以为你在管理关系，其实你在赌运气。

契约不需要多正式。一条写清楚"3 月 18 日 18:00 前交付接口文档，字段变更需提前 48 小时在任务卡和群里双通知"的备注，就已经比十次口头对齐有效。

结论二：大多数依赖冲突在识别阶段就该被拦下

我统计过自己手上 6 个已结项项目的 214 条跨任务依赖记录，按最终归因拆了一下：约 68% 的依赖冲突，根因是"这条依赖关系在排期时压根没被记下来"；约 19% 是"记下来了，但上游确实延期"；剩下约 13% 是"记下来了，但优先级被上级临时调整"。

需要说明，这是我个人的项目样本推演，不是行业统计口径。但结论方向很有参考价值：依赖冲突里真正需要"协调能力"的部分不到三分之一，剩下的三分之二其实是"识别与记录"的问题。

这也解释了为什么很多团队越开会越乱，你在用协调手段去解决一个识别问题，药不对症。

结论三：全员依赖管理是唯一可持续的解法

项目经理的注意力是稀缺资源。一个 30 人以上的项目，跨任务依赖动辄上百条，PM 一个人既记不住也盯不过来。真正可扩展的模式，是把依赖管理的责任下沉到每个任务的交付者身上。

每个成员只需要做三件事：声明我的上游、承诺我的下游、监控我的偏差。这三件事做到位，PM 就从"人肉依赖追踪器"变成了"异常升级通道"，整个系统的吞吐能力会有质的变化。

背景与真实场景：依赖是怎么把人拖住的

理论讲完了，接下来讲具体的。下面四个场景都是我在真实项目里遇到过的，每一个都造成了至少 3 天以上的延期。

场景一：串行依赖的"接力掉棒"

一个电商结算改版项目，链路是：产品出原型 → 设计出视觉 → 前端切图 → 后端接口 → 联调 → 测试。6 个环节串行，看起来清晰明了。

问题出在第三棒和第四棒之间。前端以为后端接口会按老字段返回，后端以为前端会适配新字段，双方在设计评审时都点过头，但谁也没把"字段命名以哪份文档为准"写下来。

结果联调第一天就崩了，光是字段对齐就花了 2 天。而这 2 天里，测试同学干等着，QA 资源被白白占用。

场景二：共享资源的"隐形排队"

有个团队同时跑 3 个项目，共用一套预发环境和 2 名 DBA。这三个项目在资源日历上没有任何交叉标记，各自排期看起来都很健康。

但到了上线周，三个项目同时需要 DBA 做数据变更，同时需要占用预发环境做回归。实际执行时被迫串行，后两个项目各延期 3 天和 5 天。

共享资源是一种最容易被忽略的依赖类型，因为它不在任务链上，而在资源池里。很多团队的依赖矩阵只记录任务到任务的关系，完全不记录任务到资源的关系，这是巨大的盲区。

场景三：跨部门审批的"黑盒等待"

涉及法务、安全、财务的审批依赖，是项目里最不可控的一类。我做过一个统计：在一个金融类项目中，外部审批类依赖的平均等待时长是 6.8 个工作日，而团队内部依赖的平均等待时长是 1.2 个工作日，差了将近 6 倍。

更麻烦的是可见性。内部依赖你能直接找人问，外部审批你连"现在卡在谁手上"都不一定问得出来。这种依赖如果不在项目早期启动，后期基本只能靠压缩测试时间来补。

场景四：远程与跨时区团队的"时差放大"

我参与过一个分布在三个时区的项目，团队分别在 UTC+8、UTC+1、UTC-5。一个当天下午提出的依赖问题，等到三方都能在线对齐，已经过去了 40 个小时。

时差本身不可怕，可怕的是它把每一次依赖澄清的成本从 10 分钟放大到了 2 天。在这种环境下，异步的、书面的、结构化的依赖记录不是可选项，而是唯一可行的协作方式。

常见误区拆解：为什么你的依赖管理总是失效

下面五个误区，是我在复盘会上听到频率最高的。它们之所以顽固，是因为每一个都"听起来很对"。

误区一：依赖管理是项目经理的事

这是最根深蒂固的一个。团队成员觉得"我只要把我的活干完就行"，于是依赖关系变成了 PM 一个人的记忆负担。

但 PM 并不清楚你代码里具体要调哪个接口、要等哪份数据。信息在 PM 那里是失真的、延迟的。让 PM 全权负责依赖管理，等于让一个看不见现场的人指挥现场。

误区二：口头对齐就等于确认

"我昨天跟他说过了，他说没问题"，这句话在复盘会上出现的频率极高，但它的信息量几乎为零。说了什么？什么时候？什么条件下算完成？变了怎么办？全都没有。

口头对齐的最大问题不是不可靠，而是不可追溯。出了问题你无法判断到底是对方没做，还是双方理解不一致。

误区三：甘特图上有箭头就等于管住了依赖

甘特图的连线只表达"顺序关系"，不表达"承诺强度"、不表达"变化通知机制"、不表达"失约后的替代方案"。

我见过一条甘特图连线下面挂着 4 个不同的隐含假设：字段不变、时间不变、人力不变、优先级不变。任何一个假设被打破，这条线就断了，而图上看不出来。

误区四：依赖冲突靠"加强沟通"能解决

"加强沟通"是项目管理里最没有信息量的一句话。它既没有说明沟通什么，也没有说明由谁沟通、什么时候沟通、沟通完怎么决策。

真正有效的替代说法是：在每周二 10 点前，由下游任务负责人向上游发起一次书面状态确认；上游如无法承诺，需在 24 小时内给出替代方案。这才是可执行的动作。

误区五：所有依赖都必须严格串行

很多人一旦意识到依赖重要，就走向另一个极端，把所有依赖都按最保守方式串行排布，结果项目周期被拉长 30% 以上。

实际上，相当一部分依赖是"软依赖"，比如你在等后端接口，但接口的数据结构已经确定了，你完全可以用 Mock 数据先把前端逻辑写完。识别出软依赖并允许并行，是压缩工期的关键杠杆。

专业判断逻辑：先判断，再动手

依赖管理的动作很多，但动作之前得先有判断。我总结了一套四步判断法，顺序不能颠倒。

判断第一步：区分"真依赖"和"假依赖"

真依赖是"上游不交付，下游物理上无法推进"。假依赖是"上游不交付，下游其实可以换个方式推进，只是没人愿意换"。

判断方法很简单，问一个问题：如果没有上游交付物，下游能不能产出可验证的中间结果？能，就是软依赖；不能，才是硬依赖。

我发现大约有四成的所谓"硬依赖"，其实是团队出于习惯或免责心理标记出来的软依赖。把它们识别出来，等于凭空多出四成的并行空间。

判断第二步：给依赖分四类

我习惯把依赖分成四类，每类的管理策略完全不同。

交付依赖：等一个具体的产物，比如接口、设计稿、数据表。管理重点是明确交付标准与验收方式。

顺序依赖：等一个动作完成，比如部署完成才能开始验证。管理重点是明确触发信号是谁发出。

资源依赖：等一个共享资源空闲，比如环境、DBA、设备。管理重点是资源日历和错峰机制。

信息依赖：等一个决策或口径，比如字段定义、业务规则。管理重点是决策人和决策截止时间。

这四类的失约成本差别极大。信息依赖通常最便宜也最容易解决，资源依赖最容易被忽略，交付依赖最容易扯皮。

判断第三步：用三维模型定优先级

不是所有冲突都需要立刻处理。我用三个维度给依赖冲突定级：影响度（会不会导致关键路径延期）、紧急度（离触发点还有多久）、可替代性（有没有绕过去的办法）。

三个维度都高的，必须当天升级；影响度高但可替代性也高的，优先走替代方案而不是协调；影响度低紧急度低的，记录在案、每周统一处理即可。

判断第四步：先定失约成本，再定监控强度

监控是有成本的。如果每条依赖都要求每日同步，团队会被会议淹没。合理的做法是按失约成本决定监控强度。

失约会导致关键路径延期 3 天以上的依赖，纳入每日站会同步；1-3 天的，每周两次书面确认；1 天以内的，只在触发前 48 小时确认一次。

识别篇：四步法梳理你的任务依赖

识别是整个依赖管理链条里投入产出比最高的一环。以下是我们在项目里反复使用并迭代过的四步法。

第一步：把任务拆到"可交付物"颗粒度

"完成订单模块开发"不是一个可识别的任务。它太大了，里面藏着七八条依赖你都看不见。要拆到"订单创建接口返回 200 且写入 3 张表"这种程度。

判断颗粒度是否合适的标准是：这个任务能不能用一句话说清楚"完成的样子"。说不清楚，说明还能再拆。

第二步：对每个任务问三个前置问题

不用搞复杂的依赖推导，问三个问题就能挖出八成依赖。

开始这个任务之前，我需要拿到什么？（挖交付依赖）

做这个任务的过程中，我需要等谁先完成某个动作？（挖顺序依赖）

这个任务要占用什么资源，别人是不是也要用？（挖资源依赖）

第三个问题最容易被跳过。我建议在团队内强制要求：任何涉及共享环境、共享数据、共享审批人的任务，必须填写资源依赖字段。

第三步：标注依赖类型与硬软属性

每识别出一条依赖，立刻标注两件事：它属于四类中的哪一类，以及它是硬依赖还是软依赖。

这一步的价值在于，它把你的排期从"看起来完整"变成了"可解释"。当有人问为什么这个任务不能提前，你可以直接指出是哪条硬依赖卡住了它。

第四步：指定依赖责任人并写入任务卡

依赖必须有责任人，而且这个责任人应该是"承接方"而非"交付方"，也就是说，是你在盯这条依赖，而不是指望对方主动想起你。

我见过最有效的做法是：每条依赖在任务卡里都有一个明确的字段记录"我要在什么时候确认这条依赖的状态"。这把被动等待变成了主动检查。

依赖矩阵模板与任务卡字段规范

下面是我们团队实际在用的依赖矩阵表结构，可以直接复制到表格工具里使用。

`| 任务ID | 任务名称 | 上游任务ID | 依赖类型 | 硬/软 | 上游责任人 | 承诺交付时间 | 我方确认时点 | 当前状态 | 变化通知机制 |

| T-118 | 支付渠道接入 | T-130 | 顺序依赖 | 硬 | 运维李四 | 3/22 部署完成 | 3/22 14:00 | 未开始 | 部署完成需在群里@我方 |`

如果你所在的团队有项目管理工具，把依赖写进任务卡会更好。用结构化字段描述，机器才能帮你做校验和提醒。

task: T-102 订单接口联调
owner: 李四

depends_on:

id: T-088

name: 订单创建接口开发

一、协调篇：冲突发生了，怎么破

识别做得再好，冲突依然会发生。区别只在于：有准备的团队是"处理冲突"，没准备的团队是"被冲突处理"。

1. 第一步永远是分级，不是立刻找人对齐

冲突发生时的第一反应通常是"赶紧拉个会"。但更有效的第一步是分级：这条冲突影响关键路径吗？还有多少缓冲时间？有没有替代方案？

三个问题答完，你会发现至少一半的冲突根本不需要拉会，一封说明邮件加一个替代方案就够了。

2. 四种协调策略及其适用边界

协调策略就四种，但很多人只会用其中一种，所以总觉得协调很难。

• 调整顺序：适用于依赖双方的任务可交换先后。成本最低，但要求对任务链有整体视野。
• 拆分任务：适用于部分工作可以在缺少上游的情况下先做。是压缩工期的利器，但需要提前识别出可分拆的边界。
• 增加资源：适用于资源依赖类冲突。见效快，但解决的是表象，如果资源本身是瓶颈，只是把问题推给下一个项目。
• 升级决策：适用于双方无权决定的优先级冲突。见效慢但彻底，关键是升级时要带着方案而不是带着问题。

选择策略的核心判据是"解决速度"和"复发概率"的权衡。增加资源最快，但复发率最高；升级决策最慢，但一次性解决率最高。

3. 跨部门依赖的沟通话术模板

跨部门依赖之所以难，是因为双方没有共同的 KPI。我常用的沟通结构是"背景，影响，请求，替代"四段式，实测响应率比"麻烦帮我看一下"高出很多。

【依赖协调请求】
背景：我们是 XX 项目组，正在推进 T-102 订单接口联调。

该任务计划 3 月 22 日进入联调，5 月 8 日交付到生产。

影响：如果 T-088 接口字段无法在 3 月 18 日前冻结，

联调将顺延至少 3 个工作日，连带影响 5 月上旬的商务推广节点。

请求：希望贵组在 3 月 18 日 18:00 前确认接口字段最终版本，

如届时仍无法冻结，能否在 3 月 17 日告知，我们将启用备选方案。

替代：若字段确需调整，我们可先按当前版本开发主流程，

字段冻结后再做一次适配，但需要贵组提供字段变更清单。

联系人：李四 / 截止确认时间：3 月 17 日 12:00

这个模板的关键在于：它给了对方三个东西，清楚的背景、明确的截止时间、一个不那么难做的备选动作。人不会拒绝一个已经替他想好退路的请求。

4. 什么时候该升级，什么时候不该

我的判断标准是：冲突双方在 2 个工作日内无法就"谁先动"达成一致，且该冲突已进入关键路径，就应该升级。

反之，如果冲突没有进入关键路径，或者双方还在正常沟通且已有阶段性进展，就不该升级。频繁升级会让你的协调请求贬值，后面真出大事反而没人当回事。

二、监控篇：让依赖不掉链子

识别和协调解决的是"点"上的问题，监控解决的是"面"上的问题。没有监控机制，前面做的所有工作都会随时间衰减。

1. 站会里的依赖三问

我不建议站会上逐条过依赖清单，太耗时间。更高效的做法是固定问三个问题，只让有情况的人回答。

1. 你昨天有没有因为别人的交付而被阻塞？（暴露已发生的依赖问题）
2. 你今天要推进的任务，依赖的上游有没有在按计划推进？（暴露潜在问题）
3. 你承诺给别人的交付物，今天有没有可能延期？（暴露你将成为别人的问题）

第三个问题最关键，也最少被问。它能让你在成为别人的阻塞源之前就发出预警，而不是等对方来催。

2. 依赖状态可视化的三种做法

可视化的目的不是好看，而是让异常自己跳出来。

• 看板泳道加依赖标记：在卡片上打颜色标签，红色代表依赖有风险，黄色代表依赖待确认。简单但有效。
• 依赖状态矩阵：一张表横轴是任务、纵轴是依赖，用色块表示正常、风险、阻塞。适合跨团队场景。
• 依赖燃尽视图：统计"未关闭的依赖条数"随时间的变化。如果这个数字在迭代中期还不下降，说明依赖管理整体出了问题。

三种做法我建议从第一种开始。先让依赖可见，再谈让它可控。很多团队一上来就搞复杂仪表盘，最后没人看。

3. 六个预警信号

依赖出问题前通常有征兆，我总结出六个最常出现的信号。

1. 上游任务连续两次站会没有进度更新。
2. 上游责任人连续两次会议缺席或迟到。
3. 上游任务的预估剩余时间连续三天不变。
4. 对方开始用"尽量""应该可以"这类模糊措辞回应具体时间。
5. 上游任务的上级对其投入度明显下降（比如被抽调去做别的事）。
6. 同类依赖在上一个迭代已经出过一次问题，但这次没有额外的缓冲。

任何一个信号出现，就该主动发起确认，而不是等承诺日到来。

4. 远程与跨时区团队的额外机制

同地团队靠走廊闲聊就能同步的信息，在远程团队必须显式化。我的建议是在上面三种做法之外，增加两条硬规则。

第一条：任何依赖状态变化，必须在任务卡里更新，而不是只在聊天工具里说。聊天记录会被淹没，任务卡不会。

第二条：跨时区团队设置重叠时间窗口，专用于依赖澄清，其余时间一律异步。不要把同步会议铺满全天，那会让所有人都在开会而不是在交付。

三、工具落地：从表格到专业项目管理平台

方法论讲完，最后一定会落到工具上。我的态度比较务实：工具不是决定性的，但它决定了你的依赖管理能扩展到多大规模。

1. 表格工具能撑到什么规模

我带的第一个项目就是用表格管理依赖的，12 个人、47 条依赖，跑得还不错。但到第二个项目、三个小组并行的时候，表格就开始失效了。

失效的原因不是表格不够用，而是表格没有"变化通知"能力。依赖变了，除非有人主动更新并通知，否则所有人看到的都是过期信息。

我的经验判断是：表格适合 10 人以下、依赖条目少于 50 条、单项目单团队的场景。一旦跨部门，就会开始失控。

2. 通用看板工具的边界

很多通用看板工具支持在卡片之间建立关联，看起来解决了依赖问题。但实际使用中我发现两个明显短板。

一是关联关系通常是"引用式"的弱关联，不会对排期产生约束。你可以把两个互斥的任务排在同一时段，工具不会提醒你。

二是缺少依赖链路的聚合视图。当一个任务有 5 条上游依赖时，你很难一眼看出哪条有风险。

3. 专业项目管理平台解决的是什么

当组织规模到了 100 人以上、多项目并行、还涉及合规要求时，通用工具就开始力不从心了。这时候通常需要考虑专业的项目管理平台。

以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，在依赖管理上有几个我们实际用得上的能力。任务级的依赖关系配置能够直接约束排期，前置任务变动时下游会收到提示，而不是等到联调当天才发现。

另外两个对我们很关键的点：一是 PingCode 支持私有化部署，这对于有数据合规要求的金融、制造类客户来说是硬性门槛；二是 PingCode 支持 Jira 平滑迁移，我们是分两批把历史项目的任务和依赖关系迁过来的，字段映射和关联关系基本没有丢失。

从国产替代的角度看，它是目前少有的、能把研发全流程（需求、迭代、测试、缺陷、依赖）放在一套模型里的平台，不需要在多个工具之间做数据同步，这也是我们最终选择它的主要原因。

4. 选型建议：按规模和合规要求分档

不要一上来就买最重的工具，也不要为了省钱用表格硬撑。

• 10 人以下、单团队、需求稳定：表格足够，重点是把依赖字段规范起来。
• 10-50 人、多小组、迭代节奏快：通用看板工具加依赖标记，重点是在站会里固定依赖三问。
• 100 人以上、多项目并行、有合规要求：考虑专业项目管理平台，重点关注依赖约束能力、变更通知、私有化部署和迁移成本。

四、复盘篇：把依赖管理变成团队肌肉记忆

依赖管理最容易出现的问题是"这次改了，下次又犯"。解决方式只有一个：把复盘变成固定动作。

1. 依赖复盘四问

每次迭代结束，用四个问题回顾依赖管理情况。不需要开长会，20 分钟足够。

1. 这个迭代里，有哪些依赖是事后才被发现的？（改进识别环节）
2. 有哪些依赖识别出来了，但协调不及时？（改进响应机制）
3. 有哪些依赖本可以前置处理，却被拖到了最后？（改进排期策略）
4. 有哪些依赖的替代方案本来存在，但没人想到？（改进预案意识）

四个问题对应的正是识别、协调、排期、预案四个能力维度。连续复盘三个迭代，你就能看出团队的系统性短板在哪里。

2. 依赖管理 checklist

下面这份清单可以在每个迭代规划会结束时过一遍，全部勾选才算规划完成。

• 所有任务已拆解到"一句话能说清完成样子"的颗粒度。
• 每个任务至少回答过三个前置问题。
• 每条依赖都标注了类型（交付 / 顺序 / 资源 / 信息）。
• 每条依赖都标注了硬软属性。
• 每条软依赖都有明确的 fallback 方案。
• 每条依赖都有承接方指定的确认时点。
• 关键路径上的依赖已纳入每日站会同步范围。
• 外部审批类依赖已提前至少 2 周启动。
• 共享资源依赖已进入资源日历并完成错峰排期。
• 本次迭代的依赖清单已在团队可见的位置公示。

3. 依赖管理成熟度自测

最后给一份简化版自测表，五个维度各 10 分，团队一起打分后取平均。分数不重要，重要的是找到最低的那一维。

五、不同情况下的行动建议与取舍

方法论没有普适答案，关键在于匹配。以下是我对几种典型情况的判断。

1. 按团队规模

10 人以下，别搞复杂机制。把依赖矩阵表用起来，站会加一句依赖确认就够了。过度管理反而会消耗本就稀缺的精力。

10-50 人，重点建机制。依赖三问进站会、周度依赖盘点、冲突分级处理，这三件事必须固化下来，否则会随人员流动而失效。

100 人以上，重点在工具和度量。人盯人已经不现实，必须依赖平台化的依赖约束和自动提醒，同时用依赖燃尽、阻塞时长等指标持续观测。

2. 按项目类型

瀑布型项目，依赖关系相对稳定，重点是把依赖写进基线并做定期复核。甘特图在这里是有效的，但要补上责任人和承诺标准两个字段。

敏捷型项目，依赖变化频繁，重点是短周期同步和快速替代方案。硬依赖要尽量在迭代规划时就消解掉，不要留到执行中。

混合型项目最麻烦，往往是敏捷团队交付、瀑布流程审批。我的建议是内外分开管：团队内部用敏捷节奏，对外部审批用提前量管理，两套机制并行。

3. 按团队分布

同地团队可以容忍一定的口头传递，因为信息补偿速度快。但即便如此，我也建议至少把硬依赖书面化，因为人会离职、会轮岗。

远程和跨时区团队没有选择，必须全部显式化。此时的判断标准很简单：如果一件事没有被写下来，它就等同于没有发生。

4. 什么时候该放弃精细依赖管理

这不是偷懒，而是理性的资源分配。当项目周期短于 2 周、参与方不超过 3 人、依赖关系少于 5 条时，精细管理的收益低于成本，口头同步加一张简单清单即可。

另一个典型情况是探索型任务，比如技术预研、原型验证。这类任务的不确定性本来就高，过早固化依赖反而会限制思路。此时更应该管的是时间盒，而不是依赖。

5. 什么时候必须用重工具

三种情况我建议不要犹豫：多项目共享同一批资源、依赖关系超过 100 条、有外部审计或合规留痕要求。这三种情况下，轻量工具的隐性成本（对账时间、追溯困难、责任不清）会迅速超过工具采购成本。

选型时的一个实用判断是：如果你们已经开始用 Excel 手工维护"依赖变更记录"这张表，那就是该换工具的明确信号。因为这意味着你在用人力模拟工具应该做的事。

结语：依赖管理是职场协作的复利

写到这里，回到最开始那个延期 9 天的项目。后来我们做了一件事：把所有跨任务依赖写进任务卡，每条依赖强制填写上游责任人、承诺时间、确认时点和 fallback。下一个迭代，同类问题从 11 起降到了 2 起。

我在这篇文章里最想传达的独特观点是：依赖管理的瓶颈从来不在协调技巧，而在识别与契约。大多数团队把精力花在冲突发生后的救火上，却不愿意在排期阶段多花 20 分钟把依赖写清楚。而后者恰恰是投入产出比最高的动作。

另一个观点是：依赖管理的责任必须下沉到每个任务的交付者身上。PM 不是枢纽，而是异常处理通道。当你开始主动声明上游、承诺下游、监控偏差时，你就不再是被依赖卡住的人，而是让依赖流动起来的人。

下一步我建议你做三件事。第一，把本文的依赖矩阵模板复制到你们现有的表格或项目管理平台里，先跑一个迭代。第二，在下次站会上加问第三个问题，"你承诺给别人的东西，今天有可能延期吗"。第三，用成熟度自测表给团队打个分，找到最低的那一维，只改那一维。

不需要一次改完所有事。依赖管理的收益是复利的，今天多写一行依赖记录，三个月后就会变成团队交付节奏的稳定感。