《工作结构分解实操秘诀》

《pmbok》把与知识相关的具体情景剥离掉了，本书辅助还原一部分具体情景

范围变更是造成项目失败的第二大重要和常见原因

项目经理常用进度计划而不是工作结构分解来定义下项目。在范围尚不清楚的情况下，能可靠的估计成本、资源和时间吗

什么是WBS

《PMBOK指南》：WBS（“work breaddown structure”）是对项目团队为实现项目目标，创建可交付成果而需要实施的全部工作范围层级分解。WBS组织并定义了项目总范围；；“对所要交付的内容提供一个结构化视图”

WBS用于排列独特 有形 可验证和可测量的，可统称为可交付成果的产品 成果或服务

WBS旨在界定项目范围，随后将成为确定活动和编制项目进度计划的基础

使用WBS的好处：

1 有利于项目早期理解工作范围
2 有利于防止失控的变更
3 有利于交付期望的成果
4 有利于理解不太熟悉的领域
5 有利于区分内部和外部工作
6 有利于明确项目边界和复杂性
7 为项目变更控制提供基准
8 有利于分配和解释工作
9 促进项目规划
10 避免重新规划，尽早发现问题
11 为采购打下坚实的基础
12 改善沟通
13 促进干系人对项目工作达成的共识
14 提高项目报告水平
15 获得干系人认同
16 更好地监督，控制和测量项目工作
17 建立信心并获得依赖
18 提高未来项目管理水平
19 比较各项目范围
20 有利于范围整合 时间和成本

wbs概念范围

wbs != 工作排序
wbs != gtd
wbs != 甘特图
wbs != 组织结构分解

wbs != BOM 物料清单
wbs != CBS 成本分解结构
wbs != CBS 合同分解结构
wbs != RBS 资源分解结构
wbs != RBS 风险分解结构
wbs != RBS 资源分解结构
wbs != OBS 组织分解结构

** WBS的误区：
WBS不是工作排序
WBS以可交付成果为指引（要注意知识体系的更新）
WBS不是进度计划
WBS不是组织分解结构

结构缩写	结构名称	包含的内容
WBS	工作分解结构	工作 范围 可交付成果
RBS	风险分解结构	风险类别
RBS	资源分解结构	所需资源及其组织
OBS	组织分解结构	项目组织：个人小组和部门及其功能以及相互之间的汇报关系
CBS	合同分解结构	合同和子和同
CBS	成本分解结构	项目成本
BOM	物料清单	所需材料 零件 组件或部件

为什么使用WBS

1 不使用会导致项目管理混乱，具体：规划 质量 进度 范围变更 成本 责任人 xxx
2 WBS适用于任何项目
3 项目启动阶段创建WBS；项目规划阶段优化WBS；项目执行阶段监督WBS；项目结束阶段用WBS确认工作是否完成
4 编制由项目经理和干系人共同完成，以迭代的方式
5 WBS获批后，必须遵循变更流程

有助于理解WBS的关键问题

不使用WBS后果如何：
项目规划时间加长 项目计划质量差 成本/工期/资源估算时间加长 干系人期望难以管理 范围变更控制更加困难 预算严重超支 很难判断是否对所有工作都作了计划
不清楚谁该负责什么工作 频繁的重新规划导致错过截止日期 失去客户或信誉

WBS适用于任何项目吗：是的，实践所得

何时编制和使用WBS：
项目启动阶段创建WBS 项目规划阶段优化WBS 执行阶段用WBS监控 项目收尾用WBS检验

谁来编制：
项目干系人和较了解项目工作的人的意见，迭代 反复修改

怎样编制：
领域知识，需要领域专家或者经验丰富的工程师协助确定

如何更新：
一旦被批准，只能通过变更申请（更新WBS可能对项目其他文件产生影响）
注意WBS和其他项目文件之间相互影响；
在不改变项目范围情况下，可以优化WBS，不过要通知干系人

WBS构成要素

层级 标识/编码
组件 要素=组件+属性 || 例如：1.4.1 内页设计 汤姆 $200

组件类型：人力投入型（不会产出确定的终端产品的支持型活动） 分立型(可以被直接规划和测量的终端产品的支持型活动)

