一个项目的失败

曾经看过CMM的一些资料,当时只是觉着这些东西有些空,而且很复杂,很没办法在中国的软件公司实行。可是,这么多年过来,经历了很多的项目,也领导过很多项目,发现对CMM有了新的认识。
CMM的关键问题域是很多失败和很多成功的例子所总结出来的,也许它很复杂,要求也很高,但是如果我们真的理解了这些关键问题域,那么我们应当能从一个又一个的项目的失败中走出来,以科学的精神让项目成功,让程序员不再‘挨踢’,让他们能够像普通人那样生活,休息,休假,驴行,不必有现在那么大的压力。
说个实际的吧,现在参与的一个项目,一个由于很多的原因做了足足三年的项目,真的可以用失败来标记它。
从最开始公司企图用此项目打入某行业的某用户开始,就注定了项目的路线和失败。由于公司希望拿这个项目作垫脚石,所以高层在对待这个项目的态度上就摇摆不定,开始是忽视,希望投入最少的人,做最少的功能点,期待后面的大项目。等到用户不再对后面的大规划大项目感兴趣后,突然发现这个项目变成了一个可能的潜在的产品,因此又开始重视这个项目。但是由于前期的态度,导致这个项目从一开始的功能需求就是模糊的,用户的需求的外延在不断的扩展。
同时,由于竞争的原因,用户要求进行实际的评估。这就给这个本来已经混乱的项目增加了更多的混乱。用户提出了400多个功能点,给我们的时间只有三个月。如果公司高层能够认真评估风险的话,可以看出来失败的风险是非常大的,用户给出的需求非常的简单,而且出于竞争的原因,没有给我们和用户进行需求调查的机会;结果展示平台一直都处于持续开发的过程当中;对系统所涉及的数据量和数据的复杂程度缺乏足够的重视,导致后台处理时间几乎不可忍受;没有制定测试计划;项目组与客户之间没有一个稳定的、有效的沟通机制。如果认识到了这些风险,我们本来也是有机会补救的。但是高层没有这么做,结果就是大家持续加班将近一年,可是老板们还是很不满意,因为用户不满意。
如果高层有人拿出任何一本介绍CMM的书,那么我们的下场可能不会这么悲惨了。CMM2级里的那些关键问题域会指出我们这个项目是多么的危险,需求管理,没有,风险管理,没有,计划,没有,什么都没有,只有程序员拼命的编码,编那些注定要被推翻的代码,明知道要失败,却只能继续走下去,多么悲惨的结局,剁末好的程序员。

阅读更多

没有更多推荐了,返回首页