项目主计划把范围、里程碑、关键交付物、跨团队依赖和资源安排收拢到一份可维护的基线文件，用来对齐各子计划并支撑决策。本文按字段框架、五步建立流程、角色分工、填写示例和发布前检查的顺序展开，帮助读者从零建立一份可用的主计划。主计划只覆盖到里程碑与关键依赖层级，具体任务排期和日常进度偏差分别由任务排期与进度管理承接；ONES可作为承载里程碑、依赖与基线的协作工具。
要点总览（TL;DR）
- 项目主计划管到里程碑、关键交付物和跨团队依赖层级，子计划承接专业分解，任务排期落到具体人员与日期，三层分工避免主计划退化为任务清单。
- 字段框架包含项目范围、阶段关口、里程碑、关键交付物、跨团队依赖、资源与关键角色、假设与约束、变更记录八项，每项有明确填写口径与负责人。
- 建立流程分五步：界定范围与阶段关口、确定里程碑与关键交付物、梳理跨团队依赖与资源约束、形成基线并约定变更规则、指定维护责任人与更新节奏，每步有输入、动作、输出和完成标志。
- 项目经理负责编写与维护，子计划负责人提报交付物与依赖，职能负责人确认资源约束，决策层确认基线与审批重大变更，评审分工作评审和基线确认两层。
- 发布前核对范围覆盖、交付物负责人、依赖双向确认、资源约束、变更规则和维护节奏六项，范围排除项未确认、交付物无负责人、依赖未双向确认属于必须解决的阻断项。
项目主计划包含哪些内容：一份可维护的字段框架
主计划的颗粒度决定它能否长期维护。写得太细，主计划会退化成任务清单，每次排期调整都要改主文件；写得太粗，又无法支撑跨团队协调和决策。合适的口径是：主计划管到里程碑、关键交付物和跨团队依赖，子计划承接各专业领域的分解，任务排期再落到具体人员和日期。三层各司其职，主计划才不会被日常变更淹没。
下表给出主计划的字段框架，可直接作为模板使用。负责人一列指该字段的填写与维护责任，具体角色分工在第三节展开。
| 字段 | 填写口径 | 颗粒度 | 负责人 |
|---|---|---|---|
| 项目范围 | 用一段话说明项目要交付什么、不包含什么，列出主要干系方 | 项目级，一页以内 | 项目经理 |
| 阶段关口 | 按项目阶段列出关口名称、评审方式与通过标准 | 阶段级，通常3–6个 | 项目经理，决策层确认 |
| 里程碑 | 标记重要时间点、事件或决策点，写明计划日期与判定条件 | 里程碑级，每个阶段1–3个 | 项目经理 |
| 关键交付物 | 列出跨团队交接或对外交付的成果，写明完成标准与验收方 | 交付物级，不拆到子任务 | 交付物负责人 |
| 跨团队依赖 | 记录依赖方、被依赖方、依赖内容与需要就绪的时间 | 团队间接口级 | 各子计划负责人提报，项目经理汇总 |
| 资源与关键角色 | 列出各阶段所需的关键角色、投入方式与资源约束 | 角色级，不排到个人工时 | 职能/资源负责人 |
| 假设与约束 | 记录计划成立所依赖的前提，以及预算、合规、外部条件等限制 | 条目级，逐条可追溯 | 项目经理 |
| 变更记录 | 记录基线变更的时间、内容、原因与批准人 | 每次变更一条 | 项目经理 |
填写时有三个口径值得坚持。里程碑写判定条件而不只写日期，例如“接口联调完成并通过冒烟测试”比“6月30日联调”更能支撑后续判断。关键交付物必须落到唯一负责人，多人共管等于无人负责。跨团队依赖要写成双向条目，依赖方和被依赖方都确认，避免单方面记录造成误判。
建立主计划的五个步骤：从范围界定到基线发布
五个步骤按顺序推进，每一步都有明确的输入、动作、输出和完成标志。前一步的输出是后一步的输入，完成标志用于判断是否可以进入下一步，避免带着未决问题往下走。
步骤一：界定范围与阶段关口
输入是项目立项材料、合同或需求说明、干系方清单。动作是与关键干系方确认交付边界，划出项目阶段并定义每个阶段的关口评审方式。输出是范围说明和阶段关口清单。完成标志是范围说明中的“不包含”部分获得干系方认可，每个阶段关口都有明确的通过标准。
步骤二：确定里程碑与关键交付物
输入是阶段关口清单和初步的需求或交付要求。动作是把每个阶段的关键节点转化为里程碑，识别跨团队交接或对外交付的成果并指定负责人。输出是里程碑清单和关键交付物清单，每项都有计划日期、判定条件和负责人。完成标志是所有阶段关口都有对应里程碑覆盖，每个关键交付物都有唯一负责人和完成标准。
步骤三：梳理跨团队依赖与资源约束
输入是各子计划负责人提交的依赖需求和职能负责人提供的资源可用情况。动作是汇总依赖关系，标注依赖方向与需要就绪的时间，识别资源冲突和关键角色缺口。输出是跨团队依赖清单和资源约束说明。完成标志是每条依赖都经依赖方与被依赖方双向确认，资源冲突有明确的解决方向或升级路径。
步骤四：形成基线并约定变更规则
输入是前三步形成的完整计划内容。动作是组织评审，确认后冻结为基线，同时约定变更触发条件、审批层级和记录方式。输出是基线版本和变更规则说明。完成标志是基线经决策层确认发布，变更规则写明哪些调整需要走审批、由谁批准、如何记录。
步骤五：指定维护责任人与更新节奏
输入是基线版本和项目沟通机制。动作是指定主计划维护人，约定固定更新节点（如每个里程碑评审前、每月一次）和触发式更新条件（如基线变更获批后）。输出是维护责任说明和更新日历。完成标志是维护人明确、更新节奏写入项目沟通计划，各子计划负责人知晓提报依赖变更的渠道和时限。
角色与交付物分工：谁写、谁确认、谁维护
主计划建立过程中涉及四类角色，职责边界清晰才能避免责任悬空。项目经理是主计划的编写主体和日常维护人，子计划负责人提供依赖与交付物信息，职能/资源负责人确认资源安排，决策层负责基线确认和重大变更审批。
| 角色 | 主要职责 | 输入 | 输出交付物 |
|---|---|---|---|
| 项目经理 | 组织建立过程、汇总字段内容、维护基线、记录变更 | 立项材料、各角色提报信息 | 主计划文件、变更记录、更新日历 |
| 子计划负责人 | 提报本领域的交付物、依赖需求与时间要求，确认依赖条目 | 本领域分解计划 | 交付物清单、依赖提报单 |
| 职能/资源负责人 | 确认关键角色的可用性与资源约束，参与冲突协调 | 资源需求与人员安排 | 资源约束说明、冲突处理意见 |
| 决策层 | 评审并确认基线，审批重大变更，裁决升级的依赖或资源冲突 | 评审材料 | 基线批准意见、变更审批结论 |
评审与确认环节按两层设计。第一层是工作评审，由项目经理组织子计划负责人和职能负责人核对字段完整性与依赖一致性，解决大部分信息缺口。第二层是基线确认，由决策层对范围、里程碑和资源安排做最终确认。两层评审的结论都要留痕，工作评审的问题清单和基线确认的批准意见共同构成主计划的发布依据。
在协作工具中承载这套分工时，可以把里程碑和关键交付物作为项目计划中的节点，用前后置依赖表达跨团队接口，基线发布后通过版本对比追溯变更。ONES的项目计划支持按交付物或阶段维度分解计划、为任务设置前后置依赖并用里程碑标记重要时间点，也支持设置计划与里程碑基线、对比版本追溯变更细节，适合把上述字段和评审结论落到可更新的工作项上。
示例：一个跨团队项目的主计划如何落地
以下为演示情景，用于说明字段与步骤如何组合，不代表真实项目数据。某公司启动一次会员系统升级，涉及产品、研发、数据三个团队，计划周期约四个月，分为方案设计、开发联调、上线切换三个阶段。
按字段框架填写的主计划片段如下：
| 字段 | 示例内容 |
|---|---|
| 项目范围 | 交付新版会员等级规则、积分体系和迁移方案；不包含门店POS改造 |
| 阶段关口 | 方案评审通过、联调冒烟测试通过、上线切换演练完成 |
| 里程碑 | M1 方案定稿（评审通过为判定条件）；M2 联调完成（冒烟测试通过）；M3 上线切换（演练完成且回滚方案就绪） |
| 关键交付物 | 等级规则说明书（产品团队负责）；积分服务接口（研发团队负责）；历史数据迁移脚本（数据团队负责） |
| 跨团队依赖 | 研发接口依赖产品规则定稿；数据迁移依赖研发提供新表结构；上线切换依赖三方演练排期 |
| 资源与关键角色 | 数据团队在联调阶段投入两名工程师；研发团队在切换窗口需要运维值守 |
| 假设与约束 | 假设旧系统在切换期间可读不可写；约束为切换窗口不超过四小时 |
依赖与资源约束的处理方式：三条跨团队依赖分别由提报方和被依赖方确认，其中“数据迁移依赖新表结构”被识别为关键路径上的接口，项目经理在计划中标注需要就绪的时间，并约定研发表结构变更时同步通知数据团队。资源方面，数据团队在联调阶段的投入与另一项目存在冲突，经职能负责人协调后确定优先级，冲突处理意见记入资源约束说明。
基线发布与首次更新节奏：方案评审通过后，主计划冻结为基线并发布，变更规则约定里程碑日期调整和范围增减需决策层审批，依赖条目调整由项目经理确认后记录。首次更新安排在M1评审前一周，由各子计划负责人提报依赖变化，项目经理汇总后更新主计划并保留版本对比记录。
完成检查：主计划发布前的核对项
发布前逐项核对下表，全部通过才进入基线确认环节。任一检查项未通过即构成阻断项，需在发布前解决或明确处理方案。
| 检查项 | 通过标准 | 负责人 |
|---|---|---|
| 范围与里程碑覆盖 | 每个阶段关口都有对应里程碑，范围说明包含明确的排除项 | 项目经理 |
| 关键交付物完整性 | 每个关键交付物都有唯一负责人和可判定的完成标准 | 项目经理与子计划负责人 |
| 跨团队依赖确认 | 每条依赖均经依赖方与被依赖方双向确认，标注需要就绪的时间 | 子计划负责人 |
| 资源约束说明 | 关键角色缺口和资源冲突有处理意见或升级路径 | 职能/资源负责人 |
| 变更规则 | 写明变更触发条件、审批层级和记录方式 | 项目经理，决策层确认 |
| 维护节奏 | 维护人明确，固定更新节点和触发式更新条件写入沟通计划 | 项目经理 |
阻断项的判定标准是：缺失会导致后续无法判断计划是否偏离。范围排除项未确认、关键交付物无负责人、依赖未经双向确认，这三类问题会直接影响基线有效性，必须在发布前解决。资源冲突暂无解决方案时，可带着明确的升级路径发布，但需在假设与约束中记录。全部检查项通过后，由决策层确认基线，主计划进入维护阶段。
常见问题
主计划已经发布基线，执行中里程碑日期需要调整，应该走什么流程？
里程碑日期调整属于基线变更，按主计划中约定的变更规则处理。通常由提出方说明调整原因和影响范围，项目经理评估对关键依赖和资源安排的影响，提交决策层审批，批准后更新主计划并记录变更时间、内容、原因与批准人。如果调整涉及跨团队依赖的就绪时间，需要同步通知依赖方与被依赖方，避免一方按旧日期安排工作。
子计划负责人迟迟不提交依赖信息，主计划还能发布吗？
跨团队依赖未经双向确认属于发布前的阻断项，建议先解决再发布。实际操作中可以设定提报截止时间，由项目经理汇总未提报项并升级到决策层协调；如果个别依赖确实无法在发布前确认，可在假设与约束中记录该依赖的待定状态和确认时限，同时明确它不影响基线中其他内容的有效性。带着未确认的关键依赖发布，后续容易出现排期冲突。
主计划需要多久更新一次，更新时要不要重新走基线审批？
更新节奏分两类。固定更新安排在里程碑评审前或按月度进行，主要汇总依赖变化和交付物状态，由项目经理维护，不需要重新审批基线。触发式更新发生在基线变更获批后，例如范围增减、里程碑日期调整，这类更新需要按变更规则走审批并保留版本记录。把两类更新写进项目沟通计划，各子计划负责人就能按统一节奏提报信息。
项目主计划和任务排期是什么关系，主计划里要不要写具体任务？
主计划负责里程碑、关键交付物和跨团队依赖，任务排期负责具体任务的先后顺序与人员日期安排。主计划中写具体任务会让文件随每次排期调整而频繁变更，失去基线作用。常见做法是主计划中的关键交付物向下分解为子计划，子计划再拆到任务层级，任务排期变化通过子计划反馈到主计划的交付物状态上。ONES的项目计划支持按交付物或阶段维度分解计划、为任务设置前后置依赖并用里程碑标记重要时间点，可作为承载这种分层的方式。
跨团队依赖在工具里怎么表达，才能让双方都看到？
依赖条目要写明依赖方、被依赖方、依赖内容和需要就绪的时间，并在工具中落到具体工作项上，让双方在同一处确认。ONES支持为项目任务设置前后置依赖，使任务关联可见；基线发布后还可以通过版本对比追溯依赖调整。工具承载之外，仍需在评审环节由双方口头或书面确认，工具记录与人工确认结合，依赖才不容易被单方面改动。
