离职前写对XXX客服服务业务系统总结

      几个月之前很有幸的参加了该系统的一期结尾和二期工程，先说下项目的背景: 为东北一国企从传统人工客服转向信息化系统的工程。承建给某一知名高校软件学院，典型的高校工程。这里并不是说高校工程就是豆腐渣工程，世间万物都有其两面性，就看你怎么利用它。

      先来讨论一期工程物理架构: 两台比较牛X的服务器，一台做web server 一台做 database server ， 确实在物理上，这两台机器性能无话可说，无论多差的代码都没当过机。机器好并不意味着代码可以乱写。

      再说技术架构，主要用JSF+HIBERNATE+ORACL，不知道为啥选用JSF，可能那里的老师喜欢JSF吧，接触下来相关项目都是采用这个架构，可能高校工程比较偏向于技术工业化？或者这个技术架构能卖好价钱？

      最后说下业务架构，一期中主要有基本信息维护(客户信息，组织机构，产品备件，人员信息等等)，客户需求单，需求单处理流程及相关派工单生成及处理，自动对工程师进行派工单短信发送，以及在各地平台中工程师入住情况的短信交互流程。总体上一期的最终交付产品完成了大部分功能。系统上线以后经过一段时间的波动调整后最终成功上线了，成为该国企一个个性化的集CRM,ERP,协同办公为一体的系统。让该企业在同行业里信息化流程走到了前列，顺利通过验收。

      光辉背后，我们分析下那些阴影的地方。高校项目就意味着参与人员的水平高低不齐，虽然那些都是名校的硕士，在中国实力往往和学历不成正比，这当然与中国的教育体系有着不可否认的干系。学生就意味着一切都不固定，无法保证全身心的投入在工作上。而软件系统，我觉得需要时间去沉淀，只有经过参与人员长时间对业务的理解，选择恰当的技术方案，高质量的代码，代码审核，不断的重构，才能做成真正意义上的健壮，可扩展的系统。人员的不确定性，导致了写出来的代码首先是否能满足业务需要，其次是否方便以后业务的扩展。这里往往需要开发人员从业务的角度上去考虑其延展性，提需求的人在第一时间里往往并不知道他自己需要做什么。而我们并不能只做他提出的东西，可能第二天他就告诉你，他的注意又改变了。我们不能抱怨需求的改变，毕竟软件字典里唯一不变的就是 “需求会改变” 。我们能做的就是拥抱变化。学生一年又一年的更新换代，学生是个很奇怪的人群，在高校里很少能有知识分享，就怕别人强过自己。从来不知道“舍得”二字。造成学生换代时，老的恨不的一走了之，新的啥都不懂，剩下老师干着急。在高校里学生做项目，就跟小学年代，交作业一样，能跑就行。在工程里到处留下过程式的面向对象语言，没有封装，一长串参数。一个类多的几万行代码。这样的代码实在难以琢磨，但又不的不看，无形给后面的接手的人带来长时间的熟悉期。

       最后谈谈需求方，作为需求方如果没有专业的软件人员，在某些方面就不能太过执着。与开发人员一起从一个折中的角度解决双方的矛盾。在一期的工程中由于需求的不明确抑或开发人员对需求的不理解，造成系统在数据上的冗余。从而影响二期工程，后期的工程往往比前期的工程更加困难，前期是从0到1，很简单，想怎么做都可以，后期是怎么让1变成2变成3，从物理结构上讲就要伤筋动骨，所以一个好的系统往往一定要注意前期的设计怎样考虑到以后的扩展很重要，现在二期的工程统计模块就是要在一期中错误的数据中统计出正确的数据。是不是一件很痛苦的事情。以后还面临着，数据量增长的压力，对历史数据的处理问题。怎样保证系统数据的完整性和系统的性能，我想那是二期的扩展改进的过程了吧。

      想说的太多，可惜自己不是一个善于言表的人，真的希望这个工程能真正的搞好，可惜自己心有余而环境不足。

      最后奉献一首歌， Nickelback 的 If Everyone Cared 。