# PERT公式：项目时间估算中的“瑞士军刀”为何总被用错？
上周有个客户跟我吐槽：“我们团队每次预估工期都像算卦，上次按最乐观情况排计划，结果需求变更直接炸锅！” 这让我想起三年前给某芯片研发团队做咨询时的场景——他们用传统经验估算法导致流片时间延误，险些错过市场窗口期。其实PERT公式早就在军备竞赛和互联网大厂里成为时间估算的标配，但90%的团队都只用了它的皮毛。
一、PERT公式到底是什么？与常规估算有何不同？
核心定义：- 三点估算法：不是简单拍脑袋，而是通过最乐观时间（O）、最可能时间（M）、最悲观时间（P）构建概率模型
- 加权平均机制：公式 $$ \text{预期时间} = \frac{O + 4M + P}{6} $$中，最可能时间权重占67%，避免极端值干扰
对比传统方法：
- 经验类比法：老王说“上次做类似模块用了5天”——但这次可能涉及新技术
- 专家判断法：张工拍胸脯保证“绝对3天搞定”——却没考虑测试资源冲突
- PERT优势：量化不确定性，像天气预报用概率描述降雨，而非武断下结论
二、PERT公式的隐藏技能：不只是算个平均数
（1）风险可视化：从模糊感到数字量化
举个真实案例：某APP开发团队估算登录功能耗时，给出O=2天（代码复用）、M=4天（部分重构）、P=8天（第三方接口异常）。计算得(2+16+8)/6=4.3天，同时方差$$ \frac{P-O}{6} = 1 $$
天，意味着有15.87%概率超过5.3天完成（懂统计的人自然明白这个数的意义）。
（2）与关键路径法的“化学反应”
在Ganttable中绘制甘特图时，将PERT计算结果代入关键路径分析，能精准识别“死亡倒计时”任务。比如某智慧园区项目中，土建施工的PERT预期时间比原计划多0.7天，通过蒙特卡洛模拟发现整体工期超限概率飙升至32%，及时触发应急方案。（3）敏捷开发里的“变体玩法”
别再说“敏捷不需要PERT”啦！我们在用Ganttable做Sprint规划时，把每个用户故事拆解成O/M/P三态，自动聚合成燃尽趋势曲线。有个电商项目就靠这招，在双十一大促前3周就预警了库存系统对接风险。三、那些年踩过的坑：PERT公式使用的三大禁忌
说实话，刚接触这个公式时我也犯过蠢。有次帮教育机构估算课程开发周期，直接套用公式却忘了这事——1. 把复杂依赖关系想简单了 当时以为每个任务都能独立估算，结果视频拍摄（任务A）和课件排版（任务B）存在隐性资源竞争。后来在Ganttable里加了资源负荷视图，才发现设计师每天被分配了183%的工作量。
2. 数据收集套路多 “最悲观时间”可不是让程序员随便报个吓人的数。推荐用这个历史数据对比工具，自动抓取过往相似任务的实际耗时生成参考阈值。
3. 当成免责金牌使不得 有次用PERT算出测试周期6.2天，结果开发延期导致测试时间缩水。千万别学那个项目经理甩锅说“数学公式都这么算的”，这篇文章写得好：PERT是决策辅助器，不是责任转移器！