任务依赖依赖关系全流程：实施团队风险控制与一文讲清

我经手过一个 8 个月周期的制造企业 MES + ERP 一体化实施项目，合同工期 240 天，实际交付 263 天。复盘那天，我把所有延期原因贴在白板上，最后发现 23 天的延期里，有 17 天可以追溯到同一条依赖链：客户 IT 部门对第三方设备接口协议的审批晚了 11 天，而这 11 天正好卡在我们唯一一位懂 PLC 通讯的工程师身上，他同时被三个任务占用，谁也没想到这三条看起来不相干的计划线，其实共用同一个瓶颈。

这个项目让我彻底改变了对任务依赖的看法。依赖管理的难点从来不是"画不出关系图"，而是"画出来了却没人当真"。大多数实施团队并不缺甘特图，缺的是一套能把依赖关系变成可追踪、可预警、可追责的风险控制机制。

一、先给结论：依赖管理的本质是风险管理，不是排程技术

在展开讲流程之前，我先把这几年的核心判断摆出来。如果你的时间只够看三段话，看这三段就够了。

1. 三条核心判断

判断一：依赖管理的产出不是一张网络图，而是一份"活的"依赖登记册。网络图是一次性交付物，画完就挂在墙上；登记册是每天更新的资产，它有责任人、有承诺时间、有触发条件、有失效影响。没有后者，前者只是装饰。

判断二：实施团队 70% 以上的依赖风险来自"隐性依赖"，而不是教科书里的 FS/SS/FF/SF。完成-开始、开始-开始这些类型是理论基础，但真正让项目翻车的，是同一个人被多个任务占用、等待一份接口文档、等待一个客户签字的审批。这些东西在标准项目计划表里根本没有字段可以承载。

判断三：依赖管理的终局不是"管住依赖"，而是"减少依赖"。把一条外部依赖从 11 天压缩到 8 天，收益有限；把这条依赖改成两个可并行的工作包，收益是结构性的。前者是管理动作，后者是设计动作。

2. 一个我反复使用的概念：依赖债

我借鉴技术债的思路，把"未被识别、未被记录、未被闭环的依赖关系"称为依赖债。它的特性和技术债几乎一样：前期几乎无感，后期集中爆发，而且利息随项目推进指数级增长。

一条在第 1 周就被记录的依赖延迟，处理成本可能只是调整一下计划顺序；同一条依赖如果到第 20 周才被发现，处理成本就变成了加班、加人、客户投诉、甚至验收延期。我用自己经手的项目数据做了个粗略估算，把"依赖发现时点"和"单位修复成本"做了对比。

结论很直接：依赖管理的核心 KPI 不是"依赖总数"，而是"依赖的平均发现提前期"。我现在的团队内部有个硬指标，任何一条影响关键路径的依赖，必须在承诺交付日前 10 个工作日进入登记册并分配责任人。这条规则执行两年，项目平均延期天数从 19 天降到 7 天（样本为团队同期交付的 22 个项目）。

二、背景与真实场景：一个实施项目是怎么被一条依赖拖死的

抽象地讲依赖管理没用，我把上面那个 240 天项目的真实链路完整还原一遍。你会发现，拖死项目的从来不是"某个任务没做完"，而是一连串没人负责的缝隙。

1. 场景还原：11 天的审批延迟如何变成 23 天延期

项目背景是给一家离散制造企业上线 MES 和 ERP 的集成方案，涉及车间 6 条产线的数据采集改造。客户方需要协调设备厂商提供通讯协议文档，我们要基于这份文档开发数据采集接口。

计划阶段，我们识别出了"设备通讯协议文档 → 采集接口开发"这条 FS 依赖，也写了"由客户方 IT 部门协调"。问题是，"客户方 IT 部门"不是一个能承诺时间的责任人，它是一团人。

我后来复盘，这条链路上有四层放大效应：第一层是依赖方识别错误（把客户 IT 当成了决策方）；第二层是隐性资源依赖（唯一懂 PLC 的工程师被重复占用）；第三层是缓冲错配（缓冲加在了开发任务上，没加在审批依赖上）；第四层是变更后没有做影响面评估，直接压缩了测试时间。

2. 四种基础依赖类型在实施项目中的真实分布

