一个项目的失败

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