项目计划编制、范围管理与进度计划经常被混在一起使用，但三者承担的任务不同：范围管理确定“做什么、不做什么”，为计划编制提供边界和依据；项目计划编制把范围、时间、资源、质量、风险等要素整合成一份可执行的整体计划；进度计划则是计划编制在时间维度上的核心产出，把范围中的工作包排成带依赖关系和里程碑的时间表。理解这条“定边界—做整合—排时间”的衔接关系，有助于避免把排一张进度表当成完成了项目计划。
要点总览（TL;DR）
- 项目计划编制是把范围、时间、资源、质量、风险等要素整合成可执行整体计划的过程，产出项目管理计划及各项基准。
- 范围管理确定项目边界，通过范围说明书、WBS和范围基准为计划编制提供依据；范围变更需要同步评估对进度、成本和资源的影响。
- 进度计划是项目管理计划的子计划，把范围工作包排成带依赖和里程碑的时间表，并形成进度基准。
- 三者按“定边界—做整合—排时间”的顺序衔接：收集需求、定义范围、创建WBS、整合计划、编制进度计划、形成基准。
- 执行阶段的偏差跟踪归项目进度管理，具体任务排期与依赖维护归任务排期与依赖管理，本文不展开。
项目计划编制到底在编制什么
项目计划编制是把项目从“被批准要做”推进到“知道怎么执行”的整合过程。它的产物是一份能够指导执行、支持跟踪和变更控制的整体计划，覆盖范围、时间、成本、资源、质量、沟通、风险等多个方面。编制计划时，团队需要把分散的信息汇总、对齐并形成基准，让后续执行有统一参照。
计划编制的主要输入包括：项目章程，明确项目目标、高层级要求和授权；范围基准，说明要交付什么、工作分解到什么程度；组织与资源条件，包括可用人员、技能结构、外部依赖；以及项目约束与假设，例如交付期限、预算上限、合规要求和对某些条件的预判。这些输入决定了计划能排多细、能承诺到什么程度。
关键活动通常围绕以下动作展开：
- 分解工作：把可交付成果拆成可管理的工作包，明确责任归属。
- 估算：对工作包的持续时间、工作量、成本进行估算，并记录估算依据。
- 排定时间：识别活动之间的先后依赖，形成带里程碑的时间安排。
- 配置资源：把人员、设备、外部服务分配到具体工作包，处理资源冲突。
- 识别风险：找出可能影响计划目标的事件，预留应对空间。
- 设定基准：把经过评审和确认的版本固定为范围基准、进度基准和成本基准，作为后续比较的依据。
主要输出是项目管理计划及其子计划，包括范围管理计划、进度管理计划、成本管理计划、质量管理计划、风险管理计划等，以及对应的基准。需要区分的是，计划编制完成的是“计划体系”的建立，执行过程中出现的偏差跟踪、纠偏和变更处理属于后续管理动作。
范围管理如何为计划编制划定边界
范围管理回答的是项目边界问题：哪些需求纳入、哪些交付物必须完成、哪些工作明确不做。它通过收集需求、定义范围、创建工作分解结构（WBS）等动作，产出范围说明书、WBS和范围基准。范围基准一旦确认，就成为计划编制最重要的输入之一，因为计划中的时间、成本和资源安排都要围绕这个边界展开。
WBS工作包是估算与排期的基本对象。计划编制不会直接对“整个项目”做笼统估算，而是对每个工作包估算工作量、持续时间和所需资源，再把这些工作包按依赖关系组织起来。工作包划分得是否清晰，直接影响估算的可靠性和进度安排的可执行性。工作包过粗，估算容易失真；过细，管理成本又会上升。
范围变更会触发计划与基准的更新。当客户提出新增功能、法规要求发生变化或设计调整导致交付物变化时，范围基准需要走变更流程；一旦范围发生变化，受影响的进度、成本、资源和风险安排也要同步评估和调整。如果范围变更没有进入计划更新，计划就会与实际工作脱节。
范围蔓延对计划编制的影响更隐蔽。范围蔓延指未经正式变更控制、逐步增加的小需求或“顺手做掉”的工作。单个改动看似不大，累积起来会挤占原计划的时间和资源，使进度基准失去参考价值。计划编制阶段明确范围边界和变更入口，是控制这类风险的常见做法。
进度计划在计划编制中的位置与组成
进度计划是项目管理计划的子计划之一，承载计划体系中的时间维度。它把范围中的工作包转化为有先后顺序、有持续时间、有责任人和里程碑的时间安排，回答“什么时候做什么、先后关系如何、关键节点在哪里”。进度计划不是计划编制的全部，但通常是计划编制中最直观、最常被查看的部分。
一份完整的进度计划通常包含以下组成要素：
| 组成要素 | 作用 | 与其他计划的关系 |
|---|---|---|
| 活动清单 | 把工作包进一步拆成可排期的活动 | 来源于范围基准中的WBS |
| 活动排序 | 识别活动之间的前后置依赖 | 受资源条件和技术约束影响 |
| 持续时间估算 | 给出每项活动预计耗时 | 依赖资源可用性和估算依据 |
| 里程碑 | 标记重要时间点、事件或决策点 | 常与阶段评审、交付验收对应 |
| 进度基准 | 作为执行阶段比较偏差的参照 | 与范围基准、成本基准共同构成项目基准体系 |
进度计划与计划编制中的其他部分存在联动。资源计划变化会改变活动持续时间或排序；成本计划中的预算节奏会影响资源投入强度；风险应对措施可能增加缓冲时间或调整里程碑。编制进度计划时把这些因素放在一起考虑，才能形成可执行的安排。
进度计划与执行阶段的进度管理有分工。进度计划解决“计划怎么排”，进度管理解决“执行中偏了多少、为什么偏、怎么处理”。跟踪实际进展、分析偏差、采取纠正措施、更新进度基准，属于进度管理的范畴。把两者混为一谈，容易在计划阶段就陷入执行细节，也可能在执行阶段缺少明确的比较基准。
三者的衔接流程：从范围到计划再到进度
把范围管理、计划编制和进度计划串起来，可以形成一条连续的流程：收集需求→定义范围→创建WBS→整合计划→编制进度计划→形成基准。每个步骤都有明确的角色、工作项和产出状态，前一步的输出是后一步的输入。
- 收集需求与定义范围：由业务方、产品负责人和项目团队共同确认需求，形成范围说明书，明确项目边界和验收标准。
- 创建WBS：项目团队把可交付成果分解为工作包，指定工作包负责人，形成范围基准。
- 整合计划：项目经理组织各领域负责人，把范围、资源、成本、质量、风险等安排汇总对齐，识别相互冲突的约束。
- 编制进度计划：在整合框架下排列活动顺序、估算持续时间、设置里程碑，形成进度安排。
- 形成基准：经过评审确认后，把范围、进度、成本等版本固定为基准，作为执行和跟踪的参照。
以一个企业官网改版项目为例。范围管理阶段确认要交付首页、产品页、新闻模块和后台内容管理功能，明确不包含多语言版本，形成范围说明书和WBS。计划编制阶段把WBS中的工作包分配给设计、前端、后端和测试角色，估算各工作包工作量，识别第三方支付接口依赖这一风险并预留缓冲。进度计划阶段把设计评审、开发、联调、测试和上线排成带依赖关系的时间表，设置“设计定稿”“测试完成”“正式上线”三个里程碑。如果后续提出增加多语言版本，范围变更需要先评估对进度和资源的影响，再决定是否更新基准。
常见误解是把计划编制等同于排进度表。排进度表只是计划编制中的一个动作，计划编制还包括范围确认、资源安排、风险识别和基准设定。只排时间而不确认范围和资源条件，进度表往往经不起执行检验；只做范围分解而不整合资源和风险，计划也难以落地。
在工具承载层面，ONES 支持用「项目计划」创建工作分解结构（WBS），按目标、交付物或项目阶段等维度分解计划和工作，并制定项目进度计划；也可为任务设置前后置依赖，用里程碑标记重要时间点、事件或决策点。范围与计划衔接时，ONES 支持在项目下管理需求范围、研发任务，项目经理可在项目计划中关联迭代和研发任务。这些能力对应的是把范围分解、计划整合和进度安排放在同一项目空间中承载，具体配置以实际版本与套餐为准。
容易混淆的相邻概念与边界
计划编制与项目进度管理容易混淆。计划编制关注“计划怎么形成”，产出项目管理计划和各项基准；进度管理关注“执行中进度如何被跟踪和控制”，包括实际进展记录、偏差分析、纠正措施和基准更新。本文讨论计划编制阶段的关系，执行偏差的跟踪与控制归项目进度管理，不在此展开。
计划编制与任务排期、依赖管理也有区别。任务排期是把具体任务安排到时间轴上，依赖管理是维护任务之间的前后置关系，两者都是进度计划形成过程中的操作环节。计划编制在更高层面决定要不要做、按什么优先级做、资源如何配置、风险如何应对。具体排期操作和依赖关系维护归任务排期与依赖管理主题，本文只说明它们在计划体系中的位置。
范围管理与需求管理同样需要区分。需求管理侧重需求的收集、分析、优先级排序和变更跟踪；范围管理在需求基础上确认项目边界，形成范围说明书和范围基准，并控制范围变更。需求是范围管理的输入之一，范围基准是计划编制的直接依据。
| 概念 | 核心问题 | 主要产出 | 与本文的关系 |
|---|---|---|---|
| 项目计划编制 | 如何把多要素整合成可执行计划 | 项目管理计划及子计划、基准 | 本文核心概念 |
| 范围管理 | 做什么、不做什么 | 范围说明书、WBS、范围基准 | 计划编制的输入和边界 |
| 进度计划 | 什么时候做、先后关系如何 | 活动清单、排序、持续时间、里程碑、进度基准 | 计划编制的时间维度产出 |
| 项目进度管理 | 执行中进度偏了多少、怎么处理 | 进展记录、偏差分析、纠正措施 | 执行阶段主题，本文不展开 |
| 任务排期与依赖管理 | 具体任务怎么排、依赖怎么维护 | 任务时间安排、依赖关系 | 操作层面主题，本文不展开 |
| 需求管理 | 需求如何收集、分析和变更 | 需求清单、优先级、变更记录 | 范围管理的上游输入 |
明确这些边界后，三者关系可以概括为：范围管理提供依据和边界，项目计划编制完成多要素整合，进度计划承载时间安排并形成进度基准。执行阶段的偏差跟踪、具体任务排期和依赖操作属于相邻主题，本文不重点展开。
常见问题
范围基准已经确认，客户中途提出新增需求，计划应该怎么处理？
新增需求先进入变更评估，判断它是否改变项目边界。若确认纳入范围，需要更新范围说明书和WBS，并同步评估对活动排序、持续时间、资源投入和风险应对的影响，再决定是否调整进度基准与成本基准。若变更未走流程就直接排入执行，容易形成范围蔓延，使原基准失去参照价值。
项目计划编制完成后，进度计划还需要单独维护吗？
需要。项目计划编制形成的是整体计划体系和各项基准，进度计划是其中时间维度的子计划。执行过程中活动持续时间、依赖关系或资源条件发生变化时，进度计划要随之更新，并在必要时走基准变更流程。把进度计划视为一次性产物，执行阶段就缺少可比较的时间参照。
工作包分解到什么程度，才适合用于估算和排期？
常见做法是分解到能够可靠估算工作量和持续时间、可以明确责任人的粒度。工作包过粗，估算依据不足，排期容易失真；分解过细，计划编制和维护的成本会明显上升。分解粒度还与项目复杂度、团队经验和交付节奏有关，需要在计划编制阶段与团队共同确认。
计划编制阶段需要把风险应对排进进度计划吗？
需要纳入考虑。识别出的风险如果可能影响关键活动，应在进度安排中预留缓冲或设置应对活动，并在里程碑设置上体现决策点。风险应对占用的时间和资源要与资源计划、成本计划一起对齐，否则进度表在执行时容易被突发问题打乱。
ONES 的项目计划功能能承载范围分解和进度安排吗？
根据 ONES 官方资料，ONES 支持用「项目计划」创建工作分解结构（WBS），按目标、交付物或项目阶段等维度分解计划和工作，并制定项目进度计划；也可为任务设置前后置依赖，用里程碑标记重要时间点、事件或决策点。范围与计划衔接方面，ONES 支持在项目下管理需求范围、研发任务，项目经理可在项目计划中关联迭代和研发任务。具体功能可用性以实际版本与套餐为准。
