WBS 是什么：以可交付物为导向，把范围拆到 100% 不多不少
工作分解结构（Work Breakdown Structure, WBS）是『以可交付物为导向、对项目工作做的层级化分解』——项目团队为达成目标、产出所需交付物要做的全部工作，按层级拆开，越往下层定义越细。
它是范围管理的核心产物：先有 WBS（说清『要做出哪些东西』），才谈得上排期、估成本、派活、控风险。WBS 起源于美国国防部的项目实践（后形成 MIL-STD-881 标准），现由 PMI《WBS 实践标准》推广到通用领域。
怎么拆：拆成果不拆动作，停在能估能控的工作包（8/80）
遵守 100% 规则的最好办法，是把 WBS 的每个元素定义成结果/可交付物（名词），而不是动作/活动（动词）。在 WBS 语境里，『工作』指的是努力产出的工作产物/交付物，不是努力本身。
例：写『已通过验收的登录模块』（成果），而不是『开发登录功能』（动作）。原因：成果有边界、可验收，按成果拆能稳稳套住 100% 规则；按动作拆容易越列越发散、还和排期混淆。记住：WBS 回答『要交付什么（what）』，活动排序与时间（how/when）是后面排期（如 CPM）的事。
分解到哪层算够？停在工作包（work package）——WBS 的最底层元素。PMI 定义：工作包是『可对其成本与工期进行估算和管理的最低层 WBS 组件』。拆到每个工作包能可靠估出工期与成本、能指派给一个责任人、能被监控就够了——再细就是微观管理、徒增管理开销。
业界常用的经验法则是『8/80 规则』：一个工作包的工作量大致落在 8 到 80 小时（约一天到两周）较合适——太大（超过 80 小时）估不准、藏风险；太小（不足 8 小时）管理成本盖过价值。对暂时看不清的远期工作，可先粗拆、待临近再细化（滚动式规划）。
WBS 不是任务清单/甘特图/组织图：配上字典，五步搭出范围基线
三个常见混淆，一次说清：
- ① 『WBS = 待办任务清单』——错。WBS 是按可交付物做的范围分解（成果），不是排好序的动作列表。
- ② 『WBS = 甘特图/进度表』——错。WBS 不含时间与先后顺序；它是排期的输入：先有 WBS 定清范围，再从工作包推出活动、排依赖、用 CPM 算关键路径。
- ③ 『WBS = 组织架构图』——错。WBS 分解的是『工作/交付物』，不是『部门/人』（后者是 OBS 组织分解结构）。
一句话：WBS 管『要做出什么』，排期管『何时按何序做』，组织图管『谁来做』，三者别混。
配合 WBS 的还有 WBS 字典：为每个 WBS 元素登记范围说明、交付物、负责人、验收标准、关联的进度/成本等，避免大家对『这块到底包含啥』理解不一。WBS 的核心价值是当范围基线——把模糊的『做个项目』变成一张穷尽且不重叠的交付物清单；一条实用心法：『不在 WBS 里的工作，就不属于这个项目』——既挡住临时塞进来的范围蔓延，也逼你开工前把该做的都列全、防止漏项。
搭一个 WBS 的五步：① 从最终交付物/目标出发，列出主要可交付物（第 2 层）；② 把每个主交付物拆成子交付物（成果、名词，别写成动作）；③ 继续向下分解，直到每块都是能估能派能控的工作包（参考 8/80 小时）；④ 逐层校验 100% 规则——子节点之和 = 父节点、且无范围外内容；⑤ 给每个元素编 WBS 编码、写进 WBS 字典（范围/负责人/验收标准）。完成后，这份 WBS 就是排期（CPM）、估算、风险与责任分派的统一起点。
自测 · 学完检查一下
想真正动手做题、记进度、攒连胜？到互动课里练。
什么是工作分解结构（WBS）？
答案：以可交付物为导向、对项目工作做的层级化分解——把产出所需交付物要做的全部工作按层级拆开，越往下层定义越细
WBS 的定义是『以可交付物为导向、对项目工作做的层级化分解』：项目团队为达成目标、产出所需交付物要做的全部工作，按层级拆开，越往下层定义越细。它是范围管理的核心产物——先有 WBS 说清『要做出哪些东西』，才谈得上排期、估成本、派活、控风险；它不是进度网络图（那是排期的事）、不是组织架构图（那是 OBS）、也不是待办任务清单。WBS 起源于美国国防部项目实践（后形成 MIL-STD-881 标准），由 PMI《WBS 实践标准》推广到通用领域。（出处：PMI《WBS 实践标准》；PMBOK Guide — Create WBS；Wikipedia — Work Breakdown Structure）
关于 WBS 的『100% 规则』，下面哪个说法是对的？
答案：WBS 必须涵盖项目范围的全部工作（连项目管理工作本身也算进去），且不能包含范围之外的任何工作；这条规则在每一层都成立——子节点之和正好等于父节点的 100%
100% 规则是 WBS 最重要的原则：WBS 必须涵盖项目范围定义的全部工作——所有交付物（对外、对内、阶段性），连项目管理工作本身也算进去；同时不能包含范围之外的任何工作。而且它在每一层都成立：父节点下所有子节点加起来要正好等于父节点的 100%，不多不少——加起来不到 100% 就有活没人认领（漏项），超过 100% 就在做没要求的事（镀金/范围蔓延）。它管的是『范围』，不是人力分配，也不是工期覆盖。（出处：Gregory Haugan / workbreakdownstructure.com 'The 100% Rule'；Wikipedia — WBS（100% rule 在每层都适用）；PMBOK Guide）
判断：校验 WBS 时，某个父节点下的子节点加起来只要『不超过』父节点的 100% 就算合格——少一点没关系，说明拆得保守。
答案：错误
错误。100% 规则要求子节点之和正好等于父节点的 100%，不多也不少：加起来不到 100%，意味着有活没人认领——范围出现缺口（漏项）；超过 100%，则在做范围没要求的事（镀金/范围蔓延）。所以搭 WBS 的步骤里专门有一步『逐层校验 100% 规则』：每一层都要验证子节点之和等于父节点、且无范围外内容。（出处：workbreakdownstructure.com 'The 100% Rule'；PMI《WBS 实践标准》——构建步骤与质量校验）
给电商项目搭 WBS 时，下面哪个元素的写法最符合 WBS 的约定？
答案：已通过验收的支付模块
WBS 的每个元素应定义成结果/可交付物（名词），而不是动作/活动（动词）——在 WBS 语境里，『工作』指的是努力产出的工作产物/交付物，不是努力本身。『已通过验收的支付模块』是有边界、可验收的成果；『开发…』『召开…』『优化…』都是动作，按动作拆容易越列越发散、还和排期混淆。把每个元素写成成果，正是遵守 100% 规则的最好办法：WBS 回答『要交付什么（what）』，活动排序与时间（how/when）是后面排期（如 CPM）的事。（出处：PMI《WBS 实践标准》（deliverable-oriented，非 action）；Wikipedia — WBS）
WBS 应该分解到哪一层为止？
答案：拆到工作包——『可对其成本与工期进行估算和管理的最低层 WBS 组件』：能可靠估出工期成本、能指派给一个责任人、能被监控就停
工作包（work package）是 WBS 的最底层元素，PMI 定义为『可对其成本与工期进行估算和管理的最低层 WBS 组件』。分解停的标准是『能估能控』：每个工作包能可靠估出工期与成本、能指派给一个责任人、能被监控就够了——再细就是微观管理、徒增管理开销；也没有『必须拆几层』的硬性规定。工作包是连接『范围』与『执行』的接口：往上滚动汇总成更大的交付物，往下对应具体的活动与进度。（出处：PMBOK Guide — Work Package 定义（可估算/管理成本与工期的最低层）；Wikipedia — WBS）
判断：按 8/80 经验法则，一个工作包的工作量大致落在 8 到 80 小时（约一天到两周）比较合适；对暂时看不清的远期工作，可以先粗拆、待临近再细化（滚动式规划）。
答案：正确
正确。分解不是越细越好：停的标准是拆到每个工作包能可靠估算、能指派、能被监控。业界常用的 8/80 规则说，一个工作包的工作量大致落在 8 到 80 小时（约一天到两周）较合适——太大（超过 80 小时）估不准、藏风险；太小（不足 8 小时）管理成本盖过价值。对暂时看不清的远期工作，先粗拆、待临近再细化，这就是滚动式规划（rolling wave planning）。（出处：PMBOK Guide — Decomposition / 8-80 heuristic / Rolling Wave Planning；Wikipedia — WBS）
新来的项目经理把一份画好时间条和先后依赖的甘特图发给团队，说『这就是我们的 WBS』。下面哪句纠正是对的？
答案：不对——WBS 是按可交付物做的范围分解，不含时间与先后顺序；它是排期的输入：先有 WBS 定清范围，再从工作包推出活动、排依赖、用 CPM 算关键路径
WBS ≠ 甘特图/进度表：WBS 不含时间与先后顺序，它回答『要做出什么（what）』，排期回答『何时按何序做（when）』。正确顺序是先有 WBS 定清范围，再从工作包推出活动、排依赖、用 CPM 算关键路径——WBS 是排期的输入，不是排期本身。它也不是组织架构图（那是 OBS，管『谁来做』），更不是待办任务清单（WBS 拆的是成果，不是排好序的动作列表）。（出处：Wikipedia — WBS；PMBOK Guide — WBS 是范围基线、是排期与成本的基础（非进度表））
判断：WBS 本质上就是项目的组织架构图——把公司的部门和人套到项目上，一个部门一个分支。
答案：错误
错误。WBS 分解的对象是『工作/交付物』，不是『部门/人』——按部门和汇报关系画的是组织架构图，项目管理里对应的是 OBS（组织分解结构）。一句话分工：WBS 管『要做出什么』，排期管『何时按何序做』，组织图管『谁来做』，三者别混。（出处：Wikipedia — WBS（WBS≠组织架构图，后者是 OBS）；PMBOK Guide）
判断：『不在 WBS 里的工作，就不属于这个项目』——这条心法既能挡住临时塞进来的范围蔓延，也逼团队在开工前把该做的工作列全、防止漏项。
答案：正确
正确。WBS 的核心价值是当范围基线：把模糊的『做个项目』变成一张穷尽且不重叠的交付物清单，成为排期、估算、风险识别、责任分派的共同地基。『不在 WBS 里 = 不在项目里』因此两头起作用：有人想临时塞活进来，先问『它在 WBS 里吗』——挡住范围蔓延；反过来，它也逼你在开工前把该做的都列进 WBS，防止漏项。配套的 WBS 字典为每个元素登记范围说明、交付物、负责人、验收标准、关联的进度/成本，避免大家对『这块到底包含啥』理解不一。（出处：PMBOK Guide — WBS Dictionary / Scope Baseline；Wikipedia — WBS）
从零搭一个 WBS，下面哪个步骤顺序是对的？
答案：列出主要可交付物 → 拆成子交付物（成果、名词）→ 分解到能估能派能控的工作包（参考 8/80）→ 逐层校验 100% 规则 → 编码并写 WBS 字典
搭 WBS 的常规五步：① 从项目最终交付物/目标出发，列出主要可交付物（第 2 层）；② 把每个主交付物拆成子交付物（成果、名词，别写成动作）；③ 继续向下分解，直到每块都是能估能派能控的工作包（参考 8/80 小时）；④ 逐层校验 100% 规则——子节点之和等于父节点、且无范围外内容；⑤ 编 WBS 编码、写进 WBS 字典（范围/负责人/验收标准）。方向是从范围到执行：先定『做什么』，排期（CPM）、估算、风险与责任分派都以这份 WBS 为统一起点——而不是反过来先排期、再把进度表抄成 WBS。（出处：PMI《WBS 实践标准》（构建步骤与质量校验）；PMBOK Guide）