项目计划编制可以按一条主线推进：先确认范围、验收标准和约束等输入，再把可交付成果拆成工作包，估算工期与资源，排出依赖和关键路径，落实角色与沟通安排，处理风险与假设，最后经评审冻结为基线。本文按这九个步骤说明每步的输入、动作、输出和完成标志，覆盖计划建立阶段；执行中的偏差纠偏不在本文展开。ONES 可作为承载 WBS、依赖、里程碑与基线变更的工具，下文在对应步骤中简要说明。
要点总览（TL;DR）
- 项目计划编制按“确认输入—WBS分解—估算—排依赖与里程碑—角色与沟通—风险与假设—评审冻结基线—完成检查”推进，每步产物是下一步的输入。
- WBS按可交付成果逐层拆到能独立估算工期、指定一名责任人、判断完成与否的工作包即可停止，编号与层级一一对应。
- 估算要分开记录工作量、工期和人数，并写明估算方法、假设条件和不确定区间，便于复核与解释偏差。
- 依赖确认后计算关键路径，里程碑设在交付物完成、外部交接和关键决策点；风险与假设要转化为缓冲、触发条件和责任人。
- 评审通过后冻结基线，记录版本号、批准人和批准日期，后续调整走变更申请、影响评估、审批和通知流程。
编制前先确认哪些输入
计划编制的第一步是收集输入，确认编制所依据的条件已经明确。范围不清时排出的日期缺少依据，后续变更会反复推翻计划。启动编制前，把下列四项整理成书面材料，缺项标注责任人和补齐时间。
| 输入项 | 应包含的内容 | 缺失时的处理 |
|---|---|---|
| 项目目标与范围说明 | 项目要解决的问题、交付边界、明确不做的内容 | 与发起人对齐后补写范围说明，未确认前不进入排期 |
| 验收标准与关键交付物 | 每个主要交付物的验收条件、验收方、交付形态 | 标注待定项，作为计划中的假设记录 |
| 资源与预算约束 | 可用人力及技能、外部采购额度、关键设备或环境 | 按最保守可用资源编制，并注明约束来源 |
| 里程碑或外部时间要求 | 合同节点、监管时限、上下游团队的交接日期 | 列为不可移动的固定点，排期时优先满足 |
输入清单的完成标志是：四项均有书面来源，待定项已标注假设与责任人。此时可以进入分解，不必等所有细节确定，但范围边界和外部时间要求必须已经确认。
从范围到WBS：把工作拆到可估算的粒度
WBS 按可交付成果分解，一级节点对应范围说明中的主要交付物，逐层向下拆到工作包。按部门分解容易得到“设计部工作”“开发部工作”这类无法验收的节点，交付物分解则每个节点都能回答“做出什么、由谁验收”。
分解规则
- 层级建议控制在三到四层：项目—交付物—子交付物—工作包，层级过深会增加维护成本。
- WBS 编号采用分段编码，如 1、1.1、1.1.2，编号与层级一一对应，便于在计划表和后续变更中引用。
- 每个工作包只归属一个上级节点，避免同一工作在两处重复出现。
- 工作包描述用“动词+对象+结果”的写法，例如“完成登录模块接口联调并通过冒烟测试”。
粒度判断标准
工作包拆到能独立估算工期、指定一名责任人、判断完成与否即可停止。常见参考是单个工作包工期在数天到两周之间；工期更长说明还可继续拆，短到半天以内则管理成本高于收益。分解完成的标志是：所有工作包都有编号、责任人、估算入口和验收依据，且合起来能覆盖范围说明中的全部交付物。
ONES 支持用「项目计划」创建工作分解结构，按目标、交付物或项目阶段等维度分解计划和工作，分解结果可直接作为后续估算与排期的对象。
估算工期、资源与工作量
估算要区分三个口径：工作量是完成工作包所需的人天总量，工期是日历上占用的时间，人数是投入的人力。三者关系受并行度和可用性影响，混在一起写会导致排期失真。例如一个 10 人天的工作包由 2 人并行完成，工期约 5 天，但若两人只能半投入，工期会拉长到 10 天左右。
| 方法 | 适用场景 | 注意事项 |
|---|---|---|
| 类比估算 | 有相似历史项目，处于早期粗估阶段 | 记录参照项目及差异点，误差通常较大 |
| 参数估算 | 工作量与可计量参数相关，如按接口数、页面数折算 | 参数系数需有历史数据支撑，注明来源 |
| 三点估算 | 不确定性较高、需要给出区间的工作包 | 记录乐观、最可能、悲观三个值及计算方式 |
估算结果按工作包逐条记录，字段至少包括：工作量（人天）、工期（天）、投入人数与技能要求、估算方法、假设条件、不确定区间。假设要写成可检验的句子，例如“接口文档在开发启动前冻结”，而不是“需求基本明确”。复核方式有两种：由未参与估算的资深成员独立估算后比对差异，或对偏差超过一定比例的工作包组织复核会，逐条确认假设是否成立。
排依赖、定关键路径与里程碑
有了工作包的工期，下一步是确定先后关系。逐对确认前置关系，区分完成—开始、开始—开始等依赖类型，并标注是硬依赖（技术或合同决定）还是软依赖（管理偏好）。软依赖是压缩工期时的调整空间，硬依赖则构成约束。
把工作包和依赖画成进度网络后，计算每条路径的总时长，最长路径即关键路径。关键路径上的工作包浮动时间为零，任何延误都会推迟项目完成日期，应作为重点跟踪对象；非关键路径上的工作包有一定浮动时间，可在资源冲突时适度调整。
里程碑设置在三类位置：重要交付物完成、外部交接点、关键决策点。里程碑是零工期的检查点，数量不宜过多，每个里程碑要有明确的完成判据和确认人。排期完成后对照资源约束检查冲突，例如同一人在同一周被安排两个满负荷工作包，处理方式包括调整非关键路径顺序、增加人手或与相关方协商移动软依赖，调整后重新计算关键路径。
ONES 可为项目任务设置前后置依赖，并用里程碑标记重要时间点、事件或决策点；ONES Plan 支持制定项目里程碑与甘特图，按多时间跨度查看进度。
角色分工、责任矩阵与沟通机制
计划中的每项工作都要落到具体角色。责任矩阵按工作包或交付物逐行填写，列上至少包含执行、审批、协助、知会四类角色，每行只有一个审批人，避免出现无人拍板或多人拍板的情况。
| 角色 | 填写要求 | 常见错误 |
|---|---|---|
| 执行（R） | 具体完成工作包的人或小组 | 写成部门名称，无法追到人 |
| 审批（A） | 对结果签字确认的唯一责任人 | 一行填多个审批人 |
| 协助（C） | 提供输入或支持的角色 | 把协助方当成执行方 |
| 知会（I） | 需要了解进展但不参与执行的角色 | 知会范围过大，信息噪音高 |
沟通机制与责任矩阵配套确定：例会频率按项目节奏设定，例如每周一次进度同步，每个工作包负责人用统一格式汇报完成情况、下周计划和阻塞项；状态同步以计划中的工作包状态为准，避免口头进度与计划脱节。跨团队交接点单独约定，明确交接物、交接时间、接收方确认方式和争议升级路径。计划评审与变更审批的角色也在此确定：谁有权批准基线、谁评估变更影响、谁负责通知相关方。
风险、假设与应急安排在计划中如何落位
风险登记表本身不构成计划的一部分，只有转化为计划条目才起作用。做法是逐条判断风险的影响路径：影响工期的，在对应工作包后设置缓冲时间；影响资源的，预留备用人员或外部支持额度；影响范围的，写入变更触发条件。每条风险记录触发条件、应对措施、责任人和检查时点，并与具体工作包编号关联。
假设条件单独列示，写明“若假设不成立，计划如何调整”。例如“关键第三方组件按期交付”这一假设，对应的调整方案是启用备选组件并增加联调工期。缓冲时间集中设置在关键路径末端或高风险工作包之后，并说明缓冲的动用规则：由项目经理批准，动用后记录原因并评估对里程碑的影响。应急资源写明类型和获取方式，不写具体金额时注明审批层级。
评审、冻结基线并管理变更
计划初稿完成后组织评审，参与方至少包括发起人、各工作包责任人、关键依赖方和验收方。评审要点包括：范围覆盖是否完整、估算假设是否成立、依赖与关键路径是否正确、角色与审批是否落实、风险缓冲是否合理。评审意见逐条记录处理结论，未关闭的意见标注责任人和期限。
评审通过后冻结基线。基线是经批准的计划版本，包含工作包、工期、依赖、里程碑、责任人和预算口径，冻结时记录版本号、批准人和批准日期，并与评审记录一并存档。此后计划调整走变更流程：提出变更申请，说明变更内容与原因；评估对工期、资源、关键路径和里程碑的影响；由约定角色审批；批准后更新计划并生成新版本，保留旧版本用于对比。
基线更新后通知范围包括：受影响工作包的责任人、下游依赖方、发起人与验收方、需要同步进度的相关团队。通知内容写明变更点、生效时间和对各方的具体要求。ONES 可设置项目计划和里程碑基线，对比计划与执行的偏差，并通过版本对比追溯变更细节。
一个编制示例：从范围说明到基线计划
以下为演示情景，用于说明各步骤的衔接，不代表真实项目数据。
背景与范围：某团队要在十周内上线内部报销系统的移动端审批功能。范围包括审批流程配置、移动端页面、与现有财务系统的接口联调；不包括报表模块改造。验收标准为审批流程在测试环境跑通全部审批场景，移动端在指定机型上完成兼容测试。
WBS 与排期推演：一级节点按交付物分为流程配置、移动端开发、接口联调、测试与上线四部分。以移动端开发为例，拆为页面开发、交互联调、兼容测试三个工作包，编号 2.1 至 2.3。估算页面开发 12 人天、工期 6 天（2 人并行），交互联调 4 人天、工期 4 天，兼容测试 3 人天、工期 3 天。依赖关系为 2.1 完成后开始 2.2，2.2 完成后开始 2.3，2.3 完成后进入整体测试。接口联调依赖财务系统接口文档冻结这一假设，若文档延迟，联调工作包顺延并动用其后的 3 天缓冲。
责任与风险条目：2.1 执行人为移动端开发小组，审批人为技术负责人，财务系统接口方为协助角色。风险条目“第三方接口文档延迟”关联工作包 3.1，触发条件为文档冻结日晚于计划日期，应对措施为启用备选字段映射方案，责任人为接口对接人。
基线关键字段：版本号 V1.0，批准人为项目发起人，批准日期为评审通过日；里程碑包括流程配置完成（第 3 周末）、移动端功能完成（第 6 周末）、整体测试通过（第 9 周末）、上线（第 10 周末）；关键路径经过接口联调与整体测试；缓冲总量 5 天，分布在接口联调后与上线前。
编制完成检查清单
发布前逐项核对下表，全部通过即可冻结基线；存在未通过项时，标注责任人和补齐时间，不带着缺口发布。
| 检查类别 | 检查项 | 通过标准 |
|---|---|---|
| 范围与WBS覆盖 | 范围说明中的每项交付物都有对应 WBS 节点 | 逐项对照无遗漏，范围外内容未混入 |
| 范围与WBS覆盖 | 每个工作包有编号、责任人、验收依据 | 抽查全部工作包均满足 |
| 估算与依赖 | 估算记录含方法、假设与区间 | 关键工作包均有书面假设 |
| 估算与依赖 | 依赖关系已确认，关键路径已识别 | 硬依赖与软依赖已区分，浮动时间已计算 |
| 角色与审批 | 责任矩阵每行有唯一审批人 | 无空缺、无重复审批 |
| 角色与审批 | 评审意见已关闭或已安排处理 | 评审记录完整可查 |
| 基线与变更 | 基线版本、批准人、批准日期已记录 | 版本可追溯，旧版本保留 |
| 基线与变更 | 变更申请、影响评估、审批与通知流程已明确 | 相关方知晓流程与联系人 |
清单通过后，计划即可作为执行与跟踪的依据发布；后续调整按变更流程处理，基线版本与评审记录同步更新。
常见问题
范围说明还没完全定稿，可以先开始排期吗？
可以启动分解和粗估，但不宜冻结基线。范围边界和外部时间要求这两项需要先确认，否则排出的日期缺少依据。验收标准、部分交付物细节可以标注为待定项，作为计划中的假设记录，写明责任人和补齐时间。等这些待定项关闭后，再进入评审和基线冻结。
工作包拆到多细比较合适，拆得太细会有什么问题？
判断标准是能否独立估算工期、指定一名责任人、判断完成与否。常见参考是单个工作包工期在数天到两周之间。拆到半天以内，管理成本会高于收益，状态更新和汇报占用的时间明显增加；工期超过两周，说明还有继续拆的空间，否则估算误差和进度判断都会变粗。层级建议控制在三到四层。
关键路径上的工作和非关键路径上的工作，管理方式有什么不同？
关键路径上的工作包浮动时间为零，任何延误都会推迟项目完成日期，应作为重点跟踪对象，资源冲突时优先保障。非关键路径上的工作包有一定浮动时间，在资源冲突时可以适度调整顺序或推迟，只要不超出浮动范围。调整后要重新计算关键路径，因为原来的非关键路径可能变成新的关键路径。
基线冻结之后，什么情况下需要走变更流程？
凡是影响工作包范围、工期、依赖、里程碑、责任人或预算口径的调整，都应走变更流程：提出申请、评估影响、审批、更新计划并生成新版本。工作包内部的日常执行细节调整，不影响上述要素时，按团队约定的方式记录即可。判断标准是这次调整是否改变了对相关方的承诺，改变了就需要通知受影响的责任人、下游依赖方和验收方。
计划编制中的责任矩阵和沟通机制，能否借助工具承载？
责任矩阵的核心是每行有唯一审批人、执行落到具体的人，这一结构可以用表格或工具中的角色字段承载。ONES 支持用「项目计划」创建工作分解结构，按目标、交付物或项目阶段等维度分解计划和工作；也可为任务设置前后置依赖，并用里程碑标记重要时间点、事件或决策点。责任矩阵本身是否有专门承载方式，需按实际使用环境确认。
