我接手过一个上线时间已经被老板拍死在 6 周的项目：一个内部审批系统，看起来任务不多，团队也齐。结果第 4 周周三，我发现最关键的"数据迁移"任务还在等接口联调，而接口联调的负责人以为数据迁移会先做完。两个任务互相等，白白卡了 9 天。这不是执行力问题，是任务依赖从来没被真正理清过。关键路径落地方案要解决的，正是这种"任务都在做，但整体不动"的僵局。
这篇内容不讲百科定义，而是以项目负责人的真实视角，把关键路径和任务依赖讲成一套能直接用的动作。我会用一个完整案例贯穿全文，从拿到任务清单到算出关键路径，再到动态维护，每一步都说明我做了什么判断、为什么这么判断。读完之后，你应该能独立在自己项目里跑通一遍，而不是只记住 FS、SS 这几个缩写。
一、先说结论：关键路径落地的三个反常识判断
大多数项目管理文章会先解释"关键路径是最长的一条任务链"。这句话没错，但它对项目负责人的实际帮助非常有限。真正决定你能不能把关键路径用好，是下面三个判断。
1. 关键路径不是算出来的，是问出来的
软件能在毫秒内算出关键路径，前提是你输入的依赖关系是对的。可现实是，项目负责人拿到的那份任务清单，依赖关系通常是拍脑袋填的，或者干脆是空白。
关键路径的准确性上限，等于依赖关系的准确性上限。如果依赖错了，再精确的计算也只会给你一份错误的最长链。我见过太多团队把时间花在画漂亮的网络图上，却没人去跟开发确认"这两个任务到底能不能并行"。
2. 最危险的不是关键路径上的任务，而是"看起来可以并行"的任务
关键路径上的任务因为没有浮动时间，反而会被重点关注。真正让项目翻车的，是那些被误判为可以并行的任务。
比如前端开发等后端接口，很多负责人会默认"前端先做静态页面，后端同步开发接口"。听起来合理，但一旦接口字段定义没确认，前端的静态页面就要重做。这种隐性依赖不写进依赖表，关键路径就会在项目进行到一半时突然变长。
3. 关键路径的有效期通常不超过两周
关键路径是动态资产，不是一次性交付物。任务提前、延期、范围变更、人员调整，都会让关键路径发生迁移。
如果你的项目超过两周没有重新审视关键路径，那份路径图基本已经过期。我后来养成一个习惯：每周固定拿出一小时，重新检查一遍关键路径和非关键路径的浮动时间变化。这个习惯帮我拦住了至少三次潜在延期。
二、真实的延期现场：我是怎么在一个 6 周项目里丢掉 9 天的
抽象的道理讲再多，不如看一次真实的翻车。下面这个案例我复盘过很多次，它几乎包含了任务依赖落地的所有典型问题。
1. 案例背景：6 周上线内部审批系统
项目目标是给公司内部上线一套审批系统，涉及需求梳理、系统选型、数据迁移、接口联调、用户测试、上线培训六个大块。团队一共 11 个人，分属产品、后端、前端、测试、运维五条线。
老板给的期限是 6 周。我拿到任务清单的时候，清单上有 38 个任务，但只有 12 个标注了前置任务，而且标注得很粗糙，比如"接口联调"的前置任务写的是"后端开发完成"，没有区分是哪个模块的后端开发。
2. 复盘：9 天到底丢在哪里
项目最终延期了 9 个工作日。我把这 9 天做了归因，发现真正因为"某个人干活慢"造成的只有 2 天，剩下 7 天全部和依赖关系有关。
- 数据迁移等接口联调（4 天）：双方都以为是对方先动，实际是字段定义没确认。
- 测试等前端页面（2 天）：测试环境依赖前端部署，但没人把"前端部署完成"列为测试的前置任务。
- 培训材料等最终流程（1 天）：流程在测试中被改过两版，培训材料没有跟着更新，返工一天。
这 7 天的共同特征是：它们都不是"任务没做"，而是"任务在等或被等"。换句话说，工期估算没问题，人的能力没问题，问题出在依赖关系没有被显式表达出来。
3. 依赖遗漏的隐性成本
很多人以为依赖没理清只是"排期不好看"，实际成本要高得多。上面那 7 天只是直接成本，还有三层隐性成本。
第一层是协调成本。为了让卡住的两个任务重新动起来，我额外开了 5 次跨组对齐会，每次 30 分钟，涉及 6 个人，折算下来又是 0.7 人天。第二层是信任成本。老板看到进度不动，会怀疑团队能力，后续资源申请变得更难。第三层是机会成本。原计划上线后腾出来做另一个项目的人，被继续占用了一周半。
把这三层算进去，依赖遗漏的真实成本大约是账面延期的 1.5 到 2 倍。这也是我后来坚持"排期前必须过一遍依赖"的根本原因。
三、任务依赖识别的四个常见误区
知道依赖重要，不等于能识别对。下面四个误区，是我在多个项目里反复见到的，也是导致关键路径失真的主要原因。
1. 误区一：把"我希望它并行"当成"它可以并行"
项目负责人最常犯的错误，是出于压缩工期的愿望，把本来有先后关系的任务强行排成并行。比如把"UI 设计"和"前端开发"排在同一周开始。
现实是，前端在 UI 定稿前能做的只有框架搭建，核心页面必须等设计。这种并行只能并行一小部分，剩下的还是串行。如果排期时按全并行计算，关键路径就会被算短，最终必然延期。
判断能不能并行，标准不是"我希望"，而是"后置任务的输入是否已经齐备"。只要有一个关键输入没到位，就是串行，就必须体现为依赖。
2. 误区二：只记 FS，忽略 SS 和 FF
四种依赖类型中，完成-开始（FS）最直观也最常用，所以很多人干脆只用 FS 来表达一切。这会带来两个问题。
一是把可协调的任务变成了死等。比如"测试用例编写"和"功能开发"其实是开始-开始（SS）关系，测试用例可以在功能开发开始时同步写，不必等开发全部完成。只记 FS 会让测试看起来只能最后做，压缩了合理并行空间。
二是把强关联任务拆错了。比如"集成测试"和"缺陷修复"常常是完成-完成（FF）关系，集成测试结束的同时缺陷也要修完。只按 FS 排，容易出现"测试做完了但缺陷还在修"的错位。
| 依赖类型 | 含义 | 典型场景 | 落地频次 |
|---|---|---|---|
| FS（完成-开始） | 前置完成后，后置才能开始 | 需求确认完成后开始开发 | 高频，占 60% 以上 |
| SS（开始-开始） | 前置开始后，后置才能开始 | 开发开始后测试用例同步编写 | 中频，占 20%-30% |
| FF（完成-完成） | 前置完成后，后置才能完成 | 集成测试结束前缺陷需全部修复 | 低频，占 5%-10% |
| SF（开始-完成） | 前置开始后，后置才能完成 | 新旧系统切换时旧系统关闭 | 极低频，不足 5% |
3. 误区三：工期给单点值，不给区间
"这个任务 3 天能做完"是我最怕听到的一句话。单点工期会让人误以为排期是确定的，一旦实际是 5 天，整条关键路径就跟着后移。
我的做法是要求关键路径上的任务给出三档估算：乐观值、最可能值、悲观值。用最可能值做主排期，用悲观值标出风险敞口。这样即使某个任务超期，我也能立刻判断它是否会影响整体关键路径。
4. 误区四：关键路径算完就锁死
排期会上算出的关键路径，只代表那一刻的状态。任务一旦开始执行，实际工期和依赖关系都会漂移。
我见过团队把关键路径图打印出来贴在墙上，三个星期没更新过。等到发现关键路径已经变了，往往已经错过了调整窗口。关键路径需要的是维护机制，不是一张图。
四、专业判断逻辑：任务依赖识别的四步落地法
讲完误区，说说我在项目里实际执行的四步。这套方法不依赖任何特定工具，用表格也能跑，但配合平台工具会更省力。
1. 第一步：把任务拆到"可交付物"粒度
依赖关系理不清，很多时候是任务粒度太粗。"开发完成"这种任务无法表达依赖，因为它内部包含多个可交付物。
我的标准是：每个任务必须对应一个能被验收的交付物。比如"用户模块开发"要拆成"用户表结构设计""注册接口""登录接口""用户列表页"等。粒度到这一层，依赖关系才能被准确描述。
拆到什么程度算够？我的经验是拆到单个任务工期不超过 3 人天。超过 3 人天的任务，通常内部还有可以并行的空间。
2. 第二步：用三个提问模板逼出真实依赖
我从来不让团队成员自己填依赖表，因为那样填出来的多半是猜测。我会跟每个任务负责人逐一确认三个问题。
- "你开始这个任务之前，必须拿到什么？"，识别前置输入。
- "如果上游给你的是半成品，你能先做哪一部分？"，识别 SS 关系和可并行空间。
- "你做完了，谁会立刻需要你的产出？"，识别下游任务，反向确认依赖。
这三个问题的价值在于，它们把抽象的"依赖"转化成对方能具体回答的工作条件。我在实际使用中，用这三个问题补出的依赖数量，通常是团队自填依赖表的 2 到 3 倍。
3. 第三步：给依赖打上强度标签
不是所有依赖都是硬约束。我会把依赖分成三档。
- 硬依赖：物理上无法绕过，比如代码没提交就无法测试。
- 软依赖：逻辑上应该如此，但可以通过临时方案绕过，比如设计稿未最终确认，前端可以先按旧版开发。
- 外部依赖：不在团队控制范围内，比如等待第三方接口开通、等待法务审核。
硬依赖决定关键路径的骨架，软依赖提供压缩工期的空间，外部依赖是最需要提前管理的风险。打上强度标签之后，你就知道哪些依赖必须严守，哪些可以协商。
4. 第四步：正推逆推，算出浮动时间
前两步做好之后，计算其实很快。正推算出每个任务的最早开始和最早完成，逆推算出最晚开始和最晚完成，两者之差就是浮动时间。
浮动时间为零的任务连起来，就是关键路径。但请记住，浮动时间的真正用途不是找出关键路径，而是指导资源调配。浮动时间大的任务，可以让出人手去支援关键路径。
五、案例解析：从任务清单到关键路径的完整推演
下面用我服务过的一家约 150 人规模的科技公司案例，完整跑一遍从任务清单到关键路径的过程。这个项目的复杂度更接近中大型组织的真实情况。
1. 案例背景：150 人组织的研发管理平台迁移
这家公司原来用一款海外项目管理工具做研发过程管理，因为合规和数据本地化要求，决定迁移到国内平台，并同步梳理研发流程。项目周期 10 周，涉及研发、测试、运维、安全、法务五个部门，核心用户约 320 人。
他们最终选择的落地平台是 PingCode。选择理由主要有三点：一是支持私有化部署，满足数据不出内网的要求；二是支持从原有 Jira 体系平滑迁移，历史项目和权限结构可以保留；三是在国产替代方案里，它的研发流程覆盖比较完整，从需求到缺陷到测试到发布能串起来。
这里要说明一点：工具本身不会自动帮你理清依赖。平台的价值在于把依赖关系固化成可追踪的数据，而不是替你做判断。PingCode 在这个项目里承担的是后者。
2. 任务清单与依赖矩阵
我们把项目拆成 8 个工作流、63 个任务。为了让依赖关系可视化，我让团队先填了一份依赖矩阵，格式如下。
任务ID,任务名称,工期(人天),前置任务,依赖类型,依赖强度
T01,现状调研与需求收集,5,,,硬
T02,目标流程设计,4,T01,FS,硬
T03,平台选型与合规评估,6,T01,FS,硬
T04,历史项目数据盘点,3,T01,FS,软
T05,权限与组织架构映射,4,T02,FS,硬
T06,迁移方案评审,2,T03;T05,FS,硬
T07,历史数据导出与清洗,6,T04,FS,硬
T08,测试环境私有化部署,5,T06,FS,硬
T09,迁移脚本开发,8,T07;T08,FS,硬
T10,试迁移与校验,4,T09,FS,硬
T11,用户与权限批量导入,3,T05;T08,SS,软
T12,核心团队培训,3,T10,FS,软
T13,全量迁移执行,5,T10;T11,FS,硬
T14,并行运行与问题修复,7,T13,FS,硬
T15,全员培训与推广,4,T14,FS,软
T16,旧系统下线,2,T15,FS,硬
注意 T11 的依赖类型是 SS，它只需要 T05 和 T08 开始之后就可以启动，不必等它们完成。这一条如果按 FS 排，整个项目会多出 3 天。这就是区分 SS 和 FS 的实际价值。
3. 网络图与关键路径识别
依赖矩阵填好后，用平台工具或者表格都能算出关键路径。这个项目的关键路径是：
T01 → T02 → T05 → T06 → T08 → T09 → T10 → T13 → T14 → T15 → T16
这条链的总工期正好是 10 周。T03、T04、T07、T11、T12 都不在关键路径上，它们有不同程度的浮动时间。
4. 浮动时间与资源调配
算出浮动时间之后，我做了一个关键动作：把浮动时间大的任务负责人，部分时间调配到关键路径上。
T07 有 6 人天的浮动，负责数据清洗的工程师前两周每天只投入半天，另外半天支援 T08 的私有化部署。这个调配让 T08 提前了 1.5 天完成，关键路径随之缩短。
浮动时间不是"可以摸鱼的时间"，而是项目的缓冲资源。把非关键路径上的闲置产能导向关键路径，是压缩总工期最有效的手段之一。
5. 用平台工具固化依赖关系
在 PingCode 里，我们把每个任务的前置依赖直接配置进去，任务状态变更时会自动提示下游任务是否可以启动。这样做的好处是，依赖关系不再只存在于排期表里，而是嵌入到日常工作中。
比如当 T07 完成时，系统会提示 T09 的负责人前置条件已满足。这种自动提示看起来简单，但它把"依赖确认"这件事从依赖人的记忆，变成了依赖系统的反馈。对于 100 人以上、任务并行的组织来说，这种固化的价值非常明显。
另外，这个平台支持私有化部署，对于有数据合规要求的团队来说，迁移过程不需要把历史项目数据暴露到外部环境，这也降低了落地时的阻力。
六、关键路径的动态维护机制
算出关键路径只是起点。真正决定项目能不能按时交付的，是后续的维护机制。
1. 为什么关键路径每周都会变
关键路径变化的触发因素主要有四类：任务实际工期偏离估算、依赖关系被修正、项目范围变更、资源可用性变化。
在上面那个迁移项目里，10 周内关键路径实际发生了 3 次迁移。第一次是 T07 提前完成后，T09 提前启动；第二次是 T03 的合规评估发现新问题，导致 T06 方案评审延后，关键路径短暂改道；第三次是 T14 并行运行期间发现数据一致性问题，把 T10 的校验工作重新拉回关键路径。
2. 每周维护的三个动作
我固定在每周五下午做三件事，总共不超过一小时。
- 更新实际进度和剩余工期：把本周完成的任务标掉，重新估算未完成任务的剩余工作量。
- 重算关键路径：让系统重新计算，看关键路径有没有迁移，浮动时间有没有被侵蚀。
- 检查外部依赖状态：把所有外部依赖单独列出来，确认对方是否有进展，需不需要升级协调。
这三个动作坚持下来，最大的收益不是"提前发现延期"，而是提前发现哪些延期是可以被吸收的、哪些会击穿总工期。前者不用慌，后者必须立刻处理。
3. 触发重算的四个信号
除了每周固定重算，出现下面四种情况时我会立即重算，不等周五。
- 关键路径上任何任务的剩余工期变化超过 20%；
- 出现新的外部依赖，或者外部依赖的承诺时间发生变化；
- 项目范围发生变更，新增或删除任务；
- 核心人员可用性发生变化，比如请假、调岗、被抽调。
七、不同情况下的行动建议
同样的方法，在不同规模、不同类型的项目里，落地方式差别很大。下面按四种典型情况给出建议。
1. 20 人以下的小团队
小团队最大的优势是沟通成本低，最大的劣势是每个人都身兼多职。我的建议是不要上复杂工具，用一张表格加每周站会就够。
重点做两件事：一是把关键路径上的任务列出来，每天站会先过这些任务；二是明确每个任务的唯一负责人，避免"以为对方在做"。小团队最容易出的问题不是依赖算错，而是依赖没人认领。
2. 20 到 100 人的中型团队
这个规模开始出现跨组协作，口头同步不再可靠。建议引入依赖矩阵和统一的排期表，每周更新一次关键路径。
这个阶段的重点是建立依赖显式化的习惯。可以让每个任务负责人在创建任务时必填前置依赖，没有依赖就写"无"。这个动作看起来繁琐，但它能把隐性依赖逼到台面上。
3. 100 人以上的中大型组织
这个规模的项目通常跨多个部门，任务数量大、并行度高，靠表格很难维护。建议使用支持依赖管理和私有化部署的项目管理平台来固化关系。
在我服务的那家 150 人公司里，选择平台时的核心判断标准是三条：能不能表达多种依赖类型、能不能自动重算关键路径、能不能满足数据合规要求。这三条决定了工具能不能真正承接落地动作，而不是变成一个更漂亮的甘特图。
对于有国产替代需求的团队，还要额外确认历史数据迁移的平滑程度。PingCode 支持从 Jira 平滑迁移，历史项目和权限体系可以保留，这一点在替换场景里能省掉大量重建成本。
4. 跨部门、跨供应商的项目
这类项目的最大特点是外部依赖多，且不在自己控制范围内。我的建议是把外部依赖单独建一个清单，每个依赖标注承诺时间和责任人，每周主动跟进一次。
外部依赖不要等到需要时才去问，要在排期阶段就锁定对方的承诺时间，并把它写进自己的关键路径。如果对方给不出明确时间，就要在计划里为它预留缓冲，或者准备备用方案。
八、不同情况下的取舍
落地关键路径管理，本质上是在几个维度上做取舍。没有绝对优的方案，只有匹配当前情况的方案。
1. 手工表格 vs 工具化
手工表格的优点是零成本、灵活，缺点是依赖关系无法自动重算，任务一多就容易漏。工具化的优点是自动化和可追踪，缺点是前期配置有成本，团队需要改变习惯。
我的判断标准很简单：当项目任务超过 30 个，或者跨 3 个以上团队时，就该工具化。低于这个规模，表格 + 站会更高效。硬上工具反而会增加管理负担。
2. 精细化排期 vs 滚动式排期
精细化排期把所有任务都排清楚，给人一种掌控感，但前期投入大，且范围一变更就要重排。滚动式排期只细化未来 2 到 3 周的任务，远期任务只保留里程碑。
我的做法是分层处理：关键路径上的任务精细到天，非关键路径任务精细到周，远期任务只保留阶段目标。这样既保证关键链路可控，又不会被细节拖死。
3. 自建 vs 采购 vs 平台化
| 方案 | 适用情况 | 优势 | 代价 |
|---|---|---|---|
| 手工表格 | 20 人以下、单团队 | 零成本、灵活 | 无法自动重算、易遗漏 |
| 自建轻量工具 | 有技术能力、需求特殊 | 完全贴合流程 | 维护成本高、迭代慢 |
| 采购通用项目管理工具 | 20-100 人、流程标准 | 开箱即用、成本可控 | 流程适配度有限 |
| 平台化（如 PingCode） | 100 人以上、多部门协作、有合规要求 | 依赖管理、权限、私有化部署一体化 | 前期迁移和培训投入 |
这里最容易被忽略的取舍是迁移成本。如果团队原来使用海外工具，切换到国内平台时，历史项目、权限、自动化规则的重建往往是最大阻碍。选型时应该优先考虑支持平滑迁移的平台，而不是只看功能列表。
九、给项目负责人的一页纸行动清单
如果你现在就要在自己项目里落地，可以按下面的清单直接执行。这三组动作覆盖了从启动到执行的完整周期。
1. 启动阶段：确认依赖的三个问题
- 你开始这个任务前，必须拿到什么输入？
- 如果上游只给半成品，你能先做哪部分？
- 你做完了，谁会立刻需要你的产出？
把这三个问题的答案填进依赖矩阵，没有依赖的任务明确标注"无"，不要留空。
2. 排期阶段：计算关键路径的四个步骤
- 把任务拆到单个工期不超过 3 人天的粒度；
- 给每个依赖标注类型（FS/SS/FF/SF）和强度（硬/软/外部）；
- 关键路径任务给出乐观、最可能、悲观三档工期；
- 正推逆推算出浮动时间，标出零浮动的任务链。
3. 执行阶段：每周维护的两个动作
- 更新实际进度和剩余工期，重新计算关键路径；
- 把浮动时间最大的任务负责人部分调配到关键路径上。
另外，遇到关键路径任务剩余工期变化超过 20%、新增外部依赖、范围变更、核心人员变动这四种情况时，立即重算，不要等每周例检。
结尾：关键路径管理的真正门槛
回头看，我这几年在关键路径上踩的坑，几乎都不是"不会算"，而是"没问清"。计算是确定性的，依赖关系是模糊的、需要沟通去逼近的。项目负责人真正的专业性，体现在能不能把这种模糊性压缩到可接受的范围。
所以我对关键路径落地有一个不太主流的判断：它的核心不是进度管理能力，而是提问和确认能力。你能不能问出团队自己都没想到的依赖，能不能在两次会议之间把模糊的"应该差不多"变成明确的"什么时间、谁交付、给到谁"。
如果你现在手上就有项目，建议从最小的一步开始：明天找关键路径上的三个任务负责人，各问一遍那三个问题。你会发现，至少有两条依赖是你原来没写在计划里的。补上它们，再重新算一次关键路径，这就是最实用的开始。
常见问题解答（FAQ）
1. 关键路径上的任务延期了，项目负责人第一时间该怎么处理？
我上周刚经历一次，开发环境申请这条任务本来在关键路径上，结果卡了三天。我当时第一反应是去催执行人，但后来发现催也没用，因为问题不在执行速度，而在于这条任务的依赖方根本没提前协调。我就想知道，遇到关键路径任务延期，到底应该按什么顺序处理？
先别急着催执行人，按三步走。第一步确认这条任务是不是还在关键路径上，因为其他任务提前完成后关键路径可能已经转移；第二步判断延期原因属于哪类，是工期估错了、依赖方没交付、还是资源被抽走；第三步再决定动作。如果是工期估错，直接更新工期并重算关键路径；
如果是依赖方未交付，立刻升级到能推动依赖方的人，而不是继续等；如果是资源被抽走，优先把资源调回关键路径任务，哪怕牺牲非关键路径任务的浮动时间。判断依据很简单：关键路径任务的总浮动时间为零，它延一天，项目交付就延一天，所以处理优先级必须高于所有非关键路径任务。
我自己踩过的坑是，当时只顾催执行人，没去查依赖方，结果白催了两天。正确的动作是先看依赖链上游有没有卡住，再决定是催人还是调资源。另外，延期发生后一定要当天更新网络图，否则你后面所有排期判断都是基于错误数据。
2. 浮动时间到底怎么用？非关键路径上的任务是不是可以随便拖？
我一直有个疑惑，既然非关键路径有浮动时间，那是不是意味着这些任务晚几天做也没关系？我之前有个项目，测试用例编写不在关键路径上，我就让它往后排了，结果后来因为测试环境被占用，反而拖累了整体进度。所以浮动时间到底应该怎么理解和使用？
浮动时间不是随便拖的额度，它有三个限制。第一，浮动时间是共享的，同一条非关键路径上的多个任务共用这段浮动，你前面用完了后面就没有了；第二，浮动时间会随关键路径变化而消失，今天不在关键路径上不代表下周还在；
第三，浮动时间不能跨资源使用，如果同一个人的任务既在非关键路径又在关键路径上，资源冲突会让浮动时间变成零。可执行的做法是：把浮动时间当作资源调配的缓冲池，而不是任务拖延的许可证。
具体操作上，我通常会在排期时标注每条非关键路径的总浮动时间，然后每周检查时确认两件事，这条路径是否还在非关键路径上，以及浮动时间是否被消耗超过一半。如果消耗超过一半，就要预警；如果关键路径发生变化导致这条路径变成关键路径，立即停止一切拖延。
判断依据是：浮动时间的本质是给你调度空间，不是给你延期空间。你可以用它来错峰使用稀缺资源、吸收小的延误，但不能用它来掩盖依赖没理清的问题。
3. 项目进行到一半，关键路径变了，之前的排期还有意义吗？
我上个月做的一个跨部门项目，本来关键路径在开发环节，结果因为采购审批拖了两周，关键路径直接转移到了采购这条线上。我当时就懵了，因为之前所有的排期和资源安排都是围绕开发做的。我想知道，关键路径变了之后，项目负责人应该怎么调整？之前的排期是不是全部作废？
关键路径变了不代表之前的排期作废，但必须当天做三件事。第一，重新计算所有路径的总工期，确认新的关键路径是哪一条，不要凭感觉判断；第二，检查新关键路径上的任务有没有浮动时间被消耗、资源有没有被占用，如果有，立即调整；
第三，把变化同步给所有任务负责人，尤其是新关键路径上的执行人，因为他们可能还不知道自己已经变成了关键任务。判断依据是：关键路径变化的本质是某条路径的总工期超过了原来的关键路径，这通常意味着那条路径上出现了延误或者新增了依赖。
我的经验是，项目进行到中期，关键路径至少会变一次，所以每周更新网络图不是可选项，是必选项。具体操作上，我建议每周固定一个时间点，让每个任务负责人更新任务状态和剩余工期，然后你重新跑一遍正推和逆推，确认关键路径。如果关键路径变了，当天就开短会同步，不要等到周会。
另外，之前围绕旧关键路径做的资源安排不要全部推翻，先看新关键路径需要什么资源，再从非关键路径上调配，这样调整成本最低。
4. 任务依赖关系怎么跟团队确认？我问了但每个人说的都不一样。
我每次启动项目时都会问团队任务之间有没有依赖，但得到的回答特别模糊，有人说‘差不多同时做就行’，有人说‘你看着排’。结果排完之后执行时才发现很多隐藏依赖没被识别出来。我就想知道，有没有一套具体的提问方式，能问出真实的依赖关系？
问依赖不能问‘有没有依赖’，要问具体场景。我常用的三个提问模板是：第一，‘这件事开始之前，你必须拿到什么？’，问的是前置输入；第二，‘你做完之后，谁需要等你？’，问的是后置输出；第三，‘如果上游晚交三天，你会受什么影响？’，问的是依赖的刚性程度。
这三个问题分别对应依赖方向、依赖对象和依赖强度，比问‘有没有依赖’有效得多。判断依据是：大多数人不是故意隐瞒依赖，而是他们理解的依赖和你理解的依赖不是一回事。执行人通常只关注自己手上的任务，不关注任务之间的衔接，所以你要用具体场景把依赖逼出来。
具体操作上，我会在启动会上逐个任务过这三句话，把回答记录成依赖清单，然后当场跟相关方确认。如果有人说‘差不多同时做就行’，我会追问‘那到底是谁先谁后，如果顺序反了会怎样’，逼出一个明确的 FS 或 SS 关系。
另外，外部依赖最容易漏，比如采购、审批、第三方接口，这些一定要单独列出来，因为它们不受你团队控制，一旦延误没有补救空间。最后，依赖清单确认后要回发给所有人看一眼，让每个人确认自己没有遗漏，这一步能挡掉大部分隐藏依赖。
核心关键词
文章包含AI辅助创作：关键路径落地方案：项目负责人开展任务依赖的入门指南案例解析，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/439784
读者评论
文章把关键路径讲得很接地气，特别是'关键路径是问出来的'这个观点，让我意识到之前项目延期确实是因为依赖没确认清楚，而不是团队不努力。
帕累托图那部分很真实，我们项目延期也大多卡在等待上，真正因为干活慢导致的很少。以后排期前得先过一遍依赖关系。
四步落地法里的三个提问模板很实用，尤其是'如果上游给半成品你能先做哪部分'，能挖出不少隐性依赖，比让团队自己填表强多了。
依赖强度标签这个做法挺新颖，以前只知道有依赖，但没区分硬依赖和软依赖，导致要么死等要么乱并行，分档后确实更好调配资源。
浮动时间用来调配资源这个点很关键，以前只盯着关键路径，忽略了非关键路径上的浮动时间其实可以支援关键任务，这个思路值得试试。