PERT图
PERT chart
用任务依赖网络分析项目路径和工期。
活动之间有前置依赖，需要讨论估算工期和排程风险时使用。按给定活动时长分析路径与时差。
活动、前置关系、工期单位与估算依据，以及资源容量、日历和其他限制。
条件明确的依赖网络、路径工期、关键路径和时差解释。
先理解，再动手
使用步骤
建立没有循环依赖的任务网络，工期使用统一单位。可用单一估计，或按（乐观 + 4 × 最可能 + 悲观）/ 6 估计期望工期。比较最早与最晚时间及总浮时，识别关键任务；资源容量与日历限制需另行检查。
- 01
列出全部任务
- 02
确定每项任务的前置依赖和估计工期
- 03
绘制网络关系
- 04
识别关键路径
- 05
对关键任务安排资源和风险控制
工期取决于输入与排程假设，不是完成保证；概率风险需另行评估。资源冲突可能使网络估算失效，时差不是无条件可延误时间。
看清框架结构
从一份空白提纲开始
复制到你的文档，填入真实的业务事实与判断。
查看空白提纲
PERT图 · 空白提纲 什么时候用：活动之间有前置依赖，需要讨论估算工期和排程风险时使用。按给定活动时长分析路径与时差。 需要准备：活动、前置关系、工期单位与估算依据，以及资源容量、日历和其他限制。 预期产出：条件明确的依赖网络、路径工期、关键路径和时差解释。 使用边界：工期取决于输入与排程假设，不是完成保证；概率风险需另行评估。资源冲突可能使网络估算失效，时差不是无条件可延误时间。 工作问题： 期望结果： 已有证据与假设： 未知项与下一项核查： 填写说明：项目终点、工期单位与估计假设。 1. 项目范围与单位： 填写说明：每行：ID | 任务 | 工期或乐观/最可能/悲观 | 前置ID（逗号分隔，无则填 -）。例如：B | 开发 | 2/4/6 | A。 2. 任务网络： 填写说明：关键依赖、资源冲突和估计不确定性。 3. 工期风险与跟进： 检查清单 □ 任务依赖关系清楚。 □ 关键路径被识别。 □ 工期风险能被提前管理。 考虑下一个框架 决策矩阵: 网络已暴露多种满足约束的排程方案时，用决策矩阵比较时间、资源和风险取舍，保留估算不确定性。 https://bizthinkframe.com/zh/frameworks/decision-matrix BizThinkFrame · https://bizthinkframe.com/zh/frameworks/pert-chart
跟着案例走一遍
虚构教学案例找到上线计划的关键路径
组织、人物、数据和结果均为虚构，仅用于说明框架用法。
背景与问题
星港准备上线需求系统，有几项任务可以并行。
项目经理平均催所有任务，没有识别哪项延期会推迟上线。
手头有哪些材料
- A需求确认2天，C培训材料3天，D联调2天；B开发三点估计为乐观2、最可能4、悲观6天，期望值(2+4×4+6)/6=4天。
- B、C 均在 A 后开始；D 需要 B 和 C 完成
如何使用这个框架
- 先列任务依赖，再计算两条路径的总时长。
- A→B→D 为 8 天；A→C→D 为 7 天，前者是关键路径。
- C 在其他条件不变时有 1 天浮动；不把浮动理解为可任意拖延。
按给定估计与依赖计算的工期为8天；B延期可能推动计划完工，未计资源冲突，也不是完工承诺。
8 天关键路径、7 天另一条路径和 1 天时差依赖给定时长、前置关系及资源可用假设；不是完成概率或允许任意延迟一天的承诺。
算路径前先排除三种输入问题
网络图要回答的是：哪些前置条件约束终点，哪个估计变化可能改变路径。逐任务定义什么叫完成，统一历时单位和起点。依赖应表示必要先后，不能只因为习惯这样排，就假定不能并行。
三种情况先停：网络有环或引用不存在的前置ID；乐观、最可能、悲观数字其实对应不同范围或单位；并行分支需要同一位无法同时工作的人员。算术合法不代表依赖与容量合法。
三点估计是带条件的判断，不是三条实测完成记录。询问乐观情景靠什么成立、悲观情景包含什么，并连同数字保留。本工具计算加权历时和确定输入下的路径，不生成项目完成时间的概率分布。
选择依赖计算，还是选择带日期的日程
网络回答有条件的先后问题，不知道周末、已批准排班或发起人哪天有空。下一步看缺什么材料，而不是把几张图当成可以互换的完整项目计划。
| 方法 | 需要什么 | 产出 / 限制 |
|---|---|---|
| PERT式网络 | 无环前置关系与历时估计 | 路径与时差；不模拟完成概率 |
| 甘特图 | 任务、日期和工作日历 | 日期条形；容量仍须核对 |
| 路线图 | 阶段产出和支撑条件 | 讨论方向路径；不排每项工时 |
| RACI矩阵 | 交付物与决定权 | 职责提议；不估计历时 |
完整案例：把正推和逆推都算出来
继续使用独立的星港系统上线虚构案例，不混入松桥带日期的准备计划。教学网络完整输入只有四项：A需求确认2天，无前置；B开发在A后，估计2/4/6天；C培训准备在A后，3天；D集成在B和C都完成后，2天。给定计算排除了资源冲突。
B的加权值为(2+4×4+6)/6=4天。从历时索引0开始，不映射日历日期。A到2结束，B和C都可从2开始，分别到6和5。D须等较晚的6，到8结束。因此A–B–D为8天，A–C–D为7天。把所有任务加成11天，会擅自删掉给定的并行关系。
逆推把有条件的项目终点设为8。D从6开始，因此B、C最晚都要在6结束；B最晚2开始，C最晚3开始。A必须在两个后继最晚开始中的较早值2前结束，所以从0开始。总时差为最晚开始减最早开始，只有C为1天。这是条件成立时的排程空间，不是谁独占的缓冲，也不意味着无需沟通就能推迟。
| 任务 / 历时 | 最早开始 / 结束 | 最晚开始 / 结束 | 总时差 |
|---|---|---|---|
| A / 2 | 0 / 2 | 0 / 2 | 0 |
| B / 加权4 | 2 / 6 | 2 / 6 | 0 |
| C / 3 | 2 / 5 | 3 / 6 | 1 |
| D / 2 | 6 / 8 | 6 / 8 | 0 |
改一个估计，也要复查整个网络
原结论是估计终点8天，A、B、D位于零时差路径，不是承诺8天完成。另作敏感性情景：只把C从3改成5天，则A–C–D为9，A–B–D仍为8；C变为关键任务，B有1天总时差。可见关键路径不是任务名称的永久属性。
人员另作情景核对。如果B和C必须由同一人顺序执行，保持原历时则为2+4+3+2=11天，尚未计其他限制。这是改变顺序假设后的假设试算，不是当前并行网络自动识别的结果。先确认人员，再修订依赖或估计。
复查请估计者说明范围、前置、未决工作和2/4/6各自的条件。保留旧网络，追加新输入与理由，重算正推和逆推。当前最长路径和接近它的分支都要看。不能把加权值或1天时差转换成按期概率；概率分析需要明确的不确定性模型和本整理单之外的检查。实际起止、上线授权继续单列记录。
检查你的思考
再问自己几个问题
- 哪些任务不能并行，必须等待前置完成？
- 哪条路径决定整体工期？
- 哪些延期会影响最终交付？
完成前的检查清单
- 任务依赖关系清楚。
- 关键路径被识别。
- 工期风险能被提前管理。
框架参考
参考资料说明框架定义与适用范围，不验证虚构案例的结果。