2014年开始至今,一直忙碌于一个煤矿的oa项目,新需求,变更不断,搞得大家焦头烂额,加上天气热的原因,个个看着都无精打采,感觉像不折磨的奄奄一息,对于此种情况,我有自己的一些看法:
一、从需求上看
1.这个项目是公司的市场部人员拉的单子,当时给这家公司承诺,终身维护,并且随意修改,这的确不是明智之举,一般来说,项目都是软件引导客户,而且免费维护时间也是一年,这就被完全颠覆,一部分原因就是这两年生意难做,能逮住就逮住,而且市场的人不懂技术,只要客户有意向,则不择手段,什么都承诺下来,结果给研发挖了一个大大的坑,再一个,项目来的突然,前期的调研走了过场,实施人员也很辛苦,但是瞎忙,只是一味的传递客户的“需求”,全部撇给研发,然后没事人一样,不仅如此,还随心所欲的提出问题,都不和客户进行沟通,只是发号施令,这一点,我觉得实施人员的作用完全没有发挥,就像传话筒。
2.公司的架构 sping3+hibernate3+structs2+oracle11+freemarker+jsp+servlet+maven+jQuery easyUI+协同工作流+ftp,对于公司这个架构,我觉得有一点不妥,那就是ftp,用力存储附件,文件等,再就是easyUI加载页面太慢,公司前期对界面进行了美化,并升级了一些组件,这些都不错,确实起到了一些效果,但是对并发的处理比较弱,没有对新技术的引用,比如:mongDB,虽然说数据量不是特别大,但是10年,30年之后呢,特别是附件的问题,就可以用mongDB的分片存储,这样一下子就优化了存储。
3.项目组沟通问题,需求来了以后,只是研发部门进行讨论,测试人员并没有加入,只是靠研发经理的设计文档来判断,压根就没有看到最初的需求,无法理解整体的需求,靠个人能动性根据设计文档来串联整个项目,测试的时候也只是停留在表面,无法深入到业务内部,设计文档比较粗糙,测试人员比较迷惑,也不和研发经理沟通,靠自己的理解来提出问题,然后撇给研发,最后还是研发和经理沟通,最后还是研发。
4.研发人员,组内人员的水平相差较大,能干好活的人不多,所以一些有难度的都给了这些人,以至于有的人比较闲,有的人就一直没停,最后分奖金的时候,还是按工作量来分,不考虑难度,比较悲催。
总体来讲,项目从一开始就没有人来严格把关,导致一步步沦陷,出了问题最终的矛头都指向了研发,研发好苦!!!!!