WBS是项目管理的核心元素，代表了项目要完成的工作。我们可以这么简单的看待有关项目的层次关系：
1.项目的目的。
2.项目要达到的目标。
3.为了达到目的与目标，我们应该做些什么。（工作）
4.我们应该什么时候做，要达到什么样的标准（做到什么程度），要花多少钱。
5.由谁去做？
6.我们应该如何去做？
7.会有什么风险与问题？应该如何应对？
以上是项目计划的制定过程，从第3步开始，我们就是以一个东西为核心，进行后续的部分。这就是WBS，后面所讨论的要素，都是在此基础上进行的。如果WBS做不好，一切就失去基础。所以说任何项目的项目管理，都必须以此为基础进行。如果我们还有人怀疑这个，那他就不再合适做项目管理了。
可是，我遍查了现在我能够获取到的资料，对如何做WBS都语焉不详，很少给出可以直接应用的方法。而项目经理们使用他们自己认为一贯的办法来构建WBS，那就是Activity导向，想到的是如何做项目，而不是先确定要做什么。
从PMBok的要求上来说，WBS是Deliverable导向的工作分解，而不是Activity导向的分解。那应该如何理解。 Deliverable导向，就是成果导向。我们孙老大就是成果导向，过程驱动的思维，也就是既要作对，又要效率高，持续的作对。那么项目管理也要秉承这个理念。
成果，那就是首先要考虑，你将要向客户交什么，而不是你要做什么。
举个例子：我们要交付详细设计书、合格的程序、测试报告。这是客户要求的东西，那么我们的项目就要以这些东西为中心。如果客户将整个项目分成两个部分来交付，那你就应该按照这个方式。那WBS应该就是：
车辆调度系统
车辆调度子系统
详细设计书
本1详细设计书
本2详细设计书
详细设计
评审
本3详细设计书
设计书相关文件
设计书清单
设计书检查记录
程序
本1程序
本2程序
本3程序
程序相关文件
程序清单
程序Review记录
测试报告
可视化报表与Dashboard
详细设计书
程序
测试报告
这个WBS的重点就是根据客户的要求，将交付成果分解出来，形成我们的WBS。
有的时候客户一下子将100程序发给你，然后确定了大致的工作步骤，对于每本程序都要做：详细设计、详细设计评审、开发、代码评审、测试设计、测试这几个工作。我们的项目经理直接就是用Excel做成一个矩阵表来进行管理，这样行不行？ 首先我们来研究客户的思路，就是你需要交付100本程序，那么我的问题是，他让你怎么交呢？是每本程序交的时候目录如下：
| 车辆调度系统
程序1
详细设计书1
详细设计评审记录1
程序1
程序评审记录1
测试计划1
测试记录1
程序2
详细设计书2
详细设计评审记录2
程序2
程序评审记录2
测试计划2
测试记录2
程序3
| 车辆调度系统
详细设计书
程序1
详细设计
评审
程序2
程序3
程序
程序1
程序2
程序3
测试文档
测试计划
程序1
程序2
程序3
测试记录
程序1
程序2
程序3
|
这两种方式的WBS如上所示，他们的优劣就非常明确了。第一种情况，所有东西混在一起，是不利于管理的。
以交付给客户的成果为中心，就是WBS的精髓之所在。确定了WBS的基本部分以后，还要考虑适应我们的管理需要，包括人员分工、成本归集等部分。
到具体的工作包以后，我们就可以分析如何完成该工作，定义出活动来。
如何定义活动，简单的方法是，企业将整个工作分类后，确定了标准的工作类别和工作方法。到了项目这个层级，直接饮用，按照人员分工的方式，做进一步的区分，也就是不要将一个人的工作，连续进行的，再拆分为几个部分。而应该按照分工，进行调整。我们简单示意如下： 做详细设计，公司规定的流程如下：
1.阅读客户的概要设计，提出问题，并获得澄清
2.分析难题，确定解决方案
3.计划详细设计
4.完成设计
5.自查并修正
6.提交设计，申请交叉评审
7.交叉评审并记录
8.根据交叉评审的记录修正，并获得验证
9.正式提交
这里面按照分工的原则，1-6由一个人，假设为A负责、7另外一个人负责，假设为B，则体现在项目的进度表上就是2个活动，一个详细设计，包括1-6,8-9，一个交叉评审，为7。 这两个活动起名为：详细设计、评审。关系为：FF。
今天就讲这么多了。