教科书里的四种依赖类型必须掌握，但我要说的是它们的真实使用比例和团队认知严重不符。很多实施团队花大量时间建模 SS（开始-开始）和 FF（完成-完成）关系，实际上这类关系在实施项目里占比不到 15%。

• FS（完成-开始）：最常用，也是唯一被大多数工具默认支持的。适合"文档交付→开发启动"这类刚性前后关系。
• SS（开始-开始）：两项任务需同时启动才能对齐节奏，常见于"数据清洗"和"主数据校验"并行推进。
• FF（完成-完成）：两项任务需同时收尾，常见于联调测试与问题修复。
• SF（开始-完成）：极少用，实际项目中基本可以忽略，看到有人大量使用 SF，通常是建模方式出了问题。

3. 实施团队更该盯的三种隐性依赖

（1）资源依赖：同一技能持有者被多任务占用

资源依赖的可怕之处在于它不会在任何任务清单里显示为"依赖"。计划表上看，任务 A 在第 5 周、任务 B 在第 6 周，互不相干；但执行时两者都由同一个人完成，这个人一旦卡住，两条计划线同时断裂。

我在项目里推行过一个简单的检查动作：把项目里所有任务的"责任人"列出来做透视，凡是出现同一人在同一周被分配超过 3 个任务的情况，一律标红并要求重新排期或指定备份人。这个动作执行成本极低，但拦下的资源冲突至少占我见过的冲突总量的六成。

（2）信息依赖：等待一份文档、一个口径、一次确认

信息依赖的特点是等待方往往不认为自己"被阻塞"。开发同学会想"我在等客户确认字段口径，这很正常，我先做别的"。问题是，"先做别的"如果没有回报到计划里，就等于这条路线上出现了静默的进度黑洞。

现在我们的做法是：任何超过 2 个工作日的信息等待，必须录入依赖登记册，写明"等待什么、向谁等、承诺什么时候给、拿不到会影响什么"。这条规则听起来琐碎，但它把"正常等待"变成了"可追踪风险"。

（3）审批依赖：责任方在项目组外部

审批依赖是实施团队最难控制的一类，因为责任方不在你的汇报线内。客户的需求确认、监理的阶段性签字、第三方厂商的技术确认，都属于这一类。我的经验是把审批依赖单独建一个跟踪维度，并且强制要求"每个审批都要有具体到人的对接人"，而不是"客户方"这种无效责任人。

三、常见误区：五个坑，我几乎在每个项目里都能见到

下面这五个误区，我按"造成的平均延期天数"做了排序。数据来自我对团队近三年 22 个项目复盘的归类统计，属于样本观察而非行业调研，但趋势非常稳定。

1. 误区一：把甘特图当成依赖管理系统

这是最普遍的问题。甘特图擅长表达"什么时候做什么"，不擅长表达"这条依赖由谁负责、承诺什么时候给、断了怎么办"。一条画在图上的连线，信息量只有三个：起点、终点、时间关系。它无法回答"如果第 10 周还没拿到文档，我们怎么办"。

我见过团队把甘特图打印出来贴在会议室，每周开会盯着看，但没有任何一条依赖有明确的承诺时间和责任人。这不是管理，这是可视化安慰。

2. 误区二：只识别任务依赖，不识别人的依赖

任务依赖是"任务 A 完成后任务 B 才能开始"，人的依赖是"任务 A 和任务 B 都需要张三"。前者在计划表里，后者只在张三的脑子里。

很多项目经理会说"我知道张三很忙"，但"知道"和"记录在案并设置备份人"是两回事。我坚持的做法是：凡是关键路径上的任务，责任人必须有 B 角，且 B 角要参与至少一次该任务的评审。否则 B 角只是名字，不是备份。

3. 误区三：把外部依赖当成"对方的事"

我听过太多这样的话："文档没到我们也没办法，那是客户的事。" 这句话在情绪上成立，在管理上完全失效。外部依赖的交付责任在对方，但依赖的监控责任永远在你。

正确的做法是把外部依赖当成一条需要主动运营的线：提前多久提醒、由谁对接、卡住时升级到谁、有没有替代方案。这些动作你做了，对方可能还是晚，但你有预案；不做，就只能等。

4. 误区四：缓冲加错位置

传统排程习惯在每个任务后面加缓冲，比如开发 10 天加 2 天，测试 8 天加 2 天。这种做法的问题在于缓冲被分散消耗，且每个人知道有缓冲就会前松后紧。

