系统集成项目理工程师知识点:南方移动项目计划部分(综合案例)

被委任为这个项目的项目经理后,王东心理有点复杂。一方面是因为接了一个比较重要的项目、公司领导很重视所以比较兴奋;另一个方面,他对项目感觉没底,心里有点儿空荡荡的。王东对网络还算熟悉,但对软件编程不是很熟,自己觉得只能算还行。

进公司快两年了,对公司的运作制度和项目管理制度也算比较熟悉,项目做过好几个,也算是有一定经验的项目经理了。

王东的回忆:

知道我负责这个项目后我比较关心的是项目的时间要求和人员问题。项目合同我大致看过,时间已经定死了,4个月,6月底要上线。人员方面给我派了本部门的4人和研发部的3人。我们需要完成什么工作呢?软件开发和21个业务区的接入,按《技术规范》做,4个月的时间连我在内8个人能完成吗?说实话,这就是我心里最没底的地方。

这个项目的工作范围应该是明确的、固定的(《技术规范》我还没看过呢!)。但这么多工作4个月是否能完成可能谁也不清楚,这“4个月”是销售部门跟甲方商定的,估计甲方有要求有压力,而销售部想起来觉得也差不多就定下来了,事前工程部一点儿都不了解;8个人够还是不够呢?谁都不清楚,没有概念。我还是先做项目计划吧。

公司里有一套项目管理的制度,按照项目计划模板去填就可以了。

我花了差不多一天多按以下顺序填好了计划模板中的各主要部分。

·项目概述和约束;

·项目组织和报告渠道;

·项目过程和方法;

·WBS;

·项目规模、工作量估计;

·进度计划。

(1)项目概述和约束

①关于项目目标没有太多需要考虑的地方,这类东西我都是基本上照抄我上一个项目的相同内容。

②关于软件总体功能描述在《技术规范》里都有,我只写了一句话概括了网管的功能。

③关于主要约束,我主要写了进度约束。

·需求分析:2003.2.17-2003.3.7;

·总体设计:2003.3.10-2003.3.31;

·详细设计:2003.4.1-2003.4.30;

·编码:2003.5.7-2003.5.31;

·测试:2003.6.1-2003.6.30;

·初验:2003.7.1;

·终验:2003.9.20;

·本项目不存在成本和资源约束。

④本项目与公司其他项目和部门没有依赖关系。

(2)项目组织和报告渠道

④我分了两个组:软件组和网络组。软件组由李鹏负责,网络组由我负责。

②我把以下各角色的责任都描述出来了。

·项目总监(张廷)

·项目经理(我)

·软件组长(李鹏)

·网络组长(王东)

·项目支持(李克明,主要负责质量保证)

③报告渠道。

·项目组周例会,项目组内每周召开;

·给客户的双周报,向客户即甲方汇报项目情况;

·项目报告,每双周向公司汇报项目情况。

(3)项目过程和方法

①在软件方面,我们按常规的软件瀑布型过程进行开发,其他没有特殊的技术方法。

②因为开发工作时间有限而且看起来不复杂,我裁剪了代码走查、弱化了总体设计、详细设计、单元测试和配置管理的工作。

(4)工作交付物及WBS

①项目的最终交付物是可正常运行的南方移动省级网管系统及相关文档,包括如下内容。

·网络系统软件的可执行代码;

·系统技术手册;

·合同规定由我方提供的设备;

·达到《技术规范》要求的网络系统。

②按项目的时间顺序,按照想象中的一件件工作我基本上分解出项目的工作分解结构。每件工作我都标注上其输出,大部分工作都在三五天以内,少数是10天左右。软件部分的工作基本上是按软件开发生命周期进行分解的,接入部分的工作基本上按各地区工作的时序进行分解。

(5)项目工作量估计

有了WBS估算项目规模和工作量就比较方便了。先为每一项子任务估算一个工期和占用的资源,然后可以很容易地累加出总工作量。不过,既然总工期已经定死了是4个月,那我定义的各任务的时间都是从这一最大的约束出发凑出来的。

(6)进度计划

按第一项的进度约束我定义了几个里程碑。

(7)其他

因为还有风险日志,所以我不需要在项目计划中针对风险作什么计划,等项目启动后,按风险日志的格式再处理也不迟。

有了计划模板,项目计划确实好做多了,不过对这个项目而言有不少地方我还不太有把握,例如WBS、任务工期及进度安排、资源安排、项目工作量等。但因为有模板的格式,我还是按大致的估计填上了些内容,总不能空着。

王东把项目计划提交给部门经理张廷和公司项目管理部。

张廷拿到这份计划,他最关心的是能不能按公司领导的时间要求完成这个项目。从进度安排方面看,最后的完工日期是符合合同要求的,这份计划没问题。另外,从组织、责任、沟通渠道、工作交付物和WBS等方面基本上都是常规的一些内容,每个项目大体上都是写这些内容,也都看不出有什么问题。他问了一下王东:“做好这个项目没什么问题吧?公司高层领导可是很重视的啊。”

王东也想不出有什么重要的问题,就说:“现在项目还没开始,也没什么问题。时间方面现在心里没底,我努力争取吧。人员方面以后要是有什么需要还请老总您老人家多支持!”

张廷说;“您千万别!现在每个项目都很紧张,能给你抽出8个人已经很不容易了,你知足吧!”

公司项目管理部小林问了张廷对这个计划有什么意见,张廷说没有。小林看看项目计划的格式、内容基本符合要求,而尽.部门经理也没意见,就批准了这份项目计划。

