# 用 WBS 把定好的范围，拆成能派出去的活

交付物导向、100% 规则，以及拆到什么粒度算够

> 范围与目标 · 任务拆解 · 约 7 分钟 · 10 月 02 日

## 本篇要点

1. WBS 是以交付物为导向、对项目范围的层级分解，目标是把范围切到最后能估工时、能派给一个责任人、能检查结果的工作包。
2. 判断自己有没有拆对，最直接的办法是看每个元素能不能补一句“交出来的是什么”；只能描述动作的名字，通常不是合格的 WBS 元素。
3. 100% 规则要求整个结构覆盖范围内的全部工作，且任何一层的子项加起来正好等于父项：它同时防漏和防重，项目管理本身的工作也必须占一格。
4. 100% 规则还有数量用法：给项目记 100 分往下按相对工作量分配，既能看出哪块最重，也能事后核对是否还是 100。
5. 第一层可以按产品构成拆，也可以按阶段拆，但同一层不能两种逻辑混用；多数项目三四个层次就够管了。
6. 工作包的三个条件是能估算、能派给单一责任人、有可衡量的产出；任何一条做不到就说明还得往下拆。
7. 8/80 规则（工作包 8 到 80 小时）是实务经验值，不是 PMI 的强制要求；更实用的两把尺子是“估不出来就继续拆”和“别让工作包比你开会的节奏还长”。
8. WBS 只管有什么活，日期和依赖属于进度表；外包出去的那一整块通常停在工作包层级，由承包方自己继续拆。

---

上一篇把范围收成了一页纸：为什么做、要交出哪几样东西、每样凭什么算合格。但那张纸还不能直接拿来干活。“把客服系统换掉”这个交付物，没有人能靠它开工——派给谁？多久能干完？干到什么程度算这一步结束了？

把交付物往下切，切到每一块都能估工时、能交给一个明确的人、能检查结果，这件事的做法叫 **WBS（work breakdown structure，工作分解结构）**。这篇就讲它：怎么拆、拆到多细算够、怎么知道没漏也没重。

## 一、拆的是“东西”，不是“动作”

先看最常见的错误做法。接到项目后，很多人会列这样一张清单：调研供应商、开需求会、写迁移脚本、做数据测试、培训客服、上线切换。

这看起来就像一份计划，但它有个致命问题：它是一串动作，加不起来。你没法回答“这些加起来，是不是就够了”。漏掉“历史录音要不要处理”你看不出来，多塞进去一件“顺便优化一下话术”你也看不出来。

WBS 的做法反过来：**围着要交出去的东西往下分**。PMI 给的定义是“以交付物为导向的、对项目范围的层级分解”，每一层都是对上一层更细的定义，一直分到最低一层的**工作包** [1][2]。

同样是那个客服系统项目，交付物导向的拆法长这样：

- 1.0 新客服系统上线
  - 1.1 已批准的实施方案
  - 1.2 已迁移的工单数据
  - 1.3 已配置并切换的新系统
  - 1.4 能独立操作新系统的客服团队
  - 1.5 项目管理

每个名字后面都能补一句“交出来的是什么”，而不是“我们做了什么”。这就是判断自己有没有拆对的最简单办法：**给元素起名时，问一句“做完之后我能拿什么东西给人看”**。答不上来的，基本就是动作，还得往前找一层。

顺带说一句 1.5。写周报、开例会、记变更，这些不产出业务价值，但确实要花时间，必须占一格，否则你的工时汇总会天然偏少。PMI 的 100% 规则里明确写了，这个“100%”是包含项目管理工作的 [2]。

还要注意：WBS 只管“有什么活”，不管“先干哪个、几号干”。日期和前后依赖是进度表的事，硬塞进 WBS 会让两件事都说不清 [1]。

## 二、100% 规则：不漏，也不重

WBS 最核心的一条规矩叫 **100% 规则**：整个 WBS 包含范围里的 100% 工作，不多不少；而且任何一层往下拆，子项加起来必须正好等于父项——同样不能多，不能少 [2][3]。

这条规则同时管两件事。

**管“不漏”**：看上面那个例子，如果 1.2 只写“迁移脚本”，没写“抽查比对”，那 1.2 这个父项的 100% 就不成立——没有比对，你根本不知道数据迁移完了没有。检查方法是对着父项问一句：**下面这些子项全做完了，父项是不是就真的做出来了？** 缺了哪个子项父项就交不出来，那个子项就该在。

**管“不重”**：同一件事只能出现在一个分支里。如果 1.2 写“核对数据映射”，1.3 又写“确认字段对照关系”，这实际是同一份活，工期会被算两遍，责任也会扯皮。检查方法是横向念一遍相邻的工作包，问“这两个会不会是同一个人在做同一份东西”。

100% 规则还有一个数量上的用法。给整个项目记 100 分，往下按相对工作量分：假设数据迁移这块占 30 分，它的三个子项可以分成 5、15、10 分。这样你能一眼看出哪条腿最粗、最该盯；做完之后也能回头验证，所有工作包的分数加起来是不是还是 100 [2]。

## 三、怎么往下拆：两种常见的第一刀

第一层怎么切，通常有两种切法。

**按产品构成切**：适用于做的东西本身能分成几大块。比如“新客服系统”可以分成工单模块、知识库模块、报表模块。

**按阶段切**：适用于过程本身分几段。比如实施方案、数据迁移、上线切换、培训移交。

两种都可以，甚至可以混着用，但有一条底线：**同一层里不能两种逻辑混用**。如果 1.0 下面既有“数据迁移”（阶段）又有“工单模块”（部件），你很快会分不清某个工作包该挂在哪。混层是拆 WBS 时最容易返工的地方。

层数也不用多，多数项目三四个层次就够管了 [3]。

