任务依赖前置任务全流程：项目负责人协同管理与一文讲清

三年前我接手过一个跨四个部门的项目，硬件、固件、云端、测试四条线并行，14个里程碑。上线前两周，测试负责人跟我说测试环境还没搭好。我顺着往下查：搭环境依赖运维的服务器到货，服务器到货依赖采购合同审批，合同审批压在法务，法务在等业务部门确认云服务清单。四层前置任务，整条链上没有任何一个人知道全貌。项目最终延期37天，复盘时我算了一笔账：真正因为"活儿干不完"而卡住的工时只有18人天，但因为依赖关系不透明造成的等待、返工和反复对齐，吃掉了接近300人天。

这篇《任务依赖前置任务全流程：项目负责人协同管理与一文讲清》，我不想再重复"FS/SS/FF/SF四种依赖类型"那一套教科书讲法。我想把这三年踩过的坑摊开讲清楚：项目负责人到底该怎么把前置任务这件事，从"画在甘特图上的一根线"，变成"可执行、可追踪、可复盘"的协同机制。

一、先给结论：前置任务管理的本质是管理"承诺的传递"

1. 三个我反复验证过的判断

带过十几个跨部门项目之后，我对"任务依赖"这件事的判断越来越简单，也越来越固执。

判断一：依赖关系的本质是承诺链，不是时间线。甘特图上那根箭头表示"A做完B才能开始"，但真正决定项目会不会延期的，是A的负责人有没有在B的负责人需要之前，把符合标准的东西交出去。箭头画得再漂亮，承诺断了，项目照样停。

判断二：项目负责人在依赖管理上的核心动作是"降低不确定性"，不是"催进度"。催进度是结果层动作，只有在前置任务的状态已经高度确定时才有效。当上游还停留在"应该快好了"的时候，催得越勤，对方越容易给你一个虚假的乐观答复，而这比沉默更危险。

判断三：依赖管理做得好不好，看的是前置任务的定义质量，不是依赖线条数。我见过一张有200多条依赖线的甘特图，照样每周出状况。因为那200条线里，有170条只写了任务名，没写交付标准、责任人、验收方式和变更路径。

2. 前置任务延期的真实成本结构

大部分人算项目延期成本，算的是"延期了多少天"。这个算法漏掉了大头。

我拿自己经手的一个项目做过完整复盘：显性延期18人天，但因为依赖不透明产生的等待、返工、上下文切换和反复开会，加起来接近300人天。也就是说，你能在周报上看到的延期数字，通常只占依赖管理失败总成本的6%左右，其余部分被分散到了每个团队成员的时间碎片里，谁也看不见。

3. 一个反常识的判断：依赖不是越少越好

很多方法论会告诉你"要解耦、要减少依赖"。这话在系统架构设计里基本正确，在项目协同里只对一半。

依赖减少的直接后果是接口变多。原来一个前置任务交一次就够，解耦之后变成三个团队分别对接，每个接口都要定义标准、约定时间、处理异常。我见过一个团队为了"减少依赖"，把一次联合调试拆成三次独立验证，结果集成阶段一次性爆出47个问题，全部要在最后两周解决。

我的判断是：依赖数量应该由业务本身的耦合度决定，而不是由管理偏好决定。该耦合的地方强行解耦，只是把风险从"看得见的等待"变成了"看不见的集成炸弹"，而且爆炸时间点更晚、修复代价更高。

二、三个协同断点：项目负责人被卡住的真实位置

把依赖管砸的原因归到"沟通不畅"上，是最省事也最没用的归因。我把经手项目里所有依赖相关的故障做了分类，发现它们几乎全部落在三个断点上，而且每个断点的修复动作完全不同。

1. 信息断点：依赖关系只存在某个人的脑子里

这是最常见也最隐蔽的一类。前置任务的存在，只有当事人知道；链条有多长、中间经过谁，没有人能完整说出来。

它的典型特征是：问题暴露的时间点，永远比实际发生的时间点晚一到两周。因为链条上任何一环的负责人，都只知道自己那一段，没有人有能力判断"我这个延期会不会影响最终交付"。

信息断点的修复动作只有一个：把依赖关系从口头共识变成书面清单，且这份清单必须能被链条上的每一个人看到。不是挂在项目负责人电脑里，是挂在所有人都能打开的地方。

2. 责任断点：前置任务的"完成"没有定义

信息断点解决的是"知道不知道"，责任断点解决的是"算不算完"。

