UML软件工程组织

 

 

电信软件项目管理的误区
 
作者:华亭鹤 来源:leadge.com 
 

参与过电信软件项目的人员都会发现,电信软件项目具有其独特性,但更多的是体现当前国内软件项目的通病。譬如说:需求说变就变;不切实际的进度要求;项目不正常的政治压力;项目前阶段的紧迫及项目后期的拖延验收等,都突现出当前国内软件项目的常见问题。

一直在电信行业也摸爬滚打,算起来也有好几年了。几年项目的经验慢慢在告诉我们一些道理,这些道理都是在以往项目的惨痛经历,有时回想起来,道理也就那么几条,但真正做到的人却少之又少。“吃一堑,长一智”--犯错不要紧,最怕的是犯同样的错误。但回想起来,自己的总结还是来得太晚,相同的错误竟然不止一次地重犯。

误区一:本本主义。

本本主义让诸葛亮失去了街亭;毛主席也不只一次地批判过本本主义的危害性,但历史的错误还是在今日轮回般地出现。

观念:一定要需求明确后再开始设计和开发?

项目管理、软件工程的理论一套接一套,无数的书本告诉我们,对于软件开发,需求需用户完全明确后才能开始设计和开发。但是,在电信行业,如果按该准则去办事,那只能说明你的经验还是太欠缺了。过多的项目历程、复杂的政治环境使得用户学会了自我保护。用户对于自己提的需求总是带有随意性及不间断性,但当你提出要需求确认时,用户会提出要认真评估和论证,当然,论证一轮后还需要领导的层层审批,待整个过程完成后,用户要求的项目时间可能已经过去了一大半了。退一步说,就算是用户较为爽快地对需求进行了确认,但接下来在开发过程中、甚至是项目上线后,用户新冒出来的一个想法就可以让整个系统的需求完全变样,而最终,用户却不需要负什么责任,因为他们很认真地告诉你,你缺乏行业的业务基础,对他们的需求没有理解到位。

较好的做法:关于系统面貌,用户永远都无法有一个清晰的模型,除非你能根据用户最初提出的想法去提供一个模型出来,用户再基于它来完善自己的想法。所以对于电信软件项目,原型法是一个不错的方法。你可能通过成本较低的静态页面来构建系统原型,让用户基于它来修改和补充需求,只有这样,你才有可能获取到较完整的需求。

同时,你要认识到,如果你不想等项目延期后再和用户理论责任所在的话,那么,你就永远不要等用户需求完全明确下来后才开始设计和开发。当你感觉到需求已经逐渐清晰时,你应该立即开始设计,并对一些较没有争议的地方先行开发,在设计和开发中找问题和明确问题。

误区二:完美主义。

对于电信行业的软件,永远不要有完美主义的想法,不然只会害人害己。许多项目经理出身于技术,身上流淌的是技术般偏执的血液。对于技术人员的通病是完美主义,认为自己设计出来的软件要能够满足用户的终极需求;认为自己设计出来的软件灵活到能满足所有用户个性化的需求。

如果是这样,那么实践会告诉你,你的想法会是多么的不堪一击。永远不要有一步到位的想法,因为,用户尚且没有完整终极需求,那么你一次性设计出来的软件怎么可能会满足用户的终极需求?用户的个性要求甚至数据统计要求随时会变,甚至随着基本功能的满足,用户会提出升级需求,那么你的软件怎么可能会满足用户所有个性化的需求?

较为理性的想法是:不要奢求一步登天,永远要有分阶段建设的思路。阶段性目标的准确定义,阶段的准确划分,会给你的项目及时完成提供最大的保障。相反,追求完美只会令人花费大量的时间在百关键的枝节功能上,并最终导致你软件的设计泛复杂化,甚至复杂和臃肿到技术和进度都无法支撑。

误区三:我的能力强到能同时承担设计和开发甚至测试的角色。

对于某些项目,可能由于资源及进度的因素,对于项目中的关键人员,往往出项目进度的考虑,同时出于对个人能力的充分自信,他们认为,在项目中,自己的能力强到可以同时承担设计和开发甚至测试的角色。

我们不能否认有些人的能力较为出众,对于小型项目,他们担任多个角色可能是游刃有余。但对于复杂的大型项目,角色的频繁切换会令他们筋疲力尽,最终生产力低下,能力最强的人,最终反而成为造成项目进度延期的关键任务承担者。

较为理性的想法是:踏踏实实地承担力所能及的一个角色。如果有设计的能力,那么好好做好设计这份很有前途的职业,永不要同时承担开发工作。如果资源不够,要想办法协调资源;如果实在没有资源,那么要好好评估阶段目标,或者好好评估项目目标,资源不够的情况下,要学会降低项目期望。

误区四:项目进度延后时要往项目中不断增加人员。

其实项目正常开展后,特别到了业务开发阶段,盲目地添加人员,不但不能加快项目进度,甚至会起到负作用。因为目前国内项目的设计未能明细到任何一位开发人员可以在未充分了解业务的前题下开发,即是说,人员在投入工作前,需要花很多的时间来熟悉业务,熟悉业务的阶段对项目进度没有任何帮助,甚至为了帮助新人员熟悉业务,可能会影响现有人员的正常进度。另外,我们还要认识到,要融合成一个团队整体向前推进项目,那么人员的磨合时间是需要考虑的。

较为理性的想法是:当项目有延期的迹象时,第一时间考虑的是现有人员是不是没有磨合好,是不是没有发挥出应有的作战能力。如果答案是肯定的,那么考虑的对策并不是增加人员,而应该是重新思考和定位原定的项目目标是否过高了。如果真的是目标过高,较好的做法是壮士断腕,减少一些一必要的功能,进而缩减延期时间。

误区五:当大家都没提问题时,项目应该就没有什么风险。

作为项目经理,应该有项目敏感度,也就是说,项目经理应该对于项目的风险有超乎常人的嗅觉。当大家都没提问题时,并不意味着项目没有什么风险。大家可能感觉到了风险,但他们怕自己感觉是错的而没有提出;大家也可能感觉到了风险,但他们认为项目失败后不关自己的事,所以没有提出来;大家可能感觉到了风险,但由于你平时听不进意见,所以大家都不想提出来等等,都可能是不提出的理由。

较为理性的想法是:当感觉到项目有风险时,要认真剖析造成风险的原因,评估每种原因的可能发生率,同时和项目人员交流,进一步验证自己的判断。如果风险属实,那么要对症下药,想出最佳对策,尽量防患于未然,把风险降到最低。

误区六:项目进度论证可行后,那么项目就会沿着进度推进。

对于项目进度,要多考虑偶然事件对于项目进度的冲击。临时的售前支持、政治性会议、临时出差、项目组员请假等原因,都会造成实际情况不能按原定计划来执行。

较为理性的想法是:制定项目进度时,要充分考虑到突发事件,要对风险有所预留。

总而言之,一个电信项目的成功来之不易,要保障其成功,首要的是要避免自己陷入以上的不必要的项目误区。

 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号