更有效的做法是把缓冲集中放在依赖链的末端或关键交汇点。一条涉及客户审批、第三方配合、内部资源协调的依赖链，缓冲应该加在整条链的收口处，而不是链条中间的每个环节。这样缓冲可视、可控、可统一调配。

5. 误区五：依赖变更不做影响面评估

依赖关系一旦变化（比如审批延后、交付物范围调整、责任人更换），很多团队的做法是"口头同步一下"，然后各干各的。依赖变更的杀伤力不在变更本身，而在没人系统性评估它会波及哪些下游任务。

我给团队定的规则是：任何影响关键路径的依赖变更，必须在 24 小时内产出一份影响面清单，至少包含受影响任务、受影响责任人、新的关键路径、需要重新协商的承诺时间四项。这份清单不需要多精美，一张表就够，但不能没有。

四、专业判断逻辑：依赖全流程的四阶段判断标准

讲完问题和误区，我把依赖管理的全流程拆成四个阶段：规划期的识别与建模、执行期的监控与预警、变更期的应急与重排、收尾期的复盘与沉淀。每个阶段我只给一个核心判断标准，判断标准比动作清单更有用。

1. 规划阶段：判断一条依赖是否"识别完整"

我的判断标准是看这条依赖有没有凑齐五个字段。缺任何一个字段，这条依赖就不算被识别，只能算被提到。

1. 依赖对象：具体是哪个任务、哪份交付物、哪个审批动作。
2. 责任主体：具体到人和岗位，绝不能写"客户方""相关部门"。
3. 承诺时间：对方明确承诺的时间点，而不是"大概两周"。
4. 失效影响：如果这条依赖晚 5 天，会影响哪些下游任务和哪条关键路径。
5. 应对预案：晚了之后的替代方案或降级方案是什么。

我把这五个字段做成了一个最小可用结构，可以直接用于任何工具的自定义字段或轻量表格。下面的示例是 YAML 格式的字段定义，可以直接作为登记册模板的骨架。

dependency_record:
id: DEP-2024-0317 # 依赖唯一编号，便于跨文档引用

name: "设备通讯协议文档交付"

type: external_approval # external_approval / info / resource / task

depends_on_task: "采集接口开发"

owner_name: "客户 IT 张工" # 必须具体到人

owner_org: "客户方 IT 部门"

escalation_to: "客户方项目总监"

promised_date: "2024-05-20"

buffer_days: 3 # 单独为审批类依赖设置的缓冲

impact_if_late: "关键路径顺延，UAT 压缩，验收风险等级升高"

fallback_plan: "先用模拟数据开发，接口层做适配器隔离"

status: tracking # tracking / at_risk / broken / closed

last_check_date: "2024-05-13"

这张表看起来朴素，但它把"依赖"从一句口头共识变成了可查询、可筛选、可预警的数据对象。这是我见过投入产出比最高的一个动作。

2. 执行阶段：四个预警信号比进度百分比更有用

执行期最忌讳只看"完成了百分之多少"。依赖风险的预警信号往往是间接的，我总结出四个信号，只要出现一个就应该立刻核查。第一个信号是责任人对延迟原因的描述开始变得模糊，比如从"文档已经到设备厂商了"变成"客户还在走流程"。描述变模糊通常意味着信息链条断了一环。

第二个信号是关键路径任务的承诺时间被第二次推迟。第一次推迟可以视为正常波动，第二次推迟基本可以判定这条依赖已经失控，需要升级处理。

第三个信号是某个人的任务清单在同一周内被塞进三个以上关键任务。这是资源依赖即将爆发的典型前兆，必须在爆发前拆分或调整，而不是等人扛不住。

第四个信号是依赖相关的沟通记录超过 5 天没有更新。依赖是活的，超过一周没有新进展的依赖，实际上已经处于无人看管状态。

3. 变更阶段：断裂后的 72 小时应急机制

依赖一旦断裂（对方明确无法按承诺时间交付），我要求团队在 72 小时内完成四件事，顺序不能乱：

• 0-8 小时：确认影响边界。不是重新排整个计划，而是只回答一个问题，这条依赖断裂会波及哪些下游任务，哪条关键路径会被打穿。
• 8-24 小时：评估替代方案。从降级交付、并行变串行、切换责任方、局部外包四个方向找可行解，哪怕方案不完美也要有。
• 24-48 小时：与所有受影响方重新协商承诺。这里的关键是同步协商，而不是逐级传递，否则信息会在传递中失真。
• 48-72 小时：更新登记册并重新标记关键路径。如果这一步没做，72 小时后团队就会退回到"凭记忆干活"的状态。

