1. 一个具体问题
开发者说一个接口改造大约四天。项目经理把四天写成承诺，直到第三天才发现第三方文档过时，可能还需一周。最初的估计并非完全没有依据，只是把顺利情况、常见情况和困难情况压成了一个数，隐藏了管理者最需要了解的风险。
2. 一句话解释
PERT 用乐观、最可能和悲观三种工期估计表示不确定性，并结合任务网络研究项目完成时间。
3. 出处与原意
PERT 即计划评审技术，在二十世纪五十年代的北极星项目背景下发展。PMI 的排程资料介绍了常用三点公式。经典近似将预期时长写成“乐观加四倍最可能加悲观，再除以六”，但这是一种建模规则，不是任何工作天然遵循的物理定律。
4. 原理与机制
先明确三点各自对应的条件，再计算加权估计，避免三个人随口报数取平均。经典近似标准差为悲观与乐观之差除以六，其有效性依赖分布假设。任务时间可能相关，多条路径也可能轮流成为最长路径，因此不能随便把一个路径的均值加起来，就声称得到精确的项目按时概率。对复杂网络，可用合理分布和相关性假设做模拟。
估计可以逐步更新，但应保留旧值，才能检查团队是否系统性低估某类工作。若每次都把实际延期解释为意外，就无法学习。更有价值的问题是哪些风险经常出现、三点范围是否覆盖现实，以及能否通过提前验证缩小范围。
5. 一个完整案例
以下是假设案例。数据迁移准备工作估计乐观两天、最可能四天、悲观十天，预期时长为二加十六加十再除以六，约四点六七天；近似标准差为八除以六，约一点三三天。团队进一步说明，十天情景来自历史字段缺失，而不是泛泛的“可能出问题”。他们安排半天抽样检查旧数据，发现缺失集中在一个来源，决定提前补齐映射表。随后重新估计为两天、三天、五天，预期约三点一七天。风险调查改变了输入，比仅对旧数字做更精细的小数计算更有价值。负责人另保留审批等待，并不把它混入开发时长。
6. 适用条件与反例
适合有类似经验但存在显著波动的任务估计。完全未知的研究工作可能连悲观边界都无法可靠给出，此时应先做探索。反例是管理者要求三个估计都接近既定交付日期，再计算出“科学”的平均数；公式无法纠正受压力操纵的输入。
7. 今天可以尝试的行动
选一个不确定性最大的待办，分别写出三种时长和导致差异的条件。找出让悲观情景发生的主要因素，安排一个小调查降低不确定性。把估计日期、假设和范围一起保存，后续用实际结果校准，而不是只追究谁当时猜错。