我见过太多这样的对话：上游说"我交付了"，下游说"你这交付的东西我用不了"。双方都没说谎，因为"完成"这个词从来没有被定义过。上游理解的完成是"东西给出去了"，下游理解的完成是"东西能直接接上我的活"。

责任断点的破坏力比信息断点更大，因为它会直接制造返工。前置任务的完成标准，必须在任务开始之前定义，而不是交付当天再讨论。这个标准至少要包含三件事：交付物形态、验收方式、验收人。

3. 节奏断点：上下游的交付节拍对不上

这是最容易被忽略的一类。上下游之间的依赖关系是清晰的、交付标准也定义好了，但两边的节拍不匹配。

举一个真实场景：上游团队每周五下午统一提交一批交付物，下游团队每周一上午做规划、周中执行。结果就是上游周五交的东西，下游要到下周三才能真正用上，中间白白浪费五天。这五天不是任何人的错，纯粹是节奏错位。

节奏断点的修复方式很反直觉：不要去调整工作内容，去调整交付的时点。让上游把交付切到下游的规划窗口之前，哪怕交付内容看起来"碎一点"，整体链路反而更快。

三、把依赖关系讲清楚：四种类型与前置任务识别

概念部分我不想只做定义搬运。下面这张表里，每一行我都补了一列"对应的协同动作"，因为对项目负责人来说，知道 FS 和 SS 的区别不重要，知道它们分别需要做什么动作才重要。

1. 四种依赖类型的真实含义与对应的协同动作

四种类型里，FS 用得最多，也最容易被管好。真正容易出事的是 SS 和 FF，因为它们的约束条件不是"某个点"，而是一段区间，区间里任何一方的节奏变化都会互相拖累。

FF 是我见过的最隐蔽的陷阱。表面上双方都有任务在手，看着都在干活，实际上谁都无法先完成，最后一起卡在截止日附近。识别 FF 依赖的唯一办法，是在规划阶段就问一句："你这个任务，有没有哪个部分必须等别人完成之后才算真正结束？"

2. 前置任务识别的三步法

识别前置任务这件事，很多人做成了"凭经验回忆"。我推荐的做法是三步，从工作包往下逐层收敛，每一步都会过滤掉大量伪依赖。

1. 第一步：从 WBS 找可疑界面。把工作包按交付物拆开，任何两个工作包之间存在"输入-输出"关系的，先标记为潜在依赖。这一步宁滥勿缺，目的是不遗漏。
2. 第二步：验证依赖强度。对每条潜在依赖问三个问题：下游是否真的需要上游的产出？这个需要是硬约束还是软期望？如果上游延期，下游有没有替代方案？三个问题里有两个以上答"是硬约束"，才升级为强依赖。
3. 第三步：定义可监控字段。只把强依赖纳入监控清单，并为每一条补齐六个字段：交付物、交付标准、验收人、最晚交付时间、缓冲、升级路径。

第三步入库时，我习惯用一份结构化的依赖清单，而不是在甘特图上拉一根线。线说不清楚"什么算完成"，字段可以。下面是我在实际项目里用的清单格式：

dependency:
id: DEP-014

upstream_task: T-2031 "服务器到货验收"

downstream_task: T-2105 "测试环境搭建"

3. 关键路径：找到真正卡脖子的那条链

关键路径（CPM）这个概念本身不复杂：项目中最长的一条依赖链，其长度决定项目最短工期。但很多项目负责人在实操中把它做成了"看软件自动标红的那条线"。

我要提醒的是：软件算出来的关键路径，是基于你录入的工期估算算出来的；如果你的估算是拍脑袋的，关键路径也是拍脑袋的。它会给你一种精确的错觉。

我的做法是两条路径一起看：一条是软件按工期算出来的关键路径，用来做进度基线；另一条是"风险关键路径"，也就是依赖链上不确定性最高的那几条任务组成的链。后者不会出现在任何系统里，需要项目负责人靠判断补上。

在这两条路径不一致的时候，我会优先盯风险关键路径。原因很简单：工期可以压缩，不确定性没法压缩。

四、全流程拆解：项目负责人的五个阶段动作

依赖管理不是一次性工作，它要嵌到项目全流程里，每个阶段都有一个必须做、且只有项目负责人能做好的动作。下面这五个动作，是我从多次踩坑里筛出来的最小集合。

1. 启动阶段：把"依赖共识会"开成一次契约会