工作包：WBS底层的WBS组件
如何分解：用分解技术来编制WBS，把项目工作和可交付成果分解到工作包的层次
要求：“易于管理”+“足够细节” 判断：能否对其估计时间和成本 核查：交付了较低层级的所有WBS组件，是否就能够交付较高层级的相应可交付成果

何时停止工作分解：具体问题具体分析
经验：大型或重要项目六至八层，好的WBS至少三层
何时停止分解，可以问自己这么几个问题：
基于目前的分解程度，可以把组件分配给一个人吗?
团队能够合理估算这个组件的成本和工期吗?
团队能够确认完成本组件所需的活动和里程碑吗?
我能够有效监控与本组件有关的活动吗?

对这些问题的回答都是“是”，就停止分解，否则，就继续分解
某些情况下，当编制WBS时，换没有足够的信息或者知识，无法把某个组件分解给某人，可以pending，等认知成熟了在编制

取决于项目的复杂度和结构，一个有价值的WBS一般是包含几十个组件的较为详细的结构；一个工期为几个月的项目，其WBS通常有接近100个组件

wbs字段 属性：
命名规则：尽可能使用名词来命名
100%规则：WBS涵盖了项目范围中100%的工作，列出了将要完成的所有可交付成果

不好的wbs示范

• 这辆车有多少个车门？
• 是一辆豪华车还是小型车？
• 是一辆普通车还是巡游车
• 有四个还是三个车轮？
• 车的用途是什么？
• 是一辆现代还是复古车？
  都回答不了。

考察WBS质量的标准：

• 可交付成果为到导向；
• 定义了项目范围；
• 向所有干系人明确了项目工作；
• 涵盖了100%的工作；
• 包含了需完成的所有可交付成果；
• 每个下层级分解都包括了上层级100%的工作
• 工作包有利于识别为交付工作包所需要展开的任务；
• 以图形，表格或文本呈现对项目范围的逐层分解；
• WBS组件用名词或形容词；
• 全部可交付成果的层级结构；
• 每个组件都有一个WBS标识；
• 至少有两层，其中一个分解层；
• 由工作的执行者创建；
• 干系人和专家已参与WBS的创建；
• 随着项目范围的渐进明细而更新，直到确定范围基准；
• 随着项目的变更控制而更新

WBS词典：定义和描述每个WBS组件中需要完成的工作，提供的信息不必冗长，应足以描述完成的工作

WBS创建流程

定义WBS创建团队
分析工作范围
确定是否使用WBS模板
确定WBS的编排方法
确定WBS展示形式
选用创建WBS软件
应用分解技术
应用100%规则
检查分解的层级
分配WBS标识
插入层级图例
检查组件名称
添加所需组件字段
征求干系人意见
编制WBS词典
获得对WBS的批准
沟通范围
把WBS与预算与进度计划联系起来
建立范围基准

** WBS创建方法
依据可交付成果 依据项目阶段 依据子项目 依据地理位置 依据部门 其他方法
编制工具：自上而下和自下而上 头脑风暴 专家协助或判断 思维导图 行业或公司的WBS模板 标准或指南

太粗略的WBS是没有意义的因为它无助于确定项目范围边界，无助于沟通项目范围

WBS模板：
使用WBS模板时，可以根据需要增加一些内容，也可以把不适用于当前项目的内容删去
任何一个含有WBS的文件都可以被调整或转化为未来项目的模板
公司或组织的WBS标准：一套关于创建WBS的原则，以及关于WBS的格式，编码体系，组建命名方法和所需包括的内容的规定

WBS展示：
树形图 大纲式 表格式

收集需求
定义范围

创建WBS:
在项目全过程中都要参考和使用WBS，在项目启动或规划过程组创建WBS，在执行 监控或收尾过程中使用WBS

项目启动阶段创建WBS；项目规划阶段优化WBS；项目执行阶段用WBS监控工作；项目结束阶段用WBS确定是否完成工作

确认范围
控制范围

WBS应用于范围管理

几乎所有事情都与范围及其管理有关，范围是一切规划的基础，与客户的大多数争议围绕着范围变更，范围期望和需求等事项
《范围基准》是项目管理计划的一部分，一旦批准便代表经批准的项目范围，变更提出后，有助于界定变更在项目范围内还是范围外
范围基准会直接影响项目管理计划，活动定义，成本估算，项目预算，风险识别，定性风险分析和范围确认
变更 会影响诸多方面，有可能影响项目范围，导致WBS更新

