EAI项目实施心得

　　这一段时间，忙于在代码和A公司之间奔波，所以日志也没有时间来写。
　　今天谈谈我近段时间在客户实施的心得。
　　到现场实施情况是比较复杂的，所以从刚刚开头我就没有像专家一样的到处都问（调研时可以像专家一样告诉客户一些大道理）。我们的程序是基于合同技术附件签订的，实施也就跟着签字的需求和目标走。
　　由于前一段时间让一群学生写了一些代码，虽然在质量上我有所“查阅”，但是问题最大的也就是在这里，在实施前只是把大致的错误进行了修改，就匆匆到现场实施。
　　核心代码由于是自己的思想，也让放心的手下写了，但是还必须得测试和验证其准确性。这是一个重要的工作，也可能会涉及到一些改变。
　　第一天，到了客户现场，先是对其环境要求，确定完主机和数据库后，就开始安装布置，1个小时后全部搞定，基本上给客户讲了一遍怎么使用（很粗略，因为 以后我们有培训）。接着就联合PDM系统和ERP系统进行测试，还幸运（不相信迷信也这么写），没有出事，用户的输出结果也正确，呵呵，收工回家。
　　其实，里面的问题很多。只是用户对这个陌生的事物还有好奇的心理，没有深入去学习它。
　　第二天，接着实施，在不断的测试过程当中，问题就出现了，很小的问题让客户对我的软件产生了怀疑，比如供应商编码和供应商PN号为什么输出是一样的？ 员工ID为什么传递不过来？假如PDM发布同一个树但有不同的组成结构时，做的处理不符合我们的实际业务？为什么不同层次的装配件再次发布时，数量不相 加？假如我这一次发布错了，能不能删除？
　　客户提出了很多问题，我知道我的程序开始让用户认可了，所以我的态度比较友好，（说实在的，哪时候真想找个替身），我把问题罗列出来后，做了归类，并给客户承诺完成时间，并态度友好、热情、友善、和气。。。。的给用户出错原因。当然心态必须是诚实。
　　一般客户会提出这几类问题。
　　一、软件本身的BUG，是自己的责任，勇敢的承认自己的错误，合同都签定了，还不让修改一个BUG。
　　二、在实际需求时，考虑的不充分，或者是技术实现上有制约的地方
　　三、实际业务和输出结果不符合。
　　这三类问题，前两类我们很积极并承诺尽快得给用户解决，就是不在合同之内的事也加入代码实现，我们的目的就是先让用户使用起来。
　　第三类问题，不管用户多么着急，我们也对之的实现优先级降低，同样必须让用户书面提出需求我们再做。
　　后来的三两天就是修改程序，不过这个时候我手下已经没有人了，所以我自己这两天很辛苦。同样，也发现了很多错误，尤其是表现层，我真是恨这帮学生呀。害的我不得不对之进行修改。
　　再以后就是实施，就算是我的第二个阶段吧。
　　这个阶段里，我就象一只狗似的，看见客户负责人就赶紧用舌头去舔人家的脚，（想起了发廊的小M辛苦的为我按摩），晚上人家都下班了，为了赶进度只得自愿加班，晚上经常9点后回家。
　　这个阶段里，是比较富有成果的，首先把客户前一段时间的BUG和考虑不充分的地方进行了弥补，而且用户对我修改的速度也很佩服。呵呵。（高兴的我自己好象是一个伟大的。。嗯，实施家）
　　等到用户测试结果正确，不，应该是准确（我的认为），而且从长期的测试来说，我心理比较塌实了，我进行第三个阶段。修改需求并加入新的程序。
　　这个过程比一个阶段好一些。我可以坐回公司来，上上网，聊聊天，喝口茶，再写写程序了，一两的活两天干，还能混吃两顿饭。呵呵，目前就实施在这里。

　　对EAI产品本身我给用户提供了一个规则，因为我的软件当中有版本管理和BUG提交模块，所以我每一次的修改就对版本有所影响，小的改动加小版本，大 的改动加大版本，说来也巧，等正式上线刚才从0.8上升到1版本。呵呵。同样用户的BUG管理只开放给系统管理员，我可以每天收集一下BUG，并及时进行 修改。

　　对TOMCAT中间件服务器和程序本身的性能优化是一个大问题，现在正在解决当中。
　　程序的稳定性和并发控制也准备在下一期进行修改。

　　请关注我的贴子。