这套机制我执行了两年，最大的收益不是减少了延期，而是把延期从"突然爆发"变成了"可预期的滚动调整"。团队不再在验收前两周手忙脚乱，而是在依赖断裂当周就知道后果和代价。

4. 收尾阶段：依赖复盘要产出可复用的东西

大多数团队的复盘停留在"这次哪里没做好"，产出的是一份情绪文档。我的要求是收尾阶段必须产出两样东西：一份依赖失效清单（哪条依赖失效、失效原因分类、当时是否有预案、预案是否有效），以及一套更新后的依赖检查清单（下次做同类项目时，哪些依赖必须提前识别）。

五、案例与数据观察：用工具把依赖真正管起来，到底改变了什么

前面讲的都是方法和判断，这一节讲落地。我拿团队实际用过的方式做对比，包括轻量表格、传统排程工具，以及我们后来采用的 PingCode。

1. 为什么我们把依赖管控从表格搬到了工作流平台

我们最早的方案是 Excel 依赖登记册 + 一张甘特图。这个方案在单项目、20 人以内的场景完全够用，成本几乎为零。但当我们同时跑 5 个交付项目、涉及 4 个部门、团队规模超过 100 人时，Excel 方案开始失效，问题集中在三点。

第一，依赖无法跨项目可见。A 项目的依赖方可能正是 B 项目的关键资源，这在两张独立的表里永远看不出来。第二，依赖状态不会自动更新。任务完成了要手动去改登记册，一旦有人忘了改，整张表就失去可信度。第三，依赖变更没有自动通知。依赖时间一改，受影响的下游责任人不会收到任何提醒，全靠群里吼。

这也是我们后来把依赖管理搬到 PingCode 的直接原因。PingCode 主要服务中大型企业及 100 人以上组织，而"跨项目可见性"和"自动化通知"恰恰是这类规模团队绕不过去的两个需求。当团队人数超过 100 人、并行交付线超过 3 条，依赖管理就从一个"方法问题"变成了一个"平台能力问题"。

2. 依赖登记册 vs 甘特图：两种方式的实测对比

我在团队里做过一次小范围的对照实验。同一个交付部门，两条业务线，A 线继续用"甘特图 + 周会"管理依赖，B 线改用"依赖登记册 + 平台自动化预警"，跟踪 4 个月，对比结果如下。

这次对比的样本量不大，只有两条业务线、4 个月，不能当成严谨的行业结论。但差异方向非常一致，尤其是"依赖平均发现提前期"这一项，从 3 天到 11 天，直接决定了后面所有指标。

3. 跨团队依赖的接口人机制怎么落地

跨团队依赖是实施项目的最大公约数痛点。我们的解法很土：每一条跨团队依赖，双方各指定一名接口人，接口人不是审批人，是信息同步责任人。接口人的职责只有一个，保证依赖状态的更新在 24 小时内同步到双方。

这个机制的关键在于，接口人必须在系统里有对应的位置。我们在 PingCode 里为每条跨团队依赖建立了独立的工作项，指定双方接口人为关注人，任何状态变更、时间调整都会自动通知到人。这比在群里 @ 全员有效得多，因为群消息会被淹没，而工作项通知不会。

执行这个机制之后，跨团队依赖的平均响应时长从 3.2 天降到 0.8 天。更重要的是，依赖变更的影响评估覆盖率从 34% 提升到 91%，因为评估动作被固化成了状态流转的一个必经节点，不做就无法关闭这条依赖。

4. 中大型实施团队绕不开的两个现实约束

我在给同行做咨询时发现，100 人以上的实施组织在选工具时，真正卡住他们的往往不是功能，而是两个现实约束。

（1）数据主权与私有化部署

实施项目常常接触客户的业务数据、生产数据、财务口径。很多客户的合同里明确要求实施方的项目管理数据不得存储在境外或第三方公有云。PingCode 支持私有化部署，这一点对服务大型制造、金融、能源客户的实施团队来说是硬门槛。不是"更好"，是"能不能用"的问题。

（2）从既有工具平滑迁移