需求文件对创建一个有价值的WBS是很有必要的，高质量的WBS是能被用于满足所有的项目需求

“需求标识” 和 “WBS标识” 对应起来 需求跟踪矩阵
范围之外工作清单

《范围说明书》是于范围基准相关的另一概念，包括产品范围定义，项目可交付成果和产品验收标准

WBS应用于进度和成本管理

WBS用于核查进度表中是否有多余或者缺少的内容
通过WBS标识把进度活动与WBS中的可交付成果联系起来，确保所有可交付成果都在相应的进度计划中有相应的进度活动

在WBS中为各工作包分配初步的成本估算，用这些初步估算作为输入，随着新信息的获得，对成本进行更准确的估算，这之后才能制定出项目预算

WBS应用于项目管理其他领域

使用颜色改善沟通：
1 不同层级 2 不同版本 3 进度
4 采购：外包会有风险，如合同不完善或供应商不能及时提供
例如：将通过采购过程来选择网络会议解决方案的供货商，并且由该供应商把解决方案整合进公司的网站
为了成功管理与外部子项目的界面，必须在WBS明确指出界面并定义相关工作。比如要采购网络一套网络会议系统，需要在WBS中包含该系统和相应内部系统进行整合测试的工作

WBS对促进沟通的几个作用：
帮助管理干系人对项目范围和成果的期望，有助于防止干系人对项目范围和成果的误解
可以根据可视化要素沟通工作
可以帮你确认什么在范围之内，什么在范围之外，和干系人沟通什么在项目范围之内，什么在项目范围之外
项目干系人，根据其对项目的影响力考虑其要求

沟通管理计划：用于满足干系人对项目信息需求而应该采用的沟通方法和应该沟通的信息
例：沟通对象 内容 目的 频率 方法 责任人

风险登记册：用于管理风险的矩阵图。风险登记册记录了有关项目风险的信息，如风险的可能性，影响， 得分，应对策略，风险责任人，到期日和风险状态（可以在风险登记册添加WBS标识类，把风险与可交付成果联系起来）

人力资源管理：
基于WBS编制责任分配矩阵：用于展示WBS中的工作包与项目团队成员之间关系的文件
RACI矩阵：执行 负责 咨询 知情矩阵

质量管理：
WBS中会有一些有助于管理质量的重要信息，如：技术要求 测量指标 绩效目标或质量标准
可以编制多种与质量有关的报告，如：
质量状态 错误 故障 低绩效及测试结果报告

干系人管理：
干系人登记册：包括每个干系人最关心的范围，范围变更对干系人的影响；；可能要基于控制干系人参与过程的结果，提出范围变更要求，从而可能导致对WBS的更新

在敏捷项目中使用WBS

敏捷：一种基于迭代的开发方法和框架
敏捷项目管理：个体与互动优于过程和工具，可工作的软件优于复杂的文档，客户合作优于合同谈判，应对变化优于遵循计划
Scrum：每天召开简短的站立会议进行协调
迭代和增量式开发

PMBOK 与 敏捷方法兼容性：
“由于可能发生变化，应在整个项目生命周期中，反复开展定制项目管理计划工作”
“滚动是规划是一种迭代式规划技术，即详细规划近期将要完成的工作”
“指定可行的项目进度计划，往往是一个反复进行的国车管”
“风险识别是一个反复进行的过程，因为在项目生命周期中，随着项目的进展，新的风险可能产生或为人所知”
“在迭代和增量型声明周期中，随着项目团队对产品的理解成度逐渐提高。项目阶段有目的的重复一个或多个项目活动”

PMBOK和敏捷的区别：如何管理项目范围，如何管理产品范围，如何创建WBS
项目管理：技术性可交付成果；除软件外的可交付成果；
联合使用，WBS中的技术分支，先分解到高层级，随着信息的增加和下一个迭代期的到来进行更详细的分解

没有实践，就不可能掌握任何技术，在每一个项目中使用WBS吧，体系有了，接下来该在实践中体验了
“今天就用WBS去改进你的项目”