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 详细设计书1 详细设计评审记录1 程序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。
今天就讲这么多了。