很多团队此前长期使用 Jira，工作项、看板、迭代数据都在里面。迁移的最大成本不是数据搬运，而是流程重建和历史可读性。PingCode 支持 Jira 平滑迁移，这是国产替代场景下最实际的考量之一。我见过团队因为迁移成本太高而放弃换工具，最后继续在旧系统上打补丁，依赖管理能力始终上不去。

我的判断很简单：如果团队规模在 30 人以下、并行项目不超过 2 个，轻量表格完全够用，不必上平台；一旦跨过 100 人、多个交付线并行的门槛，依赖管理就必须依赖平台能力，否则你管理的是文档，不是风险。

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

依赖管理没有万能方案，我按四种典型场景给出可执行的建议。你可以直接对号入座。

1. 小团队（10 人以下、单项目）

不要上复杂工具。用一张表格管理依赖就够，但表格必须包含前面讲的五个字段。每周固定一次 20 分钟的依赖站会，只过三件事：哪条依赖承诺时间变了、哪条依赖超过 5 天没更新、哪条依赖本周到期。

这个规模下，最大的风险不是工具有没有，而是"大家觉得项目小、不用管依赖"。我见过 6 个人的项目因为一个客户确认动作没人跟，硬生生拖了三周。

2. 中型团队（30-100 人、多项目并行）

这个阶段的重点是从"记依赖"转向"看依赖"。你需要的是依赖的聚合视图：哪些依赖本周到期、哪些依赖处于风险状态、哪些人的任务负载超标。建议至少做到依赖与任务在工作流系统中关联，而不是两张皮。

同时要开始建立"依赖变更的影响面评估"动作，因为这个规模的团队里，靠口头同步已经很容易失真。

3. 中大型组织（100 人以上、跨部门多交付线）

这个规模必须依赖平台能力。核心需求有三条：跨项目依赖可见、状态变更自动通知、依赖状态可统计可复盘。这三条靠表格和会议无法稳定实现。

选型时我建议重点验证四件事：能不能跨项目建立依赖关系；能不能为依赖单独设置自定义字段和状态流转；变更能不能自动触达相关人；有没有私有化部署选项。PingCode 在这四点上的完整度，是我在做中大型实施团队选型评估时比较认可的一档，尤其是私有化部署和 Jira 平滑迁移这两项，直接决定了能不能真正落地。

4. 甲方强管控型项目（外部依赖占比高）

这类项目的依赖管理重心完全在外部。我建议单独建立"外部依赖台账"，与内部依赖分开管理，并且给每条外部依赖设置三级升级路径：日常对接人 → 对方部门负责人 → 双方项目高层。

同时，外部依赖的缓冲要单独设置，不能和内部任务共用。经验值是把审批类依赖的缓冲设置为其承诺周期的 20%-30%，信息类依赖设置 10%-15%，内部资源类依赖则通过备份人机制解决，不依赖缓冲。

七、不同情况下的取舍：没有"全都要"的方案

方法的尽头是取舍。依赖管理涉及的四组取舍，我在不同项目里做过不同选择，没有一次是标准答案。

1. 缓冲 vs 并行：工期与成本的取舍

加缓冲意味着工期变长，客户端通常不接受；强行并行意味着风险敞口变大，团队端通常不接受。我的取舍原则是：关键路径上的依赖加缓冲，非关键路径上的任务做并行。因为关键路径的延迟没有替代方案，而非关键路径的并行失败通常还有腾挪空间。

具体到数值，我一般把关键路径依赖的缓冲设定为总工期的 8%-12%，这个比例在很多客户合同里是可以谈下来的，因为它对应的说辞是"风险准备金"而不是"效率损失"。

2. 解耦 vs 协同：架构自由度与协作成本的取舍

依赖解耦有四种常见策略，我按成本从低到高排列如下，实际项目中我通常优先用前两种。

• 预置化：在依赖正式交付前，先用模拟数据或桩模块把下游工作推进一部分。成本最低，收益直接。
• 模块化：把强依赖拆成接口清晰的模块，各自独立推进，最后集成。适合有架构能力的团队。
• 并行化：把串行依赖改造为并行任务，需要额外的协调成本，适合有成熟协作机制的团队。
• 替代化：为关键依赖准备备选供应方或备选方案。成本最高，通常只对最高风险的少数依赖使用。

