范围基线如何建立和变更：步骤、角色与检查

范围基线由经批准的范围说明书、工作分解结构（WBS）和WBS词典三份文件共同构成，在范围确认后冻结为可追溯的版本。建立基线要完成从交付物边界到工作包验收依据的逐层落实；基线生效后的范围调整则要走变更请求、影响分析、批准、升版和通知的闭环。下面按“冻结什么、怎么建立、谁负责、怎么变更、如何检查”的顺序展开，并在版本登记与变更流转处说明ONES可承载的对应动作。

要点总览（TL;DR）

• 范围基线由经批准的范围说明书、WBS和WBS词典三份文件构成，三者在交付物、工作包和验收依据上逐项对应，才算建立完成。
• 建立基线按确认交付范围、分解WBS、编写词典、组织评审、批准登记版本、发布通知六步推进，每步都有可判断的完成标志。
• 编制、评审、批准、保管四类职责分开，由客户或发起人批准，基线保管人保证同一时间只有一个生效版本。
• 基线生效后的范围调整走变更请求、影响分析、批准或驳回、更新升版、通知执行、关闭确认的闭环；不改变交付物和验收标准的执行拆解属于任务安排，不进入变更流程。
• 发布前和变更关闭前用检查清单逐项核对，重点看文件一致性、负责人与验收依据、版本记录和通知确认。

范围基线由哪三份文件构成

判断基线是否成立，先看三份文件是否齐全并相互对应。需求清单记录的是待办事项，任务列表记录的是执行安排，两者都不能替代基线。基线冻结的是经过批准、可以作为后续比较基准的交付范围。

三份文件各自承担什么

文件	必备内容	在基线中的作用
范围说明书	项目目标、主要交付物、验收标准、明确排除项、假设与约束	界定“做什么、做到什么程度、不做什么”，是WBS分解的上位依据
WBS	按交付物或阶段逐层分解的层级结构，最底层为工作包	把交付范围拆到可估算、可分配、可验收的粒度
WBS词典	工作包编号、名称、负责人、交付物、验收依据、依赖关系、估算说明	为每个工作包补充执行与验收所需的细节，防止WBS节点只有名称没有口径

工作包的粒度以“能估算、能分配、能验收”为准。一个工作包通常对应一名负责人，产出可识别的交付物，并有明确的验收依据；如果某个节点还需要多人长期协作且交付物混杂，就应继续分解。分解深度不必追求统一层数，以覆盖全部交付范围为准。

一致性核对怎么做

三份文件的一致性可以从三个方向核对：范围说明书中的每项交付物都能在WBS中找到对应分支；WBS中每个工作包都在词典中有条目，且负责人、交付物、验收依据三项不缺；词典中的依赖关系与WBS层级不矛盾，排除项没有以任何形式出现在WBS中。核对结果记录为问题清单，逐条处理后再进入批准环节。

建立范围基线的六个步骤

建立基线是一项有先后依赖的工作：先确认范围，再分解，再补细节，最后评审批准并发布。每一步都应有明确的输出和完成标志，避免在文件不齐的情况下提前冻结。

步骤	输入	动作	输出	完成标志
1. 确认交付范围	项目章程、需求文件、合同或任务书、干系人意见	整理交付物清单、验收标准、排除项、假设与约束	范围说明书初稿	交付物与排除项均有明确表述，关键干系人无重大异议
2. 分解WBS	范围说明书初稿	按交付物或阶段逐层分解，检查100%规则	WBS层级图或树状清单	所有交付物均有对应分支，最底层节点达到工作包粒度
3. 编写WBS词典	WBS、估算信息、依赖关系	为每个工作包填写编号、负责人、交付物、验收依据、依赖	WBS词典条目	每个工作包条目完整，无空缺字段
4. 组织范围评审	三份文件草案	邀请相关角色评审，记录意见、责任人和处理结论	评审记录与修订后的文件	意见全部关闭或有明确处理结论
5. 取得批准并登记版本	评审通过的文件	由批准人签字确认，登记版本号、生效日期、批准记录	带版本标识的基线文件	批准记录可查，版本号与生效日期唯一
6. 发布并通知	已登记的基线	向执行角色发布基线，说明使用方式和变更入口	发布通知与接收确认	受影响角色确认已收到并理解基线内容

第2步的100%规则指WBS子层之和完整覆盖父层交付范围，既不遗漏也不重复计入。检查方式是逐项对照范围说明书的交付物清单，确认每项都有归属分支。第4步的评审意见要落到具体条目，例如验收标准表述不清、工作包粒度过粗、依赖关系缺失，处理结果写回文件而不是停留在会议记录里。

