项目范围确认要解决的是“交付物是否达到验收标准、能否纳入基线”的问题。它把已分解的交付范围转成可核验的验收依据：先明确确认对象与边界，再准备范围说明书、WBS交付物清单和验收标准，由交付方说明、接收方逐项核对，形成书面确认记录。本文按准备、核对、记录、整改、归档的顺序展开，并说明与范围分解、变更审批的边界；ONES在确认记录与基线同步上的承载方向会在流程中自然提及。
要点总览（TL;DR）
- 范围确认的对象是交付物及其验收标准，依据是已批准的范围基准；任务拆解和范围变更审批不在确认会上处理。
- 确认按五步推进：准备材料并预约接收方、逐项说明与核对、记录通过项与差距项、差距整改与复核、形成确认记录并纳入基线。
- 项目经理负责组织与记录，交付负责人提交交付物与证据，接收方逐项核对并签署结论，质量或配置角色核对证据完整性与版本一致性。
- 确认记录应逐项对应验收标准，差距描述具体到可整改，每个差距项写明责任人与复核时点。
- 完成检查五项全部满足后，确认结果才能作为范围基线，用于后续变更比较。
范围确认要确认什么：对象、边界与前置输入
范围确认的对象是“可交付成果及其验收标准”，依据是已批准的范围基准。确认会上要逐项回答两个问题：这项交付物是否完整提交，是否满足事先写明的验收标准。任务拆解、人员分工属于执行阶段的组织安排，范围变更审批属于基线调整环节，两者都不在确认会上处理；确认会只对当前基线内的交付物给出通过或差距结论。
确认能否顺利推进，取决于会前输入是否齐备。缺少已批准的范围基准，确认就失去比较对象；验收标准写得笼统，核对只能停留在主观判断；干系人名单不清，签字结论的代表性也会受质疑。下表列出确认对象与前置输入的对应关系，可作为会前自查。
| 确认对象 | 作用 | 前置输入 | 会前检查要点 |
|---|---|---|---|
| 范围说明书 | 界定项目要交付什么、不交付什么 | 已批准的范围基准 | 版本为当前有效版本，含明确的范围排除项 |
| WBS交付物清单 | 列出待确认的交付物及层级 | 已分解并确认的工作分解结构 | 每个交付物有唯一编号，能对应到责任人 |
| 验收标准 | 提供逐项核对的客观依据 | 可核验、可判定的标准描述 | 标准可观察或可测量，避免“基本满足”一类表述 |
| 干系人名单 | 确定谁核对、谁签署 | 已识别的接收方与客户代表 | 签署人有明确授权，关键干系人到场或书面委托 |
需要区分的是，范围确认与质量控制的关注点不同：质量控制检查交付物本身是否符合技术规范，范围确认则由接收方判断交付物是否满足验收标准并接受交付。两者可以共用证据，但结论分别记录，避免用质量检查报告替代确认记录。
确认流程的五个步骤：从准备到签字归档
范围确认按固定顺序推进，每一步都有明确输入、动作、输出和完成标志。流程的价值在于让确认可重复：同一类交付节点按同一套步骤执行，确认记录的结构保持一致，后续复核和审计都有据可查。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 准备确认材料并预约接收方 | 范围说明书、WBS交付物清单、验收标准、干系人名单 | 整理待确认交付物清单，逐项附验收标准与证据位置；与接收方约定时间、参与人和确认方式 | 确认会议通知、材料包、待确认项清单 | 接收方确认参会并收到材料，待确认项与验收标准一一对应 |
| 2. 逐项演示或说明交付物与验收标准 | 材料包、交付物实物或演示环境 | 交付方按清单顺序说明每项交付物的内容与对应证据，接收方对照验收标准逐项核对 | 逐项核对过程记录 | 每项交付物均完成说明与核对，无遗漏项 |
| 3. 记录通过项、差距项与待补证据 | 核对过程记录 | 对每项给出“通过”“有差距”“待补证据”三类结论之一，差距项写明具体差距描述 | 确认记录初稿 | 每项都有明确结论，差距项描述具体到可整改的程度 |
| 4. 差距项整改与复核 | 确认记录初稿中的差距项 | 为每个差距项指定整改责任人与复核时点，整改完成后由接收方或指定核对人复核 | 整改记录与复核结论 | 所有差距项完成整改并复核通过，或经接收方同意转为遗留项并书面记录 |
| 5. 形成确认记录并纳入范围基线 | 确认记录终稿、签字信息 | 汇总通过项与复核结论，取得接收方书面结论，将确认结果与记录版本关联到范围基线 | 签字确认记录、更新后的基线记录 | 记录有接收方书面结论，基线可追溯到本次确认记录 |
第2步的核对方式可以按交付物类型调整：软件功能适合现场演示，文档类交付物适合逐章对照标准审阅，硬件或实物交付适合现场查验。方式可以不同，但“逐项对应验收标准”这一要求不变。第3步的记录粒度决定了后续整改是否可执行，差距描述应写明缺什么、差在哪里，例如“接口文档缺少错误码章节”，避免只写“文档不完整”。
第5步是容易被压缩的环节。确认结论只有落到书面记录并关联基线，才能在后续变更比较中作为基准使用。ONES的项目计划支持设置项目计划和里程碑基线，并可通过版本对比追溯变更细节；确认记录与基线版本建立关联后，后续范围调整时能清楚看到确认时的原始状态。具体功能以实际版本与套餐为准。
角色与交付物分工：谁提交、谁核对、谁签字
确认流于口头，通常是因为角色职责没有落到具体产出上。把每个角色的动作和交付物写清楚，确认过程就有了可追责的结构。以下分工适用于多数交付型项目，团队规模较小时可由一人兼任多个角色，但核对与提交应由不同人员承担，以保留基本的相互校验。
| 角色 | 核心职责 | 主要交付物 | 关键动作 |
|---|---|---|---|
| 项目经理 | 组织确认、维护确认记录 | 确认会议通知、确认记录、基线关联记录 | 准备材料包、预约接收方、主持确认、跟踪差距项整改、归档记录 |
| 交付负责人 | 提交交付物与证据 | 交付物清单、证据材料、差距项整改结果 | 按验收标准准备证据、现场说明交付物、认领差距项并组织整改 |
| 接收方或客户代表 | 逐项核对并签署结论 | 逐项核对意见、书面确认结论 | 对照验收标准核对、给出通过或差距结论、签署确认记录 |
| 质量或配置角色 | 核对证据完整性与版本一致性 | 证据完整性检查意见、版本核对记录 | 会前检查证据是否齐全、核对交付物版本与基线版本是否一致 |
项目经理的职责重心在组织和记录，不代替接收方做验收判断；交付负责人对证据的真实性和完整性负责；接收方的签署是确认生效的关键条件，签署人应具备相应授权。质量或配置角色的介入点主要在会前和会后：会前确认材料版本正确、证据齐全，会后确认整改后的版本与记录一致。角色之间出现分歧时，以验收标准和范围基准为依据，分歧本身也应写入记录，而不是在会后口头消化。
在工具层面，ONES支持在项目下管理需求范围、研发任务等内容，项目经理可以在项目计划中关联迭代和研发任务，掌握研发进度。确认所需的交付物状态、证据位置和确认结论可以围绕同一批工作项组织，减少材料在多个渠道之间来回核对。资料未提及确认记录签署与归档的专门功能，实际承载方式需结合团队配置确定。
示例：一次迭代交付物的范围确认记录
以下为演示情景，用于说明确认记录的填写结构，不代表任何真实项目。背景：某系统迭代交付节点，确认对象为三项交付物，接收方为业务方代表，交付方为研发交付负责人，项目经理组织确认。
| 编号 | 交付物 | 验收标准 | 核对结果 | 差距描述 | 整改责任人 | 复核时点 |
|---|---|---|---|---|---|---|
| D-01 | 订单查询功能 | 按订单号、时间范围两种条件查询，返回结果字段与需求文档一致 | 通过 | — | — | — |
| D-02 | 接口说明文档 | 覆盖全部对外接口，含请求参数、返回字段、错误码说明 | 有差距 | 缺少错误码章节，3个接口未标注返回字段类型 | 交付负责人 | 确认会后第3个工作日 |
| D-03 | 数据迁移结果报告 | 记录迁移记录数、校验结果与异常处理说明 | 待补证据 | 校验结果附件未随报告提交 | 交付负责人 | 确认会后第1个工作日 |
确认结论栏写明：本次确认共3项，通过1项，差距项1项，待补证据1项；差距项与待补证据完成整改并经接收方复核后，本次交付物整体视为确认通过。签字信息包括接收方代表、交付负责人、项目经理及确认日期。记录归档时关联当前范围基线版本，后续如发生范围调整，以本记录作为比较起点。
这份记录的可迁移之处在于三点：每项交付物对应一条可判定的验收标准；未通过项写明具体差距而非笼统评价；每个差距项都有责任人和复核时点。团队可以直接沿用这一结构，按自身交付物类型调整列名。
完成检查：确认是否真正闭环
范围确认达到可基线化的完成条件，需要同时满足以下检查项。任何一项不满足，确认记录都只能作为过程材料，不能作为基线依据。
- 确认对象与验收标准一一对应：WBS交付物清单中的每项交付物都有对应验收标准，无标准缺失项，也无未纳入清单的交付物。
- 每项交付物有明确结论：通过、有差距、待补证据三类结论齐全，不存在空白项或“待定”项。
- 差距项均有责任人与复核时点：差距描述具体可整改，责任人和复核日期明确，复核结论已回填。
- 确认记录有接收方书面结论：签署人具备授权，结论表述明确，签字与日期完整。
- 确认结果已同步到范围基线与相关干系人：基线记录可追溯到本次确认记录，关键干系人已知悉确认结论与遗留项。
检查通过后，范围基线才可作为后续变更比较的基准。若存在经接收方同意转为遗留项的差距，应在记录中单独列出并约定处理节点，避免在后续阶段被误认为已确认内容。ONES的瀑布项目管理方案覆盖从立项到收尾的过程，将需求管理、研发管理、测试管理和资源管理流程连接起来；确认记录与基线同步属于其中的管理动作，具体落地范围以实际配置为准。
常见问题
范围确认会上发现交付物不达标，是当场拒绝还是先记录差距？
建议先记录差距，再约定整改与复核，而不是在会上直接给出拒绝结论。具体做法是：对不达标项写明差距描述，指定整改责任人和复核时点，由接收方在复核后给出最终结论。如果差距较大、短期内无法整改，可以经接收方同意转为遗留项并书面记录，同时约定处理节点。这样处理的好处是确认记录保留了完整过程，后续复核有据可查，也不会因为一次会议未通过就中断整个交付节点。
确认记录需要哪些人签字才算有效？
确认记录生效的关键条件是接收方或客户代表的书面结论，签署人应具备相应授权。通常还需要交付负责人和项目经理签字，分别确认交付物提交情况和记录内容。团队规模较小时可以兼任角色，但提交与核对宜由不同人员承担，保留基本的相互校验。如果关键干系人无法到场，应取得书面委托，委托信息一并写入记录。
范围确认和质量检查可以合并成一次会议吗？
可以共用证据和部分参会人员，但结论应分别记录。质量控制关注交付物是否符合技术规范，范围确认由接收方判断交付物是否满足验收标准并接受交付。合并会议时，建议在记录中分栏写明质量检查结论和范围确认结论，避免用质量检查报告替代确认记录。两者混在一起记录，后续追溯时难以区分“技术合格”与“接收方接受”这两个不同判断。
确认完成后范围又发生调整，原确认记录还有用吗？
有用。原确认记录关联的是确认时的范围基线版本，后续范围调整走变更审批流程，调整后的基线可以与原记录对比，看清哪些内容在确认时已通过、哪些是新增或修改的。ONES的项目计划支持设置项目计划和里程碑基线，并可通过版本对比追溯变更细节，确认记录与基线版本建立关联后，这种对比就有了依据。具体功能以实际版本与套餐为准。
迭代节奏很快，每次交付都做完整确认会不会太重？
可以按交付物类型调整确认的深度，但“逐项对应验收标准”这一要求不宜省略。轻量做法包括：只对本次迭代新增或变更的交付物做逐项核对，沿用上次已确认且未变更的部分；核对方式从会议改为书面审阅加抽样演示；确认记录采用固定模板，减少填写成本。调整的是形式和范围，通过项、差距项、责任人与复核时点这些记录要素仍应保留，否则后续复核和基线比较会失去依据。
