红色壁虎(三磊)

Red Gecko 石子虽平凡,聚少亦成多。
  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

2.一个估计撑不了多久的项目的发展历程

Posted on 2011-05-24 15:31  红色壁虎  阅读(3615)  评论(36编辑  收藏  举报

之前发了一个抱怨文,把X项目前前后后几个人全给抱怨了。后面也有很多看管给我回复,有表示哀悼的,表示同情的,也有提意见,送安慰的,甚至还有抢占广告位的。不管怎么,本人在此表示感谢。

抱怨完了,也该反思下项目的历程和带来的教训。此文就先简述下项目的历程:估计还是以抱怨为多。望各位谅解。

 

一个估计撑不了多久的项目
发展历程

 

       记得去年的仲夏时间,天气正是当热,三十五度算凉快的,三十七八很正常,还经常能串到40的高温,当然40度往上天气预报是不敢报的,但明白人都知道,一个铁皮碗放太阳底下晒个两分钟,鸡蛋往里一敲,一个五成熟的煎蛋就出炉了,让人不得不佩服太阳核聚变的威力。

       X项目就是在这样水热火也热的环境下启动的。X项目启动之初,领导只说让G开个项目,实现这样一个功能,然后给客户看看。因为领导并没有说是正式项目,就权当是原型开发,G就给顺便整理个小三层,把页面先给画起来,数据读出来展示,然后就给客户看了。这个时候的还是直接跟A公司的老总直接联系的,M先生尚未上任。然后客户就开始提意见了,要这样,要那样的,G就照着做,但一直没有正式项目的说法,就权当是按范例这样的简单方式都给写了。G也跟领导提过,这个情况是不是应该正式立个项,领导说,再等等。就这样拖拖拉拉一个多月过去了,代码也七七八八写了不少。

       有一天,领导带来个人,跟G说,你做的那个程序现在呢正式立项了,这位以后就是你们这个项目的主管,以后有什么问题就找他。G一听心里乐呵,这个把月没白搞。QP两位项目成员也就陆续的来报道了。既然正式立项了,那不能按之前那种烂法子做啊,G就寻思着把项目重新架构下,这么大个事当然得跟主管商量下,这一来二去的还算顺利(这中间有个关于使用ORM的事,见前文)。就在此时,A公司的M先生也上任了,并指定了跟X项目接头。M先生之前兴许看过原来的demo版本的程序,一听项目调整,12个星期不能有功能产出(“项目调整“这说法是领导提的,可能是怕客户有意见),就有点不乐意,催着X项目组赶赶工,这时间太久了。这话就由领导传到了X项目组,既然是领导发话,X项目组只有惟命是从,G就给大家开了个小会,打打气,加了一个星期班,连架构,带实现,把之前一个月的事,大家给翻了个新。

这之后的一个月,都是领导亲自去客户调研,然后需求以口头和少许说明的形式,转到G这边,G再根据自己的理解分解素材,设计程序和数据库,把素材转化成任务,分配到QPG自己。我想很多看管可能都看过这样的图:

 

在这样的需求调研下,程序表现往往跟客户的需求不符。领导就把需求调研的任务干脆就直接交给G了。G兼着项目管理和设计开发,本不想再参与需求调研的事,可主管说他很忙,没有太多时间调研写需求文档,公司又没有配置专门的需求调研人员,也就只好应承了下来。也就从这个时候开始,G认识了M先生,才了解到需求为何会如此零散。M先生的事,就不过多描述了,毕竟文章还是以X项目发展为主。

简单描述下X项目的组成:此项目为电子商务网站,而网站数据几乎全依赖外部接口,这个也是由于网站业务所决定的。X项目总共前前后后开发了各式各样9个外部接口。平均的说是一个月要针对一个接口开发。QP2位成员的能力,上个文章也说了,此处不再赘述。P要为X项目画界面做图片,尤其是M先生要求网站兼容IE678 FF 和谷歌浏览器,这也够P先生忙一壶的了。而这Q就闲了,每天只等着G设计好了,告诉他功能怎么怎么做,如果这天G没空设计新功能给他,他就聊一天QQ,听一天音乐。由此可见G要忙到什么程度。人不怕辛苦就怕比较,辛苦都是可以撑下来的,可要有个人在旁边这么一比较,这心理真是全然不同了。G是农村出来的娃,辛苦点不怕,只是你辛辛苦苦一天忙到晚,人家坐你旁边聊QQ,看新闻,这感觉很是不爽,最最关键是这闲的主还是得听你指挥的小弟,这真是要命。于是就出现了前文中要求加人或者换人这样的事情。无奈项目组加人不成功,G只能继续匍匐前行。

转眼就到了年底,根据初始合同需求确认书,半年过去了,却才做完了三分之一多些的功能项,G的心中有些不安。有一次GA公司跟M先生进行需求调研,讲到了对项目目前状况的担忧,M先生不愧是过来人,信心满满的说,你放心好了,这个项目我肯定给他搞活了,不可能倒。大有一切尽在掌握中的气势。虽然M先生如是说,但G心中始终是放下不,就细细总结了这半年的得失,和来年的一些计划和改进方案,交到主管手里。

这个文档的主要内容这里摘一下:

1.确定项目驱动因素,不能由M先生带领大家挤牙膏,必须要进行项目远景定义和功能集合的详细定义。

2.项目风险总结,将近半年的各种问题进行一个简单汇总,并请求主管对项目组外的风险提出相应的处理方案。

3.延迟发布周期为1周(原来是,M先生说个需求和修改意见,然后马上开动,做完就发布给M先生审查,几乎是一个星期要发布23,而且一周内已经定好在做的功能,不接受任何修改。

4.提出项目缺陷管理。对项目问题进行统一管理,这中间引起的客户和开发时间问题,希望主管能够帮助协调。

5.每日会议的召开。(原来只有12周有次项目总结会议),随时捕获风险。

6.望主管能够部分接收G手中的项目管理工作,减轻G的工作负担。

 

也主要摘下主管对这个文档的回应:

1.       明年会跟客户进行有效沟通。

2.       明年会跟领导报告,尽量解决。

3.       同意一周发布一次,但也要尽量满足客户要求。

4.       缺陷问题很重要,要管理,但还是要以客户发布时间为第一位。缺陷可以后期修改。

5.       每日会议,有这个必要吗?如果没啥必要就不要开了,大家都比较忙。

6.       明年再定,看明年能不能抽出时间来。

 

再主要写下年后的实际执行情况:

1.       不知道主管有没沟通,反正M先生照旧。

2.       好像汇报了,但没有相应反馈动作。

3.       G强制压为一周一次发布。M先生起初不满,但不发布他也无奈,就算是默认了。

4.       几乎是直接就丢下了。原因:主管再次表示要以客户发布时间为第一位。而G照旧被压着这么多的活,再来一个缺陷管理完全是自讨苦吃,也就放弃了。 

5.       这个倒是坚持了3个多月,效果还不错. 本来Q在表达方面就有些问题,就是话说不明白,每次都要被G追问很多遍才能说出点头绪来。而这导致了QG的一些不满和抵抗。于是美工P一走,就剩下GQ2个人,每日会议干脆停掉了。

6.       看到4就知道,这个没戏了。

 

回到去年年底,客户对项目总体上表示满意,G估摸着这里面有M先生很多功劳。而公司领导以业绩不好为由,让每人领了200块的过节费就匆匆回家团聚去了。当年后GM先生那里了解到年前公司已经拿了X项目绝大部分款项时,已经离过年甚远,追悔莫及了。而这事也在X项目组3个成员的心里埋下了许多的怨愤。G先生在内的成员也少不了在闲聊时间,发泄一些对公司的不满。 这也一定程度上,导致了P的出走。有句话叫兵败如山倒,这P一走,Q也开始紧锣密鼓的找新单位,终于这个月公司也接到了Q的离职申请。本就人丁不旺的X项目组就剩下2个光杆司令:G和主管。其实Q的离职对项目影响并不大,而P的离职相对来说大的多,P这一走,美工就没了,而多功能的M先生重操就业兼职做美工,这是G也得佩服的事,说啥来啥,都能上。

项目晃晃悠悠的走到了今天,眼看着也要到头了。而G站在项目的边缘不知何去何从。

 

 

 

文中G的一些作为这个岗位上的人犯的严重错误,都用下划线 标出来。希望各位看管不要犯类似错误。具体可能会再写一个文分析。还是那句话,但不保证有下文。