4. 时间估算与排期：PERT估算法、三点估算法、关键路径法（CPM）基础、缓冲时间（Slack/Float）计算
时间估算，说白了就是回答一个问题：这事儿到底要干多久？
我刚带项目那几年，最怕的就是拍脑袋估时间。老板问「这个功能多久能做完？」我随口说「两周」，结果干了一个月还没收尾。后来我学乖了——不是靠直觉，而是靠方法。
这一章，咱们就把时间估算的几把硬家伙捋一遍。PERT、三点估算、关键路径、缓冲时间，这些名字听着唬人，其实核心逻辑很简单。
4.1 三点估算法：告别单点猜测
先问个问题：你估时间的时候，是不是只给一个数字？比如「这个模块5天搞定」。
但现实是，5天可能只是最理想的情况。万一需求变、接口出问题、同事请假呢？三点估算法的思路很简单——别只猜一个数，猜三个。
| 估算类型 | 含义 | 符号 |
|---|---|---|
| 乐观时间 | 一切顺利，啥都不出岔子 | O |
| 最可能时间 | 正常情况，有点小波折但能搞定 | M |
| 悲观时间 | 能想到的坏事全发生了 | P |
有了这三个数，就能算出一个加权平均。公式长这样：
期望时间 (TE) = (O + 4M + P) / 6为什么是除以6？说白了，就是给「最可能时间」多加点权重。我习惯在Excel里直接拉公式，每次估完三个数，自动出期望值。
举个例子：
你估一个功能开发：乐观2天，最可能4天，悲观8天。
TE = (2 + 4×4 + 8) / 6 = (2 + 16 + 8) / 6 = 26 / 6 ≈ 4.33天
你看，不是简单的平均（2+4+8）/3=4.67，而是更靠近最可能值。
我的习惯：每次估完三点，我会再问自己一句：「悲观时间是不是真的够悲观？」很多人低估了悲观值。我曾经有个项目，悲观估了10天，结果真出了个线上事故，修了14天。从那以后，我让团队把悲观值再乘1.2。
4.2 PERT估算法：把三点估算串成网络
三点估算解决的是「单个任务估多久」。但一个项目有几十个任务，它们之间有前后依赖关系。这时候就需要PERT（计划评审技术）了。
PERT的核心就两步：
- 拆任务：把项目拆成一个个小活动，标出谁先谁后。
- 算期望：对每个活动用三点估算算出TE，然后沿着路径累加。
我当年第一次用PERT，是在一个硬件+软件联调的项目里。硬件组说「打板要3周」，软件组说「驱动开发要2周」，但硬件不打完，软件没法联调。PERT一画出来，关键路径一目了然——硬件那边一延期，整个项目都得等。
注意：PERT不是算完就完。它最大的价值是让你看到哪条路径风险最高。如果某条路径上的任务全是悲观值偏大的，那这条路就是你的重点关注对象。
4.3 关键路径法（CPM）：找到那条最长的链
关键路径法，英文叫Critical Path Method，简称CPM。名字听着高大上，其实道理特简单：
一个项目里，总有一条任务链，它的总工期最长。这条链就是关键路径。链上的任何一个任务延期，整个项目就延期。
怎么找关键路径？我一般分四步走：
- 列出所有活动，标出每个活动的工期。
- 标出依赖关系：A做完才能做B，B和C都做完才能做D。
- 正向计算：从起点开始，算每个活动最早啥时候能开始（ES）、最早啥时候能结束（EF）。
- 反向计算：从终点倒推，算每个活动最晚啥时候必须开始（LS）、最晚啥时候必须结束（LF）。
正向和反向算完，你就能得到两个关键指标：
| 指标 | 公式 | 含义 |
|---|---|---|
| 总浮动时间 (Total Float) | LS - ES 或 LF - EF | 整个项目能容忍的延迟量 |
| 自由浮动时间 (Free Float) | 后继任务ES - 当前任务EF | 不影响下一个任务的最大延迟 |
关键路径上的任务，总浮动时间 = 0。
这意味着什么？意味着这些任务一天都不能晚。晚一天，项目就晚一天。
我记得有一次做电商大促项目，前端团队有个任务在关键路径上。他们估了3天，结果第2天发现接口文档没对齐。我立刻协调后端优先处理，硬是赶在deadline前搞定了。如果当时没意识到那是关键路径，可能就放过去了。
4.4 缓冲时间（Slack/Float）计算：给自己留条后路
缓冲时间，也叫浮动时间。说白了就是一个任务能晚多久，而不影响项目总工期。
计算其实不复杂：
总浮动时间 (TF) = 最晚开始时间 (LS) - 最早开始时间 (ES)
或者
总浮动时间 (TF) = 最晚结束时间 (LF) - 最早结束时间 (EF)举个例子：
- 任务A：最早第2天开始，最晚第5天开始 → TF = 5 - 2 = 3天
- 任务B：最早第3天开始，最晚第3天开始 → TF = 0天（关键路径）
任务A有3天缓冲，意味着它可以晚3天开工，项目总工期不受影响。但任务B一天都不能晚。
我的经验：缓冲时间不是让你摸鱼的。我一般会把缓冲时间当成「风险储备」。比如任务A有3天缓冲，我会跟团队说：「前2天正常干，如果遇到问题，还有1天可以救急。」但千万别一开始就把缓冲用掉——万一后面还有更大的坑呢？
4.5 避坑指南：时间估算常见的几个坑
做了这么多年项目，我踩过的坑不少。挑几个典型的说说：
- 「乐观偏差」：总觉得这次不会出问题。我曾经有个项目，所有任务都按最可能时间估，结果每个任务都超了20%。后来我强制要求每个任务必须给出悲观值，并且悲观值不能低于最可能值的1.5倍。
- 「忽略依赖等待」：任务A做完要等审批，审批要2天。很多人只算开发时间，忘了算等待时间。PERT网络里一定要把「等待」也当成一个活动。
- 「关键路径只找一条」：大项目往往有多条接近关键路径的链。我习惯把总浮动时间小于等于2天的路径都标出来，作为「次关键路径」一起盯着。
- 「缓冲时间被滥用」：有些团队成员看到有缓冲，就慢慢干。我后来定了个规矩：缓冲时间由项目经理统一管理，任务负责人不能自行消耗。
我曾经犯过的错：在一个跨团队协作的项目里，我算出了关键路径，但没有每周重新评估。结果中途有个任务提前完成了，关键路径变了，我没发现，导致后续排期全乱套。记住：关键路径是动态的，要定期刷新。
4.6 小结：这些方法怎么配合用？
你可能会问：这么多方法，我到底用哪个？
我的建议是：组合使用。
- 用三点估算给每个任务算期望工期。
- 用PERT把任务串成网络，看清依赖关系。
- 用CPM找出关键路径，知道哪些任务碰不得。
- 用缓冲时间管理风险，给自己留余地。