## 四、拆到多细算够：工作包的三个条件

拆到某一层之后，如果这块活同时满足下面三条，就可以停手了，它成为一个工作包：

1. **能估**：能比较有把握地说出要多少人、多少天、多少钱。PMI 对工作包的定义就是“最低一层、能够据以估算并管理成本和工期的工作” [3]。
2. **能派给一个人**：有清楚的责任人，而不是“大家一起干”。PMI 的说法是工作包要有单一的职责点 [1]。
3. **能检查**：干完以后有可衡量的产出，比如一份比对报告、一份考核记录。

反过来也成立：**哪一条做不到，就说明还得往下拆**。估算时心里没底，是最常见的信号。

拿 1.2 里的“迁移脚本”举例。“写一个把三年工单从旧库搬到新库的脚本”——这活交给一个工程师，他可能说三周，也可能说两个月，这个区间大到没法排期。那就继续拆：字段映射表、脚本主体、试跑与修复、正式迁移。拆到每一块你都能问出“这块大概两天还是五天”的时候，就到位了。

## 五、8/80 只是经验值，真正管用的是两个判断

项目管理圈里流传一条经验规则叫 **8/80 规则**：工作包的工时最好落在 8 到 80 小时之间，低于 8 小时太碎，管理成本比活本身还高；高于 80 小时又太大，估不准也追不动 [4][5]。

这条规则有用，但要说清它的身份：**它是实务里流行的经验值，不是 PMI 的强制要求** [4]。80 小时大致是一个人干两周，40 小时相当于一个人干一周——用它找感觉可以，拿它当尺子逐条量就没必要了。

真正能用来判断的手上有两把。

第一把是**估不出来就继续拆**。这比任何数字都直接：你需要的是能排期、能对比进度的粒度。一个工作包如果连干它的人自己都给不出范围，它就不合格。

第二把是**别让工作包比你开会的节奏还长**。如果你每周开一次进度会，工作包却要三周，那接下来三周你每周都只能听到“还在做”。把工作包切到一周上下的量级，每周的会上你才能听到“这块完了、那块卡住了”。

## 六、几个容易踩的坑

**按部门拆。** 第一层写成“技术部、业务部、客服部”。这画的是组织架构，不是活。分到部门名下之后，跨部门的那部分工作谁都不认。

**拆到动作就散架。** 就是前面那张待办清单。判断标准还是能不能加总：动作清单加起来不构成完整的项目范围 [1]。

**忘了外部件。** 交给供应商做的部分、中间产物（比如一份要领导签字的方案）、别人交给你之后你才能开工的东西，都算范围内的交付物，都要在树上有位置 [2]。

**以为所有工作包都得拆到同样细。** **外包出去的那一整块通常不必往下拆**——它在你这里就是一个工作包，具体怎么分由承包方自己的 WBS 决定 [5]。

拆完之后，还有一件配套的事：把这些工作包的边界、责任人、验收条件写下来，让不同的人看到“1.2.3”时想到的是同一件事。这部分叫 WBS 字典，是这些工作包真正能被管理起来的落点，留到下一篇细讲。

<details>
<summary>自检：下面几个 WBS 元素，问题出在哪</summary>

- “开三次需求评审会”：动作。改成“已签字确认的需求清单”，评审会只是产出它的过程。
- “系统模块”（和“数据迁移”并列）：换层了。前者是产品部件，后者是阶段，不能放在同一层。
- “编写用户手册”：能派、也有产出，但如果它旁边并列着一堆更小的事项，说明这一层拆得过细了，可以和相邻的小项合并成一个工作包。
</details>

## 术语表

- 工作分解结构（WBS）：把一个项目的全部范围，按“要交出的东西”一层层往下分，直到每块活都能估、能派、能查。
- 交付物导向：拆的时候围着“做出什么东西”分组，而不是围着“我们做了什么动作”分组；只有这样各层才能加得起来。
- 100% 规则：整个结构包含范围内的全部工作、且不包含范围外的工作；每一层子项加起来必须正好等于父项。
- 工作包（work package）：WBS 最底层的那一块活，能估算成本和工期、有唯一责任人、有可衡量的产出。
- 8/80 规则：一条实务经验值，建议工作包落在 8 到 80 小时之间，避免拆得太碎或太大；不是强制标准。

## 来源

1. [PMI Blog: What Is a Work Breakdown Structure (WBS)?](https://www.pmi.org/blog/work-breakdown-structure)
2. [PMI: Practice Standard for Work Breakdown Structures — 100% 规则的原始表述与 100 分示例](https://www.pmi.org/learning/library/practice-standard-work-breakdown-structures-8063)
3. [Wikipedia: Work breakdown structure — 工作包定义与分解层数](https://en.wikipedia.org/wiki/Work_breakdown_structure)
4. [ProjectEngineer: Create WBS — 自上而下/自下而上拆法与 8/80 规则](https://www.projectengineer.net/knowledge-areas/project-scope/create-wbs/)
5. [IT Project Management: Coordinating WBS Components — 工作包粒度与外包处理](https://flylib.com/books/en/4.274.1.46/1/)
6. [PMI: Practice Standard for Work Breakdown Structures, Third Edition](https://www.pmi.org/standards/work-breakdown-structures-third-edition)

---

原文：https://pangzhengboyin.com/articles/wbs-decompose-scope-into-work-packages-ae48b54e

> **庞征博引** · 想学的，慢慢都会
>
> 庞征博引是把想学的东西写成连载的 AI 学习工具。说出想学什么，它会先了解你的基础，再把主题写成一篇篇 5–10 分钟能读完的文章；边读边问，接下来学什么跟着你走。这篇就是这样写出来的。
>
> 开始你自己的连载 → https://pangzhengboyin.com