DMS北京投产支持

去年9月份DMS准备投产， 卡中心将DMS一帮兄弟火急火燎的召到北京实施投产。但当众兄弟到位以后，卡中心业务部门感觉到很大压力。因为他们平常操作的一些常用功能在系统中实现的不是很完美，很影响他们工作效率。所以他们抵制投产，强烈要求在实现或修改功能后才能投产。为什么在UAT业务部门没有很明确的提出来需求呢？为什么卡中心内部运营和业务部门都没有协调好就把我们叫过去投产呢？最后的结果是暂不投产，业务部门继续使用老系统，并且和外部厂商续签1年合同，等DMS完成业务要求功能后再投产替换老系统。

去年DMS投产以失败告终，有我们的原因也有业务、运营的原因。我们的原因是前期工作做的还是不够充分，没有深入挖掘的用户的需求，对用户的操作习惯不了解，没有很贴近的观察业务实际操作流程，而很多需求的实现都是想当然的。当系统成型后展现给用户，用户觉得不满意甚至抵触，导致用户对我们系统的怀疑，对我们是否了解业务的怀疑，容易产生对系统实施或需求挖掘容易产生不配合的想法。同时系统又要重新编码实现，做了很多无用功，后果是“相当严重”。所以在开发实现之前需要深入的调研需求，对需求的分析应该注重细节上的确认，往往一个小地方的忽略，对系统的功能影响会相当大。

失败会不会重复上演？2011年3月16日，我们又被召集去北京投产DMS，还是时间很紧张。业务部门是上帝，一召唤，我们就屁颠屁颠的赶过去了。开始是我和项目组另外一个人先去准备投产环境，项目经理随后驾到。到达第二天赶到卡中心，等软件中心发出投产版本后，需要将新版本更新到准生产环境，然而卡中心对准生产环境的访问控制的很严格，只能通过指定的终端访问或者只能在外围访问指定的端口。所有又折腾着去找不受限制的访问终端。因在卡中心偶没几个认识的，打电话问了一圈，找这台机器试试那台机器试试，一天的工作接近尾声了，才在DCM处找到一台机器。悲哀，刚开始就这么困难，支持很不到位。

版本更新完成后 ，查看准生产测试日常文件是否已经传下来。cd到txt目录，数据文本已下传但有几个文本的文件名异样。在原来的文件命名规则的最后面都加了".SH" ，还有几个文件不在要求的范围内并且是空文件(size=0)。找ATOS确认情况，ATOS说文件名带有".SH"的文件是表示上海的数据，而未带的是非上海的，几个空文件是他们系统实现的问题每次跑批都会自动生成的。因文件名不符合DMS规范，在和他们协商后将文件名改为DMS规范形式。空文件因不影响功能，就暂时保持下传空文件。准投产时还有这样的问题，说明DMS就没有和外围系统明确过接口或者说明确了但未充分测试。

数据文件都规整了，开始导入。导入中发现报文件重复错误，和ATOS确认。其将几个不应该传给DMS的文件下传了，导致文件重复，要求ATOS修改。又是一个接口问题！！！

数据导入完成了，通知业务加班加点的做测试工作。业务完成交易后跑批上传数据。崩溃！生成文本时出错。查找原因发现问题是在不应该出现多条记录的情况下出现了多条记录，导致文本生成失败。和业务确认实际上是否有多条记录存在的情况，业务也不知道。咨询老系统维护人员，他们说不存在多记录情况。最后仔细询问才得知DMS和老系统输入的标准不一样。按老系统输入是不会产生多记录情况，而DMS的标准是不可避免会产生多条记录的。最后只能当场改程序，虽然这样做违规而且有风险。但为了投上去也只能先斩后奏了。这问题暴露出UAT测试不充分，我们对此需求的分析也不充分。

前期工作完成后准备投产，在投产评估会议上，又冒出一个问题。DMS投产后将外包给DCM进行日常的维护，而DCM对新上线的系统有他们自己的要求和评估，有自己的流程需要做。不得已投产将延迟一个星期。又是一个头疼的问题，这个过程应该在投产前都应该的想到的，计划时应该请DCM一起评估工作安排，最后搞得比较被动。又一次提醒我们，对自己不可控的投产环境应该提前确认其对投产的要求以及相关流程步骤，对每个可能出现问题的环境有一个方案，以免遇到问题措手不及。凡是预则立，不预则废。

没能按时投产，偶又先从北京撤了。虽然暂时还未成功，但也汲取了教训，发现了很多问题，也是有收获的。