我做过一次完整复盘：5 个部门、28 个交付节点、计划工期 96 天，实际用了 137 天。把 41 天的偏差逐条归因之后，我发现一个很扎心的结论，真正被算法算错的关键路径，一天偏差都没有；出问题的全是那些"画在图上是我的任务、实际上是别人点头才能动"的节点。从那以后我就不再把关键路径当成一道计算题，它更像一场需要签字确认的承诺赛。
这篇文章不讲 A→B→C 工期相加的教科书例题，只讲一件事：跨部门场景下，任务依赖怎么从一张空白的白板，走到一张所有部门都认账的网络图。下面所有数据都来自我参与过的项目复盘，涉及推演的部分我会明确标注为示意数据。
一、先给结论：跨部门关键路径的成败，八成在"算"之前就决定了
很多人搜"关键路径怎么做"，默认自己缺的是算法。我先把这个假设推翻：算法是最容易的那部分，任何一本项目管理教材都能给你公式；真正难的是依赖关系有没有被外部团队真正承诺过。
1. 三条我反复验证过的结论
结论一：依赖不是顺序，是承诺。"B 在 A 之后开始"只描述了一个时间关系，它完全没有回答"谁对 A 的完成负责、A 完成的判定标准是什么、A 延期了谁来兜底"。跨部门项目里，这后半句才是关键。
结论二：关键路径是谈判结果，不是计算结果。CPM 算出来的最长链是"数学上的最长链"，能落地执行的是"各方都点头之后的长链"，两者经常不是同一条。
结论三：关键路径会漂移，而且漂移速度和你更新它的频率成反比。你一个月看一次，它就会在你看不到的地方悄悄换掉三四个节点。
2. 单部门 CPM 和跨部门 CPM 的五个本质差异
很多人把单部门项目里跑通的那套方法原封不动搬到跨部门场景，然后失败，原因是这两件事的底层假设完全不同。下面这张表是我在两次复盘后整理出来的差异清单。
| 对比维度 | 单部门 CPM | 跨部门 CPM |
|---|---|---|
| 依赖的决定权 | 同一负责人，可自行调整顺序 | 由外部团队承诺，必须协商 |
| 浮动时间的归属 | 本部门可支配 | 常被外部占用且无人告知 |
| 颗粒度的定义者 | 团队内部统一标准 | 各部门标准不一致，颗粒度相差数倍 |
| 偏差的可见性 | 每日可见 | 往往滞后 1-2 周才暴露 |
| 纠偏手段 | 加人、加班、调序 | 只能谈判、升级、换方案 |
看懂这张表，你就会明白为什么跨部门关键路径经常"算得准、跑不动"，差异不在计算环节，而在依赖的定义权和纠偏手段上。
3. 一个反常识的判断：算得越"准"，越容易失效
我见过最典型的失败案例，是项目经理花了两周把网络图做到近乎完美，精确到半天，然后这份图在两周内彻底作废。原因恰恰是它太精确了，精确到任何一个部门的实际进度变化都会让整张图失真，而没有人愿意承担"改图"的成本。
所以我的判断是：跨部门关键路径的初始版本，应该刻意保留粗糙度，只覆盖那些真正跨接口的节点，而不是试图把每个部门内部的任务都收上来。
二、真实场景：那张看起来很专业的网络图，第三周就废了
光说结论容易空。我把一个具体项目的完整过程拆开讲，包括我当时的错误操作。
1. 项目背景：5 个部门、28 个节点、96 天计划
项目是某业务中台的一次支付链路重构，涉及订单、支付、用户、风控、运维 5 个部门，我作为协调方，手下没有一个人是这 5 个部门的直属成员。计划工期 96 天，我用常规 CPM 做出了 28 个节点的网络图，识别出 9 个关键节点。
当时我很有信心，因为图做得很漂亮：任务名、工期、负责人、前置任务一应俱全，还用虚线标了浮动时间。现在回看，那张图最大的问题是，所有任务名都是"动作"，没有一个是"交付物"。
2. 第一周到第三周发生了什么
第一周基本正常。第二周开始出现第一次偏差：支付网关的接口文档比计划晚了两天，因为他们的技术方案需要内部评审，而这件事从来不在我的图里。
第三周连续爆发两次返工。一次是订单中心的开发已经启动，才发现支付回调的幂等规则还没定；另一次是测试环境被另一个项目占用，排期整体后移四天。三次事件没有一次来自"算错"，全部来自"图里没有的依赖"。
3. 依赖从识别到认账，中间漏掉了 78%
项目结束后我回溯了一遍依赖的完整生命周期，发现了一个更值得警惕的数字：最初通过访谈识别出的依赖有 86 条，但真正走到"三方确认并进入基线跟踪"的只有 19 条，流失率接近 78%。
流失发生在四个环节：识别但没记录、记录但没指定承接人、指定了但没确认、确认了但没进基线。每流失一层，关键路径的准确性就下降一档，而管理层看到的永远是最后那 19 条。
4. 复盘出的三种典型崩法
第一种是"隐性依赖漏算"。外部评审、变更审批、环境申请、安全扫描，这些都不是交付物，但都会占用工期，而且几乎不会出现在项目经理的第一版网络图里。
第二种是"伪关键路径"。因为大量依赖没被记录，你算出来的最长链其实是一条内部链路，真正的瓶颈（比如某个共享专家）藏在别人的排期表里，你根本看不见。
第三种是"关键路径无人认"。图是你的，工期是别人的。只要关键路径上的任务不由同一个组织考核，它在你这里叫"关键"，在对方那里叫"待排期"。
三、四个误区：多数人卡在"技术正确"上
下面四个误区，我在不同项目里反复见到，它们共同的特点是"在技术上完全正确，在跨部门场景里完全无效"。
1. 误区一：把"依赖"当成"顺序"
最常见的操作是把依赖写成"先做 A 再做 B"，然后把它填进前置任务字段。这在单部门里没问题，在跨部门里会直接丢掉三个关键信息：交付物是什么、由谁判定完成、延期了找谁。
我后来强制要求：每一条跨部门依赖必须能填满一句话，"某部门把某个具体交付物，在某个明确标准下交给某部门，超期由谁上报"。填不满这条依赖就不进基线。
2. 误区二：按组织结构切任务颗粒
很多团队切任务的方式是把部门名字写上去，然后每个部门各自往下拆。结果就是 5 个部门交上来 5 套颗粒度完全不同的清单：有的拆到人天，有的只写"完成开发"，合并的时候根本无法对齐，只能靠项目经理拍脑袋统一。
我的做法是反过来：先按"接口"切，再按部门分派。颗粒度的定义权必须掌握在协调方手里，而不是交给各部门自行决定。
3. 误区三：关键路径只算一次
很多团队把关键路径当成项目启动时的一次性输出物，做完就锁进文档。但关键路径的本质是"当前最长链"，任何一条非关键路径的延期都可能让它换人。
关键路径的更新频率，应该和项目的变更频率匹配，而不是和里程碑匹配。跨部门项目里，我建议最少每周复核一次，变动期甚至要每三天一次。
4. 误区四：把关键路径当成催办清单
这是最隐蔽的误区。识别出关键路径之后，很多项目经理的做法是每天盯着这几个节点催。催办只能解决"意愿问题"，解决不了"能力问题"和"资源问题"。
如果关键节点延期是因为对方团队同时在做三个项目，那么再催也没用，你需要做的是资源优先级谈判，或者把这条路径从关键路径上换掉。
四、专业判断逻辑：依赖是"可承诺的接口"，不是"先后的顺序"
到这里可以给出我的核心方法论：把每一条跨部门依赖，重构为一张"接口卡"。接口卡不是文档之美，它是让依赖可被承诺、可被验收、可被追责的最小单位。
1. 颗粒度的四条验收标准
我判断一个任务能不能进入跨部门依赖图，用四条标准筛。四条全过才收，缺一条就打回重拆。
- 单一责任人可承诺：这条任务能不能指到一个具体的人，而不是一个部门或一个小组。
- 交付物可被描述：能不能说清楚"交出来的是什么"，而不是"做了什么"。
- 完成标准可判定：双方能不能就"做完了"达成无争议的判据，最好能量化。
- 工期不超过 10 个工作日：超过就说明颗粒太粗，里面还藏着未拆分的依赖。
这四条标准看起来简单，但真正筛一遍你会发现，初始清单里通常有 40% 以上的任务过不了关。这不是坏事，被筛掉的部分，正是过去悄悄吃掉工期的部分。
2. 用"接口卡"代替任务名
下面是我实际使用过的接口卡模板。它不是表格，而是一段结构化文本，因为跨部门沟通时，对方需要的不是"你的任务名"，而是"我要交付什么、按什么标准、什么时候"。
交付物：订单中心 → 支付网关 的「支付结果回调」接口
接口编号：IF-ORD-PAY-003
发起方：订单中心（责任人：A）
承接方：支付网关（责任人：B）
交付形态：接口文档 v1.2 + 沙箱环境可调用 + 幂等规则说明
验收标准：
回调成功率 ≥ 99.5%（沙箱连续 1000 次压测）
重复回调具备幂等性，不产生重复订单状态变更
失败回调具备重试机制，重试上限 3 次
依赖类型：FS（订单状态机「待支付 → 已支付」必须在回调联调通过后启动）
承诺工期：5 人天（含 1 人天缓冲）
违约触发：超过承诺工期 2 个工作日，自动上报项目协调方
最后确认时间：第 2 周周三
三方确认：发起方 A / 承接方 B / 协调方 C
这张卡最关键的不是内容多，而是最后三行：违约触发、最后确认时间、三方确认。没有这三行，它就是一份普通文档，没人会为它负责。
3. 四类依赖在跨部门场景的适用边界
四类依赖（FS/SS/FF/SF）在教材里只是一段定义，但在跨部门场景里，它们的适用范围和风险差别很大。我的经验是：FS 最安全但最容易拖长工期，SS/FF/SF 更灵活但极易失控。
| 依赖类型 | 含义 | 跨部门典型场景 | 最大风险 |
|---|---|---|---|
| FS 完成，开始 | 前序完成后，后续才能开始 | 接口文档定稿 → 联调启动 | 被滥用为默认关系，导致链路串行过长 |
| SS 开始，开始 | 前序开始后，后续才能开始 | 双方同时进入开发，各自实现协议 | 滞后量未定义，实际变成并行失控 |
| FF 完成，完成 | 前序完成后，后续才能完成 | 数据迁移与校验必须同时收尾 | 一方拖延，"完成"标准被稀释 |
| SF 开始，完成 | 前序开始后，后续才能完成 | 新系统上线后，老系统才能下线 | 极少使用，误用后产生隐藏长链 |
我做过一次粗糙统计：跨部门项目里，使用占比最高的 FS 反而是延期贡献最低的，而使用最少的 SS/FF/SF 加起来贡献了大部分延期。原因很直接，这三类依赖都带"滞后量"，而滞后量几乎没有人在第一版里定义清楚。
4. 隐性依赖显性化的五个动作
隐性依赖是跨部门关键路径最大的黑洞，因为它不体现在任何交付物上。我总结出五个把它显性化的动作，每个动作都对应一类最常见的隐性依赖。
- 把"我们等他们"写成条目：凡是出现"等某某确认"，就要单独建一条任务，哪怕它只有 0.5 天。
- 把外部流程写入路径：合规审查、采购审批、变更窗口、安全扫描，这些是流程不是交付，但占工期。
- 把共享专家标成资源约束：同一个人同时服务多个项目时，他的排期冲突本身就是一条依赖。
- 把环境依赖单列：测试环境、数据脱敏、第三方沙箱，这些资源往往是多项目竞争的重灾区。
- 把"口头同意"变成书面确认：没有书面记录的同意，在延期发生时一律视为不存在。
五、从 0 到 1 的五步落地：谁参与、产出什么、怎么确认
这一节是全文的操作核心。我把它拆成五步，每一步都写清楚参与人、产出物和确认方式，你可以直接照着执行。
1. 第一步：画跨部门接口地图（第 1-2 天）
参与人只要两类：各部门的业务接口人（不是项目经理），以及你作为协调方。不要一开始就召集全员开会，先做一对一访谈。
产出物是一张"接口地图"，格式很简单：横轴是部门，纵轴是交付物，交叉点是交接点。每个交接点用一句话描述交付物，不允许出现部门内部任务。
2. 第二步：建依赖矩阵并做三方确认（第 3-5 天）
把接口地图转成依赖矩阵，每条记录包含接口编号、发起方、承接方、依赖类型、滞后量、承诺工期、浮动时间、是否关键路径。示例如下：
接口编号,发起方,承接方,依赖类型,滞后量Lag,承诺工期,浮动时间,是否关键路径
IF-ORD-PAY-003,订单中心,支付网关,FS,0,5人天,0,是
IF-PAY-UAC-001,支付网关,用户中心,SS,2人天,3人天,4人天,否
IF-UAC-RSK-002,用户中心,风控中心,FF,1人天,4人天,2人天,否
IF-RSK-OPS-001,风控中心,运维中心,FS,0,2人天,0,是
IF-ORD-OPS-004,订单中心,运维中心,SF,0,1人天,6人天,否
三方确认指的是发起方、承接方、协调方都要在同一份记录上确认。协调方的角色不是签字仪式，而是负责判断这条依赖是否真的需要走跨部门流程，以及浮动时间归属谁。
3. 第三步：合并排期，算出关键路径（第 2 周）
合并排期时最容易犯的错误是把各部门的排期直接相加。正确的做法是：只合并接口级任务，各部门内部任务用"承诺工期"整体占位，等到认账会之后再逐层展开。
合并完成后，按标准 CPM 正推最早开始时间，逆推最晚开始时间，两者相等或浮动时间最小的链路就是关键路径。这一步的具体算法不复杂，复杂的是确保输入的数据是经过确认的。
4. 第四步：开一次"认账会"（第 2 周末）
认账会是整个流程里唯一不可省略的环节。它不是汇报会，议程只有四项，建议控制在 90 分钟以内。
- 逐条展示关键路径上的任务，由承接方当场确认工期和资源。
- 逐条确认浮动时间的归属，谁的浮动时间，谁有权使用。
- 确认违约触发机制：延期几天上报、上报给谁、触发什么动作。
- 确认下一次复核时间，默认每周一次，变动期加密。
认账会的产出不是会议纪要，而是一份所有人确认过的基线。没有确认的条目，宁可不放进关键路径，也不要放进去了没人认。
5. 第五步：把关键路径放进固定节奏（第 3 周起）
关键路径一旦进入执行期，它的任务就是"维持准确"。我用的方法是每周一次二十分钟的复核：只看三件事，关键路径有没有变、浮动时间有没有被占用、有没有新增隐性依赖。
下面这张图是我在一个项目中记录的关键路径漂移过程。前三周漂移最剧烈，第四周之后趋于稳定，这符合大多数跨部门项目的规律。
六、数据观察与工具边界：什么时候需要工具，什么时候只需要一张表
讲完方法，绕不开工具问题。我的立场比较明确：小规模、短周期的跨部门项目，一张结构化的表就够；一旦部门数量超过 4 个、依赖超过 40 条、或者项目周期超过一个季度，人工维护基线基本会失控。
1. 我用 PingCode 观察到的四个变化
我参与过的一个中台项目在使用 PingCode 前后的对比数据比较有参考价值。这里需要说明的是，PingCode 主要服务中大型企业及 100 人以上组织，它的价值恰好体现在"依赖数量多、部门多、基线维护频繁"这类场景上。
最直观的变化是依赖确认从"口头"变成"系统留痕"。以前跨部门确认靠邮件和群消息，延期时各说各话；现在每条依赖都有明确的发起方、承接方和确认时间，争议成本大幅下降，这是我认为最被低估的一个收益。
2. 团队规模与跨部门依赖数量的关系
我整理过接触过的几个项目，发现一个比较稳定的规律：团队规模每翻一倍，跨部门依赖数量大约增长 1.8 倍左右，而工期偏差率随之上升。原因是沟通路径随人数呈组合式增长，而每个依赖都需要一条沟通路径去维护。
这也解释了为什么 100 人以上的组织几乎必然需要工具支撑，不是人变懒了，而是依赖数量超出了人工跟踪的上限。
3. 工具的边界：它解决不了"认账"
必须说清楚一点：任何工具都只能让依赖"可见"，不能让它"被承诺"。我在一个项目里见过依赖关系在系统里挂得清清楚楚，但承接方从来没点开看过，最后照样延期。
所以工具的正确用法是：把它当成认账结果的存放地，而不是认账过程的替代品。先开会认账，再录系统；而不是录完系统，就当已经认账。
4. 什么样的组织适合上 PingCode 这类平台
PingCode 支持私有化部署，也支持 Jira 的平滑迁移，这对有国产替代需求的中大型组织是一个比较实际的选项。它的适用场景我判断有三条：
- 组织规模在 100 人以上，跨部门依赖长期存在，不是偶发性的协作需求。
- 有合规或数据驻留要求，需要私有化部署而不是纯 SaaS。
- 正在做工具链国产替代，希望从既有平台平滑迁移，降低团队重新学习成本。
反过来，如果你的项目只有 3 个部门、周期两个月、依赖不到 30 条，上线一套平台反而会增加维护负担。工具的选择标准应该是"依赖的绝对数量"，而不是"团队的感觉先进程度"。
七、不同情况下的行动建议
同样的方法论，在不同规模的项目里执行方式差别很大。下面按四种常见场景给出具体建议。
1. 3 个部门以内、周期 2 个月以内
这种情况不需要工具，也不需要复杂的 CPM。我的建议是三步走：画一张接口地图，把 20 条以内的高风险依赖标出来，然后每周花 30 分钟核对一次。
关键动作只有一个：所有依赖必须口头加书面双重确认，书面可以是一封邮件或一条群消息的明确回复。这个规模的项目，过度流程化是最大的浪费。
2. 5 个以上部门、周期半年以上
这种情况必须建立完整机制。我的建议是：设置专职或半专职的协调角色，建立统一依赖表，每周一次复核，每月一次完整的基线重算。
同时要考虑工具支撑。依赖数量超过 60 条以后，人工维护的成本会急剧上升，而且极易出现"表格版本不一致"的问题，这时候引入支持私有化部署的项目管理平台是比较划算的选择。
3. 多项目并行、共享同一批关键人
这种情况的难点是资源约束，而不是逻辑依赖。我的建议是把关键人单独列成"资源日历"，把他的可用时间当成一条约束写进网络图。
具体做法是：先在图上保留他的时间，再排其他任务，而不是先排任务再去抢他的时间。这个顺序调整看起来小，实际能减少大量被动延期。
4. 已经延期了，怎么补救
如果项目已经延期，不要急着压缩所有任务。我的建议顺序是：先重算关键路径（因为原来的很可能已经失效），再找真正的瓶颈资源，最后才考虑压缩工期。
压缩时优先动"浮动时间被占用"的那部分，其次是拆分串行任务为并行。最后才考虑加班，因为加班对跨部门团队的效果最差，你无法让别人的团队加班。
八、不同情况下的取舍：哪些事不值得做
方法论讲完，必须讲取舍。因为跨部门项目的资源永远是稀缺的，你做了 A 就做不了 B。我在项目里踩过最多的坑，不是做得太少，而是做得太全。
1. 不值得：追求网络图的完整性
把每个部门的内部任务都收上来，看起来严谨，实际上会带来两个问题：维护成本指数级上升，以及关键路径被大量噪音淹没。
我的建议是只维护接口级网络图，部门内部任务用承诺工期整体占位。这样图上的节点数量通常能减少一半以上，而关键路径的准确性几乎没有损失。
2. 不值得：把所有依赖都设成 FS
把所有依赖统一设成 FS 看起来最安全，实际上会人为拉长链路，尤其是那些本可以并行启动的接口。我的经验是：能并行的就设 SS 或 FF，但必须同时定义滞后量；定义不了滞后量的，就老实回退到 FS。
判断标准很朴素：如果双方可以在对方"完成"之前就开始工作，就说明存在并行空间；如果连边界都说不清，就说明还没准备好并行。
3. 值得 vs 不值得：一张对照表
| 动作 | 投入成本 | 收益 | 我的建议 |
|---|---|---|---|
| 全量任务网络图 | 40-60 人时 | 工期改善 5-10% | 不值得，维护成本过高 |
| 接口级依赖图 | 12-18 人时 | 工期改善 20-30% | 强烈建议，投入产出比最高 |
| 每周认账会 | 6-8 人时/周 | 返工减少 15-25% | 建议，但控制在 20-30 分钟 |
| 关键路径漂移预警 | 3-4 人时/周 | 偏差下降 10-18% | 建议，依赖数超过 40 条时必做 |
| 全量四类依赖建模 | 8-10 人时 | 工期改善 3-6% | 视情况，只对高并行接口使用 |
这张表的核心意思是：投入和收益不是线性关系。你花在人时最多的"全量建模"上，收益反而是最低的。
4. 三种情况下应该放弃关键路径法
第一种是探索型项目，需求本身还不确定，工期无法预估，这时候做关键路径是浪费时间。这种情况应该用时间盒而不是依赖图。
第二种是任务高度同质、可以随时加人的项目，比如批量数据处理。这种情况关键路径法意义不大，扩缩容比排依赖更有效。
第三种是团队少于 10 人、所有人坐在同一个空间的项目。这种情况下口头沟通的成本低到足以覆盖依赖管理，强行引入流程反而降效。
九、总结与下一步
1. 一句话总结我的观点
关键路径在跨部门场景里失败，几乎从来不是因为算错，而是因为依赖没有被承诺、没有被记录、没有被持续更新。把任务拆到"接口"粒度，把承诺落到"三方确认"，把维护节奏固定到"每周一次"，这三件事做到了，关键路径自然就准了。
我还想补一个可能不太讨喜的判断：跨部门关键路径管理中，最贵的成本不是算力，也不是工具，而是"让别人认账"这件事的沟通成本。工具能降低记录成本，但降低不了承诺成本，这一点想清楚了，很多工具选型纠结会自然消解。
2. 这周你只需要做三件事
- 画一张接口地图。只标交付物和交接点，不标部门内部任务，控制在 2 小时内完成。
- 用四条颗粒度标准筛一遍。过不了关的任务先不打回，但标记出来，它们大概率就是过去吃掉你工期的那部分。
- 约一场 60 分钟的认账会。议程只讨论关键路径上的任务、浮动时间归属、违约触发机制，不做汇报。
如果你的项目依赖数量已经超过 40 条、参与部门超过 4 个，可以同步评估一下是否需要一个能承载依赖基线和私有化部署要求的项目管理平台，比如 PingCode 这类面向中大型组织的方案。但请记住顺序：先认账，再上系统；先想清楚流程，再选工具。
常见问题解答（FAQ）
1. 跨部门项目里，关键路径到底该怎么算？
我是公司里那种没有直接管理权、但要对项目整体交付负责的人。每次到了跨部门排期，四个部门各发一张表，我把日期拼在一起就算出了关键路径。可上线后发现算出来的路径跟实际情况完全对不上，到底是我算法有问题，还是这件事本身就没法用一套公式解决？
算准的前提不是先套公式，而是先把依赖颗粒度统一。具体做法：第一步，把每个任务改写成‘交付物+责任人+接收方’的形式，比如‘设计定稿交给开发联调’而不是‘设计阶段’；第二步，只保留能被单一责任人承诺的任务，凡是需要两个部门共同完成的动作，拆成两条任务，用一条依赖连起来；
第三步，把四个部门各自的排期合并到一张图上，用完成，开始（FS）依赖做主干，只对确实并行的环节才用开始，开始（SS）或完成，完成（FF）。判断依据是：合并后如果出现某个任务的浮动时间为负，说明两边的承诺日期互斥，这不是算法错，而是排期本身没对齐。
跨部门关键路径算不准，九成问题出在任务颗粒度和依赖定义上，而不是关键路径法本身失效。
2. 任务依赖有四类，跨部门场景到底该用哪一种？
我之前看教程只知道完成，开始这一种依赖，结果在跨部门协作里被坑过好几次。比如市场部的素材要等产品部的功能说明，但两边其实可以并行推进一部分；又比如测试验收要等开发完，但开发内部是分模块交付的。我经常分不清哪种依赖能反映真实的约束关系，怕用错反而把图搞乱。
四类依赖里，完成，开始（FS）是默认主干，适合上游交付物是下游启动前提的场景，比如开发联调完成后测试才能开始；开始，开始（SS）适合需要同步启动、但各自完成时间可以不同的场景，比如两个部门的接口对齐会必须同时开；完成，完成（FF）适合两个任务必须同时收口的场景，比如代码冻结和文档定稿要同步交付；
开始，完成（SF）在跨部门实务中极少用，除非是交接班类场景，一般不建议引入，容易让非专业成员误解。落地时建议只允许主干使用FS，其余三类必须由协调方在依赖表上标注理由，并且每条依赖要有发起方、承接方两方确认，否则默认视为无效依赖，不进入网络图。
判断依据是：依赖类型越多，跨部门沟通成本越高，能不用就尽量不用。
3. 网络图画出来之后，怎么让其他部门认账？
我经历过最尴尬的一次，就是我花了两天把跨部门网络图和关键路径都画好了，开会时各部门都说‘这不是我们的排期’，当场就僵住了。他们不是不配合，而是觉得这张图是我单方面拼出来的，跟他们内部排期没有关系。我想知道有没有办法让这张图从‘我的图’变成‘大家的图’。
关键动作是把图从‘我算的’变成‘我们一起确认的’，具体分三步。第一步，在画图之前先做一次单独对齐，跟每个部门确认两件事：你们承诺的交付日期是哪天，你们的交付物具体是什么形态，这步不做，后面开会必翻车；
第二步，把合并后的网络图提前两天发给各方，只标注与对方相关的任务和依赖，要求对方回复‘认可’或‘哪条依赖不对’，把争议提前暴露；第三步，开一次不超过60分钟的认账会，逐条过关键路径上的依赖，每条依赖必须由承接方口头确认，由协调方记录，确认后的版本号冻结作为基线。
判断依据是：跨部门认账的核心不是说服，而是让每个部门在自己的任务上签字，没有确认动作的排期表，本质上只是协调方的单方假设。
4. 关键路径算完之后怎么维护，为什么总会失效？
我做过的项目里，关键路径基本是画完那一周有效，后面一更新进度，路径就漂到别的地方去了，原来盯的那几个任务不再是卡点，可团队还在按老路径推进，结果又延期。我想知道关键路径到底应该多久复核一次，路径漂移之后该怎么同步给各个部门，才不会每次都手忙脚乱。
关键路径本身就是动态的，任何任务实际进度偏离计划超过一定幅度，比如浮动时间被消耗掉一半以上，路径就可能漂移，所以它必须按节奏复核而不是算一次就固定。可执行做法是固定每周或每个迭代做一次复核，具体三步：第一，只更新实际开始、实际完成和剩余工期三个字段，不要顺手改承诺日期；
第二，重算浮动时间，把浮动时间为零或最小的任务链重新标为关键路径，跟上一版做对比，找出新增和退出的任务；第三，如果关键路径发生变化，用统一话术同步，直接说明‘原关键路径上的某项任务浮动时间已耗尽，新的卡点是某任务，需要某部门在某个日期前给出交付’，不要只说‘计划变了’。
判断依据是：维护关键路径的成本远低于事后救火，而跨部门同步的关键是给出具体任务、具体日期、具体承接方，而不是泛泛提醒大家注意进度。
核心关键词
文章包含AI辅助创作：关键路径怎么做？跨部门团队落地方案：任务依赖从0到1，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/391642
读者评论
看完挺有共鸣的，我们跨部门项目也经常算得准跑不动。作者说的‘依赖是承诺不是顺序’很到位，但现实里推书面确认太难了，尤其是对方部门根本不配合的时候，有没有更‘软’一点的落地技巧？
依赖漏斗那个78%流失率太真实了，我上一家公司就是这样，识别了上百条依赖，最后真正跟踪的就十几条。问题出在没人愿意当‘恶人’去逼各部门签字，项目经理权限不够，这几乎是死结。
文章说算得越准越容易失效，这点我保留意见。准确本身没错，错的是把准确当成一劳永逸。如果配上高频更新机制，精确的图反而能更快暴露偏差。作者自己也说要每周复核，所以问题不在精度，在不维护。
接口卡这个思路很实用，尤其适合我们这种多供应商协作的项目。但我好奇的是，如果对方的交付标准没法量化，比如‘用户体验良好’这种，接口卡怎么落地？感觉作者的方法更偏技术型团队。