上一篇把范围收成了一页纸：为什么做、要交出哪几样东西、每样凭什么算合格。但那张纸还不能直接拿来干活。“把客服系统换掉”这个交付物，没有人能靠它开工——派给谁？多久能干完？干到什么程度算这一步结束了？
把交付物往下切，切到每一块都能估工时、能交给一个明确的人、能检查结果，这件事的做法叫 WBS（work breakdown structure，工作分解结构）。这篇就讲它：怎么拆、拆到多细算够、怎么知道没漏也没重。
一、拆的是“东西”，不是“动作”
先看最常见的错误做法。接到项目后，很多人会列这样一张清单：调研供应商、开需求会、写迁移脚本、做数据测试、培训客服、上线切换。
这看起来就像一份计划，但它有个致命问题：它是一串动作，加不起来。你没法回答“这些加起来，是不是就够了”。漏掉“历史录音要不要处理”你看不出来，多塞进去一件“顺便优化一下话术”你也看不出来。
WBS 的做法反过来：围着要交出去的东西往下分。PMI 给的定义是“以交付物为导向的、对项目范围的层级分解”，每一层都是对上一层更细的定义，一直分到最低一层的 工作包 12。
同样是那个客服系统项目，交付物导向的拆法长这样：
- 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% 工作，不多不少；而且任何一层往下拆，子项加起来必须正好等于父项——同样不能多，不能少 23。
这条规则同时管两件事。
管“不漏”：看上面那个例子，如果 1.2 只写“迁移脚本”，没写“抽查比对”，那 1.2 这个父项的 100% 就不成立——没有比对，你根本不知道数据迁移完了没有。检查方法是对着父项问一句：下面这些子项全做完了，父项是不是就真的做出来了？ 缺了哪个子项父项就交不出来，那个子项就该在。
管“不重”：同一件事只能出现在一个分支里。如果 1.2 写“核对数据映射”，1.3 又写“确认字段对照关系”，这实际是同一份活，工期会被算两遍，责任也会扯皮。检查方法是横向念一遍相邻的工作包，问“这两个会不会是同一个人在做同一份东西”。
100% 规则还有一个数量上的用法。给整个项目记 100 分，往下按相对工作量分：假设数据迁移这块占 30 分，它的三个子项可以分成 5、15、10 分。这样你能一眼看出哪条腿最粗、最该盯；做完之后也能回头验证，所有工作包的分数加起来是不是还是 100 2。
三、怎么往下拆：两种常见的第一刀
第一层怎么切，通常有两种切法。
按产品构成切：适用于做的东西本身能分成几大块。比如“新客服系统”可以分成工单模块、知识库模块、报表模块。
按阶段切：适用于过程本身分几段。比如实施方案、数据迁移、上线切换、培训移交。
两种都可以，甚至可以混着用，但有一条底线：同一层里不能两种逻辑混用。如果 1.0 下面既有“数据迁移”（阶段）又有“工单模块”（部件），你很快会分不清某个工作包该挂在哪。混层是拆 WBS 时最容易返工的地方。
层数也不用多，多数项目三四个层次就够管了 3。
四、拆到多细算够：工作包的三个条件
拆到某一层之后，如果这块活同时满足下面三条，就可以停手了，它成为一个工作包：
- 能估：能比较有把握地说出要多少人、多少天、多少钱。PMI 对工作包的定义就是“最低一层、能够据以估算并管理成本和工期的工作” 3。
- 能派给一个人：有清楚的责任人，而不是“大家一起干”。PMI 的说法是工作包要有单一的职责点 1。
- 能检查：干完以后有可衡量的产出，比如一份比对报告、一份考核记录。
反过来也成立：哪一条做不到，就说明还得往下拆。估算时心里没底，是最常见的信号。
拿 1.2 里的“迁移脚本”举例。“写一个把三年工单从旧库搬到新库的脚本”——这活交给一个工程师，他可能说三周，也可能说两个月，这个区间大到没法排期。那就继续拆：字段映射表、脚本主体、试跑与修复、正式迁移。拆到每一块你都能问出“这块大概两天还是五天”的时候，就到位了。
五、8/80 只是经验值，真正管用的是两个判断
项目管理圈里流传一条经验规则叫 8/80 规则：工作包的工时最好落在 8 到 80 小时之间，低于 8 小时太碎，管理成本比活本身还高；高于 80 小时又太大，估不准也追不动 45。
这条规则有用，但要说清它的身份：它是实务里流行的经验值，不是 PMI 的强制要求 4。80 小时大致是一个人干两周，40 小时相当于一个人干一周——用它找感觉可以，拿它当尺子逐条量就没必要了。
真正能用来判断的手上有两把。
第一把是 估不出来就继续拆。这比任何数字都直接：你需要的是能排期、能对比进度的粒度。一个工作包如果连干它的人自己都给不出范围，它就不合格。
第二把是 别让工作包比你开会的节奏还长。如果你每周开一次进度会，工作包却要三周，那接下来三周你每周都只能听到“还在做”。把工作包切到一周上下的量级，每周的会上你才能听到“这块完了、那块卡住了”。
六、几个容易踩的坑
按部门拆。 第一层写成“技术部、业务部、客服部”。这画的是组织架构，不是活。分到部门名下之后，跨部门的那部分工作谁都不认。
拆到动作就散架。 就是前面那张待办清单。判断标准还是能不能加总：动作清单加起来不构成完整的项目范围 1。
忘了外部件。 交给供应商做的部分、中间产物（比如一份要领导签字的方案）、别人交给你之后你才能开工的东西，都算范围内的交付物，都要在树上有位置 2。
以为所有工作包都得拆到同样细。 外包出去的那一整块通常不必往下拆——它在你这里就是一个工作包，具体怎么分由承包方自己的 WBS 决定 5。
拆完之后，还有一件配套的事：把这些工作包的边界、责任人、验收条件写下来，让不同的人看到“1.2.3”时想到的是同一件事。这部分叫 WBS 字典，是这些工作包真正能被管理起来的落点，留到下一篇细讲。
自检：下面几个 WBS 元素，问题出在哪
- “开三次需求评审会”：动作。改成“已签字确认的需求清单”，评审会只是产出它的过程。
- “系统模块”（和“数据迁移”并列）：换层了。前者是产品部件，后者是阶段，不能放在同一层。
- “编写用户手册”：能派、也有产出，但如果它旁边并列着一堆更小的事项，说明这一层拆得过细了，可以和相邻的小项合并成一个工作包。