制定项目计划的核心，是把项目目标拆成可交付成果，再依次确定范围、里程碑、任务与依赖、资源与工期、风险与假设，最后经评审确认形成基线。本文按这一顺序给出可执行步骤、角色分工、完整示例和完成检查清单，范围限定在计划建立阶段，执行中的偏差跟踪与具体排期算法另行讨论。
要点总览（TL;DR）
- 项目计划从交付物清单开始：先把目标翻译成可验收的成果，再用WBS拆到可估算、可指派、可判断完成的粒度。
- WBS之后设里程碑、拆任务并固定字段，再标注依赖、估算工期、识别关键路径，缓冲放在关键路径末端和高不确定性任务之后。
- 资源、风险与假设要写进计划正文：资源分配表暴露超负荷，风险写清触发信号与应对动作，假设指定确认人。
- 计划经评审关闭问题后冻结为基线，后续范围、时间、资源变化走变更申请与影响评估，变更记录按版本留存。
- 用完成检查清单逐项核对交付物、任务、依赖、缓冲、资源、风险、评审与基线，全部满足或有明确处理方案即可基线化。
先定交付物：项目计划的起点
项目计划的起点是交付物清单，时间表在交付物明确之后才有意义。目标描述的是期望结果，交付物描述的是可以被验收的具体产出。制定计划时，先把项目目标翻译成一份可交付成果清单，再围绕清单展开后续拆解。
从目标推导交付物，可以按三个问题逐条追问：项目结束时，客户或业务方要拿到什么？每个成果由哪些组成部分构成？每个组成部分完成的标志是什么？把答案写成名词性条目，避免写成“做好需求分析”这类动作描述，改为“需求规格说明书（含验收标准章节）”这类可交付对象。
每项交付物都要配验收标准。验收标准写清三件事：由谁验收、依据什么判断合格、需要留下什么证据。例如“接口文档通过评审，评审记录归档，接口清单与联调环境一致”。验收标准在计划阶段写，可以提前暴露理解分歧，避免任务执行到一半才发现交付物定义不一致。
交付物清单完成后，用工作分解结构（WBS）向下拆解。WBS 按目标、交付物或项目阶段等维度组织，把每项交付物拆成若干工作包。拆解深度以三个条件为停止标志：工期可以估算、可以指派单一负责人、完成与否可以判断。三个条件同时满足即可停止，不必为了形式统一继续下拆；规模较大的项目可以拆到工作包层，规模较小的项目拆到任务层即可。
本步骤的输入是项目目标与范围说明，动作是列交付物、写验收标准、做 WBS 拆解，输出是可交付成果清单与 WBS 初稿。完成标志是清单中每项交付物都有验收标准，WBS 每个末级节点都满足上述停止条件。
从WBS到里程碑与任务清单
WBS 回答“要做什么”，里程碑和任务清单回答“按什么节奏做、由谁做”。这一步把 WBS 的末级节点转化为带时间节点和责任人的计划骨架。
里程碑标记项目中的重要时间点、事件或决策点，通常对应阶段交付物的完成或关键评审的通过。设置里程碑遵循两条原则：一是每个里程碑都对应一个可验证的交付物或决策，二是数量控制在团队能持续关注的范围内。一个持续数月的项目设置五到八个里程碑较为常见，里程碑过多会退化为普通任务，过少则失去阶段控制作用。
里程碑与阶段交付物一一对应后，把 WBS 末级节点展开为任务。任务粒度以“一个负责人能在一到两周内完成并交付可检查的结果”为参考，跨职能、跨系统的工作继续拆分。每个任务指派单一责任人，协作人员作为参与方记录，避免出现共同负责却无人推进的情况。
任务清单需要固定字段，保证后续排期、跟踪和评审使用同一套信息。常用字段如下：
| 字段 | 填写要求 |
|---|---|
| 任务名称 | 以动词开头，指向具体产出 |
| 所属交付物/工作包 | 关联 WBS 节点，便于回溯 |
| 负责人 | 单一责任人 |
| 参与人 | 协作角色及投入方式 |
| 计划开始与完成时间 | 精确到日 |
| 前置/后置依赖 | 标注依赖的任务及类型 |
| 验收标准 | 可检查的完成条件 |
| 状态 | 未开始、进行中、已完成等 |
本步骤的输入是 WBS 初稿，动作是设里程碑、拆任务、指派负责人、补齐字段，输出是里程碑清单与任务清单。完成标志是每个里程碑有对应交付物，每个任务有唯一负责人和可判断的完成条件。
排依赖、估工期、留缓冲
任务清单确定后，进度安排要解决三个问题：任务按什么顺序做、每项做多久、留多少余量。三者共同决定计划是否可执行。
依赖关系分为强制依赖和选择依赖。强制依赖来自工作本身的逻辑，例如开发完成才能测试；选择依赖来自组织约定或资源安排，例如某评审固定在双周会议上进行。识别依赖时逐条检查任务之间是否存在输入输出关系，把依赖类型和对象标注在任务上，形成前后置关系。依赖标注完成后，检查是否存在循环依赖和跨团队交接点，跨团队交接点通常是最容易延误的位置，需要单独确认对方的时间承诺。
工期估算优先采用执行者参与的方式。由负责该任务的成员给出估算，项目经理汇总后组织校准，校准依据包括历史同类任务的实际用时、工作量与可用人力的比值、外部供应商或第三方的承诺时间。多人校准的作用是暴露估算假设，例如某人估算三天是基于已有环境可用，若环境需要重新搭建则工期不同。估算结果记录假设，便于后续偏差分析。
依赖和工期确定后，识别关键路径。关键路径是决定项目最短完成时间的那条任务链，链上任何任务延误都会直接推迟项目完成。识别方法是沿依赖关系从开始推到结束，找出总工期最长的路径。关键路径上的任务需要更严格的负责人确认和更频繁的进度检查，非关键路径任务则可以利用浮动时间吸收局部延误。
缓冲设置在两个位置：关键路径末端设置项目缓冲，用于吸收整体不确定性；关键路径上高不确定性任务之后设置汇入缓冲，用于防止局部延误传导。缓冲大小结合任务不确定性、外部依赖程度和团队经验确定，没有统一比例。缓冲是计划的一部分，需要明确谁有权动用、动用后如何记录，避免缓冲被日常延误悄悄消耗。
本步骤的输入是任务清单，动作是标注依赖、估算工期、识别关键路径、设置缓冲，输出是带依赖与工期的进度安排及关键路径说明。完成标志是每项任务有工期和依赖，关键路径已标注，缓冲位置和动用规则已写明。
资源、风险与假设一起进计划
只覆盖时间的计划在执行中容易失效，因为任务能否按时完成取决于谁来做、可能遇到什么、依赖哪些外部条件。资源、风险和假设应当作为计划正文的一部分，与任务和里程碑同步确认。
角色与资源投入的对应方式，是把任务清单中的负责人和参与人汇总到角色维度，形成资源分配表。表中记录每个角色在各阶段的投入比例或人天、可用时间段、是否存在跨项目共享。资源分配表的作用是提前发现同一人在同一时间段被多个任务占满的情况。ONES 的工时日历可以查看资源饱和度，并据此调整节点负责人，成员工时报表和饱和度报表可用于分析资源利用情况、调整资源分配。
风险登记写清四要素：风险描述、发生条件或触发信号、影响范围、应对动作与责任人。应对动作分为规避、减轻、转移和接受四类，计划阶段至少为高影响风险写明触发后的具体动作和决策人。风险描述避免写成“进度可能延误”这类笼统判断，改为“第三方接口联调环境在第三周前未就绪，导致联调任务顺延，由接口负责人每周确认环境状态，未就绪时启动备用模拟环境”。
假设是计划成立所依赖的前提，外部依赖是计划之外但影响计划的条件。两者都需要记录并指定确认人。例如“假设测试环境在开发完成后一周内可用”“依赖供应商在第二个月中旬交付硬件”。假设被推翻时，相关任务的工期和顺序需要重新评估，因此假设清单要与任务关联，而不是单独存放。
资源冲突时的处理顺序建议为：先调整非关键路径任务的排期，利用浮动时间消化冲突；再调整任务负责人，前提是接手人具备相应能力；然后缩减范围或分批交付，与需求方确认优先级；最后才调整里程碑或项目完成时间，并走变更流程。这个顺序的原则是优先在计划内部消化冲突，把对交付承诺的影响降到最低。
本步骤的输入是任务清单与进度安排，动作是编制资源分配表、登记风险与假设、明确冲突处理顺序，输出是资源分配表、风险与假设清单。完成标志是每个高影响风险有应对动作和责任人，每条假设有确认人，资源冲突有预设处理顺序。
评审、基线化与变更控制
计划经过评审确认后才成为基线。基线是后续执行对比的参照，也是变更管理的起点。评审和基线化不是形式环节，而是让关键干系人对交付物、时间、资源和风险形成共同承诺的过程。
评审参与角色通常包括项目经理、技术负责人、主要任务负责人、需求方代表以及受计划影响的其他团队代表。评审要点集中在五处：交付物与验收标准是否完整、任务粒度与责任人是否明确、依赖与关键路径是否合理、资源投入是否与任务匹配、风险与假设是否有应对和确认人。评审中发现的问题记录为待办，明确修改责任人和关闭时间，修改完成后再次确认。
基线冻结的判断标准由组织评审规则决定，通用判断是：评审问题已关闭或已明确处理方案，关键干系人确认交付物、时间与资源承诺，风险应对动作已落实到责任人，计划版本已归档。满足这些条件后冻结为基线版本，后续执行以该版本为对比基准。
基线之后的范围、时间、资源变更走变更申请与影响评估流程。变更申请写清变更内容、原因、提出人；影响评估覆盖受影响的交付物、任务、依赖、关键路径、资源和风险，给出对完成时间的影响结论；由有权决策的角色审批，审批结果和评估结论一并记录。ONES 支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，并通过对比版本细节追溯变更。
变更记录按版本留存，每条记录包含变更编号、申请时间、变更内容、影响评估结论、审批结果、生效版本。变更记录的作用是让后续复盘能够还原计划为何调整，也为同类项目的估算提供依据。
本步骤的输入是完整的计划草案，动作是组织评审、关闭问题、冻结基线、建立变更流程，输出是评审记录、基线版本与变更登记表。完成标志是基线版本已归档，变更流程和记录模板已确定。
角色分工与各阶段交付物
计划制定涉及多个角色，职责不清会导致交付物无人负责或重复确认。下表汇总各角色在计划制定过程中的主要职责与对应产出，组织可按项目规模合并角色，但每项交付物应有明确责任人。
| 角色 | 主要职责 | 对应交付物 |
|---|---|---|
| 项目经理 | 组织计划制定全过程，汇总任务与进度，主持评审，维护基线与变更记录 | 计划整体、评审记录、基线版本、变更登记表 |
| 技术负责人 | 确认技术类交付物与验收标准，参与工期校准，识别技术依赖与风险 | 技术交付物清单、技术风险条目、依赖标注 |
| 职能/资源负责人 | 确认人员投入与可用时间，处理资源冲突，确认外部依赖 | 资源分配表、外部依赖确认记录 |
| 任务负责人 | 提供工期估算，确认任务验收标准，承诺任务完成时间 | 任务工期估算、任务级验收标准 |
| 需求方代表 | 确认交付物范围与验收标准，参与基线评审 | 范围确认意见、评审确认记录 |
评审与确认环节的责任归属需要单独明确：评审由项目经理组织，技术类内容由技术负责人把关，资源承诺由职能负责人确认，范围与验收标准由需求方代表确认。基线冻结由项目经理提交、有权决策的角色批准，批准后由项目经理归档并通知相关方。
示例：一个版本发布项目的计划制定过程
以下为演示情景，用于说明从目标到基线的制定过程，不对应真实客户项目。
项目背景与目标：某产品计划在十周内发布一个新版本，包含三项功能改进和一次数据结构调整，目标是按期发布并通过上线前质量评审。
交付物与 WBS：交付物清单包括功能设计说明、三项功能开发完成的可运行版本、数据结构迁移脚本与回滚方案、测试报告、发布说明。WBS 按交付物拆解，功能开发下拆为设计确认、编码、自测、联调四个工作包，测试报告下拆为用例编写、功能测试、回归测试。
里程碑与任务：设置四个里程碑：设计确认完成、功能开发完成、测试通过、发布评审通过。每个里程碑对应上述交付物。任务清单中，编码任务按功能模块拆分，每项指派一名开发负责人，工期三到八天不等，验收标准为自测通过并提交代码评审。
依赖、工期与缓冲：联调依赖编码完成和测试环境就绪，回归测试依赖功能测试通过。关键路径为设计确认、编码、联调、功能测试、回归测试、发布评审。在联调之后设置汇入缓冲两天，用于吸收接口对接问题；在发布评审前设置项目缓冲三天，用于吸收回归测试发现的问题修复时间。
风险与假设：风险条目包括“测试环境在编码完成后一周内未就绪，导致联调顺延，由测试负责人每周确认环境状态，未就绪时启用备用环境”；“数据结构迁移脚本在预发环境验证失败，由开发负责人准备回滚方案并在迁移前完成演练”。假设包括“需求方在设计确认后不再提出范围变更”“运维团队在发布周提供发布窗口”。
基线评审与变更：评审会上需求方确认交付物范围，技术负责人确认依赖与关键路径，职能负责人确认开发与测试人力投入。评审提出一项问题：回归测试时间估算偏紧，调整为增加一天并相应调整项目缓冲。问题关闭后计划冻结为基线版本。执行到第五周时，需求方提出增加一项功能改进，项目经理组织影响评估，结论为增加约六天工作量并影响发布评审时间，提交变更审批，审批结果和评估结论记入变更登记表。
计划制定完成检查清单
计划是否可以进入基线化，可逐项核对以下检查项。全部满足或对未满足项有明确处理方案时，计划达到可基线化标准。
| 检查维度 | 检查项 | 通过标志 |
|---|---|---|
| 交付物 | 交付物清单是否完整，每项是否有验收标准 | 每项交付物有验收人、判断依据和证据要求 |
| 拆解 | WBS 末级节点是否可估算、可指派、可判断完成 | 无无法估算或无人负责的节点 |
| 任务 | 任务粒度、负责人、工期是否明确 | 每个任务有唯一负责人和计划起止时间 |
| 依赖 | 前后置依赖是否标注，跨团队交接点是否确认 | 无循环依赖，交接点有对方时间承诺 |
| 关键路径 | 关键路径是否识别并标注 | 关键路径任务有负责人确认和检查安排 |
| 缓冲 | 缓冲位置、大小和动用规则是否写明 | 缓冲有明确位置和动用记录方式 |
| 资源 | 资源分配表是否覆盖全部任务，冲突是否有处理顺序 | 无同一时段超负荷且未处理的角色 |
| 风险 | 高影响风险是否有应对动作和责任人 | 每条高影响风险有触发信号和应对动作 |
| 假设 | 假设与外部依赖是否记录并指定确认人 | 每条假设有确认人和复核时间 |
| 评审 | 评审问题是否关闭，关键干系人是否确认 | 评审记录完整，问题有处理结论 |
| 基线 | 基线版本是否归档，变更流程是否建立 | 基线版本可查，变更登记表模板已确定 |
检查中发现的问题应记录责任人和关闭时间，处理完成后再次核对。计划基线化之后，后续执行中的进度对比与偏差纠偏按项目进度管理流程进行，计划本身的变化通过变更流程管理。
常见问题
项目计划一定要拆到很细的任务层级吗？
不必。WBS 的拆解深度以三个条件为停止标志：工期可以估算、可以指派单一负责人、完成与否可以判断。三个条件同时满足即可停止，规模较大的项目拆到工作包层，规模较小的项目拆到任务层即可。继续下拆的代价是维护成本上升，计划更新频率变高，反而容易失去参照价值。
工期估算应该由谁来做，项目经理直接定可以吗？
建议由执行该任务的负责人先给出估算，项目经理汇总后组织校准。校准依据包括历史同类任务的实际用时、工作量与可用人力的比值、外部供应商的承诺时间。项目经理单方面拍定工期，容易遗漏环境准备、评审等待等隐性时间，执行阶段偏差也更难解释。估算时写下的假设要一并记录，便于后续分析偏差原因。
缓冲留多少合适，有没有通用比例？
没有统一比例。缓冲大小结合任务不确定性、外部依赖程度和团队经验确定。位置比大小更关键：关键路径末端设置项目缓冲吸收整体不确定性，关键路径上高不确定性任务之后设置汇入缓冲防止局部延误传导。缓冲还需要写明谁有权动用、动用后如何记录，否则会被日常延误逐步消耗，到项目后期失去作用。
计划基线化之后，需求方再提新要求怎么处理？
走变更申请与影响评估流程。变更申请写清变更内容、原因和提出人；影响评估覆盖受影响的交付物、任务、依赖、关键路径、资源和风险，给出对完成时间的影响结论；由有权决策的角色审批，审批结果和评估结论一并记录。ONES 支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，并通过对比版本细节追溯变更。变更记录按版本留存，可为同类项目的估算提供依据。
计划制定阶段和进度管理阶段的边界在哪里？
计划制定阶段解决“做什么、按什么顺序做、谁来做、留多少余量”，产出是经评审确认的基线。基线之后进入执行，进度对比、偏差识别与纠偏属于项目进度管理的范围；计划本身的范围、时间、资源调整则通过变更流程管理。把两个阶段的动作分开，可以避免执行中随意改动基线，也避免计划阶段过度细化到无法维护。
