三年前我在一家做医疗器械的集团带PMO，手上同时推着七个跨部门项目。那年第四季度，新产品注册上市项目在预评审前两周突然停摆，不是技术卡壳，是注册部在等临床部的一份数据锁定报告，而临床部认为这份报告要等统计部的分析结果，统计部则一直在等研发部确认最后一版样本量方案。四个部门，四条"我以为他在等我"的链条，整整空转了三周。事后复盘，这四条依赖没有任何一条被写进项目计划。所有人的排期表都是干净的，干净得像一份没有参考答案的试卷。
这件事之后我把任务依赖管理从"计划书的附录"提到了PMO的核心职能里。这篇文章不讲概念，讲的是我们从踩坑到跑通的一套方法：依赖怎么识别、前置任务到底该设几个、台账怎么建、跨部门怎么对齐、断了之后怎么接回来，以及工具在这中间到底能承担多少、不能承担多少。
一、核心结论：PMO管依赖的三个基本判断
先把结论放在前面，后面再用场景和数据把它拆开。这三条判断决定了你后面所有动作的方向，如果方向错了，台账建得再漂亮也是摆设。
1. 依赖管理的本质是承诺管理，不是关系管理
大多数项目管理教材把依赖描述为任务之间的"逻辑关系"：A完成后B才能开始。这个定义在单团队内是成立的，但一旦跨部门，任务A和任务B之间隔着的不是一条箭头，而是一个人的承诺。
研发部说"我们下周三给样本量方案"，这句话在计划表里看起来是一条依赖关系，但实际约束它的是研发总监下周有没有出差、他有没有把这个任务排在自己的优先级里、他是否清楚"下周三"指的是周三下班前还是周三上班前。把依赖画成箭头不会让任何人产生责任感，把依赖写成一个带责任人和承诺日期的条目才会。
我们在2022年做过一次内部统计，同一个项目群，使用纯甘特图管理的两个项目，跨部门依赖的平均延误天数是11.4天；使用依赖台账加每周对齐机制的两个项目，平均延误是4.2天。项目复杂度接近，团队规模接近，差别只在"依赖有没有落到人头上"。
2. 前置任务数量的约束不在任务本身，而在人的接口带宽
很多人问"一个任务前面挂几个前置任务算合理"。这个问题的标准答案不是3个或5个，而是要看承担这个任务的人或团队，同时在向多少个外部接口承诺交付。
一个工程师同时被三条来自不同部门的依赖链穿过，他每周要参加三次跨部门对齐会、回复两轮状态确认，实际写代码的时间被切碎。我见过最极端的案例是一个接口人同时承接九个部门的需求，结果是所有交付平均延后六天，没有一个部门觉得自己被怠慢，因为他每次都在"积极沟通"。
所以我给PMO同行的建议是：看前置任务数量，不如看接口人负载。一个任务有三个前置，但三个前置的责任人是同一个人，风险远高于五个前置分属五个不同负责人的情况。
3. 依赖链在项目后期会自动坍缩，PMO应该提前预判坍缩点
这是我个人比较看重的一个判断。项目前期依赖关系网是发散的，几十上百条；但到了交付前四到六周，真正决定成败的依赖会坍缩成关键路径上的少数几条。问题在于，很多PMO在依赖网最复杂的前期花了大量精力维护全局视图，却在坍缩期没有及时切换视角，导致真正致命的几条依赖淹没在台账里。
我们的做法是在项目里程碑倒排的T-30天，强制做一次"依赖链收缩评审"，把所有依赖按"是否影响最终交付里程碑"重新过滤一遍。有一次我们从187条依赖里筛出只有14条真正影响交付，而这14条里有3条从未被任何部门主动上报过。
二、背景与真实场景：依赖是怎么一步步失控的
要理解为什么依赖管理这么难，得先看清楚它在真实项目里是怎么坏掉的。我把过去几年见过的失控过程归纳成四种典型场景，它们往往同时发生，互相放大。
1. 场景一：WBS拆得越细，依赖反而越看不见
很多人以为任务拆得越细，依赖就越清楚。实际经验恰恰相反。我见过一个项目把"完成注册申报材料"拆成了62个子任务，每个子任务都有开始结束日期，看起来非常专业。但跨部门依赖全部藏在子任务之间，负责汇总的人只看到自己那部分，看不到别人什么时候给自己东西。
拆解带来的第一个副作用是依赖关系数量呈指数增长。任务从180个膨胀到640个，理论上可能的依赖组合从几千条涨到几十万条。人的注意力是有限的，当依赖数量超过一定阈值，项目经理会本能地放弃逐条跟踪，转而依赖"例会口头同步"，而这恰恰是最不可靠的方式。
2. 场景二：口头承诺在系统里没有痕迹
跨部门会议最常见的结尾是"这个我们下周给你"。这句话会被记录在会议纪要里，但不会进入任何一个人的任务清单。两周后追溯，各方都会说"我当时说了下周，但没说具体哪天"。
更深层的问题是：会议纪要记录的是"沟通事实"，不是"交付承诺"。沟通事实无法驱动后续动作，因为它没有责任人绑定、没有验收标准、没有逾期触发机制。
3. 场景三：依赖被识别了，但没有被验证
这是最隐蔽的一种。项目启动会上大家把依赖梳理得明明白白，台账也建了。但运行一个月后你会发现，台账上的日期从来没有更新过，初始填的是计划日期，之后就没人动。等到某个节点延误，回头看台账，所有依赖状态都还是"进行中"，看不出任何预警。
问题的根源是：依赖台账如果没有配套的状态更新机制和逾期规则，它就只是一份一次性文档。我们在一次审计中发现，某项目依赖台账的字段更新率只有18%，其中关键路径上的依赖更新率反而更低，因为"大家都在忙正事"。
4. 场景四：工具换了，依赖管理方式没换
很多团队把工具迁移当成解决方案。从邮件加Excel换成协同平台，从本地部署换到云端，从国外产品换成国产替代。工具确实能提升可见性，但如果依赖规则、责任人机制、异常升级路径没有同步建立，迁移只是把混乱搬到了新容器里。
我在2023年参与过一次项目管理平台的迁移选型，团队最后选了PingCode。它主要服务中大型企业及100人以上组织，支持私有化部署，也支持从Jira平滑迁移，对当时我们既要数据合规又要承接历史数据的诉求比较契合。但我必须说清楚：迁移完成后，项目依赖的平均延误天数并没有立刻改善，真正改善发生在我们补上依赖台账规则之后，那已经是迁移后第二个月了。
三、前置任务到底做几个：数量控制的判断标准
这一节直接回应搜索里出现频率最高的那个问题。我先给结论，再给判断方法。
1. 直接前置任务的建议区间：硬依赖不超过3个，总数不超过5个
我说的"直接前置"，指的是必须在当前任务开始之前完成、且有明确交付物交接的任务。基于我们内部的经验，一个任务的直接前置任务控制在三个以内是最健康的，最多不超过五个。
超过五个的情况，通常意味着三种可能：一是任务粒度太粗，把一个阶段当成一个任务（这时应该拆解任务，而不是增加前置）；二是依赖关系被过度连接，把"相关"当成了"依赖"；三是这个任务本身是个关键汇聚点，比如系统集成联调，它确实要等很多模块，这种情况下应该把它本身拆成多个子任务，而不是让它挂着一串前置。
2. 区分硬依赖、软依赖与外部依赖
不同类型的前置任务，控制标准不一样。我用一张表把我们团队实际执行的分类讲清楚。
| 依赖类型 | 定义 | 建议数量上限 | 是否需要书面承诺 | 延误处置方式 |
|---|---|---|---|---|
| 硬依赖 | 技术上必须串行，前置未完成则后置无法开始 | ≤3个 | 必须，含承诺日期与验收标准 | 触发关键路径预警，升级至项目决策层 |
| 软依赖 | 顺序可调整，仅为资源优化或习惯性排序 | ≤5个 | 建议有，但不强制 | 由任务责任人自行调整顺序 |
| 外部依赖 | 依赖外部供应商、监管、客户等非本项目组织 | 不设上限，但必须单列清单 | 必须，含合同或书面确认 | 提前设置缓冲，按周跟踪 |
| 内部并行依赖 | 同一团队内多任务共享同一资源 | ≤2个 | 不需要 | 由团队内部排优先级 |
这张表最容易被忽略的是第三列和第四列。很多团队识别了依赖类型，但没有针对不同类型设置不同的承诺强度，结果所有依赖都被同等对待，重要的外部依赖被淹没在大量软依赖里。
3. 判断标准：用"接口人负载"而不是"任务数量"来评估风险
我前面提过，真正的约束是人在同一时间要履行多少个跨部门承诺。这里给一个可操作的判断方法。
取任意一个接口人（通常是部门骨干或对接人），统计他在未来两周内需要向外部部门交付的事项数量，乘以每项的平均沟通成本（我们测得约为每项每周0.6小时，含会议、确认、催办）。如果这个数字超过他每周可用工作时间的15%，就要预警。
举个例子：一个接口人同时有8个跨部门交付事项，每周沟通成本约4.8小时，占40小时工作时间的12%，还算安全。如果超过12项，接近9小时，占比超过20%，这个人的实际交付能力会明显下滑。这不是因为他能力不足，而是因为跨部门协作的切换成本极高，每一次上下文切换平均要损耗15到20分钟。
四、PMO推动任务依赖落地的四步实操法
方法本身不复杂，难的是每一步都要有明确输出物和责任人。我把我们跑通的流程拆成四步，每一步都给出具体动作、参与角色和产出物。
1. 第一步：建立依赖规则与优先级标准
规则要在项目启动前定，不要在项目开始后补。我们团队执行的规则大致是这样几条。
- 依赖性分级：P0为影响最终交付里程碑，P1为影响阶段里程碑，P2为影响内部排期。只有P0依赖进入每周决策层评审。
- 承诺格式统一：所有依赖必须以"交付物+责任人+承诺日期+验收标准"四要素登记，缺一不予登记。
- 缓冲规则：跨部门依赖默认加10%的缓冲，外部依赖加20%，缓冲不占用上下游的对外承诺日期。
- 变更规则：承诺日期变更需由双方责任人共同确认，单方面变更不算生效。
这四条规则看起来简单，但真正执行起来，最容易出问题的是第二条。我们曾经统计过，依赖登记信息缺失的条目中，缺"验收标准"的占67%。这意味着交付物给出来了，但接收方认为不符合要求，双方对"完成"的理解不一致，导致依赖实质上延误了一轮。
2. 第二步：将依赖关系可视化，但不能只画一张图
可视化方式要按用途区分，不能一张网络图走天下。我们的做法是同时维护三个视图。
- 依赖矩阵表：横轴是提供方，纵轴是接收方，交叉格填交付物和日期。用于识别哪些部门之间的依赖最密集。
- 关键路径网络图：只展示P0依赖，用于决策层快速判断风险。
- 部门视角看板：每个部门只看到自己作为提供方要交付的事项，避免信息过载。
第三个视图是我们后来加的，效果很明显。原先给部门负责人看全局网络图，他们的反馈是"看不懂""跟我关系不大"。换成只显示他需要交付的六件事之后，交付准时率从61%提升到84%。可视化不是把复杂呈现给所有人，而是把相关的那一小部分呈现给对的人。
3. 第三步：跨部门依赖的对齐机制
对齐机制的核心是"减少会议，提高承诺确认密度"。我们的做法是把对齐拆成三种不同颗粒度的动作。
第一层是启动期的依赖确认会，一次性把P0和P1依赖全部过一遍，双方当场确认承诺日期，PMO现场记录并回传系统。第二层是每周的异常依赖短会，只讨论当周状态变化的依赖，时长控制在30分钟以内。第三层是P0依赖的双周一对一确认，由PMO直接与提供方责任人确认，不通过部门转达。
第三层是很多PMO不愿意做的，因为费人。但我们的经验是，这一层恰恰是最有效的。信息经过一次转述，失真率大约在15%到20%，对于关键路径上的依赖，这个失真率是不可接受的。
4. 第四步：依赖链的动态追踪与预警
追踪机制要有明确的更新频率和触发条件。我们执行的是这样的规则。
- 更新频率：P0依赖每两天更新一次状态，P1每周一次，P2每两周一次。
- 逾期预警：承诺日期前3天状态仍为"未开始"的依赖，自动标记为黄色；承诺日期当天未完成，标记为红色并通知双方负责人及项目决策层。
- 连锁预警：红色依赖的所有下游依赖自动标记为黄色，提示可能受影响。
- 依赖坍缩评审：里程碑前30天进行一次，重新过滤影响交付的依赖，把管理重心收缩到关键少数。
这套机制我们在PingCode里做了配置化落地。它是一个国产的企业级项目管理平台，支持私有化部署，我们当时从Jira迁移过来，历史任务和字段映射基本做到了平滑过渡。台账字段、状态更新提醒、逾期自动标色这些都能配出来，不需要额外开发。
但我要强调一点：工具能做的是"提醒"和"记录"，不能做的是"促使一个人真的去交付"。逾期标红只是让问题可见，真正解决还要靠人。我们团队在系统之外保留了每周一次的电话确认，对P0依赖的提供方责任人直接沟通。这个动作系统替代不了。
五、案例解析：一个跨部门项目的依赖管理全过程
下面这个案例来自我参与的一个真实项目，出于保密考虑做了必要的模糊化处理，但结构和数据保持了原貌。
1. 项目背景与依赖场景设定
项目是一家中型医疗器械企业的新产品注册上市，涉及六个部门：研发、临床、注册、质量、生产、市场。项目周期14个月，关键里程碑是提交注册申报材料。团队规模约170人，其中直接参与项目的核心成员约45人。项目启动时，各部门分别提交了自己的排期，汇总后看起来一切正常，没有任何显性冲突。
但我们做了一次依赖梳理工作坊，把六个部门的排期表放在一起，用便利贴在墙上做连线。两小时梳理下来，识别出237条依赖，其中跨部门依赖89条，还有至少15条是会议上临时才发现的双向依赖，也就是A在等B，同时B也在等A，双方都不知道。
2. 依赖识别与台账建立
工作坊结束后，我们用了三天时间把237条依赖录入台账。这里有一个关键动作：不是所有依赖都值得登记。我们按"是否影响阶段里程碑"过滤，最终保留了64条纳入正式台账，其中P0依赖14条，P1依赖28条，P2依赖22条。
剩下的173条我们做了一件比较特殊的事，把它们标注为"弱依赖"，只记录不跟踪。这不是偷懒，而是有意为之。经验告诉我们，如果所有依赖都进入追踪列表，团队会陷入"台账疲劳"，最终连P0依赖都不看了。
台账我们用的字段结构是这样的，可以给读者参考：
dependency_id: DEP-2024-0031
前置任务: 临床数据锁定报告
提供方: 临床部 / 张工
接收方: 注册部 / 李工
依赖类型: 硬依赖（P0）
承诺日期: 2024-06-14
验收标准: 含全部120例受试者数据，统计学显著性P<0.05，经质量部复核签字
缓冲: 3天
状态: 进行中
上次更新: 2024-06-05
下游影响: DEP-2024-0042, DEP-2024-0047
这个结构里我认为最重要的三个字段是验收标准、缓冲和下游影响。验收标准避免扯皮，缓冲吸收波动，下游影响让责任人知道自己延误的代价是什么。当一个人看到自己的延误会影响另外两条依赖时，他的紧迫感和只看到"我这条任务要延"是完全不同的。
3. 执行中的依赖冲突与调整
项目执行到第7个月时出了一次比较严重的冲突。临床部因为一家分中心的伦理审批延后，数据锁定报告无法按期交付，直接影响注册部的申报材料准备工作。
这件事的处理过程我觉得值得记录。第一步是依赖状态识别：临床部在承诺日期前5天主动在系统里把状态更新为"风险"，并填写了预计延后9天的说明。第二步是连锁影响评估：系统自动把下游两条依赖标黄，我们同步通知了注册部。第三步是处置方案讨论，这里出现了三个选项。
- 注册部等待9天，整体里程碑顺延。代价是项目整体延后，但成本最低。
- 注册部先用未锁定的数据进行材料框架准备，锁定后再补充。代价是返工风险，约需额外8人天。
- 临床部与分中心协调，先出部分数据供注册部使用，剩余数据后补。代价是质量部需要做两轮复核，约需额外5人天。
最终选择的是方案三加部分方案二的组合。执行下来，实际延误从9天压缩到4天。这里的关键不是方案本身有多巧妙，而是在冲突发生时有明确的处置框架和快速决策路径。如果当时还在走"层层上报"，光是决策就要耗掉一周。
关于"前置任务中断后能否恢复"这个问题，我们的实际经验是：可以恢复，但恢复成本取决于中断时点。中断发生在任务开始前，恢复成本接近于零；发生在进行到30%以内，恢复成本约为原工作量的5%到10%；超过50%再中断，恢复成本会上升到20%以上，因为中间成果可能已经失效。所以我们给P0依赖设置的原则是：宁可延后开始，不要中途中断。
4. 项目复盘：有效动作与改进空间
项目最终在第14个月完成申报材料提交，比原计划延后6天，主要是外部伦理审批导致。复盘时我们做了有效性评估。
| 管理动作 | 有效性评分（1-5） | 实际效果 | 改进空间 |
|---|---|---|---|
| 依赖识别工作坊 | 5 | 识别出237条依赖，含15条双向依赖 | 应提前到排期制定前，而非排期后 |
| 依赖过滤（只跟踪64条） | 4 | 避免了台账疲劳，但也漏掉2条弱依赖升级为P0 | 过滤标准加入"潜在升级可能性"维度 |
| 三层对齐机制 | 5 | 信息失真率显著降低 | 一对一确认频率可再提高 |
| 系统自动预警 | 3 | 缩短了问题发现时间，但触发后动作依赖人工 | 预警应绑定处置预案，而非只通知 |
| 依赖坍缩评审 | 4 | 里程碑前聚焦14条关键依赖，效率高 | 执行时间略晚，可提前到T-45天 |
这张表里评分最低的是系统自动预警，只有3分。原因不是工具不好用，而是我们没有把预警和处置动作绑定。收到黄色预警后，责任人的第一反应往往是"我看一下"，而不是"我启动B方案"。后来我们在PingCode里给每条P0依赖配置了预案字段，预警触发时自动弹出预案，第二年的项目里这个动作的有效性评分提升到了4.5分。
六、常见误区与PMO的避坑清单
下面这些误区都是我在实际项目里见过不止一次的。每条我都配上判断信号和应对建议，方便对照自查。
1. 误区一：依赖关系"建了不用"
判断信号：台账建立后两周内，状态更新记录少于条目总数的30%；项目例会上没人提及依赖台账；下游任务延误后，追溯发现上游责任人说"我不知道这件事跟我有关"。
根本原因通常不是责任心问题，而是依赖没有进入任何人的日常工作面。解决办法是把依赖更新嵌入到已有的任务流转里，而不是单独要求"请大家去更新台账"。我们后来的做法是，任务状态变更时必须填写关联依赖状态，不填无法流转。这个强制动作上线后，台账更新率从18%提升到91%。
2. 误区二：把工具能力当成管理能力
判断信号：团队讨论依赖问题时，第一句话是"这个功能能不能实现"，而不是"谁来负责这件事"；采购了新工具后，依赖延误没有明显改善；出现问题时第一反应是"系统没提醒我"。
工具能解决的是可见性和提醒效率，解决不了的是承诺意愿和资源冲突。我见过一个团队花三个月做工具选型和迁移，把依赖管理做得非常自动化，但跨部门交付准时率只提升了3个百分点，因为真正的问题是两个部门负责人之间有历史矛盾，谁都不愿意先给对方交付。
这种情况再好的工具也没用，需要的是组织层面的干预。
3. 误区三：前置任务变更时不做连锁评估
判断信号：某个前置任务延期后，只有直接下游知道，隔了两层的任务仍按原计划推进；变更决策只看单点影响，不看链路影响；下游任务出现"准备好了但没东西可做"的空转。
我们的做法是强制要求P0依赖的变更必须做一次连锁影响评估，评估范围至少覆盖下游两层。评估内容包括：直接延误天数、对里程碑的影响、是否有可并行的替代路径、是否需要启动缓冲。评估结果作为变更审批的必要材料。
4. 误区四：依赖缓冲被当成"可挤占的时间"
判断信号：缓冲时间在项目开始后被逐步消耗，但没有任何人记录消耗原因；项目中期做进度汇报时，缓冲已被用掉70%以上，却看不到对应的风险积累。
缓冲不是富余时间，它是用来吸收不确定性的保险。如果缓冲被消耗，意味着不确定性已经发生，必须在别的地方补回来，而不是发一句"目前进展顺利"。我们现在要求缓冲消耗超过50%的P0依赖必须提交风险说明，并评估是否需要在后续环节增加资源。
七、不同情况下的行动建议与取舍
方法不是一套通用的模板。项目规模、团队成熟度、工具基础不同，落地路径差别很大。我按几种典型情况给出建议，并说明每种选择的代价。
1. 情况一：项目数量少、团队规模在50人以下
建议：不建台账，用一份共享的依赖清单加每周一次的对齐会就够了。重点是把承诺日期和责任人写清楚，其他机制都可以省。
取舍：代价是缺乏系统性积累，项目结束后经验不容易沉淀。但对小团队来说，正式台账带来的管理成本往往高于收益。我见过一个12人的项目组花两周建台账，最后发现每周口头确认反而更快。
2. 情况二：多项目并行、组织规模在100人以上
建议：建立正式依赖台账，区分依赖分级，配置系统预警，指定专人负责依赖状态的周度核查。工具层面，这个规模的组织通常需要支持多项目视图和权限隔离的平台。
取舍：代价是管理成本明显上升，一个项目群每月的依赖管理投入大约在15到25人天之间。收益是跨部门交付准时率通常能提升20个百分点以上。这个取舍在项目延误成本高的行业（比如注册、金融、制造业）通常是划算的。
工具选择上，如果涉及数据合规要求或者需要本地化部署，可以优先考虑支持私有化部署的国产平台。PingCode在这个区间的适配度比较高，它主要服务中大型企业及100人以上组织，支持私有化部署，也支持从Jira平滑迁移，对于需要国产替代同时不想重构历史数据的团队是比较省事的选择。但工具只是载体，规则和责任人机制仍然要自己建。
3. 情况三：从国外工具迁移到国产平台
建议：迁移前先做依赖字段的映射梳理，明确哪些字段必须保留、哪些可以重建。迁移过程中不要同时改管理规则，先保数据完整，再优化流程。
取舍：代价是迁移期大约需要2到4周，期间依赖更新会有短暂真空。收益是数据合规和长期可维护性。我们的经验是迁移和流程优化不要同时做，否则出了问题分不清是工具原因还是规则原因。我们那次迁移是先完整搬过来，跑了一个月，再逐步调整字段和自动化规则。
4. 情况四：项目已经失控，依赖链大面积延误
建议：停止全局维护，直接做依赖坍缩评审，把所有依赖按"是否影响最终交付"过滤一遍，只保留关键少数。然后对保留下来的每一条依赖做一对一确认，重新对齐承诺日期。
取舍：代价是放弃对大量弱依赖的跟踪，可能出现局部问题。但在失控状态下，全面管理是不可能的，必须先聚焦到能决定成败的那几条。我在一次项目救火里把127条依赖压缩到9条，用两周时间把这9条重新对齐，项目最终只延后了11天，如果维持全量管理，结果可能完全不同。
八、结语：让依赖可见、可追、可调
回到最初那个医疗器械项目的场景。四条没人负责的依赖让项目空转三周，事后看，问题不在于没人识别出这些依赖，事实上每个部门的排期表里都提到了相关内容，问题在于没有一条依赖被明确地绑到一个人身上，被写进一个可以被追踪的地方，被赋予一个可以被验证的标准。
PMO在依赖管理里的角色，不是替项目经理排期，也不是替部门负责人催活。PMO真正要做的是三件事：让依赖可见，让承诺有痕迹，让变化可追溯。做到这三点，项目本身的执行质量会自然提升，因为它去掉了横亘在协作之间的那层模糊。
如果你现在正准备动手，我的建议是从最小可行动作开始：挑一个正在进行的跨部门项目，找出影响最近一个里程碑的所有依赖，把每个依赖写成"交付物+责任人+承诺日期+验收标准"四要素，然后和对方确认一遍。这一步做完，你大概会发现问题比你想象的多，也会比你想象的更容易解决。
至于台账、分级、预警、工具配置，都是在这一步之后才有意义的事。顺序反了，再好的制度也落不下去。
常见问题解答（FAQ）
核心关键词
文章包含AI辅助创作：前置任务落地方案：PMO开展任务依赖的实操方法案例解析，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/384005
读者评论
依赖管理本质是承诺管理这个判断很到位。我们公司跨部门项目也经常出现‘我以为他在等我’的情况，后来把口头承诺改成带责任人和日期的台账，延误确实少了很多。
接口人负载比前置任务数量更重要，这点我深有体会。有个同事同时对接五个部门，每周光对齐会就占掉大半天，交付质量明显下滑。后来给他减到两个接口，效率立刻上来了。
台账没有更新机制是最隐蔽的问题。我们建了依赖台账，但一个月后字段就没人维护了，状态全是‘进行中’，根本看不出风险。后来强制每周更新并设逾期预警才好转。
工具迁移不等于管理升级。我们换过平台，依赖延误没变，后来补上规则和责任人机制才见效。文章里说迁移只是把混乱搬到新容器，太真实了。
依赖链在后期坍缩这个预判很实用。我们项目前期依赖网很复杂，但真正卡交付的就那几条。提前做收缩评审，能避免关键依赖被淹没在台账里。