快乐的天空

时间来得快,去得也快

 

一个失败软件项目的思考

一、对一个估计撑不了多久的项目的抱怨(原文)
项目概况
甲方: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先生要求网站兼容IE678 FF 和谷歌浏览器,这也够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. 明年再定,看明年能不能抽出时间来。
再主要写下年后的实际执行情况:
1. 不知道主管有没沟通,反正M先生照旧。
2. 好像汇报了,但没有相应反馈动作。
3. 被G强制压为一周一次发布。M先生起初不满,但不发布他也无奈,就算是默认了。
4. 几乎是直接就丢下了。原因:主管再次表示要以客户发布时间为第一位。而G照旧被压着这么多的活,再来一个缺陷管理完全是自讨苦吃,也就放弃了。
5. 这个倒是坚持了3个多月,效果还不错. 本来Q在表达方面就有些问题,就是话说不明白,每次都要被G追问很多遍才能说出点头绪来。而这导致了Q对G的一些不满和抵抗。于是美工P一走,就剩下G跟Q2个人,每日会议干脆停掉了。
6. 看到4就知道,这个没戏了。
回到去年年底,客户对项目总体上表示满意,G估摸着这里面有M先生很多功劳。而公司领导以业绩不好为由,让每人领了200块的过节费就匆匆回家团聚去了。当年后G从M先生那里了解到年前公司已经拿了X项目绝大部分款项时,已经离过年甚远,追悔莫及了。而这事也在X项目组3个成员的心里埋下了许多的怨愤。连G先生在内的成员也少不了在闲聊时间,发泄一些对公司的不满。这也一定程度上,导致了P的出走。有句话叫兵败如山倒,这P一走,Q也开始紧锣密鼓的找新单位,终于这个月公司也接到了Q的离职申请。本就人丁不旺的X项目组就剩下2个光杆司令:G和主管。其实Q的离职对项目影响并不大,而P的离职相对来说大的多,P这一走,美工就没了,而多功能的M先生重操就业兼职做美工,这是G也得佩服的事,说啥来啥,都能上。
项目晃晃悠悠的走到了今天,眼看着也要到头了。而G站在项目的边缘不知何去何从。
三、从G犯的错误来看X项目如何失败的(原文)
下面做个简单分析,从G犯的错误来看看X项目失败的原因。
1. G兼着项目管理和设计开发,本不想再参与需求调研的事,可主管说他很忙,没有太多时间调研写需求文档,公司又没有配置专门的需求调研人员,也就只好应承了下来。 
G本身已经兼着太多的职位,导致工作不能做好了,还要去接下一个本可以不搭的事情。这就导致时间更不够用。时间不够用将辐射出更多的问题:
1) 因为很有多工作压着,为了能够按时完成,必然胡乱瞎搞,能省则省,最终的结果就是质量完全不到位。
2) 没有办法进行有效的总结回顾
3) 长此以往,必将导致心理失衡,产生厌烦心理,从快乐工作变成了赶鸭子上架。
4) 以上3点连在一起,必然出现恶心循环,最终要么人崩溃,要么项目崩溃。
目前想来,解决方法只能是,积极主动而又耐心的反复沟通,对主管和领导进行主动劝说,让公司安排个人来专门调研需求以及分担G的其他工作,让G能够专心与程序设计开发或者项目管理。上文回复中,有很多人提到了PM的重要性和存在的问题,而G身兼PM在内的多职,必然导致了项目问题,偏偏这么重要的问题,被领导主管和G在内的X项目组成员所忽略。
2. 人不怕辛苦就怕比较,辛苦都是可以撑下来的,可要有个人在旁边这么一比较,这心理真是全然不同了。G是农村出来的娃,辛苦点不怕,只是你辛辛苦苦一天忙到晚,人家坐你旁边聊QQ,看新闻,这感觉很是不爽,最最关键是这闲的主还是得听你指挥的小弟,这真是要命。
这个是心理因素,说明G这个人心理不够淡定。合理的解决方案之一兴许跟1中的一样,让人分担G的工作,使G专心与自己的所长。再者,就是人员合理流动,对于不能达到岗位需求的员工,要及时更换或补充,一方面不至于引起其他成员的不满,另一方面也是项目成功的必要条件。敏捷开发的中心思想就是以人为本,如果人心涣散,项目想成功都难。黎叔说了,人心散了,队伍不好带了,于是黎叔也被抓了。
 3. Q在表达方面就有些问题,就是话说不明白,每次都要被G追问很多遍才能说出点头绪来。而这导致了Q对G的一些不满和抵抗。 
这是对人的管理不善,带来的严重后果之一,G明显缺乏那种让人家为他或者为公司卖力的领导能力。此点在2中已经有表现。
4. 连G先生在内的成员也少不了在闲聊时间,发泄一些对公司的不满。
G在一定意义上是X项目的负责人,而他带头在成员面前表示对公司的不满,这必将给项目组成员带领极坏的影响。这个举动说明了G在管理这个岗位上的不成熟,没有从大的方向进行考虑问题,而只是一泄心中怨气。致使人心动摇。 
5. M先生提出需求和修改,然后马上开动,做完就发布给M先生审查,几乎是一个星期要发布2到3次(此处的发布指,将程序发布到测试服务器,供客户试用和审查) 
这个就是明显的没有做好项目管理,简直就是把项目交给客户来管。程序发布,还是比较消耗精力的,而发布后,客户发现的各种错误异常,会要求马上更正,就导致了有时候一天中多次发布的情况出现,就因为几个很小的错误,导致时间消耗在 修改-发布-修改-发布 上。
解决方法:
1) 按照较长的时间周期进行发布,但不宜过长,比如1周或者2周。并且跟客户协商好,当前发布版本的错误,推迟到下个版本修改。
2) 每周邀请客户代表到公司来参与项目进展会议。让客户每星期都能了解到项目在进展,放宽他的心。约定好,每个月发布一次测试版本,让客户测试体验,相关问题,放到后续版本中修复。
3) 对需求的获取和变更进行控制,比如要求客户形成书面文字,进行需求提交等。
6. G照旧被压着这么多的活,再来一个缺陷管理完全是自讨苦吃,也就放弃了。
G因为手里活来不及而放弃了缺陷管理,这是可悲的。缺陷管理可以说产品质量的保障之一,缺陷管理那长长的列表尖叫着提醒项目存在的问题。这是一个项目出现质量问题,最显眼的警报器。没有缺陷管理,几乎很难进行项目质量的监督。缺陷管理一开始的缺少和后来提出又放弃,很大程度上决定了项目的失败的必然,一个不注重质量的项目,谈何成功?即使功能全部完成,你敢放到公网上让黑客转悠2圈吗?
综上所述,凸显出G项目管理能力上的匮乏和心理的不成熟。这是项目走向失败一个很大的原因所在。在此希望各位看官,能更多的提出G的问题所在,也希望能提供相应的改正建议。在此感激不尽。

posted on 2012-06-02 00:02 探路者 阅读(271) 评论(0)  编辑 收藏 引用 所属分类: 项目管理


只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理


导航

统计

常用链接

留言簿

随笔分类

随笔档案

文章分类

文章档案

新闻档案

Android

Compiler Course

VIM

编译技术集合

测试

高性能计算

个人博客

框架/组件/库

搜索

最新评论

阅读排行榜

评论排行榜