关键路径不是任务最多、最重要或负责人最忙的那条线，而是在当前工期和依赖条件下，决定项目最早完成时间的最长路径。计算时先从起点向前推，得到每项任务的最早开始、最早完成；再从终点向后推，得到最晚开始、最晚完成。两组时间的差，才是判断任务能否延迟的依据。
如果要把结果放进项目甘特图排期，应先核对依赖，再标日期。下面以一场培训活动的筹备为演算案例，算完六项任务，并解释为什么“有两天总浮时”不等于“推迟两天也不影响其他人”。
先锁定六项任务和计算条件
本例从时间 0 开始计时，单位为工作日；一项持续 2 天的任务在时间 0 开始、时间 2 完成。所有关系均为“完成后才能开始”（FS），没有提前量、滞后量、周末日历或共享人力限制。持续时间已确定，任务不可中途拆分。实际项目不满足这些条件时，需要先调整模型，不能直接套用结果。
| 编号与任务 | 持续时间 | 直接前置任务 | 完成条件 |
|---|---|---|---|
| A 确认培训目标 | 2 天 | 无 | 明确对象、学习目标及练习范围 |
| B 制作讲解与练习材料 | 5 天 | A | 材料可供完整演练 |
| C 准备报名与参与方式 | 3 天 | A | 报名信息及参与路径已确认 |
| D 完成培训演练 | 2 天 | B、C | 材料与参与路径一起走通，问题已处理 |
| E 编写参加说明 | 2 天 | C | 说明与实际报名、参与方式一致 |
| F 做最终准备检查 | 1 天 | D、E | 演练结果与参加说明均已核对 |
关系为 A→B、A→C、B→D、C→D、C→E、D→F、E→F。D 必须等 B 和 C 都完成；F 必须等 D 和 E 都完成。箭头表达成果的先后依赖，不是部门汇报关系，也不代表同一负责人必须串行工作。暂时说不清前置成果时，可以先按需求依赖关系的梳理方法补齐条件，再进入计算。
前推：汇合点取最晚到达的前置结果
用 ES 表示最早开始时间，EF 表示最早完成时间。起始任务 ES=0；其他任务的 ES 等于所有直接前置任务 EF 的最大值，随后用 EF=ES+持续时间计算完成时间。
- A：ES=0，EF=0+2=2。
- B、C 都等待 A，因此 ES 都是 2；B 的 EF=2+5=7，C 的 EF=2+3=5。
- D 同时等待 B 和 C，ES=max(7,5)=7，EF=7+2=9。
- E 只等待 C，ES=5，EF=5+2=7。
- F 等待 D 和 E，ES=max(9,7)=9，EF=9+1=10。
所以，本模型最早在时间 10 完成。不能在汇合点取平均值，也不能因为一条支线先结束，就让后续任务提前启动。例如 C 在时间 5 完成，D 仍要等到 B 在时间 7 完成。
后推：分叉点取最早要求交付的后续任务
用 LS 表示最晚开始时间，LF 表示最晚完成时间。本例不另加外部截止日期，以前推得到的时间 10 为项目终点。末项 F 的 LF=10、LS=10−1=9。向前逐项计算时，任务的 LF 等于所有直接后续任务 LS 的最小值，再用 LS=LF−持续时间计算。
D、E 都要在 F 最晚开始的时间 9 之前完成，所以两者 LF=9、LS=7。B 的后续只有 D，故 LF=7、LS=2。C 后续有 D 和 E，两者 LS 均为 7，因此 C 的 LF=min(7,7)=7、LS=4。最后，A 必须在 B、C 中更早需要它的那一项之前完成：LF=min(2,4)=2，LS=0。
| 任务 | ES | EF | LS | LF | 总浮时 TF | 自由浮时 FF |
|---|---|---|---|---|---|---|
| A | 0 | 2 | 0 | 2 | 0 | 0 |
| B | 2 | 7 | 2 | 7 | 0 | 0 |
| C | 2 | 5 | 4 | 7 | 2 | 0 |
| D | 7 | 9 | 7 | 9 | 0 | 0 |
| E | 5 | 7 | 7 | 9 | 2 | 2 |
| F | 9 | 10 | 9 | 10 | 0 | 0 |
关键路径是 A→B→D→F，总工期为 2+5+2+1=10 天。这条路径上的任务总浮时均为 0。另两条完整路径 A→C→D→F、A→C→E→F 都是 8 天。路径长度的比较与前推、后推结果应当一致。
这里采用的计算关系与 PMI 的关键路径计算说明一致。如果项目有指定截止日、复杂日历、其他依赖类型或资源平衡安排，最晚时间与浮时可能不同，不能只看这张简化表。
总浮时与自由浮时：C 有两天余量，为什么仍会影响 E
总浮时 TF=LS−ES=LF−EF，表示在本模型中，不推迟项目完成时间所允许的时间余量。自由浮时 FF=后续任务最早 ES−本任务 EF，表示不推迟任何直接后续任务最早开始时间的余量。末项 F 以项目终点计算，本例为 0。
C 的总浮时为 4−2=2 天，但自由浮时为 min(D 的 ES 7，E 的 ES 5)−C 的 EF 5=0 天。因为 E 原本计划在时间 5 接着 C 开始，C 一旦延迟，E 的最早开始就会后移；只是 E 这条支线原本有余量，项目暂时仍能在时间 10 结束。
| 调整 | 直接影响 | 项目完成时间 |
|---|---|---|
| C 延迟 1 天开始 | C 在 6 完成，E 改为 6→8；D 仍为 7→9 | 仍为 10，但需要通知 E 的负责人 |
| C 延迟 2 天开始 | C 在 7 完成，E 改为 7→9；两支在 9 汇合 | 仍为 10，相关余量已用尽 |
| C 延迟 3 天开始 | C 在 8 完成，D、E 都变为 8→10 | F 变为 10→11，项目延迟 1 天 |
因此，不能把 C 的两天和 E 的两天相加，承诺这条支线能延迟四天。它们会共享同一段路径余量。浮时也不是负责人可以自行使用的假期：需要看资源安排、已约定的交付时间和后续团队准备情况，再共同决定是否调整。
在白板上评审，先核关系再改日期
在 Boardmix 画布上用六个矩形放置任务，将任务编号、工期和完成条件写进节点，再按前置关系连线。先让各负责人确认箭头代表的交付物，确认后再填 ES、EF、LS、LF；用另一种线色突出 A→B→D→F，并在旁边保留工期与资源假设。按前推、后推的结果填写数值，安排一位同事沿依赖线复核；任务工期或依赖变化后，重新计算并更新对应节点。
评审时可以把 C 的延迟方案放在原计划旁边，让 E 的负责人看到自己的开始时间也会变化。若同一人同时负责 B 和 C，应另标资源冲突，调整任务安排后重新计算；原先允许并行的模型已不再适用。若只缩短 C，却没有改变较长的 A→B→D→F 路径，项目也不会因此提前完成。
每次更新保留三个信息：哪项工期或依赖变了、为什么变、从哪个确认版本开始生效。关键路径可能随着这些变化转移，也可能出现多条同长路径。把当前零浮时任务及接近零浮时的支线一起关注，比只给一条红线贴上“永远优先”更有用。
粤公网安备44030502008643