大部分项目的启动会开成了宣讲会：讲目标、讲范围、讲分工，然后散会。真正的依赖关系一个字都没确认。

我后来把启动会拆成两段：前半段照常宣讲，后半段专门开"依赖共识会"，只做一件事，让每个模块负责人当场说出自己的上游是谁、下游是谁、需要对方交付什么。

这个会有个关键设计：不允许说"我跟某某沟通"。必须说出具体的人名、具体的交付物、具体的时间点。凡是说不出来的，当场标记为"依赖未识别"，会后由项目负责人一对一补。

我做过统计，一次45分钟的依赖共识会，平均能暴露8到12条此前完全没有被识别出的隐性依赖。这些依赖如果在执行阶段才暴露，平均每条要花2到4天来处理。

2. 规划阶段：前置任务交接单

共识会上识别出的依赖，需要在规划阶段固化成交接单。这不是一份文档，而是一份"双方签字确认的执行依据"。

交接单的核心不是把依赖清单抄一遍，而是把"最容易扯皮的部分"提前写死。我的模板里固定包含四项内容：

• 交付物形态：是文档、代码、环境还是一份确认邮件？形态不同，下游的准备动作完全不同。
• 验收方式：下游用什么方式确认"这东西可用"？抽检、全检、还是跑通一个具体场景？
• 验收人：必须写具体的人名，不能写"测试团队"。写团队等于没写，因为团队不会为一件具体的事负责。
• 异常处理路径：交付不达标时怎么办？是上游补做，还是下游临时兼容，还是升级给项目负责人？

最后一项最容易被省略，但它的价值最高。我在一个项目里做过对比：有明确异常处理路径的依赖，平均处理时长1.2天；没有的，平均4.7天，因为每次都要重新开会决定谁来处理。

3. 执行阶段：三级预警，让问题在变成事故之前暴露

执行阶段最常见的错误是"等结果"。等到交付日当天才发现前置任务没完成，那时候能做的只有救火。

我的做法是给每条强依赖设三级预警，预警触发不需要复杂的判断，只需要看时间：

1. 黄色预警：距离最晚交付时间还有5天，前置任务进度低于计划的80%。触发动作：项目负责人一对一问一次"卡在哪"。
2. 橙色预警：距离最晚交付时间还有3天，进度仍低于计划的80%，或者上游给出了第一次延期预期。触发动作：启动异常处理路径，同时评估下游能否并行推进部分工作。
3. 红色预警：距离最晚交付时间不足1天，或者上游明确表示无法按期交付。触发动作：升级到双方负责人，同时启动缓冲。

这套机制的关键在于"提前量"。黄色预警的价值不在于解决问题，而在于把信息差从两周压缩到五天。五天的提前量，足够下游调整排期、也足够上游申请支援；到了红色预警才动作，就只能接受延期。

4. 监控阶段：依赖变更管理与缓冲设置

项目推进到中期，依赖关系一定会变。需求变了、人员换了、上游的技术方案改了，依赖链随之变化。问题不在于变更本身，而在于变更被静默处理。

我要求所有强依赖的变更都必须走三步：

• 记录变更内容：变更了什么，为什么变。这一步只是留痕，成本极低。
• 评估影响面：这条依赖的下游还有谁？变更会传导几层？这一层最容易漏，因为很多项目负责人只看直接下游。
• 更新缓冲与通知链：影响面确定之后，重新分配缓冲，并通知受影响的所有人。

缓冲设置本身也有讲究。我见过最多的做法是"每个任务都加一点缓冲"，看起来安全，实际效果很差，因为每一层都会把自己的缓冲用掉，最后总工期被拉长了三分之一，按期完工率却没提高多少。

我现在的做法是把缓冲从单个任务里抽出来，集中放在依赖链末端或者关键节点前，形成一个看得见的"缓冲池"，由项目负责人统一支配。这样做有两个好处：一是不拉长总工期，二是缓冲被消耗时所有人能看到，能形成压力传导。

5. 收尾阶段：依赖复盘与知识沉淀

项目结束后的复盘，大部分团队会总结"哪些做得好、哪些要改进"，但很少专门复盘依赖关系。这是个很大的浪费。

依赖复盘只需要回答三个问题：哪条依赖链出问题最多？哪类断点在这类项目里反复出现？下次再做同类项目，哪些依赖可以直接预判？