在工具承载层面，ONES支持用「项目计划」创建工作分解结构，按目标、交付物或项目阶段等维度分解计划和工作，并可为任务设置前后置依赖、用里程碑标记重要时间点。这与第2步的分解和第3步的依赖登记相对应；基线版本登记与变更流转的具体配置，则以团队实际使用的功能为准。

谁负责建立与批准基线

基线需要有人编制、有人评审、有人批准、有人保管，四类职责分开，才能避免执行者自行冻结范围。角色名称可按组织习惯调整，职责归属应明确到人。

角色	主要职责	交付物
项目经理	组织基线编制，汇总输入，安排评审，登记版本并发布	基线文件成套版本、评审记录、发布通知
范围负责人（或需求负责人）	编写范围说明书，维护交付物清单、验收标准与排除项	范围说明书
技术负责人	参与WBS分解，确认工作包的技术可行性与依赖关系	WBS分支与词典中的技术条目
客户或发起人	确认交付范围与验收标准，批准基线	批准记录
评审参与角色	从质量、测试、实施等角度提出意见并确认处理结果	评审意见与关闭记录
基线保管人	维护版本登记，保管批准记录，控制基线文件的发放	版本登记表、基线档案

签字要求按组织治理规则确定，通常由客户或发起人对范围说明书与基线整体批准，技术负责人对WBS与词典的技术内容确认。基线保管人一般由项目经理或项目管理办公室指定人员担任，负责保证同一时间只有一个生效版本。执行团队在收到发布通知后，应确认自己负责的工作包、交付物和验收依据，发现口径不清时通过变更或澄清渠道反馈，不自行修改基线内容。

范围变更如何走完一个闭环

基线生效后，范围调整要经过变更请求、影响分析、批准或驳回、更新升版、通知执行、关闭确认六个环节。范围变更与执行阶段的任务拆解要区分开：在不改变交付物、验收标准和排除项的前提下，把工作包继续拆成执行任务、调整人员分工，属于执行安排；一旦涉及新增或删减交付物、修改验收标准、改变排除项，就应进入变更流程。

变更请求应包含的字段

字段	填写要求
变更编号与标题	唯一编号，标题概括调整对象
提出人与日期	记录请求来源，便于后续沟通
变更内容	具体说明新增、删减或修改的交付物、工作包或验收标准
变更理由	业务需求、技术约束或外部条件变化
影响范围	涉及的WBS分支、工作包编号与依赖关系
影响分析	对进度、成本、质量、依赖和验收标准的影响评估
处理结论	批准、驳回或退回补充，附批准人与日期

闭环各环节的动作

影响分析要按同一口径评估：进度上看是否改变里程碑或关键路径，成本上看是否增加工作量或外部投入，质量上看是否影响验收标准与测试范围，依赖上看是否牵连其他工作包或外部交付。分析结论写入变更请求，作为批准依据。

批准权限按组织变更管理规则执行，本文只写到衔接点：批准人依据影响分析作出决定，驳回的请求记录理由并关闭，需要补充信息的退回提出人完善。批准后同步更新范围说明书、WBS和WBS词典，登记新版本号与生效时间，保留旧版本以备追溯，然后通知受影响的执行角色，执行完成并确认结果后关闭变更。未经批准的调整不进入基线，只在待决清单中跟踪。

ONES在ALM方案中围绕需求、基线、版本和变更建立统一管理对象，支持需求变更影响分析与过程状态追踪；当需求发生变化时，可沿关联关系分析受影响的任务、测试和交付内容，并保留过程追踪依据。对于需要把变更请求、影响分析和版本记录放在同一处流转的团队，这类关联关系可以作为变更闭环的承载方式，具体字段与审批配置以实际使用为准。

一个范围基线的示例

以下为演示情景，用于说明文件如何填写，不代表真实项目数据。

范围说明书片段

示例项目为某内部报销系统的升级。交付物包括：报销单在线填报模块、审批流配置、历史数据迁移、用户操作手册。验收标准为：填报与审批流程通过业务方场景测试，历史数据抽样核对一致，手册经使用部门确认。排除项为：与外部财务系统的接口改造、移动端应用开发。

WBS与词典条目示例

