create-work-breakdown-structure

创建工作分解结构

将项目范围分解为一组层级式工作包，以便进行估算、分配和跟踪。WBS 通过将复杂的可交付成果拆分为可管理的组成部分，为工作量估算、资源规划和进度制定奠定基础。

适用场景

• 项目章程获批且范围已定义之后
• 规划具有明确可交付成果的传统／瀑布式项目
• 将大型计划拆分为可管理的工作包
• 为工作量估算和资源规划建立依据
• 对所有必需工作形成共同理解

输入

• 必需：已批准的项目章程（尤其是范围和可交付成果部分）
• 必需：项目方法论（传统／瀑布式，或在规划中采用 WBS 的混合式方法）
• 可选：类似项目的历史工作量数据
• 可选：团队组成和可用技能
• 可选：组织的 WBS 模板或标准

流程

步骤 1：从章程中提取可交付成果

阅读项目章程。列出所有可交付成果和验收标准。将它们分为 3-7 个顶层类别（这些将成为 WBS 第 1 级元素）。

**预期结果：**与章程中的可交付成果相匹配的 WBS 第 1 级元素列表。

**失败时：**如果章程内容含糊，请返回 draft-project-charter 以完善范围。

步骤 2：分解为工作包

将每个第 1 级元素分解为子元素（第 2 级、第 3 级）。应用 100% 规则：子元素必须涵盖父元素范围的 100%。分解到工作包满足以下条件时停止：

• 可估算（可按人日分配工作量）
• 可分配（由一人或一个团队负责）
• 可衡量（有明确的完成／未完成标准）

创建 WBS 大纲：

# Work Breakdown Structure: [Project Name]
## Document ID: WBS-[PROJECT]-[YYYY]-[NNN]

### WBS Hierarchy

1. [Level 1: Deliverable Category A]
   1.1 [Level 2: Sub-deliverable]
      1.1.1 [Level 3: Work Package]
      1.1.2 [Level 3: Work Package]
   1.2 [Level 2: Sub-deliverable]
2. [Level 1: Deliverable Category B]
   2.1 [Level 2: Sub-deliverable]
3. [Level 1: Project Management]
   3.1 Planning
   3.2 Monitoring & Control
   3.3 Closure

应用 WBS 编码（1.1.1 格式）。确保最多深入 3-5 级。始终包含“项目管理”分支。

**预期结果：**完整的 WBS，包含 15-50 个工作包，且每个工作包都有唯一的 WBS 编码。

**失败时：**如果分解超过 5 级，说明范围过大——请考虑拆分为子项目。

步骤 3：编写 WBS 词典

为每个工作包（叶节点）编写词典条目：

# WBS Dictionary: [Project Name]
## Document ID: WBS-DICT-[PROJECT]-[YYYY]-[NNN]

### WBS 1.1.1: [Work Package Name]
- **Description**: What this work package produces
- **Acceptance Criteria**: How to verify it's done
- **Responsible**: Person or role
- **Estimated Effort**: [T-shirt size or person-days]
- **Dependencies**: WBS codes this depends on
- **Assumptions**: Key assumptions for this work package

### WBS 1.1.2: [Work Package Name]
...

**预期结果：**每个叶节点工作包都有对应的词典条目。

**失败时：**缺少词典条目表示分解不完整——请重新检查步骤 2。

步骤 4：估算工作量

为每个工作包应用一种估算方法：

• T 恤尺码估算（XS/S/M/L/XL），用于早期规划
• 人日，用于详细规划
• 三点估算（乐观／最可能／悲观），用于不确定性较高的工作

创建汇总表：

## Effort Summary
| WBS Code | Work Package | Estimate | Method | Confidence |
|----------|-------------|----------|--------|------------|
| 1.1.1 | [Name] | 5 pd | person-days | High |
| 1.1.2 | [Name] | M | t-shirt | Medium |

总工作量 = 所有工作包工作量之和。

**预期结果：**每个工作包都有工作量估算，并注明置信度。

**失败时：**如果置信度为低的工作包超过 30%，请安排 SME 参加完善会议。

步骤 5：识别依赖关系和关键路径候选项

梳理工作包之间的依赖关系：

## Dependencies
| WBS Code | Depends On | Type | Notes |
|----------|-----------|------|-------|
| 1.2.1 | 1.1.1 | Finish-to-Start | Output of 1.1.1 is input to 1.2.1 |
| 2.1.1 | 1.1.2 | Finish-to-Start | |

找出依赖工作包组成的最长链——这就是关键路径候选项。

**预期结果：**依赖关系表中至少标明完成到开始关系。

**失败时：**如果依赖关系形成循环，说明分解存在错误——请重新检查步骤 2。

步骤 6：评审并建立基准

将 WBS 和词典汇总为最终文档。核实每个层级都符合 100% 规则。取得利益相关者的签字确认。

**预期结果：**创建并评审 WBS.md 和 WBS-DICTIONARY.md 文件。

**失败时：**如果利益相关者发现范围遗漏，请添加工作包并重新估算。

验证

• 已创建包含文档 ID 和 WBS 编码的 WBS 文件
• 满足 100% 规则：每个层级的子项都完整体现父项范围
• 每个叶节点都有对应的 WBS 词典条目
• 所有工作包都有工作量估算
• 已识别依赖关系，且不存在循环引用
• 已包含项目管理分支
• 已识别关键路径候选项
• WBS 深度不超过 5 个层级

常见误区

• 混淆交付成果与活动：WBS 元素应使用名词（交付成果），而不是动词（活动）。应写“用户身份验证模块”，而不是“实施身份验证”。
• 违反 100% 规则：如果子项未涵盖父项 100% 的范围，就会遗漏工作。
• 层级太浅或太深：2 个层级对规划而言过于笼统；6 个及以上层级则属于事无巨细。建议采用 3–5 个层级。
• 跳过项目管理分支：项目管理工作（规划、会议、报告）也是实实在在的工作，需要投入工作量。
• 尚未分解就进行估算：应估算工作包，而不是类别。一级估算并不可靠。
• 没有词典：没有词典的 WBS 只是一棵标签树；词典则明确了完成标准。

相关技能

• draft-project-charter — 提供用于 WBS 分解的范围和交付成果
• manage-backlog — 将 WBS 工作包转化为待办事项，以便跟踪
• generate-status-report — 根据 WBS 完成百分比报告进度
• plan-sprint — 如果采用混合方法，则根据 WBS 工作包制定冲刺计划
• conduct-retrospective — 审查估算准确性和分解质量