研发好苦

         2014年开始至今，一直忙碌于一个煤矿的oa项目，新需求，变更不断，搞得大家焦头烂额，加上天气热的原因，个个看着都无精打采，感觉像不折磨的奄奄一息，对于此种情况，我有自己的一些看法：

一、从需求上看

       1.这个项目是公司的市场部人员拉的单子，当时给这家公司承诺，终身维护，并且随意修改，这的确不是明智之举，一般来说，项目都是软件引导客户，而且免费维护时间也是一年，这就被完全颠覆，一部分原因就是这两年生意难做，能逮住就逮住，而且市场的人不懂技术，只要客户有意向，则不择手段，什么都承诺下来，结果给研发挖了一个大大的坑，再一个，项目来的突然，前期的调研走了过场，实施人员也很辛苦，但是瞎忙，只是一味的传递客户的“需求”，全部撇给研发，然后没事人一样，不仅如此，还随心所欲的提出问题，都不和客户进行沟通，只是发号施令，这一点，我觉得实施人员的作用完全没有发挥，就像传话筒。

       2.公司的架构  sping3+hibernate3+structs2+oracle11+freemarker+jsp+servlet+maven+jQuery easyUI+协同工作流+ftp，对于公司这个架构，我觉得有一点不妥，那就是ftp，用力存储附件，文件等，再就是easyUI加载页面太慢，公司前期对界面进行了美化，并升级了一些组件，这些都不错，确实起到了一些效果，但是对并发的处理比较弱，没有对新技术的引用，比如：mongDB，虽然说数据量不是特别大，但是10年，30年之后呢，特别是附件的问题，就可以用mongDB的分片存储，这样一下子就优化了存储。

      3.项目组沟通问题，需求来了以后，只是研发部门进行讨论，测试人员并没有加入，只是靠研发经理的设计文档来判断，压根就没有看到最初的需求，无法理解整体的需求，靠个人能动性根据设计文档来串联整个项目，测试的时候也只是停留在表面，无法深入到业务内部，设计文档比较粗糙，测试人员比较迷惑，也不和研发经理沟通，靠自己的理解来提出问题，然后撇给研发，最后还是研发和经理沟通，最后还是研发。

      4.研发人员，组内人员的水平相差较大，能干好活的人不多，所以一些有难度的都给了这些人，以至于有的人比较闲，有的人就一直没停，最后分奖金的时候，还是按工作量来分，不考虑难度，比较悲催。

总体来讲，项目从一开始就没有人来严格把关，导致一步步沦陷，出了问题最终的矛头都指向了研发，研发好苦！！！！！