项目管理指南 · 规划与范围
工作分解结构(WBS):示例与创建方法
工作分解结构(WBS)是将项目的全部工作按层级分解为更小、更易于管理的交付物和工作包。它显示项目将产出什么,并成为估算、进度计划、预算和任务分配的基础。本指南介绍优秀 WBS 的规则、实例详解以及逐步创建 WBS 的方法。
要点总结
- WBS 将项目的全部范围分解为交付物,并在最底层分解为工作包。
- 100% 规则:WBS 包含全部范围且仅包含该范围,每一层的总和恰好等于其上层要素。
- 以交付物(名词)而非活动(动词)来命名要素;活动应放在进度计划中。
- 一直分解到每个工作包都可以估算、指定负责人并跟踪为止,通常为三到四层。
- WBS 词典描述每个要素,它与范围说明书一起构成范围基准。
- 与实际做事的人一起创建 WBS,然后用它来驱动进度计划和预算。
什么是工作分解结构(WBS)?
A 工作分解结构(WBS) 是以交付物为导向,将项目的全部范围按层级逐步分解为更小部分的结构。最顶层是整个项目;下面的每一层将其上层要素划分为组成部分,直到 工作包 ,可以对其进行估算、分配和跟踪。WBS 显示的是将交付*什么*,而不是何时交付或如何交付。
PMI 的 PMBOK 指南将 WBS 定义为对项目团队为实现项目目标、创建所需交付物而需要实施的全部工作范围的层级分解。在 PMI 的框架中,经批准的 范围说明书、WBS 和 WBS 词典共同构成 范围基准,它是衡量和控制范围的参照点。
这一技术起源于美国的大型国防和航天项目,美国国防部至今仍在维护一项 WBS 标准(MIL-STD-881)。PMI 也发布了专门的 *Practice Standard for Work Breakdown Structures*(工作分解结构实践标准)。不过,您不需要国防级规模的项目也能从中受益:对于小团队而言,在白板上画一个简单的三层 WBS 往往就足够了。
WBS 通常绘制成树状图(类似组织结构图),或写成带缩进和编号的大纲或表格。两者表达的是同一件事:整个项目被分解为若干部分,各部分加起来恰好等于整体。
WBS 为何重要
创建 WBS 只需几个小时,却能在整个项目过程中带来回报。它可以帮助您:
- 看清完整的范围。 分解工作可以暴露出原本会被遗忘的交付物,例如培训、数据迁移或文档。
- 更准确地估算。 小而定义明确的工作包远比整个项目容易估算。请参阅我们的指南: 成本估算.
- 明确责任归属。 每个工作包都有一个负责人,使问责一目了然。 RACI 矩阵 可以将角色与 WBS 要素对应起来。
- 制定进度计划和预算。 活动、工期和成本按工作包进行规划,并通过 WBS 逐层汇总。
- 控制范围。 在 WBS 中找不到对应位置的工作,往往意味着出现了 范围蔓延.
- 识别风险。 逐一审视每个要素,是一种结构化地追问“这里可能出什么问题?”的方法。
- 沟通。 一页纸的 WBS 图让发起人和团队对项目包含的内容有共同的认识。
WBS 是项目管理计划的核心部分:进度计划、成本基准和资源计划都围绕它来组织。
优秀 WBS 的关键规则
100% 规则
100% 规则 是最重要的原则。WBS 包含项目范围所定义的 100% 的工作,包括项目管理工作,且不包含范围之外的任何内容。它适用于每一层:任何要素的下层要素加起来必须恰好等于该要素 100% 的工作,不多也不少。如果某个下层要素包含不属于其上层要素的工作,那就超出了范围;如果下层要素没有涵盖上层要素的全部工作,那就有遗漏。
交付物,而非活动
将 WBS 要素命名为描述成果的 名词 (如“支付集成”“用户指南”“会场”),而不是描述行动的动词(如“集成支付”“编写指南”“预订会场”)。以交付物为导向的要素更便于检查完整性和定义验收标准。产出每个工作包所需的活动将在之后的进度计划中列出。
要素相互排斥
任何一项工作都不应出现在两个地方。重叠会导致估算重复计算、责任归属混乱,以及在谁做什么的问题上产生争执。
分解到合适的层级
当工作包小到可以可靠地估算、分配给一位负责人并进行跟踪时,就停止分解;但也不要小到管理它比完成它还费力。常见的经验法则(并非正式标准)包括:
- 8/80 规则: 一个工作包的工作量应大约在 8 到 80 小时之间。
- 报告周期规则: 一个工作包不应跨越超过一到两个报告周期,以便进展清晰可见。
- “合理即可”规则: 只有在能改善估算、分配或控制时才进一步分解。
大多数项目需要三到四层。大型项目集可能需要更多层级,而小型项目可能只需要两层。
每个工作包只有一个负责人
每个工作包都应有一位唯一的责任人,即使有多人参与。共同负责通常意味着无人负责。
WBS 层级与组成部分
WBS 层级从顶层开始编号。各组织使用的具体标签不尽相同,但典型结构如下:
| 级别 | 包含内容 | 示例(客户门户) |
|---|---|---|
| 1 | 项目或最终交付物 | 1 客户门户 |
| 2 | 主要交付物或阶段 | 1.3 设计;1.4 构建;1.5 测试 |
| 3 | 子交付物 | 1.4.1 前端;1.4.2 后端;1.4.3 集成 |
| 4 | 工作包(最底层) | 1.4.3.1 支付服务商集成 |
活动和任务位于工作包之下,但它们属于 项目进度计划 ,而不是 WBS 本身。我们关于 项目任务和活动 的指南解释了其中的区别。
您还会遇到的其他组成部分:
- WBS 编码: 一种编号方案(1、1.1、1.1.1),为每个要素提供唯一标识,并显示其在层级结构中的位置。编码将 WBS 与进度计划、预算和工时记录联系起来。
- 工作包: WBS 的最底层,在这一层估算工作量、成本和工期并分配工作。请参阅我们的 工作包指南.
- 控制账户: 位于工作包之上的管理控制点,在此对范围、预算和实际成本进行比较,通常配合使用的方法是 挣值管理.
- 规划包: 用于占位的工作,已知属于范围之内,但尚未细化到足以分解为工作包的程度。
- WBS 词典: 详细描述每个要素的配套文件(见下文)。
工作包是计划变为实际工作的地方。
工作分解结构的类型
主要的选择在于如何组织第 2 层。两种最常见的方法是基于交付物和基于阶段。
| 基于交付物的 WBS | 基于阶段的 WBS | |
|---|---|---|
| 第 2 层的组织依据 | 主要产出(设计、构建、培训) | 项目阶段(启动、规划、执行、收尾) |
| 优势 | 便于检查范围和 100% 规则;产出的责任归属清晰 | 契合顺序式生命周期和阶段关口审批;相关方较为熟悉 |
| 需要注意 | 可能掩盖先后顺序;需要依靠进度计划来显示顺序 | 交付物可能被拆分到不同阶段,造成重叠 |
| 适合人群 | 大多数项目,尤其是产品、IT 和建筑项目 | 设有正式阶段评审的瀑布式项目 |
许多团队采用混合方式:第 2 层为阶段,第 3 层为交付物。无论选择哪种方式,都要在每一层保持一致。其他组织方式还包括按地点(场地或建筑物)、按子系统(工程)或按组织单位划分,不过按部门划分往往会削弱对交付物的关注。
同一个 WBS 可以用多种格式呈现:
- 树状图: 最适合向发起人和团队展示前三层。
- 大纲: 带缩进和编号的列表;创建和编辑都很快捷。
- 表格或电子表格: 每个要素占一行,包含编码、负责人、工作量和成本;非常适合展示细节和汇总。
- 在进度计划工具中: WBS 成为以下视图中的摘要任务结构: 甘特图.
工作分解结构示例
以下示例展示了同样的原则如何应用于不同类型的项目。请以此为起点,并根据您自己的范围调整各要素。
示例 1:客户门户(基于交付物)
| WBS 编码 | 要素 | 说明 |
|---|---|---|
| 1 | 客户门户 | 第 1 层:整个项目 |
| 1.1 | 项目管理 | 计划、状态报告、风险管理、收尾 |
| 1.2 | 需求 | 研讨会、已签核的需求文档 |
| 1.3 | 设计 | 1.3.1 用户体验设计;1.3.2 视觉设计;1.3.3 技术设计 |
| 1.4 | 构建 | 1.4.1 前端;1.4.2 后端;1.4.3 集成 |
| 1.5 | 测试 | 1.5.1 系统测试;1.5.2 用户验收测试 |
| 1.6 | 培训 | 面向支持人员的指南和培训课程 |
| 1.7 | 部署 | 发布和上线后支持 |
这与我们免费的 WBS 模板中的示例相同,在该模板中,为每个要素输入的工作量和成本会汇总为项目总计。
示例 2:同一项目,基于阶段
| WBS 编码 | 要素 |
|---|---|
| 1 | 客户门户 |
| 1.1 | 启动:商业论证、章程 |
| 1.2 | 规划:需求、计划、预算 |
| 1.3 | 执行:设计、构建、测试、培训 |
| 1.4 | 部署:发布、支持移交 |
| 1.5 | 收尾:验收、经验教训 |
基于阶段的版本更便于阶段关口评审,但请注意,主要交付物都隐藏在“执行”之中。您需要再增加一层才能让它们显现出来。
示例 3:办公室搬迁
| WBS 编码 | 要素 |
|---|---|
| 1 | 办公室搬迁 |
| 1.1 | 项目管理 |
| 1.2 | 新场所:租约、装修、家具 |
| 1.3 | IT 和电信:网络、工位和设备、电话 |
| 1.4 | 搬迁后勤:搬运、打包、仓储 |
| 1.5 | 人员和沟通:员工情况介绍、平面布置图、新办公地点指南 |
| 1.6 | 撤离旧场所:清理、维修、交还 |
请注意 1.6 中这个容易被遗忘的交付物。撤离旧场所是有实际成本的实际工作,WBS 能让它尽早显现出来。
示例 4:会议
| WBS 编码 | 要素 |
|---|---|
| 1 | 年度会议 |
| 1.1 | 项目管理 |
| 1.2 | 会场和餐饮 |
| 1.3 | 议程安排:演讲嘉宾、日程、会议资料 |
| 1.4 | 营销与报名 |
| 1.5 | 参会者体验:胸牌、指示标识、应用 |
| 1.6 | 音视频和直播 |
| 1.7 | 会后工作:调查、报告、内容 |
如何创建工作分解结构
按照以下步骤,可以为任何项目创建 WBS。小型项目可以在一次研讨会中完成;较大的项目可能需要多次会议。
- 从已批准的范围出发。 收集 项目章程、范围说明书、需求以及任何合同或工作说明书。尚未定义的范围是无法分解的。
- 定义第 1 层。 在顶层写下项目的最终交付物或项目名称。
- 选择第 2 层的组织方式。 在主要交付物和阶段之间做出选择(见上文),并加入项目管理分支。
- 分解每个要素。 将每个第 2 层要素分解为其组成 可交付成果。要问“它由什么组成?”,而不是“我们需要做什么?”
- 分解到工作包为止。 持续分解,直到每个最底层要素都可以估算、分配给一位负责人,并在一个报告周期内进行跟踪。
- 应用 100% 规则。 检查每个上层要素的下层要素是否涵盖其全部工作且不多出任何内容。查找缺漏和重叠。
- 为要素编号。 为每个要素分配唯一的 WBS 编码,以便在进度计划、预算和报告中引用。
- 编写 WBS 词典。 描述每个工作包:范围、交付物、验收标准、负责人、假设和估算。
- 与团队和相关方一起评审。 实际做事的人能发现遗漏的要素和不切实际的拆分;相关方则确认没有超出范围的内容。
- 确立基准并持续维护。 一经批准,WBS 就成为范围基准的一部分。此后只能通过以下方式更新: 变更控制.
WBS 词典
A WBS 词典 是 WBS 的配套文件。WBS 显示结构;词典则解释每个要素,让每个人都确切了解其中包含的内容。它对工作包尤其有用,相当于给负责人的一份简要任务说明。
词典条目通常包括:
- WBS 编码和要素名称。
- 工作描述,以及包含和排除的内容。
- 可交付成果和验收标准。
- 负责人(负责的个人或组织)。
- 工作量、成本和工期估算。
- 关键里程碑和依赖关系。
- 假设、制约因素和已知风险。
- 资源、质量要求和参考资料。
词典条目示例
| 字段 | 入门级 |
|---|---|
| WBS 编码 | 1.4.3.1 |
| 要素 | 支付服务商集成 |
| 描述 | 将门户的结账功能连接到支付服务商的 API,包括银行卡支付和退款。不包括直接借记。 |
| 验收标准 | 测试支付和退款在沙盒环境中成功;通过安全审查 |
| 负责人 | 技术负责人 |
| 估算 | 10 天工作量 |
| 依赖关系 | 1.3.3 技术设计已获批准;服务商账户已开通 |
| 假设条件 | 服务商沙盒环境从第 6 周起可用 |
对于较大的工作包,您可以将条目扩展为完整的工作包描述,可使用我们的 工作包模板.
从 WBS 到进度计划和预算
WBS 不是进度计划,但它是进度计划的输入。WBS 商定后:
- 列出产出每个工作包所需的活动。
- 识别 任务依赖关系 ,明确各活动之间的先后关系。
- 估算工期和工作量;我们的 工作量估算指南 介绍了主要技术。
- 制定进度计划,找出 关键路径 ,并添加 里程碑.
- 估算每个工作包的成本,并将其汇总为 项目预算.
弄清楚哪份文件回答哪个问题会很有帮助:
| 文档 | 回答的问题 | 包含内容 |
|---|---|---|
| WBS | 我们将交付什么? | 交付物和工作包的层级结构 |
| WBS 词典 | 每个要素具体包含什么? | 描述、负责人、标准、估算 |
| 进度 | 何时进行,按什么顺序? | 活动、依赖关系、工期、日期 |
| 甘特图 | 进度计划随时间推移是什么样子? | 时间线上的横条,通常按 WBS 分组 |
| 产品待办事项列表 | 接下来构建什么最有价值? | 史诗、特性和故事的有序列表 |
制定进度计划是完成 WBS 之后的自然下一步。
在敏捷项目中使用 WBS
《Scrum 指南》没有提及 WBS,敏捷团队通常改为基于有序的 产品待办事项列表 开展工作。不过,其背后的理念,即把大的成果分解为更小的价值单元,仍然是敏捷中非常重要的一部分。
根据我们的经验,由主题、 史诗、特性和用户故事组成的待办事项层级结构,所起的作用与基于交付物的 WBS 类似,但有两个关键区别:它按价值排序,而不是为完整性而构建;并且预期会随着团队的学习而变化。
一个轻量级的高层级 WBS 仍然可以帮助敏捷和混合型项目:
- 在第一个冲刺之前与发起人商定总体范围和预算。
- 展示可能不会出现在待办事项列表中的非软件交付物,例如培训、数据迁移或采购。
- 支持滚动式规划:近期工作被详细分解,后期工作则保留为规划包。
- 将敏捷团队整合到依据 WBS 进行报告的更大项目集中。
常见的 WBS 错误
| 错误 | 重要性 | 解决方法 |
|---|---|---|
| 列出活动而非交付物 | WBS 变成了任务清单,缺漏难以发现 | 将要素改用名词命名;把活动移到进度计划中 |
| 遗漏项目管理工作 | 违反 100% 规则;估算偏低 | 在第 2 层加入项目管理分支 |
| 过度分解 | 跟踪的开销超过了工作本身 | 当工作包可以估算并指定负责人时即停止分解 |
| 分解不足 | 估算只是猜测;进展无法看到 | 将大的工作包分解到能在一个报告周期内完成 |
| 要素重叠 | 工作量被重复计算,责任归属混乱 | 将同级要素相互比对,检查是否重复 |
| 包含超出范围的工作 | 从第一天起就隐藏着范围蔓延 | 对照范围说明书检查每个要素 |
| 独自创建 WBS | 遗漏工作,团队认同度低 | 与实际做事的人一起召开研讨会 |
| 从不更新 | 计划逐渐脱离实际 | 范围变化时通过变更控制进行更新 |
WBS 模板和工具
我们的免费 工作分解结构模板 提供 Google Sheets、Excel 和 PDF 格式。它包含 WBS 编码、层级、交付物或工作包、描述、负责人、工作量(天)、成本和状态等列,工作量和成本会汇总为项目总计。可搭配 项目成本估算模板 进行详细的成本核算,并使用 甘特图模板 将工作包转化为进度计划。
大多数项目管理软件都可以通过嵌套任务或带自动编号的摘要任务来承载 WBS,从而使 WBS 与进度计划保持同步。我们关于 甘特图软件 以及我们的 项目管理软件排名 的指南比较了各种选项。
本主题的免费模板
常见问题
简单来说,什么是工作分解结构?
工作分解结构就像一棵家谱树,涵盖项目必须交付的一切:整个项目位于顶部,被分解成越来越小的部分,直到每个部分都可以估算和分配。
WBS 有哪些层级?
第 1 层是项目,第 2 层是主要交付物或阶段,第 3 层是子交付物,最底层是工作包。大多数项目需要三到四层。
WBS 中的 100% 规则是什么?
WBS 必须包含项目范围内的全部工作,包括项目管理,且不包含范围之外的任何内容。在每一层,下层要素加起来必须恰好等于其上层要素 100% 的工作。
什么是 8/80 规则?
这是一条经验法则:一个工作包的工作量应大约在 8 到 80 小时之间。它是关于合适详细程度的指导原则,而不是正式标准。
WBS 中的工作包是什么?
工作包是 WBS 的最底层:一项有明确定义、只有一位负责人、可以估算、排期和跟踪的工作。
什么是 WBS 词典?
WBS 词典是详细描述每个 WBS 要素的文件,包括范围、交付物、验收标准、负责人、估算、依赖关系和假设。
WBS 应该使用名词还是动词?
用名词。WBS 要素描述的是交付物(产出什么),而动词描述的是活动,活动应放在进度计划中。
WBS 和甘特图有什么区别?
WBS 以层级结构显示将交付什么。甘特图在时间线上显示工作何时进行。甘特图通常按照 WBS 来组织。
WBS 和项目进度计划是一回事吗?
不是。WBS 定义范围;进度计划则加入交付该范围所需的活动、依赖关系、工期和日期。
应该何时创建 WBS?
在规划阶段,范围说明书商定之后,制定进度计划、预算和资源计划之前。
由谁创建 WBS?
由项目经理牵头,与将要开展工作的团队成员和领域专家一起完成。
WBS 如何编号?
使用层级编码:项目为 1,第 2 层为 1.1 和 1.2,第 3 层为 1.1.1,依此类推。每个编码都是唯一的,并显示要素所在的位置。
敏捷项目使用 WBS 吗?
通常不使用传统形式的 WBS。由史诗、特性和故事组成的待办事项列表起着类似的作用,不过一个轻量级的高层级 WBS 有助于编制预算和管理混合型项目。
WBS 在项目期间可以更改吗?
可以,但一旦确立基准,就只能通过正式的变更控制进行更改,并相应更新范围说明书、进度计划和预算。