制定项目主计划，核心是把范围、交付物、里程碑、依赖和资源承诺整理成一份可执行、可跟踪的基线。它回答项目整体怎么走、在哪些节点交付什么、由谁负责；具体任务的逐日排期属于下一层计划。主计划通常以文档承载整体约定，再落到工作项与里程碑上跟踪，ONES 可用于这一层承载。
要点总览（TL;DR）
- 主计划回答项目整体怎么走：目标与范围、阶段与交付物、里程碑、依赖、资源与角色、风险与假设、基线七项构成最小完整集合，逐日排期留给下一层计划。
- 制定按六步推进：明确目标与范围、拆分阶段与交付物、识别依赖与关键路径、设定里程碑与验收标准、落实角色与资源承诺、评审并形成基线，每步以输出物通过确认为完成标志。
- 项目经理牵头并对计划完整性负责，职能负责人确认资源承诺，技术负责人确认交付物拆分，业务方确认目标与验收标准，评审会逐项确认、异议项指定回复人和期限。
- 主计划在工具中分两层承载：文档层保存范围、假设、里程碑定义与基线记录，工作项层承载阶段、交付物与任务，依赖和里程碑字段与文档对应。
- 发布前按范围、里程碑、依赖、资源、风险、基线六类逐项核对；范围未经业务方确认、里程碑缺判定条件、依赖未获承诺、关键角色空缺、评审重大问题未闭环时应阻断发布。
主计划要解决什么问题，包含哪些内容
主计划解决的是项目整体层面的协调问题：项目目标是否清晰、范围边界在哪里、分几个阶段推进、每个阶段交付什么、关键节点在什么时间、哪些工作依赖其他团队、谁对结果负责、哪些前提一旦变化需要重新评审。它服务于管理层和跨团队协作，让各方对“整体怎么走”形成同一份约定。
主计划与任务排期、进度管理分工不同。主计划确定阶段、交付物、里程碑和依赖关系，是后续排期的依据；任务排期把阶段内的工作拆到具体任务和责任人，安排先后顺序与时间；进度管理在执行阶段持续收集完成情况，与基线对比。三者层层细化，主计划不承担逐日排期的职责，否则容易在细节变化中失去稳定性。
一份可评审的主计划应包含以下要素：
| 要素 | 要写清的内容 | 缺失时的典型问题 |
|---|---|---|
| 目标与范围 | 项目要达成的业务结果、范围边界、明确不包含的内容 | 执行中范围不断扩张，各方理解不一致 |
| 阶段与交付物 | 阶段划分、每阶段的可验收交付物 | 只有时间点没有产出，验收时争议多 |
| 里程碑 | 重要时间点、事件或决策点及其判定条件 | 关键节点模糊，进度判断依赖口头同步 |
| 依赖关系 | 跨团队、跨系统的前后置依赖及提供方 | 某一方延迟，整条链路被动等待 |
| 资源与角色 | 各阶段投入的角色、职责与资源承诺 | 计划排了，人不到位 |
| 风险与假设 | 已识别的风险、成立的前提假设及应对方向 | 前提变化后计划失效却无人察觉 |
| 基线 | 经评审确认的版本，作为后续对比的基准 | 计划反复修改，无法判断偏差 |
这七项构成主计划的最小完整集合。项目规模较小时可以合并表达，例如把风险与假设并入范围说明，但不宜整项省略。
制定主计划的六个步骤
六个步骤按顺序推进，每一步都有明确输入和输出，前一步的输出是后一步的输入。完成标志以输出物通过确认为准，不以会议开完为准。
第一步：明确目标与范围边界
输入是项目立项信息、业务需求和干系人诉求。动作是与业务方确认项目要解决的业务问题、成功标准，以及明确排除在外的内容。输出是一页范围说明，包含目标、成功标准、范围内事项、范围外事项和关键假设。完成标志是业务方与项目经理对范围说明达成一致并留档。
第二步：拆分阶段与交付物
输入是范围说明。动作是按项目阶段或交付物维度做工作分解，形成阶段—交付物—主要工作包的层级结构，每个交付物写明验收口径。输出是工作分解结构（WBS）和交付物清单。完成标志是每个交付物都有唯一负责人和可判断的完成标准。
第三步：识别依赖与关键路径
输入是WBS和交付物清单。动作是逐项识别交付物之间的前后置关系，重点标注跨团队、跨系统的依赖，明确依赖的提供方和需要时间，据此找出决定项目总工期的关键路径。输出是依赖清单和关键路径说明。完成标志是每条跨团队依赖都有提供方确认的时间承诺。
第四步：设定里程碑与验收标准
输入是阶段划分、交付物和关键路径。动作是在关键决策点、重要交付完成点和外部承诺时间上设置里程碑，每个里程碑写明判定条件和验收人。输出是里程碑清单。完成标志是每个里程碑都能用客观证据判断是否达成，而非主观评价。
第五步：落实角色与资源承诺
输入是WBS、依赖清单和里程碑。动作是明确各阶段需要的角色、投入方式和时间窗口，由职能负责人确认人员安排。输出是角色资源表和资源承诺记录。完成标志是关键角色获得职能负责人的明确承诺，而非默认可用。
第六步：评审并形成基线
输入是前五步的全部输出。动作是组织评审会，逐项检查范围、交付物、依赖、里程碑、资源和风险，处理评审意见后定稿。输出是经确认的主计划文档和基线版本。完成标志是评审结论为通过，基线版本完成归档，变更方式同步给相关方。
角色分工与各阶段交付物
主计划的制定由项目经理牵头，但各步骤的产出需要不同角色参与和确认。分工不清时，计划容易变成项目经理一个人的文档，执行阶段缺乏约束力。
| 步骤 | 主要负责 | 参与角色 | 交付物 | 确认人 |
|---|---|---|---|---|
| 明确目标与范围 | 项目经理 | 业务方、技术负责人 | 范围说明 | 业务方负责人 |
| 拆分阶段与交付物 | 项目经理 | 技术负责人、各职能负责人 | WBS与交付物清单 | 技术负责人 |
| 识别依赖与关键路径 | 项目经理 | 各依赖提供方负责人 | 依赖清单、关键路径说明 | 依赖提供方负责人 |
| 设定里程碑与验收标准 | 项目经理 | 业务方、技术负责人 | 里程碑清单 | 业务方与技术负责人共同确认 |
| 落实角色与资源 | 职能负责人 | 项目经理 | 角色资源表、资源承诺记录 | 职能负责人 |
| 评审并形成基线 | 项目经理 | 全体干系人代表 | 主计划文档、基线版本 | 评审会决策人 |
各角色的职责边界需要说清。项目经理对计划的完整性和一致性负责，组织各步骤推进并维护基线；职能负责人对资源承诺负责，确认投入的人员和时间窗口；技术负责人对交付物的技术可行性和拆分合理性负责；业务方对目标、范围和验收标准负责。评审会由项目经理组织，参与方包括业务方、技术负责人、主要职能负责人和关键依赖提供方，决策方式建议采用逐项确认：无异议项直接通过，有异议项记录待办并指定回复人和期限，涉及范围或里程碑调整的由业务方决策人拍板。
示例：一个跨团队项目的主计划骨架
以下为演示情景，用于说明主计划的组织方式，不代表任何真实项目。
假设某企业要上线一套内部审批系统，涉及业务部门、应用开发团队、数据平台团队和运维团队。主计划骨架可以这样组织：
| 阶段 | 主要交付物 | 里程碑 | 跨团队依赖 |
|---|---|---|---|
| 需求与方案 | 需求规格、技术方案 | M1 方案评审通过 | 业务部门提供流程清单；数据平台确认接口规范 |
| 开发与集成 | 审批功能、数据接口 | M2 集成联调完成 | 数据平台提供测试环境与接口；运维确认部署资源 |
| 测试与验收 | 测试报告、验收记录 | M3 业务验收通过 | 业务部门安排验收人员与时间窗口 |
| 上线与移交 | 上线记录、运维手册 | M4 正式上线 | 运维完成上线操作与监控配置 |
依赖标注要写到“谁、在什么时间、提供什么”的程度。例如“数据平台团队在M2前两周提供联调环境及接口文档”，比“依赖数据平台支持”更可跟踪。基线记录建议保留版本号、确认日期和确认人；变更记录写明变更内容、原因、影响的范围与里程碑、提出人和批准人。示例中若业务部门在开发阶段新增审批类型，应记录为变更：影响M2时间与测试范围，经业务方决策人批准后更新基线版本，而不是直接改原计划。
用工具承载主计划：从文档到可跟踪的工作项
主计划落到协作工具时，通常分两层承载：文档层保存范围说明、假设、里程碑定义和基线记录，工作项层承载阶段、交付物和任务，并通过依赖和里程碑字段与文档对应。这样评审时看文档，执行时看工作项，两者指向同一份约定。
在 ONES 中，可以用「项目计划」创建工作分解结构，按目标、交付物或项目阶段等维度分解计划和工作，并制定项目进度计划；项目任务可以设置前后置依赖，里程碑用于标记重要时间点、事件或决策点。计划与里程碑可以设置基线，用于对比计划与执行的偏差，并通过版本对比追溯变更细节。对于研发类项目，项目计划还可以关联迭代和研发任务，项目下可管理需求范围、研发任务等内容。这些能力对应主计划的承载与跟踪环节，具体入口和配置以实际产品版本为准。
承载结构建议按以下方式组织：
- 主计划文档记录目标、范围边界、假设、里程碑判定条件和基线版本说明，作为评审与变更的依据。
- 工作项按阶段和交付物分层建立，每个交付物对应一个可验收的工作项，负责人与文档中的角色表一致。
- 跨团队依赖在任务上设置前后置关系，依赖提供方和约定时间写入任务说明。
- 里程碑单独标记，判定条件与文档中的验收标准保持一致。
- 变更时更新文档并形成新的基线版本，工作项同步调整，评审结论与变更记录关联留存。
状态同步方面，建议在固定节奏的例会上对照基线检查里程碑达成情况和工作项完成情况，把偏差和风险记录回主计划文档，保持文档与工作项一致。深圳农商行依托 ONES 瀑布项目模板对关键里程碑、交付物进行规范化管理的实践，可作为里程碑与交付物管理的参照，其做法仅适用于该客户场景。
完成检查：主计划是否可以发布
发布前按六类检查项逐项核对，每项都要有可查的证据，不能只凭印象判断。
| 检查类别 | 检查项 | 通过标准与证据 |
|---|---|---|
| 范围 | 目标、成功标准、范围内外事项是否写清 | 范围说明有业务方确认记录 |
| 里程碑 | 每个里程碑是否有判定条件和验收人 | 里程碑清单完整，判定条件可客观核验 |
| 依赖 | 跨团队依赖是否都有提供方和时间承诺 | 依赖清单中每条有提供方确认 |
| 资源 | 关键角色是否获得职能负责人承诺 | 资源承诺记录可查，关键角色无空缺 |
| 风险 | 主要风险与假设是否识别并有应对方向 | 风险清单有责任人和应对措施 |
| 基线 | 计划是否经评审确认并归档 | 评审结论为通过，基线版本与变更方式已同步 |
以下情形建议阻断发布：范围说明未经业务方确认；关键里程碑缺少判定条件；存在未获提供方确认的跨团队依赖；关键角色无资源承诺；评审提出的重大问题未闭环。这些问题在发布前解决的成本远低于执行阶段返工。检查通过后，主计划即可作为基线发布，后续调整按约定的变更方式处理。
常见问题
主计划制定到一半，业务方提出新增需求，应该怎么处理？
先判断它是否改变范围边界。若属于原范围说明中已排除的内容，按变更处理：记录变更内容、原因、影响的范围与里程碑、提出人和批准人，由业务方决策人批准后更新基线版本，工作项同步调整。若只是原范围内的细化，补充到交付物清单即可，不必重开评审。关键是不要直接改原计划而不留记录，否则基线失去对比意义。
项目规模较小，七项要素可以合并或省略吗？
可以合并表达，例如把风险与假设并入范围说明，把阶段与交付物合并成一页清单。不宜整项省略的是范围边界、里程碑判定条件和基线：范围不清会导致验收争议，里程碑没有判定条件就无法客观判断进度，没有基线则后续无法区分计划调整和执行偏差。规模小时形式可以简化，确认动作仍要留痕。
跨团队依赖的提供方一直不给明确时间承诺，主计划还能发布吗？
建议先阻断发布，把该依赖列为待办，指定回复人和期限，在评审记录中写明。依赖没有时间承诺，关键路径和里程碑时间就缺乏依据，发布后一旦对方延迟，整条链路被动等待且难以界定责任。若业务方决策人接受以假设时间先行发布，应在风险与假设中写明该前提，并约定假设失效时重新评审的条件。
主计划发布后，文档和工作项如何保持同步？
约定固定节奏的对照检查，在例会上同时看里程碑达成情况和工作项完成情况，把偏差与风险记录回主计划文档。变更时先更新文档并形成新的基线版本，再调整工作项，评审结论与变更记录关联留存。ONES 支持为项目计划和里程碑设置基线，对比计划与执行的偏差，并通过版本对比追溯变更细节，可作为这一环节的承载方式，具体入口以实际产品版本为准。
主计划与迭代计划、任务排期是什么关系？
主计划确定阶段、交付物、里程碑和跨团队依赖，是后续排期的依据；迭代计划和任务排期把阶段内工作拆到具体任务、责任人和时间顺序。研发类项目可以在项目计划中关联迭代和研发任务，让主计划与执行层保持对应。主计划不承担逐日排期职责，否则容易在细节变化中频繁改动，失去作为基线的稳定性。
