可交付成果的确认与WBS落实是同一条链条上的两个动作：先把成果定义清楚并取得干系人认可，再以成果为起点逐层分解到可分配、可估算、可验收的工作包。本文给出六步主线、清单字段、分解规则、角色分工和一份完整示例，并附收尾检查清单，帮助项目团队把范围说明书与WBS对齐后再进入执行。
要点总览（TL;DR）
- 可交付成果先按“名称—验收标准—责任人—验收方式”定义清楚，经干系人确认后写入范围说明书，再作为WBS的上层节点逐层分解。
- 确认环节要留下书面载体：评审会纪要、书面签认或明确回复，记录结论、遗留项、责任人和复核时间。
- 工作包以可分配单一责任人、可估算工期与成本、可独立验收三条同时满足为停止分解的标准，并用成果编号与工作包编号建立双向追溯。
- 分解中发现成果缺失或验收标准不清，回补到范围说明书并更新版本后再继续分解，避免WBS与范围两张皮。
- 进入执行前用检查清单核对：每项成果有验收标准和责任人、在WBS中至少对应一个工作包、每个工作包可追溯到成果、两份文件版本一致。
从成果到工作包：确认与落实的主线
可交付成果从“被提到”到“被落实”，中间需要经过定义、确认、分解、对应四个动作。缺少定义，确认时无从判断；缺少确认，分解出的工作包容易偏离干系人预期；缺少对应关系，验收时难以证明某个成果由哪些工作支撑。以下六步把这条路径拆成可操作的环节，每一步都明确输入、动作、输出和完成标志。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 识别可交付成果 | 项目目标、合同或需求文件、阶段评审结论 | 逐条列出项目需要产出的成果，区分最终成果与阶段成果 | 可交付成果初稿清单 | 清单覆盖项目目标与合同承诺的全部成果 |
| 2. 定义四要素 | 成果初稿清单 | 为每项成果写清名称、验收标准、责任人、验收方式 | 可交付成果定义表 | 每项成果四项要素齐全，验收标准可判断 |
| 3. 干系人确认 | 定义表、评审材料 | 组织评审或书面签认，记录结论与遗留项 | 确认记录、范围说明书可交付成果段落 | 关键干系人明确表示认可，遗留项有责任人和期限 |
| 4. 写入范围说明书 | 确认记录 | 把确认后的成果定义整理进范围说明书 | 范围说明书定稿版本 | 说明书中的成果与确认记录一致 |
| 5. 逐层分解到工作包 | 范围说明书、成果定义表 | 以成果为上层节点向下拆分，直到满足工作包粒度标准 | WBS层级结构 | 每个工作包可分配单一责任人、可估算、可独立验收 |
| 6. 建立对应关系 | WBS、成果定义表 | 为工作包编号并回填对应成果编号，写入WBS字典 | WBS字典、对应关系表 | 每项成果至少对应一个工作包，每个工作包可追溯到成果 |
六步之间存在回退：第5步分解时若发现某成果验收标准含糊，应回到第2、3步补充定义并重新确认，再继续分解。把回补动作留在范围说明书层面处理，可以避免在WBS里临时增加条目造成范围与计划两张皮。
可交付成果清单与确认记录怎么写
确认环节最常见的缺口是“口头同意了，但找不到依据”。解决办法是准备一份字段固定的可交付成果清单，并让每次确认都留下可追溯的记录。清单字段建议如下。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 编号 | 按项目统一规则编制，后续WBS引用同一编号 | D-01 |
| 名称 | 用名词描述产出物，避免写成动作 | 用户登录模块 |
| 类型 | 最终成果、阶段成果或管理成果 | 阶段成果 |
| 验收标准 | 写成可判断的条件，含功能、质量或文档要求 | 通过登录、找回密码、异常提示三类用例测试，缺陷关闭率100% |
| 责任人 | 对成果产出负责的单一角色 | 后端开发负责人 |
| 验收人 | 有权判定成果是否通过的角色 | 产品负责人、测试负责人 |
| 计划完成时间 | 与里程碑或阶段节点对齐 | 2025年6月30日 |
确认方式按成果影响范围选择。涉及跨部门接口或合同承诺的成果，适合召开评审会并形成会议纪要；影响范围明确、干系人较少的成果，可用书面签认；日常迭代中的小成果，邮件或协作工具中的明确回复即可作为确认依据。三种方式都应留下同一类信息：谁确认、确认了什么版本、结论是什么。
确认记录建议包含四部分内容：确认对象及版本、参与确认的角色、确认结论（通过、有条件通过、不通过）、遗留项及处理安排（责任人、完成时间、下次复核时间）。有条件通过的成果要写清条件满足后才能进入分解，避免带着未决问题拆工作包。
范围说明书中的可交付成果段落，写法上按“成果名称—验收标准—责任人—验收方式”逐条展开，并在段首说明成果总数与分类。段落末尾注明对应的确认记录编号，便于后续核对版本。
把可交付成果分解进WBS的规则
WBS承接可交付成果的关键，是让成果成为分解的上层节点，而不是在任务列表旁边另挂一份成果清单。分解顺序建议为：项目→阶段或主要成果→子成果→工作包。上层节点优先使用可交付成果名称，使结构本身就能回答“这个阶段要交出什么”。
工作包粒度用三条标准判断：可分配给单一责任人；工期与成本可估算；可独立验收。三条同时满足即可停止分解。只满足其中一条时继续下拆，例如某成果只能由多人共同完成，说明还未拆到可分配的程度。
编号对应规则建议采用“成果编号+序号”的形式，例如成果D-01下的工作包编为D-01.1、D-01.2。这样从工作包编号即可反查所属成果，从成果编号也能列出支撑它的全部工作包。WBS字典中为每个工作包记录：工作包编号、名称、对应可交付成果编号、验收标准、责任人、估算工期、前后置依赖。
分解过程中发现缺口时，按缺口类型回补：成果缺失，补入可交付成果清单并走确认；验收标准不清，回到定义环节细化；责任人不明，在角色分工中明确后再拆。回补完成后更新范围说明书版本，再继续分解，保持两份文件同步。
在工具层面，ONES的项目计划支持按目标、交付物或项目阶段等维度创建工作分解结构，并可为任务设置前后置依赖、用里程碑标记重要节点，适合把上述分解结果直接承载为可跟踪的计划结构。具体可用范围以实际部署与套餐为准。
角色分工与各环节交付物
确认与分解涉及多个角色，职责不清时容易出现“谁都看过、没人拍板”。下表按环节列出主责角色、配合角色和交接产物。
| 环节 | 主责角色 | 配合角色 | 交付物 | 交接时点 |
|---|---|---|---|---|
| 识别与定义可交付成果 | 项目经理 | 需求或业务负责人、技术负责人 | 可交付成果清单与定义表 | 确认会前 |
| 干系人确认 | 项目经理组织，验收人或业务负责人决策 | 技术负责人、质量负责人 | 确认记录、范围说明书成果段落 | 阶段启动前 |
| WBS分解 | 项目经理 | 技术负责人、各工作包责任人 | WBS层级结构 | 计划评审前 |
| WBS评审 | 技术负责人与质量或验收人 | 项目经理 | 评审意见、WBS字典 | 执行启动前 |
| 验收对照 | 验收人 | 工作包责任人 | 验收记录与成果编号对照 | 各成果完成时 |
决策角色需要单独说明：确认环节由有权接受成果的一方拍板，项目经理负责组织与记录，不代替验收人做结论。WBS评审环节由技术负责人判断分解是否完整、工作包是否可执行，质量或验收人判断验收标准是否可核验。两类意见都通过后，WBS才进入执行。
一个交付物落到WBS的完整示例
以下为演示情景，用于说明方法，不代表真实项目数据。某系统建设项目的一项阶段成果为“用户登录模块”。
定义阶段，成果编号定为D-01，类型为阶段成果，验收标准写为“通过登录、找回密码、异常提示三类用例测试，缺陷关闭率100%，接口文档齐全”，责任人为后端开发负责人，验收人为产品负责人与测试负责人，计划完成时间为6月30日。
确认阶段，项目经理组织评审会，产品、测试、后端三方参加。会议结论为有条件通过，条件是补充异常提示的文案规范；遗留项责任人为产品负责人，6月10日前完成，6月12日复核。确认记录编号CR-03，范围说明书同步更新。
分解阶段，以D-01为上层节点拆出四个工作包：D-01.1登录接口开发、D-01.2找回密码流程开发、D-01.3异常提示与文案实现、D-01.4接口文档编写。每个工作包均指定单一责任人，工期可估算，且能独立验收。
WBS字典中，D-01.3条目记录对应成果编号D-01、验收标准“异常提示覆盖三类用例且文案符合规范”、责任人前端开发负责人、估算工期5个工作日、前置依赖D-01.1。验收时按成果编号汇总四个工作包的完成情况，对照D-01的验收标准统一判定。
这个示例的可迁移规律有三点：成果编号贯穿清单、WBS与验收记录；确认环节的遗留项在分解前关闭；工作包粒度以可分配、可估算、可验收三条同时满足为准。
落实完成前的检查清单
进入执行前，用以下清单逐项核对。每项都能给出明确判断，不满足的项回到对应环节处理。
- 每项可交付成果均写有验收标准，且标准可由第三方判断是否达成。
- 每项可交付成果均指定单一责任人和明确的验收人。
- 每项可交付成果在WBS中至少对应一个工作包，无孤立成果。
- 每个工作包均可追溯到上层可交付成果编号，无来源不明的工作包。
- 每个工作包满足可分配单一责任人、可估算工期与成本、可独立验收三条标准。
- 确认记录齐全，包含结论、遗留项、责任人与复核时间，遗留项已关闭或有明确处理安排。
- 范围说明书中的成果段落与确认记录一致，WBS字典中的验收标准与范围说明书一致。
- 范围说明书与WBS为同一版本，版本号与更新时间可查。
- 关键里程碑已标记，里程碑与主要可交付成果的完成时间对应。
清单全部通过后，可交付成果的确认与WBS落实即告完成，项目可以进入执行与验收阶段。执行过程中如发生范围调整，按变更流程处理后再更新本清单涉及的文件版本。
常见问题
可交付成果在确认会上被“有条件通过”，还能继续分解到WBS吗？
可以继续准备分解，但不宜把带条件的成果直接当作已确认成果进入执行。建议把条件写成明确的遗留项，注明责任人、完成时间和复核时间，在分解前或分解早期关闭。若条件涉及验收标准本身，应先更新成果定义和范围说明书，再据此拆分工作包，避免工作包按旧标准设计、验收时又要返工。
WBS分解到一半发现漏了一项可交付成果，应该怎么处理？
按缺口类型回补到范围说明书层面处理：成果整体缺失的，补入可交付成果清单并走确认；验收标准不清的，回到定义环节细化；责任人不明的，先在角色分工中明确。回补完成后更新范围说明书版本，再继续分解，并同步修改WBS字典中的对应关系。这样能保持成果清单、范围说明书和WBS三者一致，避免在WBS里临时加条目造成范围与计划脱节。
工作包拆到什么程度算合适？有没有统一的层级数量要求？
判断标准是三条同时满足：可分配给单一责任人、工期与成本可估算、可独立验收。满足即可停止分解，不满足就继续下拆。层级数量随项目规模和成果复杂度变化，不必套用固定层数；关键是每个工作包都能对应到上层可交付成果，并在WBS字典中记录验收标准和责任人。
范围说明书和WBS在项目执行中如何保持版本一致？
把两份文件纳入同一套版本管理：每次确认或回补后更新范围说明书版本号与更新时间，WBS字典同步引用该版本；发生范围调整时按变更流程处理，审批通过后同时更新两份文件，并在检查清单中核对成果段落与WBS字典的验收标准是否一致。ONES支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，并通过对比版本细节追溯变更，可作为版本对照的辅助手段，具体可用范围以实际部署与套餐为准。
用ONES落地这套方法时，可交付成果清单和确认记录放在哪里？
现有资料说明了ONES在计划层面的能力：项目计划支持按目标、交付物或项目阶段等维度创建工作分解结构，任务可设置前后置依赖，里程碑可标记重要节点，适合承载分解结果和进度跟踪。可交付成果清单、确认记录与评审结论的具体承载方式，资料未作说明，建议结合团队现有文档与评审流程安排，并以实际部署环境确认可用功能。
