一个失败软件项目的思考

一个失败软件项目的思考01摘要：文章介绍的是一个失败软件项目的过程。很烂的项目经理往往会直接决定一个项目的生死，你是这样的项目经理？一、对一个估计撑不了多久的项目的抱怨（原文）项目概况甲方：A公司乙方：本人所在公司（称B公司）项目：X项目是A公司外包到B公司的电子商务项目。人物：A公司M先生，X项目组，主管、G、Q、P成员项目状况X项目当前状况不太好，可以说后果比较严重。1.几乎处于停滞状态。现在的需求获取方式可以称之为“挤牙膏”；在现有功能完成，而A公司联系人M先生，提出新需求之前，开发人员完全不知道下一步是什么。并不是需求调研没跟上，而是跟上了M先生无话可说（讲不出需求）。另一方面，项目当前实现功能跟合同写的又有很大落差，不可能截止。这个矛盾就导致了项目几乎停滞。2.项目本身质量也堪忧。X项目组，组成非常简单，1个主管，1个高级程序员（下面简称G成员），1个北大毕业的程序员（少“青鸟”2字，简称Q成员），1个美工皆程序员（简称P成员），ZERO测试。X项目组的需求调研、项目管理，程序设计，技术攻坚外加运维全皆在那个可怜的G成员(就是那个高程)身上。3.上个月美工皆程序员撤退了，这无疑又是给项目雪上加霜。原因分析造成项目如此惨淡的原因，也是多种多样。1.A公司的M先生，是在X项目开始的时候才进入A公司的，而M先生原来是写过代码的。G成员心想M先生有程序员的前身，好沟通，还暗暗偷笑。可没料到的是，M先生原先是个半吊子程序员，只写过几个asp页面，而心里却甚是得意，大有编程不过如此之气势。就是这样的程序员前身，给项目带来数不尽的压力。顺便摘几句就可以管中窥豹：“这个简单了吧，只要数据库这样这样，然后读出来就行了”，“这个有这么难吗？不就是加2个页面的事”。如此等等就不列举了。但这其实还是能应付的，最大的问题是啥呢。之前讲了他是项目开始进的A公司，或者说是A公司专门挑的给给X项目组跟A公司牵线的。这是好事啊。可也是坏事，坏哪了？X项目作为一个电子商务外包，现在却要跟一个不熟悉业务，跟X项目组成员一样的现学现卖的M先生调研需求。如此，我想“项目停滞”恐怕也是能够想象的了。2.项目组成员组成问题也很多。G成员身皆多职，但一个人的精力毕竟是有限的，如果这么多的工作要8个小时内完成，几乎是不可能的，就算完成恐怕也是偷工减料了。于是整个项目周期经常出现这样情形：G成员忙的焦头烂额，而其他2个人就聊聊QQ看看新闻。并不是G成员不舍得把工作交给别人，而是另2个成员，非设计好的功能不做，P成员毕业才不过半年也就请有可原，而Q成员，自“北大”毕业，工作也已经一年多了，这就有点说不过去了。Q成员的事，还是事实为依据：有这么个功能，1个主表1个从表，依据主表当前选中记录，显示并修改从表的内容，这功能，就这么简单一个功能，G成员估摸着熟悉需求加表设计加功能也就是2天时间的事，可Q成员愣是给整了一个星期，结果一发布出去，还一堆问题，挨M先生一堆说。这样的组成和水平，我想代码质量不能保证也是在所难免了，更别提还没有测试人员。3.基于2的问题，很多看官肯定要说了，这样的情况，还不赶紧跟领导提意见换人嘛？提啊，G成员可没少提。G成员要求也不高，就提这样个要求：请领导给我们再加个美工或者程序员。如果加美工呢，让P成员转程序开发（这个是P成员自己提的，他一直不想做美工，而且人也机灵，转程序员也行），麻烦再把那个Q先生给换下去，你说拿着3000的工资，干着这个活，我也是为公司节省成本啊。如果加个程序员呢，质量要稍微高点的，另外就要把P成员的思想工作好好做做，让他当个全职美工。可领导说了，我们这个小公司小项目，这样哪行呢，这成本太高了，我看你们也不是很忙，先这样吧。G成员听着郁闷，这人家QP成员的确不是很忙...G成员当时就差说：你不换他们那就把我换了吧。毕竟还是饭碗要紧，就吞回去了。得......这一来一切照旧。4.这项目组里都讲到了就差个主管，主管我就不给取外号了，比较是主管，咱得尊重。主管呢，是领导派下来的，其实不负责管理，也不负责开发，人家是搞delphi的牛人，但对C#是一窍不通，可是这人偏偏啥都爱插一手。就说，项目刚开始，G成员思量着上个ORM，就跟主管打个报告，列了几个ORM的优势。人家主管就是牛：第二天给回话，不要上什么ORM了，你看这个sql多好。这不看还好，一看就吓倒。人家的sql全是写在frm上的，直接调用一个公用方法连接到数据库。看样子跟他光用讲的不行。于是G成员重新整理了一遍ORM的优缺点，又认认真真写了个demo，再交上去。这次主管2天没给信，以为有点效果。那天正吃完饭，主管就把G成员给喊过去了，这主管能啊，真是爱学习，电脑上整理一个vs2005：G啊，ORM这个问题，我不是很懂，但我问了几个朋友，他们说没啥必要，如果非要上呢，就用这个吧，你看看这是我朋友写给我的。G成员心里一颤，看来这事要完。一看代码果然是头凉到脚。这这这也是orm？这写个sql读个datatable，再给他赋值给一个对象，然后这对象再给页面控件赋值，就算OOORRM了？真是尼玛的有木有！！！！！！！！！！看官跟你讲，这事还没完。ORM这事是没戏了，那咱就上个微软企业库，这总行吧。企业库刚搭建完那天，主管就来了，说，这么长时间了，让我看看成果。这事没的说，领导看下工作成果，合情合理。可偏又看出个事。ExecuteScalar这个方法，常写sql连数据库的人都知道，获取单值。主管就问了ExecuteScalar这个奇怪的方法是啥意思，G成员就给他解释：这个是从数据库获取单值的。看看主管迷糊，又加一句：就是获取第一行第一列的那个值。这不加估计迷糊迷糊也就过去了，可这话一出口，主管就笑了（得意的笑，我得意的笑….），这他在行啊。主管说：这个方法以后不要用了，这个跟ExecuteDataSet重复了，你就取DateSet第一行第一列就行了。G成员当时就怒了，XX的，这有完没完。经过几回合的较量，终究姜还是老的辣，告到领导那被批回来了。G成员这次算是彻底服了。于是以后有什么东西该藏藏，大气不出一个，他说他的，我干我的。可这又何苦呢？唉～～～一声哀叹尽千愁啊！5.对美工P的出走也交待几句。这美工呢，毕业没多久，但人好学，所以进步也快。进项目之前就是讲好了，等他把C#掌握得能完全参与项目了，他就不干美工了，想写代码。这领导也是同意的，结果一直干干干，从去年干到今年，提也提过几次，也没听到什么时候能找美工来替他。而且人家乃是蛟龙，能被这小水潭给困住？就另觅明主去也。这一换工作，工资直接翻番。二、一个估计撑不了多久的项目的发展历程（原文）之前发了一个抱怨文，把X项目前前后后几个人全给抱怨了。后面也有很多看管给我回复，有表示哀悼的，表示同情的，也有提意见，送安慰的，甚至还有抢占广告位的。不管怎么，本人在此表示感谢。抱怨完了，也该反思下项目的历程和带来的教训。此文就先简述下项目的历程：估计还是以抱怨为多。望各位谅解。一个估计撑不了多久的项目的发展历程记得去年的仲夏时间，天气正是当热，三十五度算凉快的，三十七八很正常，还经常能串到40的高温，当然40度往上天气预报是不敢报的，但明白人都知道，一个铁皮碗放太阳底下晒个两分钟，鸡蛋往里一敲，一个五成熟的煎蛋就出炉了，让人不得不佩服太阳核聚变的威力。X项目就是在这样水热火也热的环境下启动的。X项目启动之初，领导只说让G开个项目，实现这样一个功能，然后给客户看看。因为领导并没有说是正式项目，就权当是原型开发，G就给顺便整理个小三层，把页面先给画起来，数据读出来展示，然后就给客户看了。这个时候的还是直接跟A公司的老总直接联系的，M先生尚未上任。然后客户就开始提意见了，要这样，要那样的，G就照着做，但一直没有正式项目的说法，就权当是按范例这样的简单方式都给写了。G也跟领导提过，这个情况是不是应该正式立个项，领导说，再等等。就这样拖拖拉拉一个多月过去了，代码也七七八八写了不少。有一天，领导带来个人，跟G说，你做的那个程序现在呢正式立项了，这位以后就是你们这个项目的主管，以后有什么问题就找他。G一听心里乐呵，这个把月没白搞。Q和P两位项目成员也就陆续的来报道了。既然正式立项了，那不能按之前那种烂法子做啊，G就寻思着把项目重新架构下，这么大个事当然得跟主管商量下，这一来二去的还算顺利（这中间有个关于使用ORM的事，见前文）。就在此时，A公司的M先生也上任了，并指定了跟X项目接头。M先生之前兴许看过原来的demo版本的程序，一听项目调整，1到2个星期不能有功能产出（项目调整这说法是领导提的，可能是怕客户有意见），就有点不乐意，催着X项目组赶赶工，这时间太久了。这话就由领导传到了X项目组，既然是领导发话，X项目组只有惟命是从，G就给大家开了个小会，打打气，加了一个星期班，连架构，带实现，把之前一个月的事，大家给翻了个新。这之后的一个月，都是领导亲自去客户调研，然后需求以口头和少许说明的形式，转到G这边，G再根据自己的理解分解素材，设计程序和数据库，把素材转化成任务，分配到QP和G自己。我想很多看管可能都看过这样的图：在这样的需求调研下，程序表现往往跟客户的需求不符。领导就把需求调研的任务干脆就直接交给G了。G兼着项目管理和设计开发，本不想再参与需求调研的事，可主管说他很忙，没有太多时间调研写需求文档，公司又没有配置专门的需求调研人员，也就只好应承了下来。也就从这个时候开始，G认识了M先生，才了解到需求为何会如此零散。M先生的事，就不过多描述了，毕竟文章还是以X项目发展为主。简单描述下X项目的组成：此项目为电子商务网站，而网站数据几乎全依赖外部接口，这个也是由于网站业务所决定的。X项目总共前前后后开发了各式各样9个外部接口。平均的说是一个月要针对一个接口开发。Q和P2位成员的能力，上个文章也说了，此处不再赘述。P要为X项目画界面做图片，尤其是M先生要求网站兼容IE678FF和谷歌浏览器，这也够P先生忙一壶的了。而这Q就闲了，每天只等着G设计好了，告诉他功能怎么怎么做，如果这天G没空设计新功能给他，他就聊一天QQ，听一天音乐。由此可见G要忙到什么程度。人不怕辛苦就怕比较，辛苦都是可以撑下来的，可要有个人在旁边这么一比较，这心理真是全然不同了。G是农村出来的娃，辛苦点不怕，只是你辛辛苦苦一天忙到晚，人家坐你旁边聊QQ，看新闻，这感觉很是不爽，最最关键是这闲的主还是得听你指挥的小弟，这真是要命。于是就出现了前文中要求加人或者换人这样的事情。无奈项目组加人不成功，G只能继续匍匐前行。转眼就到了年底，根据初始合同需求确认书，半年过去了，却才做完了三分之一多些的功能项，G的心中有些不安。有一次G去A公司跟M先生进行需求调研，讲到了对项目目前状况的担忧，M先生不愧是过来人，信心满满的说，你放心好了，这个项目我肯定给他搞活了，不可能倒。大有一切尽在掌握中的气势。虽然M先生如是说，但G心中始终是放下不，就细细总结了这半年的得失，和来年的一些计划和改进方案，交到主管手里。这个文档的主要内容这里摘一下：1.确定项目驱动因素，不能由M先生带领大家挤牙膏，必须要进行项目远景定义和功能集合的详细定义。2.项目风险总结，将近半年的各种问题进行一个简单汇总，并请求主管对项目组外的风险提出相应的处理方案。3.延迟发布周期为1周（原来是，M先生说个需求和修改意见，然后马上开动，做完就发布给M先生审查，几乎是一个星期要发布2到3次）,而且一周内已经定好在做的功能，不接受任何修改。4.提出项目缺陷管理。对项目问题进行统一管理，这中间引起的客户和开发时间问题，希望主管能够帮助协调。5.每日会议的召开。（原来只有1到2周有次项目总结会议），随时捕获风险。6.望主管能够部分接收G手中的项目管理工作，减轻G的工作负担。也主要摘下主管对这个文档的回应：1.明年会跟客户进行有效沟通。2.明年会跟领导报告，尽量解决。3.同意一周发布一次，但也要尽量满足客户要求。4.缺陷问题很重要，要管理，但还是要以客户发布时间为第一位。缺陷可以后期修改。5.每日会议，有这个必要吗？如果没啥必要就不要开了，大家都比较忙。6.