按项目计划,项目软件部分的第一大项工作是进行需求分析。这方面工作王东让软件组长李鹏全权负责。甲方这边的负责人郭处让他手底下的小凌负责跟李鹏来谈软件需求。小凌和另外两位甲方的人员针对未来的网管系统各个功能分别提出他们的想法,李鹏就跟他们谈并逐一作记录。虽然谈需求进行得不是很有规律,但是最后需求分析还是按时完成了,得到了一份关于该项目网管系统的需求说明书。该说明书对系统的各个功能、使用方法都提出了要求,有些要求非常具体。

李鹏告诉王东说这份需求文档的内容虽然有些方面提得比较细,但有不少地方跟《技术规范》不一致,想商量商量怎么处理。最后他们觉得这份需求有些地方是对《技术规范》的发展,有些地方是细化,体现了甲方现在对网管系统的实现要求,与其到测试或验收时再处理,还不如现在就考虑。王东把需求文档提交给了甲方请他们审阅。

设计、编码工作基本是以需求文档为基础而进行的。

项目工作铺开后,大家才发现项目的工作没有原来计划的那么简单,有些工作在原WBS中是没有的,还有不少工作是计划外的,这都占用了项目成员的很多精力。王东习惯性地感叹:“意外太多了!怎么我们做的每一个项目都有这么多意外,原来做出来的计划就没有办法顺利地执行下去,计划没有变化快啊!”这样,项目计划就没办法按原来的进度要求走下去了,原来每个人的正常工作节奏全都被打乱了,每个人都很忙。

关于接入部分的工作,王东去了南方某省需要接入的好几个地方才发现甲方各地准备工作根本没准备好,这将会严重地影响整个项目的进度,而这些准备工作原本是Simple公司希望甲方在接入工作开始前就做好的,甲方也曾说他们将负责把各地所有的接入准备工作都做好。王东问各地的相关负责人这个项目的工作怎么安排,负责人的回答大同小异,基本上都说省局为这个项目召集他们开过会,具体的工作也都考虑过或做过一些工作,不过现在工怍特别忙,有部分工作也没顾上,有些人还说曾想完整地规划好要做的所有准备工作,但也不清楚准备工作具体都需要做哪些。王东又打电话问负责这个合同的销售代表老杨:“关于接入的准备工作当初跟甲方是怎么定的、怎么交待的?”老杨说:“哎呀小李,你不找我我还想找你呢,签完合同就不知道这个项目怎么样了。你说各地市的接入准备工作吗?他们说是他们负责的呀,我就没多管,你是不是该督促他们一下啊?”

接入工作的进展也影响到了软件开发的工作,按原计划到5月中旬应该可以进行软件调试的网络环境没按时就绪。

按王东的项目计划研发部应该在4月初额外派3个人来三四天帮他们解决一个技术问题。时间到了4月初研发部却没动静,王东急了,打电话问人怎么还不过来,研发部经理诧异地问:“你什么时候跟我说过这事?”王东说:“我都写在计划里了!计划也发给过你了!”研发部经理说:“每天文件这么多,我怎么可能把你的每一个字都细看呢?”

还有一件更麻烦的事:公司为甲方所订购的一批网络设备到货时间将会耽误项目的进度,国内供货部分还好一点,国外供货最晚的要到7月中旬左右才会到货。王东又感叹:“天不助我啊!”

王东每两周都会跟郭处沟通一次项目的情况,郭处知道了设备到货时间的问题后问王东:“你们公司没有去考虑过这个问题吗?”

5月22日,甲方高层领导来到开发现场听项目组的汇报并观看系统演示,为了表示重视,公司领导和张廷也来了。当时系统并没有完全开发完毕,大家只看到了主要的功能模块。

看完后,甲方领导表达了意见。

(1)对项目的进度极不满意。

(2)系统演示出的功能与《技术规范》不一致,最后的验收将以《技术规范》为标准。

(3)从项目前阶段的工作过程可以看出Simple公司投入到项目中的资源不足,希望Simple公司领导充分重视该项目。

(4)为对项目的沟通和监督,从当天开始甲方将每8个工作日来现场听取项目汇报并观看演示。

公司领导对甲方的意见非常意外,立即让王东汇报项目情况。王东的汇报中提到了资源不足。领导问项目组的8个人他是怎么使用的,王东说从项目开始到现在他们都很忙。领导无话可说,又问王东要增加多少人,王东说估计4人左右。领导说虽然公司很重视这个项目,但现在公司资源非常紧张,需要王东详细规划出这4个人怎么使用的一个计划然后再审批。王东觉得这样很麻烦,本来项目工作就很多,还要把时间浪费在这种形式化的表面文章中,但俗话说胳膊不能跟大腿拧、好汉不要跟领导顶,还是简单写了为这4个人各分配哪个方向的工作作为计划交了上去。

在随后的几次汇报中,甲方领导在观看软件演示时多次提出了修改意见。对于这些意见李鹏提出这属于项目范围变更,要求按变更来处理。但郭处说这不是范围变更,软件功能本来就该做成这祥子,是开发组理解错了,不存在变更不变更的问题。为了能够说服郭处,李鹏和王东详细查阅了《技术规范》,结果悲观地发现在很多地方《技术规范》并没有清楚描述要做成什么样,所以很难判定甲方的意见是不是属于变更。既然是这样,就只有满足甲方的要求了。

项目的麻烦开了头就刹不住,估计项目的时间目标是不可能实现的了,不知道客户的高层领导和公司的高层领导要怎么着急呢,唉……

现在回过头来看项目的计划,王东觉得这项目计划其实真的没什么用,项目是活的计划是死的能有用吗?还不如不做!只不过公司有制度,不做不行罢了。