XX市XX公司的资源系统项目感想

最近两个月在忙这个项目--是个很赶时间的项目。忙到周六周日也要自觉加班。很累,甚至有时候想吐,但是还是撑过来的。下辈子不做开发了~~~

这个项目从7月开始投标然后陆陆续续有人加进来,我是8月初加进来的。7月部门经理A就先主导需求调研,同时招聘这个项目的项目经理。初步需求搞定了就到了8月份。由于自己有相同的项目的开发和管理经验,A要求我过来支撑一下前期开发工作。等到项目经理到位了,A就脱身了。然后就进入了我们辛苦的8月和痛苦的9月。

做项目的向来都很辛苦,不加班不正常。不过这样频繁的加班,我是很难顶,感觉是自己的极限了。人员到其后,A问我这个项目问题大不大。自己当时没有理解A的意思,再和之前的项目开发做对比,就很乐观地说没问题。我这么一说,A就渐渐脱离了这个项目,等到我反应过来的时候,自己已经集开发管理、设计和开发于一身了。新来的项目经理B一直在熟悉需求,迟迟没有上手。需求和进度的控制也没有人做。

下面是一下零零散散的感想

1、A脱身太早,需求调研衔不上。我和B到位后,A就成天出差。虽然做了初步的需求调研,很多东西又是有待客户确认的甚至是业务逻辑不清晰的。需求的不明就直接得影响到我们对业务的理解和系统设计。也许是系统业务比较复杂,原先招到项目经理C,在A一个下午的业务培训后,C第二天就不来公司了。呵呵,有的时候用这个方法考验一个人的抗压能力还是比较有效的。

2、B迟迟不能把握需求。在我看来,一个项目的责任是自上而下的。所以谈感想的时候也要自上而下。B是A强力推荐的。估计在社会经验上面的丰富程度让A做出了这个决定。8月份的B始终都处于整体业务的梳理阶段,至于需求调研和项目进度的控制做的很少。我有时候也在埋怨他不能快速上手,甚至有一次急起来当面说B控制不到需求(这个性格需要改改)。如果我是B的话,有了这个教训,在做新业务的时候,自己会努力的快速熟悉业务并对需求做跟进。

3、我的定位问题。原本以为A会一直主导本项目的需求调研和项目管理。所以给自己的定位是开发兼内部技术支持的角色。后来发现A脱身的时候,自己已经在做他做的事情了。这个时候,如果可以及时和A沟通,讨论如果继续支持项目进度的话,估计自己不用经常加班、项目管理也会比较顺畅。我只是默默的加班,经常性的加班也导致工作效率的下降,以此恶性循环。

4、开发环境的搭建问题。7月份在调研的时候已经有人进入这个项目并开始做架构的梳理和公共环境的搭建了。不过搭建的环境确实不敢恭维。我们拥有相同的项目经验,当不一定可以原班照抄的把原先的项目搬过来用,这一点小公司应该最清楚。搬过来后的结构,无用的代码堆积得让人感觉像是一个超级大胖子身上的肥肉。公共数据库始终都没能搭建好,用户使用的informix9.4,而我们用了11.5版本的,而且试用版的只支持一个用户连接,严重影响了共同开发的效率。QQ上成天都有人要求释放连接。另外没有搭建WEB服务器为我们后来部署给用户的时候保留了相当大的难度。

5、叫不是很强的应届生开发复杂的业务模块。只一点对项目没有太大的影响,但是其中的问题需要抛出来。一个很赶进度的项目,在我看来最好不要让没有项目经验的人参与。我这里说的是项目经验,也许用开发经验来形容会比较好。一个新人在早期确实是只有投资没有回报的,我们不可以责怪他。但是当我问道为什么要叫一个新人到这个项目的时候,A说:他在简历上写了有1年的项目经验!我们先不说这个新人使用的骗人手段。为什么在面试的时候不能对这个人进行摸底呢?就因为他要的工资低!不由得,我想到自己进入公司的情况,应该也是一年经验而且要的工资比较低。这个习惯要改,至少如果是我招人的话(不知道什么时候能到这个级别)。

6、合作的问题。这个问题在我们的开发中没有成为一个大问题,因为大家都想把这个项目做好。需要提到的一点,就是和老板的沟通问题。在为用户部署程序的时候,发现的web服务器支持jstl有些问题,导致需要现场更改很多的代码。事后问道B,回答:老板说web服务器没什么差别,就没有管。如果是当时的我,同样也不会反驳老板,因为我确实没有用过websphere,更不要说和tomcat的差别了。更何况是老板,没有充足的理由,也最好不要反驳他。现在的话,有了彻夜修改代码的惨痛经历后,情况应该会不一样了。说到头还是经验的问题。

7、乱七八糟的问题。比如代码管理服务器经常死掉、数据库版本不一致等等。

总结一下:

大多情况下,付出是有回报的。有朋友就跟我提议,赶快让老板加工资。很现实,可我没有这个习惯,也不习惯在这个节骨眼上做这样的事。作为经验的总结,我很高兴自己能以当前的角色进入这个项目,虽然没有得到相应的物资或者精神奖励,但是我很清楚自己得到了什么。这是最重要的,至少对现阶段的我来说。

1、要把需求写好。这个不用说了,谁都不想更改设计。

2、做好需求的跟进和需求的版本控制。需求也有版本,做好了,加以时间的控制。切切实实让内部的开发人员感到自己没对的是一个确定了的需求。

3、模拟环境和开发环境。

4、控制好用户的进度要求。这个需要比较高的谈判技巧和应变能力。总体来说还是为内部创造比较宽松的开发时间。不要三天两头的过去调试系统,时间浪费很大。

5、合理分工,尽量发挥各人的优势。再牛的人也有极限,分工要合理。

6、需要注意程序员的心态。过长时间的加班会导致身心疲惫,开发效率可想而知。需要一些休息或这实质性的进展让同志们看到希望。

7、牢牢地跟进开发进度。适当地做调整,让项目始终处于掌控之中。

猜你喜欢

转载自pcial.iteye.com/blog/248195
xx