去年第三季度，我所在的 120 人研发交付组织，把一个原计划 4 个半月的版本硬生生拖成了 7 个月。复盘时我们把 380 个任务、41 个里程碑全部倒回表格里重算了一遍，结论让会议室安静了很久：真正造成延期的只有 6 个任务，它们全部集中在两条依赖链上，而这两条链在项目启动时的排期表里，被标注为"低优先级、约 3 周浮动时间"。那一刻我才真正理解，关键路径管理不是项目经理画甘特图的手艺，而是企业管理者分配注意力和资源的决策工具。
这篇入门指南，我想把踩过的坑、算过的数、以及在 PingCode 这类平台上真正跑通的流程，完整讲清楚。
一、先给结论：关键路径管理的本质是"资源优先级管理"
如果你只从这篇文章里带走一句话，我希望是这句：关键路径管理解决的不是"任务怎么排"，而是"有限的人和钱应该压在哪条链子上"。它是一套优先级决策机制，画图只是它的表达形式。
我在过去五年里参与过十几家企业的项目治理诊断，一个稳定出现的规律是：延期项目里约 80% 的根因，都能追溯到"资源被投在了非关键路径的任务上"。团队很忙，加班很多，日报很漂亮，但决定交付日期的那条链子始终没有被优先保障。
所以我把关键路径管理拆成四个管理者动作：识别（哪条链子决定日期）、压缩（能不能缩短它）、保护（资源和注意力向它倾斜）、监控（它变了要第一时间知道）。这四个动作里，只有"识别"需要项目管理专业知识，其余三个都是纯粹的管理决策。
反常识的地方在这里：多数管理者以为关键路径是排期阶段算一次就固定的。真实情况是，在一个 4 个月的项目里，关键路径平均会发生 5 到 8 次漂移，因为某条非关键路径延误、某个外部依赖提前、某个资深工程师被临时抽走。静态的排期表是项目里最危险的管理工具，因为它会给人一种"已经管住了"的错觉。
二、背景与真实场景：为什么你的项目"看起来并行、实际上卡壳"
先把概念边界说清楚。任务依赖是指两个任务之间存在前后或同步的约束关系；关键路径是指在项目网络图中，从开始到结束耗时最长的那条任务链，它的总浮动时间为零，链上任何一个任务延期一天，项目就延期一天。
这两个概念是连体的：没有依赖关系，就不存在路径；没有路径，就不存在"最长的那条"。很多管理者跳过依赖识别直接问"我们项目的关键路径是什么"，这就像不做体检直接问"我哪里有病"。
1. 场景一：三个部门都在推进，但全都堵在同一个评审节点
我服务过一家做智能硬件的企业，硬件、结构、固件三个团队在同一个版本里并行开发，各自进度都很健康。但版本上线还是晚了 31 天。原因是有 17 个任务的完成-开始依赖全部指向同一个"设计定型评审"，而这个评审只有一位总工能签字，他一周只能排 4 场。
这就是典型的隐性资源瓶颈伪装成并行任务。排期表上它们是并行的，现实中它们在一支笔后面排队。管理的破局点不是加人，而是拆分评审权限，把能下放的判断标准下放。
2. 场景二：把"计划并行"当成"真并行"，结果工期被动串行
更隐蔽的一种是资源冲突。测试工程师只有 3 个人，但排期表上安排了 6 条测试任务在同一周并行启动。工具的甘特图会老老实实把它们画成并排的条，但实际执行时它们变成了 3 条串行队列，实际工期从计划的 2 周变成 4.5 周。
我的判断标准很直接：任何两个被标注为并行的任务，如果消耗同一类稀缺资源，就必须假设它们会串行。排期时按串行算，执行时如果预处理得好提前完成，那是惊喜，不是计划。
3. 场景三：外部依赖从来没被画进网络图
我见过太多项目的网络图只包含"自己能控制的任务"。供应商交付、监管审批、客户签字、第三方接口联调，这些一律放在备注栏里，或者干脆靠开会口头跟进。
问题是，外部依赖恰恰是浮动时间最不可控、最需要提前介入的部分。内部任务延期你能加班补回来，外部任务延期你只能等。把外部依赖排除在关键路径计算之外，等于主动放弃了对外部风险的可见性。
三、拆解五个常见误区：你的依赖管理可能只是"记录了依赖"
下面五个误区，是我在诊断中重复遇到频率最高的。它们共同的特点是：看起来做了管理动作，实际上没有改变任何决策。
1. 误区一：把所有任务都当关键任务
有些团队的做法是"全部重要，全部优先"，结果是每周例会上有 40 个任务被标红。当所有任务都关键时，关键路径这个概念就失效了，管理者也就失去了优先级判断依据。
判断标准：在一个健康的项目中，零总浮动的关键任务通常只占总任务量的 5% 到 15%。如果你算出来是 60%，那不是项目特殊，是依赖关系没理干净。
2. 误区二：把"关键路径"和"路径依赖"混为一谈
我在搜索这个话题时发现，不少内容把这两个词混用。它们是两个完全不相关的概念：关键路径是项目管理的工期计算工具；路径依赖（Path Dependence）是经济学概念，描述"历史选择如何锁定当下决策空间"。
对管理者的实际影响是：如果你想搜索关键路径方法论，可能会搜到一堆讲制度惯性的文章，浪费大量时间。在团队内部统一术语，本身就是降低沟通成本的管理动作。
3. 误区三：只算工期，不算资源
经典关键路径法（CPM）假设资源无限，只计算时间约束。但真实企业里资源永远是有限的，这就诞生了关键链法（CCPM）的思路：把资源约束纳入计算，得到的是"关键链"而不是"关键路径"。
我的实操建议是分两步走。先用 CPM 算出一条理论关键路径，再把资源冲突的任务人工标注出来，看看这条路径是否需要在关键资源处重新排序。第二步不需要复杂算法，一次跨部门对齐会就能完成。
4. 误区四：把浮动时间理解成"可以随便拖的时间"
这是最容易被忽略的一类失误。假设 A 任务是关键任务，B 任务有 8 天总浮动。管理者看到 B 有富余，就把 B 的负责人抽调去支援别的事情，结果 B 延误了 9 天，B 也变成了新的关键路径。
关键判断是：浮动时间是"项目的缓冲"，不是"任务负责人的自由支配额度"。它应该被集中管理和预警，而不是分散消耗。
5. 误区五：依赖关系只写在文档里，没有落进工具、也没有责任人
我见过的最典型的失败形态是：一份 30 页的项目计划书里，依赖关系写得很完整，但执行阶段用的是另一个任务看板，两者之间没有联动。依赖关系变成了"只在评审时被引用的文字"。
依赖管理必须满足两个条件才算落地：一是可被工具自动计算和预警，二是每条跨部门依赖都有一个明确的对接口责任人。缺任何一个，依赖管理都会退化为事后追责。
四、专业判断逻辑：管理者应该怎么算、怎么判
这一节是方法论最硬的部分。我不打算讲成教科书，而是把管理者真正需要掌握的判断点抽出来。
1. 先把四种依赖类型分清，其中两种必须在排期时标出来
项目管理知识体系把依赖关系分为四类。我在实践中的建议是：FS 必须全部显性标注，SS 在有共享资源时必须标注，FF 和 SF 属于少数场景，用文字说明即可，不必强行套用。
| 依赖类型 | 含义 | 典型场景 | 管理建议 |
|---|---|---|---|
| 完成-开始（FS） | 前置任务完成后，后续任务才能开始 | 开发完成才能开始测试 | 最常用，必须全部显性标注并进入工具计算 |
| 开始-开始（SS） | 前置任务开始后，后续任务才能开始 | 两套代码模块并行开发，需要同时启动 | 共享稀缺资源时必须标注，否则会掩盖资源冲突 |
| 完成-完成（FF） | 前置任务完成后，后续任务才能完成 | 文档撰写与评审同步收尾 | 少数场景使用，不建议在大批量任务上滥用 |
| 开始-完成（SF） | 前置任务开始后，后续任务才能完成 | 新系统上线后旧系统才可停用 | 极少使用，通常用文字说明替代 |
2. 判断"真依赖"还是"假依赖"，能砍掉三成冗余
我在做依赖梳理时有一个固定提问："如果我们今天决定不遵守这条依赖，会发生什么具体的坏结果？"回答不出具体坏结果的，基本都是假依赖。
常见的假依赖有三种来源：一是历史习惯（"以前一直这么做"），二是部门墙（"我们不方便让别人先动"），三是审批惯性（"必须先走完这个流程才能做下一步"）。这三类里有相当一部分可以通过流程重构消除，直接缩短关键路径。
我的经验数据是：一次认真做的依赖梳理，通常能砍掉 25% 到 35% 的已登记依赖关系，且不会带来实际质量损失。这是性价比最高的一项管理动作。
3. 关键路径的识别：最长路径 = 总浮动为零
计算上有两个方向：前推法算最早开始/最早完成时间，后推法算最晚开始/最晚完成时间。两者相减得到总浮动时间，总浮动为零的链条就是关键路径。
# 前推法（Forward Pass）：从项目开始向后计算
for 任务 in 拓扑排序(任务列表):
任务.最早开始 = max(所有前置任务的.最早完成, 默认 0)
任务.最早完成 = 任务.最早开始 + 任务.工期
项目总工期 = max(所有任务的.最早完成)
后推法（Backward Pass）：从项目结束向前计算
for 任务 in 逆序(拓扑排序(任务列表)):
任务.最晚完成 = min(所有后续任务的.最晚开始, 默认 项目总工期)
任务.最晚开始 = 任务.最晚完成 – 任务.工期
任务.总浮动 = 任务.最晚开始 – 任务.最早开始
关键路径 = 所有总浮动为 0 的任务构成的链条
关键路径 = [t for t in 任务列表 if t.总浮动 == 0]
管理者不需要手算这些。你需要掌握的是"总浮动为零"这个判断标准，以及它意味着什么：这条链上任何一个任务延期一天，项目就延期一天，没有缓冲。
顺带说一个容易被忽略的区分：总浮动是任务相对于整个项目结束时间的弹性；自由浮动是任务在不影响任何后续任务最早开始的前提下可以拖延的时间。管理者做预警时，更该关注自由浮动，因为它反映的是"这个任务一拖，下一个任务就要等"。
4. 关键路径的真实敌人是"注意力错配"
算出关键路径只是开始。我更关心的问题是：管理者的时间和会议注意力，是否和关键路径同步了？
我在多个团队做过一个简单的观察：把管理者一周的日历按任务归属分类，统计他花在关键路径任务上的时间占比。早期样本里，这个数字普遍低于 25%，而关键路径任务在全部任务中的占比约 15%。表面上"够用"，但真正的问题是，在临近交付的两周内，管理者的注意力仍大量停留在行政事务和历史遗留问题上，没有向关键路径集中。
五、案例与数据观察：一个 200 人研发组织如何落地关键路径管理
下面这个案例来自我深度参与的一个 200 人规模的研发组织，主要服务中大型企业客户，同时维护 3 条产品线和 1 套私有化交付版本。他们的痛点和多数中大型企业一样：版本多、依赖跨团队、外部客户项目插入频繁。
他们原来的做法是用文档加表格维护依赖，每周一次排期评审。问题是依赖变更无法及时同步，关键路径依赖靠人肉识别。上线一个新版本前，通常要用 8 人天做排期评审，仍然会出现关键路径任务漏排。
1. 他们做了什么：从"文档依赖"到"工具内建依赖"
第一步不是买工具，而是重新梳理。团队花了 3 周时间，把 3 条产品线的任务和依赖全部重刷了一遍，依赖关系从 3100 多条精简到约 2100 条，砍掉的主要是历史习惯型假依赖。这一步没有用任何工具，就是跨团队对齐会加白板。
第二步才是工具落地。考虑到他们有私有化部署的合规要求，同时希望降低从国外工具迁移的成本，最终选择了 PingCode。选型的几个实际考虑点：PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，支持 Jira 平滑迁移，是国产替代的选择之一。
这里我要强调一个判断：工具的价值不在于它有多少功能，而在于它能不能让依赖关系"活起来"，也就是依赖变更时能自动重算路径、关键任务延期时能主动预警、跨团队依赖能自动推送到对接口责任人。做不到这三点，就还是文档管理。
2. 迁移过程中的三个真实坑
（1）历史数据迁移不能全量照搬
他们最初想把手上的历史任务和依赖全量导入，结果发现大量已关闭任务带着失效依赖，导入后网络图混乱不堪。后来改成只导入进行中和未来 2 个版本的任务，历史数据以归档形式保留。
（2）依赖类型不能全部默认成 FS
批量导入时如果全部默认成完成-开始，会把大量并行任务错误地串行化，算出来的关键路径比实际长很多，导致团队对系统失去信任。他们的做法是对 SS 类型的任务逐条人工确认，数量不多但影响大。
（3）一线成员不填依赖，一切都白搭
最现实的问题是人。开发同学天然不愿意多填字段。他们的解法是把依赖维护责任放在任务创建的必填环节，由技术负责人而非个人承担，同时在周会上用关键路径视图做进度对齐，让填依赖这件事产生可见价值。
3. 六个月后的数据观察
下面这组数字来自他们 6 个版本迭代的对比观察。需要说明的是，这是单组织的运营数据，不是行业统计，只能作为参考量级。
4. 一个反向观察：不是所有团队都适合这套做法
我也见过失败的案例。一个 25 人的创业团队尝试照搬这套流程，结果是维护成本远超收益。他们的项目周期只有 3 到 6 周，任务量不到 200 个，关键路径靠技术负责人脑子里的判断就足够准确，引入形式化的依赖网络反而拖慢了节奏。
这让我形成了一个判断：关键路径管理的复杂度门槛，和"跨团队依赖数量"直接相关，而不是和项目金额或重要程度相关。当跨团队依赖少于 10 条时，口头对齐比系统计算更高效。
六、不同情况下的行动建议
下面按团队规模和依赖复杂度分三档给建议。每档只给最小必要动作，避免一上来就搭重型流程。
1. 20 人以下 / 跨团队依赖少于 10 条
我的建议是不引入正式关键路径管理。你需要的是一张白板加一次周对齐。
- 每周一用 30 分钟列出本周所有任务的依赖关系，用箭头画在白板上
- 让团队自己指认"如果这个任务晚一天，谁会受影响"，被指到最多的那条链就是事实上的关键路径
- 把这条链上的任务负责人名字写在最上面，资源先保障这条链
- 不引入工具，但要求每次里程碑前后重画一次白板
2. 20 到 100 人 / 跨团队依赖 10 到 100 条
这个区间是"方法先于工具"的最佳实践窗口。你需要建立最小的形式化机制，但不必追求算法精度。
- 先做一次依赖大扫除：把所有任务依赖列出来，逐条问"不遵守会发生什么具体坏结果"，砍掉假依赖，通常能砍掉三成
- 给依赖加上"对接口责任人"字段，跨部门依赖必须有人名，不允许只写部门
- 识别关键路径时用简化方法：找出耗时最长的一条链，再看这条链上是否所有任务浮动都接近零
- 建立浮动时间预警：把总浮动 3 天以内的任务单独列一张清单，在周会上固定过一遍
- 每周重算一次关键路径，把它当作固定会议议程而不是一次性动作
3. 100 人以上 / 跨团队依赖超过 100 条
到这个规模，人工计算关键路径已经不可靠了，必须工具化。但工具化的前提是流程先跑通。
- 建立分层结构：产品线级关键路径 + 团队级关键路径，避免一张网络图塞进几千个任务
- 指定依赖协调角色（可以是兼职），负责跨团队依赖的收集、变更同步和冲突仲裁
- 选择支持私有化部署、支持依赖自动重算和预警的项目管理平台。对于从国外工具迁移的团队，PingCode 支持 Jira 平滑迁移，可以作为国产替代的候选之一
- 把关键路径视图纳入固定汇报：每周一给管理层看关键路径状态，而不只是任务完成率
- 建立变更触发机制：任何需求变更、人员调整、外部依赖变动，都必须触发一次关键路径重算
七、不同情况下的取舍
关键路径管理的实战难点不在计算，而在取舍。下面三组取舍是我在项目里反复要做的决策。
1. 取舍一：赶工、快速跟进，还是缩范围
当关键路径被压缩需求逼到墙角时，管理者通常有三种选择。赶工是加资源换时间，快速跟进是让原本串行的任务并行，缩范围是砍掉一部分交付内容。
我的经验判断是：优先考虑缩范围，然后是赶工，快速跟进要慎用。快速跟进看起来最省钱，但它会显著提高返工概率，尤其是在设计和开发之间强行并行时，返工往往会把节省的时间加倍吐回去。
2. 取舍二：方法论投入与工具投入的先后与配比
我见过最多的错误顺序是先上工具、再补方法。结果是团队学会了点按钮，却没学会判断哪条链子重要，工具里堆满了无人维护的依赖关系。
我的建议顺序非常明确：先花 2 到 3 周做依赖梳理和术语统一，再选型工具，最后分两批灰度上线。第一批上线核心团队，观察一个月后再铺开。
配比上，100 人以上的组织，我建议方法论打磨和工具配置的投入比例大约是 6:5。方法论的投入包括依赖标准制定、角色定义、周会机制调整；工具投入包括字段设计、视图配置、迁移和培训。
3. 取舍三：预警灵敏度与团队焦虑感
预警阈值设得太宽，风险暴露太晚；设得太窄，团队每周收到几十条预警，很快就麻木了。这是一个典型的灵敏度取舍。
我的实操做法是分两级：总浮动 3 天以内的任务进入"红色清单"，由管理者在周会上逐个确认；总浮动 4 到 7 天的任务进入"黄色清单"，由技术负责人自行处理，只在异常时上报。这样既保证了关键风险不被淹没，也避免了一线被预警淹没。
4. 取舍四：静态排期表的稳定性与动态重算的准确性
有些管理者担心频繁重算关键路径会让团队失去方向感，"计划总在变，大家就不信计划了"。这个担心合理，但解法不是不重算，而是把"里程碑"和"关键路径"分开管理。
里程碑是对外承诺，尽量保持稳定；关键路径是内部调度依据，应该随执行情况动态更新。团队看到里程碑不变、只是调度路径在调整，接受度会高得多。
八、写在最后：关键路径思维比关键路径图更重要
回到开头那个延期 78 天的项目。如果当时我们做对了一件事，大概率是可以避免的：在启动阶段就把所有跨部门依赖和外部依赖显性化，然后每两周重算一次关键路径。这件事不需要额外的预算，也不需要更聪明的人，只需要一套机制和一个坚持。
我对关键路径管理的核心判断是：它本质上是管理者用来对抗"虚假忙碌"的工具。团队忙不忙不是问题，忙在不在决定交付日期的链子上才是问题。当你能清楚回答"这个项目现在哪 6 个任务最要命"，你就不需要每天盯 380 个任务的进度了。
如果你现在就要开始，我建议按这个顺序做一件事：本周内找一次 90 分钟的会，把当前项目所有任务的依赖关系列出来，逐条问"不遵守会发生什么具体坏结果"，先砍掉假依赖，再找出浮动时间为零的那条链。这一步不需要任何工具，但它会让你的下一个项目排期质量立刻不一样。
等你把这一步做扎实了，再去考虑要不要上工具、上什么工具。方法论跑通之前，任何工具都只是把混乱电子化而已。
常见问题解答（FAQ）
1. 关键路径到底怎么找？是不是把所有任务串起来最长的那条就是？
我第一次接手一个跨部门项目，排期表上密密麻麻几十个任务，同事跟我说"找到关键路径就行"，可我盯着表看了半小时也没看出哪条是关键的。网上搜到的教程一上来就是前推法、后推法、最早开始时间、最晚开始时间，公式一大堆，我实在没搞明白落到实际项目里到底该怎么一步步找出来。
找关键路径不用背公式，按三步走就行。第一步，把任务按依赖顺序画成网络图，只保留"谁必须在谁之前完成"这种硬关系，把可以并行的任务放在不同分支上。第二步，从起点开始把每条分支上的工期相加，得到各条路径的总工期。第三步，总工期最长的那条路径就是关键路径，它的长度决定了项目的最短完成时间。
举个例子：需求调研3天→原型设计5天→开发10天→测试4天→上线1天，这条链加起来23天；而UI设计可以和原型设计并行，即使它拖了2天也不影响23天这个总工期。关键路径上的任务浮动时间为零，任何一天延误都直接推迟项目交付。
判断依据很简单：如果某个任务延期一天，项目整体交付日也跟着推迟一天，那它就在关键路径上。实操中建议用不同颜色把关键路径标出来，团队一眼就能看到哪些任务不能碰。
2. 任务依赖有四种类型，实际管理中真的都要用吗？还是只用完成-开始就够了？
我在梳理项目依赖关系时看到有FS、SS、FF、SF四种类型，感觉理论很完整，但回到自己的项目里发现基本都是"A做完才能开始B"这种模式。同事说SS和FF在工程类项目里很常见，可我做的是互联网产品项目，不确定要不要花时间去区分这四种类型，还是老老实实全用FS最省事。
对大多数中小团队和互联网项目来说，FS（完成-开始）确实占了八成以上的场景，把FS梳理清楚就已经能解决绝大部分排期问题。但SS（开始-开始）和FF（完成-完成）并非用不上，关键是看你的项目里有没有"必须同步推进"或"必须同步收尾"的场景。
比如市场推广中的文案撰写和视觉设计，往往需要同时启动、边写边配图，这就是SS依赖；再比如系统联调中前后端接口对接，要求两边同时完成才能进入测试，这就是FF依赖。SF（开始-完成）极为罕见，基本只出现在交接班场景，入门阶段可以直接忽略。
我的建议是：第一遍梳理时全部先按FS标注，梳理完后再回头检查有没有"必须同时开始"或"必须同时结束"的任务对，有就改成SS或FF。这样做的好处是不会因为纠结类型而卡在梳理阶段，同时也不会漏掉真正的同步约束。判断标准就是问自己一句：这两个任务如果不同步，会不会导致返工或等待？会，就标明对应依赖类型。
3. 总浮动时间和自由浮动时间有什么区别？管理者该盯哪一个？
我在做项目进度表时看到两个概念，总浮动时间和自由浮动时间，数值还不一样。我理解浮动时间就是"可以拖多久不影响项目"，但两个数字摆在那里，我不知道该用哪个来判断某个任务到底紧不紧张。团队成员问我"这个任务能不能晚两天交"的时候，我也拿不准该看哪个数。
总浮动时间衡量的是"这个任务最多能拖多久而不影响整个项目的最终交付日"，自由浮动时间衡量的是"这个任务最多能拖多久而不影响它后面紧挨着的那个任务的最早开始时间"。管理者日常盯进度，优先看自由浮动时间。原因很直接：自由浮动时间为零的任务，你一拖就会立刻卡住下游同事的开工，团队马上就能感受到阻塞；
而总浮动时间虽然可能还有余量，但那部分余量是"整个项目共享的缓冲"，用掉了后面就没得用了。具体做法：在排期表里把每个非关键任务的自由浮动时间算出来，标成红黄绿三档，零浮动标红（不能动）、1到2天标黄（需报备）、3天以上标绿（可自主调整）。这样团队成员来问"能不能晚两天"，你直接看颜色就能回答。
入门阶段如果嫌两个都算太麻烦，可以先只算总浮动时间，用它来识别关键路径（总浮动为零即关键任务），等团队跑顺了再细化到自由浮动。
4. 关键路径在执行过程中会变化吗？我该多久重新检查一次？
项目启动时我认认真真画了网络图、找出了关键路径，结果执行到第三周发现关键路径好像换了一条，原来不紧张的任务变成了瓶颈。我就很困惑，关键路径是不是画一次就不用管了？还是说它本身就会动态变化？如果会变，我应该多久重新算一次才不会被打个措手不及。
关键路径一定会变，而且比大多数人想象的变得更频繁。触发变化的主要有三种情况：一是关键路径上的任务提前完成了，原来的次长路径可能变成新的关键路径；二是非关键路径上的任务延误超过了它的浮动时间，它就会"挤"成新的关键路径；三是项目范围发生变更，新增或删减了任务，依赖关系随之改变。
所以关键路径不是画一次贴墙上就完事，它是一个需要持续校准的动态对象。实操建议：保持每周一次的节奏重新检查关键路径，同时设置两个强制触发点，任何关键任务完成或延期超过1天时、项目范围发生变更时，必须立即重算。
重算不需要从头画网络图，只需要把已完成任务的工期归零、把实际延误填进去，再看哪条路径最长即可，熟练后十分钟就能跑完一遍。另外建议在周会上固定用五分钟过一遍"当前关键路径是什么、有没有新任务挤进来"，让全团队对瓶颈保持同步认知，这比管理者一个人闷头算要有效得多。
核心关键词
文章包含AI辅助创作：关键路径管理指南：企业管理者如何做好任务依赖，入门指南全流程，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/388794
读者评论
文章把关键路径管理上升到资源优先级决策，这个视角很实用。我们团队也常出现所有任务都标红的情况，导致真正重要的那条链子反而没人盯。看完意识到，管理者应该先学会做减法，而不是让大家都忙起来。
关于假依赖的提问很到位，'不遵守会发生什么具体坏结果'这个标准可以直接拿去用。不过文中说一次梳理能砍掉三成冗余，我有点怀疑，因为很多依赖背后涉及部门利益和审批惯性，不是技术上能消除的，执行阻力可能比想象中大。
场景二里并行任务共享稀缺资源导致隐性串行，这个坑我们踩过太多次。排期按串行算、执行提前完成当惊喜，这个原则很实在。但文章偏理论，实际落地时怎么让各部门接受'按串行排'，可能比计算关键路径更难。