WBS按交付物分解为四个分支，其中“审批流配置”分支下含工作包“多级审批规则配置”。对应词典条目为：工作包编号WP-2.1；负责人为实施顾问；交付物为审批规则配置说明与测试环境配置结果；验收依据为业务方确认的三类审批场景全部通过；依赖为填报模块字段定义完成。

一次变更的处理

业务方提出新增“报销单抄送财务主管”功能。变更请求记录变更内容为新增抄送规则，理由为财务复核需要，影响范围为审批流配置分支下的WP-2.1及测试工作包。影响分析结论为：进度增加三个工作日，成本增加相应人天，验收标准需补充抄送场景，依赖关系不变。批准后范围说明书补充该交付物，WBS增加对应工作包，词典补充验收依据，基线版本由V1.0升为V1.1，生效日期登记为批准当日，通知实施顾问与测试负责人，执行完成并确认后关闭变更。

基线建立与变更的完成检查

检查项用于发布前自检和变更关闭前复核，每项都应能给出“是”或“否”的判断，而不是笼统评价。

发布前检查

• 范围说明书、WBS、WBS词典三份文件齐全，且交付物、工作包、词典条目逐项对应。
• 每个工作包都有负责人、交付物和验收依据，没有空缺字段。
• 范围说明书中的排除项未出现在WBS中，假设与约束已记录。
• 评审意见全部关闭或有明确处理结论，批准记录可查。
• 版本号与生效日期唯一，旧版本已归档。
• 受影响执行角色已收到发布通知并确认。

变更关闭前检查

• 变更请求包含变更内容、理由和影响范围，影响分析覆盖进度、成本、质量、依赖与验收标准。
• 批准或驳回记录完整，驳回理由已记录并关闭。
• 批准后的范围说明书、WBS和词典已同步更新，版本号与生效时间已登记。
• 受影响角色已收到通知，执行结果已确认。
• 未批准的调整仍在待决清单中跟踪，未混入基线。

常见问题

范围基线建立后，执行过程中把工作包继续拆成任务，需要走变更流程吗？

不需要。判断标准是交付物、验收标准和排除项是否发生变化。在这些内容不变的前提下，把工作包拆成更细的执行任务、调整人员分工或安排先后顺序，属于执行阶段的组织安排，由执行团队在基线范围内处理即可。

一旦涉及新增或删减交付物、修改验收标准、改变排除项，就应提交变更请求，按影响分析、批准、升版、通知的流程处理。团队可以在基线发布时就把这条边界写进使用说明，减少执行中的反复确认。

基线已经批准，但评审时遗漏了一条验收标准，应该怎么补？

按范围变更处理，不直接修改已生效的基线文件。由范围负责人提交变更请求，说明补充的验收标准内容、涉及的工作包和理由，完成对进度、成本、质量和依赖的影响分析，经原批准人或其授权角色批准后，同步更新范围说明书、WBS和WBS词典，登记新版本号与生效时间，并通知受影响的执行角色。

如果遗漏导致当前执行口径不清，可以先把相关条目列入待决清单跟踪，明确临时处理方式，避免执行团队各自理解。

范围变更被驳回后，提出人还能做什么？

驳回的请求应记录理由并关闭，提出人可以据此调整方案后重新提交，或改为在现有基线范围内寻找替代做法。若驳回原因是影响分析不充分，退回补充信息后再评审是常见处理方式。

被驳回的调整不进入基线，也不应通过执行中的临时安排变相实施。团队可以把这类请求保留在待决清单中，在下一轮范围评审时统一评估。

多个变更同时批准时，版本号怎么管理？

建议按批准顺序逐个升版，每个版本对应明确的生效时间和变更内容，避免把多个变更合并成一个版本后难以追溯。若组织习惯批量发布，也应保证每个变更请求都能对应到具体版本和生效日期。

基线保管人负责维护版本登记，保证同一时间只有一个生效版本，旧版本归档保留。执行团队以最新生效版本为准，历史版本用于追溯和审计。

ONES 能承载范围基线的哪些管理动作？

ONES 支持用「项目计划」创建工作分解结构，按目标、交付物或项目阶段等维度分解计划和工作，并可为任务设置前后置依赖、用里程碑标记重要时间点；同时支持设置项目计划和里程碑基线，通过版本对比追溯变更细节。在 ALM 方案中，需求、基线、版本和变更作为统一管理对象，需求变化时可沿关联关系分析受影响的任务、测试和交付内容，并保留过程追踪依据。

范围说明书、WBS词典的统一登记方式以及变更请求的字段与审批配置，需结合团队实际使用的功能和配置确定。