需要强调的是，解耦不是免费的。每一次解耦都会增加接口定义、联调测试、一致性维护的成本。我在一个项目里为了解耦一条外部依赖，额外投入了 15 人天做适配层，最终节省了约 9 天工期。这笔账是否划算，取决于那 9 天对交付节点的意义。

3. 工具管控 vs 轻量自管：规范性与灵活性的取舍

工具管控的收益是可追踪、可统计、可传承；代价是录入成本、学习成本和流程刚性。轻量自管的收益是灵活、启动快；代价是依赖随人员流动而流失。

我的判断标准是看团队的人员流动率。流动率低、核心成员稳定的团队，轻量自管的隐性成本可控；流动率高的团队，不把依赖沉淀到系统里，等于每次换人都要重新踩一遍坑。

4. 私有化 vs SaaS：安全合规与运维成本的取舍

服务大型客户、涉及敏感数据的实施团队，私有化部署往往是硬性要求，没有讨论空间。代价是需要有人负责部署、升级、备份，运维成本真实存在。

纯 SaaS 方案在中小项目和内部工具场景下更省事，但如果你的客户合同里出现数据本地化条款，这个选择就不成立了。我的建议是在选型早期就把这条约束确认清楚，而不是等签约后才发现要换工具。

八、四个高频追问

1. 依赖管理和关键路径法是什么关系？

关键路径法是基于依赖关系计算出来的结果，依赖关系是输入，关键路径是输出。很多人反过来做，先定关键路径，再去找依赖，这是倒因为果。正确顺序是先完整识别依赖、建立依赖网络，再让工具或人工计算出哪条链路最长、哪条链路最没有浮动时间。依赖识别不全，关键路径一定是错的。

2. 依赖关系变更后，最快多久要调整计划？

我的经验值：影响关键路径的依赖变更，24 小时内出影响面清单，72 小时内完成重新协商和计划更新。不影响关键路径的变更，可以纳入每周的例行依赖评审。

这里的关键不是速度本身，而是速度的一致性。如果团队有时 3 天响应、有时 2 周响应，下游就永远无法判断这条依赖是否可信。

3. 有没有必要为每条依赖都设缓冲？

没有必要，而且有害。为每条依赖设缓冲会导致缓冲总量被稀释，真正需要时反而无余量可用。我的做法是只对关键路径上的依赖、以及历史失效率高的外部依赖设置缓冲，其余依赖通过预案和备份人机制应对。

4. 依赖管理做得好，能完全避免项目延期吗？

不能。依赖管理能解决的是"可预见的依赖风险"，无法解决需求根本性变更、技术方案失败、客户组织调整这类结构性冲击。但它的价值在于：当冲击来临时，你知道哪些部分还在掌控中，哪些必须放弃，而不是全线失控。我经手的项目里，依赖管理做得好的项目延期天数通常更少，但更重要的是，这些项目在延期发生时损失可控，且团队不崩溃。

九、结尾：依赖管理的终局是"少依赖"

回到开头那个延期 23 天的项目。如果当时我们做了三件事，把审批依赖的责任人从"客户 IT 部门"落到具体的人身上、为唯一懂 PLC 的工程师指定备份人、把缓冲从开发任务挪到审批依赖的收口处，我判断至少能挽回 12 到 15 天的延期。这不是事后聪明，这些动作在当时都完全具备执行条件。

所以我对依赖管理的最终看法是：它不是一门排程技术，而是一套把"不确定性"变成"可管理对象"的工作方式。你识别得越早，成本越低；你记录得越具体，责任越清晰；你闭环得越彻底，组织积累越厚。

而真正的终局，是从"管理依赖"走向"设计依赖"。管理依赖是让既有的依赖尽量不失效，设计依赖是从一开始就减少关键依赖的数量，把串行改并行、把外部依赖拆成可控模块、把单点技能变成团队能力。少一条依赖，就少一个可能让整个项目停摆的单点。

如果你现在就要动手，我建议按这个顺序做三件事：今天就把当前项目的所有依赖列出来，检查每一条是否具备"责任主体、承诺时间、失效影响"三个字段；本周内给关键路径上的每条依赖指定一个具体到人的责任人；下个项目启动时，把依赖登记册作为立项交付物之一，而不是等出问题再补。

依赖管理这件事，从来不是等你想清楚了才开始，而是从你写下第一条有责任人的依赖那一刻就开始生效。