我自己的做法是维护一份"依赖模式库"，把每次复盘出的高频依赖链记下来。比如做硬件+软件结合的项目，"服务器到货 → 环境搭建 → 联调"这条链几乎每次都会出问题，那我下次在规划阶段就会自动把它标为高风险链，提前配置缓冲和预警。

依赖管理的成熟度，最终体现在你能不能提前预判，而不是能不能快速救火。

五、四个高频误区与它们的真实代价

下面这四个误区，我在不同的项目里反复见到，几乎每个项目负责人至少踩过其中两个。它们的共同点是：看起来都像在"认真做管理"，实际都在制造风险。

1. 误区一：把依赖画进甘特图，就当管理完成了

这是最普遍的一个。项目负责人花两天时间把甘特图拉得漂漂亮亮，依赖箭头一根不差，然后认为依赖管理这件事已经做完了。

问题在于，甘特图记录的是"关系"，不记录"约定"。它告诉你A和B有先后关系，但它不告诉你A要交什么、什么算完成、谁验收、延期了找谁。所有真正会导致扯皮的信息，在甘特图里都是缺失的。

我的判断是：甘特图是给管理层看进度用的，依赖清单才是给执行团队用的。两者不能互相替代。

2. 误区二：用"多沟通"代替"定义交付标准"

"这个问题主要是沟通不到位"，这句话在复盘会上出现的频率极高，但它几乎从来不指向真正的解决方案。

沟通本身不能创造确定性。上游和下游每天开一次会，如果"完成"的标准还是模糊的，那么每天开会的结果就是每天重新吵一次。我见过一个项目，为了解决交付物不达标的问题，把同步会从每周一次改成每天一次，坚持了三周，返工率没有任何改善，团队士气先崩了。

真正的解决方案只有一个：把"完成"的定义写下来，双方确认，然后照着执行。定义清楚了，沟通频率反而可以降低。

3. 误区三：缓冲加在自己身上，而不是加在依赖链上

这是我自己踩过最深的坑。早期带项目时，我给每个任务都留了缓冲，觉得这样最保险。结果项目照样延期，而且延得更多。

原因后来想明白了：个人缓冲会被个人消耗掉，而且消耗的过程是隐性的。每个人都会不自觉地把自己任务的缓冲当作"可以慢慢做"的空间，等到交付时缓冲刚好用完，下游拿到的还是"卡点交付"。但总工期已经被这些缓冲拉长了很多。

正确的做法是把缓冲从个人手里拿走，集中到项目层面，由项目负责人根据实际情况动态分配。

4. 误区四：依赖变更不做影响面分析

这条误区的发生频率比前三条低，但单次破坏力最大。

典型场景是：某个上游任务因为技术方案调整，交付物从"接口文档+Mock数据"变成了"接口文档"，交付时间不变。负责人觉得"少了个东西，应该更快"，就直接改了，没通知下游。下游按原计划等 Mock 数据做前端联调，等到交付日才发现东西没了，整个联调计划推倒重来。

依赖变更的危险不在于变更本身，而在于变更的传导范围往往超出变更人的视野。所以影响面分析必须由项目负责人来做，而不是由变更发起人判断，因为只有项目负责人手里有完整的依赖链视图。

六、工具怎么选：让前置任务真正"看得见"

工具在依赖管理里的作用，不是替你管理，而是让"依赖状态"这件事在组织内可见。选错工具的典型症状是：团队每天都在工具里更新状态，但项目负责人依然不知道哪条链快断了。

1. 三种载体各自的能力边界

市面上常见的依赖可视化载体有三类：甘特图/网络图、看板、以及带依赖字段的项目管理平台。它们在能力上不是替代关系，而是各有盲区。

我的选择逻辑是看三条：依赖数量、变更频率、跨部门人数。依赖少、变更少、人少，用看板加一张共享表格就够了；依赖多、变更频繁、跨三个部门以上，就必须上带依赖字段的平台。

2. 工具落地的三个判定标准

工具选型时最常犯的错是看功能清单。功能多不等于能用起来。我判断一个工具能不能在依赖管理上真正落地，只看三条：

1. 能不能给依赖挂载自定义字段。如果只能画箭头，不能给箭头挂"交付标准""验收人""最晚交付时间"，那它只能做可视化，不能做管理。
2. 变更后能不能自动通知受影响的人。如果每次变更都要项目负责人手动去通知，那这套机制在项目忙起来之后一定会崩。
3. 状态更新的人是不是真正在干活的人。如果工具里的状态需要项目负责人代为更新，那么信息永远是滞后的。状态必须由任务负责人自己更新。

