WBS模板由项目范围说明书和WBS分解表两部分组成：前者界定项目边界、可交付成果与验收条件，后者用层级编号把可交付成果逐层分解到工作包。填写时按“项目—阶段—可交付成果—工作包”展开，编号采用1、1.1、1.1.1形式，工作包作为分解终点，不再继续拆成任务。下面给出可直接复制的空白表、字段口径、必填判断和一个完整示例。
要点总览（TL;DR）
- WBS模板由项目范围说明书和WBS分解表两部分组成，前者界定边界与验收条件，后者承载层级结构与工作包信息。
- 层级按“项目—阶段—可交付成果—工作包”展开，编号采用1、1.1、1.1.1形式，工作包是分解终点，不再继续拆任务。
- 工作包必须填清交付物、验收标准、责任人和工期；交付物写产出什么，验收标准写什么状态可以关闭这一行。
- 层级编号、名称、类型、交付物、验收标准、责任人、工期为必填，前置依赖和备注按项目情况选填。
- 模板需按项目规模裁剪层级深度，并维护版本记录；范围变更时同步增删WBS对应行并检查编号与依赖引用。
可复制空白WBS模板表
模板分为两张表。第一张是项目范围说明书，用于在分解前把项目边界说清楚；第二张是WBS分解表，用于承载层级结构与工作包信息。两张表通过项目名称和可交付成果对应，建议放在同一份文档中连续填写。
表一：项目范围说明书
| 字段 | 填写内容 |
|---|---|
| 项目名称 | |
| 项目目标 | |
| 范围边界（包含什么） | |
| 可交付成果清单 | |
| 验收条件 | |
| 除外事项（明确不做什么） | |
| 假设与约束 |
表二：WBS分解表
| 层级编号 | 层级名称 | 层级类型 | 交付物 | 验收标准 | 责任人 | 工期 | 前置依赖 | 备注 |
|---|---|---|---|---|---|---|---|---|
| 1 | 项目 | — | ||||||
| 1.1 | 阶段 | |||||||
| 1.1.1 | 可交付成果 | |||||||
| 1.1.1.1 | 工作包 |
示例行仅用于说明编号递进关系，实际填写时按项目需要增减行数。若项目规模较小，可以省略“阶段”层，直接从项目分解到可交付成果，再落到工作包。
WBS字段说明与填写口径
字段口径统一后，不同人填出的WBS才能横向比较和汇总。以下逐列说明含义与常见写法。
| 字段 | 含义 | 填写口径 |
|---|---|---|
| 层级编号 | 标识该行在分解结构中的位置 | 采用1、1.1、1.1.1形式，父级编号加序号；同级编号连续，不跳号；新增行插在末尾并顺延后续编号 |
| 层级名称 | 该层级对应的对象名称 | 用名词或名词短语，如“需求确认”“首页设计稿”，避免写成动作句 |
| 层级类型 | 区分该行是阶段、可交付成果还是工作包 | 阶段用于划分项目大段落；可交付成果是可验收的中间产物；工作包是分解终点，能直接估算工期和指派责任人 |
| 交付物 | 该行完成后产出的具体物件 | 写“做出什么”，如文档、原型、代码包、验收报告，尽量可指认 |
| 验收标准 | 判断交付物合格的依据 | 写“做到什么程度算完成”，如评审通过、覆盖全部页面、缺陷数低于约定值 |
| 责任人 | 对该行结果负责的人 | 工作包填具体负责人；阶段和可交付成果可填牵头人，避免只写部门名 |
| 工期 | 完成该行所需时间 | 工作包填估算工期并注明单位（如人天、工作日）；上层工期由下层汇总，不单独估算 |
| 前置依赖 | 开始前必须先完成的事项 | 只填直接前置项的层级编号，如“1.1.1.1”；不写间接依赖，不写文字描述 |
| 备注 | 补充说明 | 记录假设、风险提示或待确认事项，保持简短 |
交付物与验收标准分列填写是这套模板的关键。交付物回答“产出什么”，验收标准回答“什么状态可以关闭这一行”。两者混写时，后续验收容易出现“东西交了但算不算完成”的争议。
层级类型的判断标准是“是否还需要继续向下分解”。阶段和可交付成果通常还要往下拆，工作包则应当可以直接安排执行、估算工期和指派责任人。工作包以下的任务拆解属于执行计划，放在排期或任务管理中处理，不进入WBS表。
必填与选填字段划分
必填字段保证WBS能被读懂、能用于排期和验收；选填字段按项目复杂度和团队习惯补充。判断依据是：缺少该字段是否会导致无法确认范围、无法指派或无法验收。
| 字段 | 必填/选填 | 理由与适用场景 |
|---|---|---|
| 层级编号 | 必填 | 没有编号无法建立层级关系和依赖引用 |
| 层级名称 | 必填 | 标识分解对象的基本信息 |
| 层级类型 | 必填 | 决定该行是否继续分解，也是判断工作包边界的依据 |
| 交付物 | 必填（工作包及以上） | 范围管理的核心对象，缺失则无法对应范围说明书 |
| 验收标准 | 必填（工作包） | 工作包是执行与验收的最小单元，必须有完成判据 |
| 责任人 | 必填（工作包） | 工作包需要明确到人才能安排执行；上层可暂填牵头人 |
| 工期 | 必填（工作包） | 排期的基础数据；上层由汇总得出 |
| 前置依赖 | 选填 | 存在先后顺序约束时填写；完全独立的工作包可留空或写“—” |
| 备注 | 选填 | 用于记录假设、风险或待确认事项，内容少时可省略 |
缺填时的处理方式：工作包的验收标准或责任人暂时无法确定，先在备注中标注“待确认”并写明确认时点，不要留空行直接进入排期；上层行的工期留空即可，由下层汇总填充。范围说明书中的除外事项如果一时列不全，至少写出已知的边界外内容，避免后续范围蔓延。
完整填写示例：一个网站改版项目
以下示例为演示情景，用于说明范围说明书与WBS表如何对应填写，字段与前述模板保持一致。
范围说明书填写示例
| 字段 | 填写内容 |
|---|---|
| 项目名称 | 公司官网改版 |
| 项目目标 | 完成官网视觉与信息架构改版，上线后可正常访问并支持内容自主更新 |
| 范围边界 | 首页、产品页、关于页的视觉设计与前端实现；内容管理后台的栏目配置 |
| 可交付成果清单 | 改版设计方案、前端页面、内容管理后台配置、上线验收报告 |
| 验收条件 | 设计稿评审通过；页面在主流浏览器显示正常；后台可完成栏目增删改；验收报告经项目负责人签字 |
| 除外事项 | 不包含服务器迁移、不包含多语言版本、不包含历史文章内容重写 |
| 假设与约束 | 假设现有服务器可承载新页面；约束为上线时间不晚于季度末 |
WBS三层分解示例
| 层级编号 | 层级名称 | 层级类型 | 交付物 | 验收标准 | 责任人 | 工期 | 前置依赖 | 备注 |
|---|---|---|---|---|---|---|---|---|
| 1 | 官网改版 | 项目 | 改版后官网上线 | 验收报告签字 | 项目经理 | 汇总 | — | |
| 1.1 | 设计阶段 | 阶段 | 设计方案 | 评审通过 | 设计负责人 | 汇总 | — | |
| 1.1.1 | 视觉设计 | 可交付成果 | 首页与内页设计稿 | 评审通过 | 设计师 | 汇总 | — | |
| 1.1.1.1 | 首页设计稿 | 工作包 | 首页高保真设计稿 | 评审通过且覆盖全部模块 | 设计师A | 5个工作日 | — | 含两轮修改 |
| 1.1.1.2 | 产品页设计稿 | 工作包 | 产品页高保真设计稿 | 评审通过且与首页风格一致 | 设计师A | 4个工作日 | 1.1.1.1 | |
| 1.2 | 开发阶段 | 阶段 | 前端页面与后台配置 | 联调通过 | 开发负责人 | 汇总 | 1.1 | |
| 1.2.1 | 前端实现 | 可交付成果 | 可访问的页面 | 浏览器兼容测试通过 | 前端负责人 | 汇总 | 1.1.1 | |
| 1.2.1.1 | 首页前端开发 | 工作包 | 首页前端代码 | 与设计稿一致，主流浏览器显示正常 | 前端B | 6个工作日 | 1.1.1.1 | |
| 1.2.1.2 | 产品页前端开发 | 工作包 | 产品页前端代码 | 与设计稿一致，主流浏览器显示正常 | 前端B | 5个工作日 | 1.1.1.2 |
工作包字段逐项看：以“1.2.1.1 首页前端开发”为例，交付物是“首页前端代码”，验收标准是“与设计稿一致，主流浏览器显示正常”，责任人为前端B，工期6个工作日，前置依赖填“1.1.1.1”即首页设计稿完成。这一行可以直接进入排期，不需要再拆任务；具体切图、组件开发等动作在执行计划中安排。
范围说明书与WBS的对应关系体现在可交付成果清单上：清单中的“改版设计方案”对应1.1.1，“前端页面”对应1.2.1，“内容管理后台配置”可继续在1.2下新增可交付成果行。除外事项中的服务器迁移、多语言版本不出现在WBS中，这样两张表互相校验，避免漏项或超范围。
模板调整与维护方法
模板用起来之后，需要按项目类型裁剪字段、控制层级深度，并建立版本记录，否则不同项目的WBS会逐渐失去可比性。
- 按项目规模调整层级深度。规模小、需求稳定的项目可省略阶段层，按“项目—可交付成果—工作包”三层展开；跨部门、周期长的项目保留阶段层，工作包粒度控制在能在一到两周内完成的范围，便于跟踪。
- 字段增删的取舍原则。新增字段前先确认它是否影响范围确认、指派或验收；例如需要跟踪成本时可增加“预算”列，需要跟踪质量时可增加“检查方式”列。删除字段时保留编号、名称、类型、交付物、验收标准、责任人这六项，其余按项目情况取舍。
- 模板版本与变更记录。在模板文档开头维护版本号和变更说明，记录每次字段调整的原因和生效项目；团队共用一份模板时，指定一人负责合并修改，避免多份版本并行。
- 范围变更时同步更新WBS。范围说明书中的可交付成果或除外事项发生变化时，同步增删WBS对应行，重新检查编号连续性和前置依赖引用；已进入执行的工作包变更，在备注中记录变更原因和确认人。
当WBS需要多人协作填写和长期维护时，可以把范围说明书作为项目文档沉淀，把分解结构放到支持多层级工作项的工具中管理。ONES的项目计划支持按目标、交付物或项目阶段等维度创建工作分解结构并制定进度计划，任务可设置前后置依赖，里程碑用于标记重要时间点；从项目到任务的多层级管理可以让工作包进度自下而上反馈。范围说明书这类文档可放在ONES Wiki中，通过页面模板库建立制式模板，并保留页面版本以便查看和回滚。设置计划与里程碑基线后，还能对比计划与执行的偏差，追溯变更细节。这些能力适用于使用ONES瀑布项目管理解决方案的场景，具体层级深度和编号配置以实际产品为准。
常见问题
工作包拆到多细比较合适？
判断标准是这一行能否直接安排执行、估算工期并指派责任人。常见做法是把工作包控制在能在一到两周内完成的范围，便于跟踪进度。如果一行还需要继续向下拆才能安排执行，说明它仍是可交付成果而非工作包；如果拆得过细，WBS会退化成任务清单，排期和维护成本都会上升。具体粒度还受项目周期和不确定性影响，周期长、变更多的项目宜保留较细的工作包。
小项目可以省略阶段层吗？
可以。规模小、需求稳定的项目可按“项目—可交付成果—工作包”三层展开，省略阶段层，编号相应变为1、1.1、1.1.1。省略阶段层后，可交付成果直接挂在项目下，层级类型仍按阶段、可交付成果、工作包三类标注，便于与其他项目汇总比较。跨部门、周期长的项目建议保留阶段层，让不同阶段的责任和验收节点更清晰。
范围说明书里的可交付成果和WBS里的可交付成果如何对应？
范围说明书中的可交付成果清单是WBS分解的起点，清单中的每一项都应在WBS中找到对应的可交付成果行，再向下分解为工作包。示例中“改版设计方案”对应1.1.1，“前端页面”对应1.2.1。除外事项中列明的内容不出现在WBS中，两张表互相校验，可以检查是否漏项或超出范围。范围说明书新增可交付成果时，WBS同步增加对应行。
前置依赖只填编号，遇到跨阶段依赖怎么写？
前置依赖列只填直接前置项的层级编号，跨阶段依赖同样用编号表达，例如开发阶段的工作包依赖设计阶段某个工作包，就填该工作包的编号。间接依赖不逐条填写，由编号关系体现。如果依赖关系复杂、数量较多，可以在备注中补充说明，或改用专门的依赖关系图管理，WBS表保持简洁，避免文字描述混入编号列。
范围发生变更后，WBS需要整体重编吗？
不需要整体重编。范围说明书中的可交付成果或除外事项变化时，在WBS中增删对应行，新增行插在末尾并顺延后续编号，然后检查编号连续性和前置依赖引用是否仍然有效。已进入执行的工作包发生变更，在备注中记录变更原因和确认人。若变更涉及多个阶段或影响里程碑，建议先完成变更确认再更新WBS，避免执行中的计划反复调整。
