第一次打开 OmniPlan 3 Pro Edu，最容易卡住的不是画甘特图，而是不知道先填什么：任务、资源、依赖和基线如果顺序反了，时间线看起来很完整，项目却无法执行。

我把官方教程里的典型游戏项目换成一个更容易复用的“课程上线项目”：需求确认、内容制作、开发、测试、发布五个阶段。目标不是把所有按钮点一遍，而是做出一份能分配给团队、能追踪偏差的计划。

本文按“已拥有教育授权的 OmniPlan 3 Pro”来写。OmniPlan 3 的 Standard/Pro 功能与授权状态，请在 **OmniPlan ▸ About OmniPlan** 和 **OmniPlan ▸ Licenses** 中核对；界面截图来自 The Omni Group 的 OmniPlan 3 官方手册。

先看懂三个视图各自解决什么问题

OmniPlan 的 Task View 适合排时间和依赖，Resource View 适合看谁过载，Network View 则适合检查任务之间的逻辑关系。不要把三个视图当成三份数据，它们只是同一个项目模型的不同投影。

图：官方 OmniPlan 3 Task View 截图，左侧是任务层级，右侧是时间条、里程碑和依赖。

图片来源：OmniPlan 3 官方手册。

图：官方 OmniPlan 3 Resource View 截图，按人员或资源分组查看任务负载。

图片来源：OmniPlan 3 官方资源视图说明。

如果你只需要一个人的待办清单，Task View 已经够用；当多人共享资源、任务存在前后约束时，再切到 Resource View 和 Network View。

新建项目时，先定日期和工作日历

选择 **File ▸ New Project** 后，先在 Project Inspector 中确定项目是“从固定开始日期向后排”，还是“从固定结束日期向前倒排”。课程上线、版本发布这类项目通常有明确截止日，可以选择固定结束日期；研发迭代则更常从开始日期向后排。

接着检查工作周和例外日期：

• 把周末、法定假期或团队休假加入日历。
• 统一时区和一天的工作时长。
• 不要一开始就给任务填得过细，先保证阶段边界正确。

这一步看似基础，却决定了后面所有任务的开始、结束和资源冲突。日期不可信，后面的“关键路径”也没有意义。

图：抽象流程图说明任务分组、依赖、资源均衡和基线之间的先后关系；它不是 OmniPlan 界面截图。

用里程碑和任务组搭骨架

先创建零时长的里程碑，再创建任务组。以课程上线为例，可以先写出：

课程上线（里程碑）
├── 需求确认
├── 内容制作
├── 客户端开发
├── 联调与测试
└── 发布准备

在 OmniPlan 中，带有展开箭头的行是任务组，菱形标记通常表示里程碑。任务名称尽量使用动作加对象，例如“确认课程大纲”“完成支付接口联调”，不要写成“处理一下”“开发工作”。

每个普通任务至少补齐三件事：

1. Duration：日历上的持续时间。
2. Effort：真正需要投入的工作量。
3. Resource：谁或什么设备来完成。

Duration 和 Effort 不是一回事。一个任务持续三天，可能只需要某人投入八小时；如果把两者混填，资源均衡会产生误导。

连接依赖，再让 OmniPlan 排程

选中前置任务和后置任务，使用工具栏的 **Connect** 建立依赖。课程上线项目里，“内容制作完成”应先于“联调与测试”，“联调与测试完成”又应先于“发布准备”。

依赖关系建议从业务事实出发，而不是为了让线条好看：

• 前置任务交付物明确，才建立 Finish-to-Start。
• 可以并行的任务不要强行串行，否则项目被人为拉长。
• 真正需要多人同时到场的活动，使用 Pro 提供的 Meeting task 类型，并确认所有资源的可用时间。

切到 Network View 后，检查有没有孤立节点、循环依赖或一条任务链被错误地串成“单线程”。官方手册把 Network View 定义为查看任务关系的视图，这里最适合做结构检查。

图：官方 OmniPlan 3 Network View 截图，用节点和连线检查任务依赖。

图片来源：OmniPlan 3 Network View 手册。

分配资源并执行一次均衡

在 Resource View 中创建人员、设备或外部资源，再回到 Task View 给任务分配。资源的 Units 表示可投入比例；同一个人只在半天参与项目，就不要按 100% 填写。

完成分配后，点击工具栏 **Level**，或使用 **Project ▸ Level Resources**。均衡的作用是根据资源可用时间调整任务安排，不是凭空缩短工期。均衡后要重点查看：

• 关键任务是否被推迟；
• 某个资源是否仍连续超载；
• 里程碑是否越过项目截止日期；
• 是否有任务被拆成不符合业务的碎片。

如果排程结果不符合现场，先回到 Duration、Effort、Units 和工作日历检查，不要直接拖动时间条“修图”。

设置基线，开始记录计划与实际的差异

计划确认后选择 **Project ▸ Set Baseline**。基线是当时计划的快照；之后你更新实际进度，基线不会跟着改变。再通过工具栏的 Baseline/Actual 菜单选择 Split 或 Both，对比原计划和当前进度。

图：基线保持计划初版，实际进度持续变化，偏差暴露后再调整资源或日期。

更新任务时，优先记录真实完成度和剩余工作量，再让排程重新计算。不要把“预计完成”直接改成“已完成”，否则基线比较会失去意义。

Pro 功能什么时候值得用

OmniPlan 3 Pro 的官方文档列出了几类增强能力：

能力	适合场景	使用提醒
Monte Carlo Simulation	任务工期有不确定性，需要估计里程碑按时完成的把握	先提供合理的最小、最大 Effort；没有范围时，模拟结果没有参考价值
Multi-Project Dashboard	同时查看多个相互关联的项目	先统一资源命名和日期口径
Earned Value Analysis	需要跟踪预算、计划价值和实际成本	成本字段和资源费率要先维护
Reports / HTML 报告	给非项目成员输出进度	先确认报告模板包含必要字段
Publish / Subscribe、AppleScript	多人协作或重复自动化	先配置仓库、权限和脚本执行边界

官方说明还特别提醒：Monte Carlo 模拟依赖任务的 Effort 估计；如果没有设置最小和最大工作量，预测会退化成“按当前计划完成”。

教育版使用时的边界

“Edu”通常描述授权对象，不代表可以跳过软件本身的版本和许可检查。安装后建议做一次自检：

1. 在 **About OmniPlan** 查看当前版本和许可状态。
2. 新建一个不含敏感数据的练习项目，确认 Pro 菜单（Simulation、Reports、Publish 等）是否可见。
3. 如果项目要与他人协作，先用副本测试发布、订阅和冲突处理。
4. 导出 PDF 或 HTML 报告前，检查姓名、成本和内部路径是否需要脱敏。

这套流程适合课程排期、软件迭代、活动筹备和小型研发项目。它不能替代团队的需求评审、资源承诺和风险登记；如果任务经常跨项目抢占同一资源，应该先把项目边界和优先级治理清楚，再把复杂度交给 OmniPlan。