第三条尤其关键。我见过不少团队，工具配得很漂亮，但更新状态的是项目经理，任务负责人根本不登系统。这种情况下工具的实时性等于零，因为它反映的是项目经理的认知，不是实际进度。

3. 中大型组织的实际选择：PingCode 使用观察

当团队规模到100人以上、项目横跨多个部门时，上面三条判定标准会同时被卡住：依赖字段需要足够灵活，变更通知需要覆盖到人，状态更新要能约束到执行层。这种情况下，单纯靠一个看板工具已经撑不住了。

我在给一家两百多人规模的硬件+软件企业做流程梳理时，接触过 PingCode 这套平台。它在依赖管理这块有几个我觉得值得说的特点。

第一，它主要服务中大型企业及100人以上组织，产品设计本身就默认了"多项目并行、跨部门协作"这个前提。这意味着它的依赖字段、权限模型、跨项目视图不是后期硬加的，而是原生能力。对于只在单个小团队内部用的场景，这套能力其实是过剩的。

第二，支持私有化部署。这一点对制造业、金融、部分国企类客户是硬门槛，代码、图纸、客户数据不能出内网。我们当时接触的那家企业，选型的第一条否决项就是"必须能私有化"，很多 SaaS 工具在这一步就被筛掉了。

第三，支持从 Jira 平滑迁移。这一点在实操层面的价值比听起来要大。很多中大型团队的历史数据、工作流配置、字段体系都沉淀在 Jira 里，迁移最大的成本不是数据搬运，而是工作流和字段的重新映射。如果映射关系要人工重建，一个几十人的研发团队通常要停摆一到两周。

综合来看，在需要国产替代、又对私有化和迁移成本敏感的中大型组织里，PingCode 是一个不需要太多犹豫的选项。但我要补一句判断：工具解决的是"依赖可见"和"变更可追溯"，它不解决"愿不愿意承诺"。后者是管理问题，换什么工具都一样。

七、一个跨部门项目的依赖管理实录

下面这个案例来自我参与梳理的一个真实项目，涉及硬件、嵌入式、云端和测试四个团队，总人数约90人，属于典型的"多部门强耦合"场景。为了保护商业信息，具体产品名和部分数字做了模糊化处理，但结构和数据逻辑是真实的。

1. 背景与初始依赖结构

项目目标是六个月完成一版新硬件产品的量产准备。四条主线的依赖关系是这样的：硬件定型是嵌入式和云端的共同前置，嵌入式固件是测试的前置，云端接口是测试的前置，而量产准备又同时依赖硬件、固件、云端三条线全部冻结。

项目启动时，团队画了一张甘特图，大约标了40条依赖线。看起来挺完整。但实际上，这40条线里只有11条写了具体的交付标准，其余的只是一根从A指向B的箭头。

2. 断点出现与调整动作

项目推进到第三个月，问题集中爆发。测试团队连续两周处于"人到了但没法干活"的状态，因为固件和云端接口都没到可测状态。查下去发现三个问题同时存在。

第一，硬件团队理解的"定型"是"原理图冻结"，嵌入式团队理解的"定型"是"硬件能稳定跑起来供他们调试"。两个理解差了将近三周。这是典型的信息断点加责任断点叠加。

第二，云端接口的交付物定义是"接口文档和Mock数据"，但直到交付日，硬件团队才知道 Mock 数据是前端联调必需的，而他们一直以为固件团队自己会处理。这是影响面分析缺失导致的连锁反应。

第三，测试团队的排期是按周规划的，而固件和云端的交付是"攒一批集中提交"，两边节拍完全错位，即便交付了也要等下一周才能开始测。这是节奏断点。

我们做了四件事来纠正：把四个团队的负责人拉到一起，重新定义每个关键节点的"完成标准"并当场确认；把所有强依赖重新登记成结构化清单，补齐六个字段；给每条强依赖设置三级预警；把测试团队的规划节拍从"每周一次"调整为"随时接收"，同时要求上游按最小可用单元交付，而不是攒批次。

3. 结果与可复用经验

调整之后，项目又推进了三个月。这三个月里没有再出现"人到场但没活干"的情况，测试团队的平均等待时间从每周22人天降到6人天。虽然整体项目仍然比原计划晚了11天，但相比调整前的趋势，已经避免了预计60天以上的失控。

这个案例里最值得复用的经验有两条。第一条是"完成标准必须当场对齐，而不是文档对齐"。文档发出去没人看，会上当场说一遍、当场确认，效果完全不同。

第二条是"最小可用单元交付"。上游攒批次交付看起来效率高，实际是在把自己的节奏强加给下游。改成小单元交付后，上游的工作量并没有显著增加，但下游的利用率提升了一大截。

八、不同规模、不同情况下的行动建议与取舍

依赖管理没有通用方案。团队规模不同，投入产出比完全不同。我按规模把建议分成三档，并给出每档的取舍。

1. 5-20人团队：轻量做，别上系统

这个规模下，依赖关系通常不超过10条强依赖，团队成员彼此都知道对方在做什么。上系统是过度设计，配置工具的时间比处理依赖本身还长。

我的建议是：只用一张共享表格 + 一次周会。表格里列清楚强依赖的六个字段，周会上花10分钟过一遍红色和橙色项。这就够了。

取舍点在于：你会牺牲一部分可追溯性，人员流动时依赖知识容易丢失。如果团队人员流动率高，建议至少把依赖清单沉淀成文档，不必上工具。

2. 20-100人团队：把交接单和预警机制固化下来

这个规模是依赖管理问题最容易爆发的区间。团队已经无法靠"大家互相知道"运转，但还没到必须上重型平台的阶段。

我的建议是：交接单必须模板化，三级预警必须固化成固定节奏。交接单可以放在共享文档里，预警可以靠每周一次的依赖专项会来承载。关键是这两件事必须成为固定动作，而不是项目负责人想起来才做。

取舍点在于：这个阶段会额外增加项目负责人每周大约3小时的固定投入，而且短期内看不到明显收益。我的经验是收益在第二个项目周期才开始显现，第一周期主要是止损。

3. 100人以上组织：流程标准化 + 平台承载

到了这个规模，依赖管理的复杂度已经超过人工协调的极限。跨部门、多项目并行、人员流动、异地协作，任何一个因素都会让共享文档方案失效。

我的建议是：流程先标准化，再上平台。顺序不能反。先明确强依赖的准入标准、交接单字段、预警规则、升级路径，然后用平台把规则固化下来，让执行不依赖某个人的自觉。

取舍点有三个：一是平台选型周期长，通常会占用1-2个月；二是私有化部署对 IT 资源有要求；三是流程标准化期间会有短期效率下降，因为团队需要适应新的交付节奏。这三点都需要提前跟管理层对齐预期。

4. 几种必须做的取舍

九、总结：三个独特判断与明天就能做的三件事

1. 三个值得记住的判断

第一，依赖管理的抓手是"承诺"，不是"时间"。所有关于甘特图、关键路径、缓冲的技术，本质都是在为承诺的传递创造条件。如果承诺本身不牢，再精密的进度模型都是幻觉。

第二，项目负责人真正的管理半径，是从WBS收敛出来的那一小部分强依赖。我在案例里给出的数据是14%，从240条潜在关联收敛到34条纳入监控。管理精力应该压在这14%上，而不是平均分配给每一条线。

第三，缓冲的归属权比缓冲的总量更重要。把缓冲从个人手里拿走、集中到项目层面统一调度，比在每个任务后面加安全边际有效得多。这也是"每个任务都加缓冲"看起来最安全、实际最差的原因。

2. 明天就能做的三件事

1. 找出你当前项目里最长的三条依赖链，写下每一环的"完成标准"和"验收人"。不用全项目做，只做最长的那三条。如果写不出来，说明责任断点已经存在了。
2. 给这周还要交付的前置任务设一次黄色预警。具体动作就是问上游一句话："距离交付还有5天，你现在完成到什么程度？"问这一句，你就能拿到别人拿不到的信息差。
3. 把当前散落在各个任务上的缓冲合并成一个数字，写在自己手里。不需要马上重新分配，先让缓冲这件事从隐性变成显性，你就已经比大多数人清楚项目的真实风险在哪。

依赖管理这件事，本质上没有太高的技术门槛。真正的门槛在于：你愿不愿意在项目还顺利的时候，去做那些看起来多余的动作，开一场45分钟的依赖共识会、填一份有六个字段的交接单、在交付日前5天发一条预警。

这些动作在项目顺利时看起来毫无价值，在项目出事时却是唯一能救你的东西。