目前的项目中,暴露出两个比较严重的风险,吸取教训特总结于此。
一、网银项目的模式请见前面的介绍,中间业务平台提供的接口文档给我们项目组,按以往的流程都是由提供方配置IO表(在网关中负责解析、转换双方数据的文件),但银行方的经办人在项目开始的时候要求我们来配置此文件。由于项目组成员不熟悉这边的流程,于是IO表由项目组来配置,由于人员对此都不熟悉,而且中间业务平台也未提供一份配置IO表的详细说明(仅有一份网关对IO表的要求),风险在此产生,但至今才发现,出现的结果就是SOAP返回的报文和页面显示的数据一致,但与交易端显示的数据不同,经过排查发现是此IO表的2个字段顺序与接口文档不一致,于是项目组将接口文档与所有的IO表核对了一边(92个文件,46对IO表),所幸只发现这个IO表配置有问题。
总结:对于项目中不熟悉的流程及其他事情,最好是问问相关领导的意见,而且尽可能的要求经办人、中间业务平台提供详细的文档及邮件,做到有据可查。由于这种工作肯定是在项目组中平均分配,那么PSM一定要将要求做清楚的说明,宁罗嗦勿错过。在这种风险发生以后要尽早提出,让整个大项目组能作为经验的积累。
二、由于贵金属的项目中涉及很多的金额、计量单位,但是中间业务平台提供的接口文档中对数据的单位说明几乎为零,不久前,已经产生了一个生产问题,白银的行情中的计量单位应为元/千克,但开发人员以为是元/克(因黄金、铂金的单位均为元/克)。对于项目来说就存在很严重的风险,开发人员及测试人员对数据的单位没有可以依赖的一个标准,换而言之,就是根本不确定某个数据的单位是否正确。(目前提出了此风险,但还未有解决方案,我的建议是:1. 删除页面中所有的单位,和客户端一样只显示数值 2. 由业务人员或中间业务平台提供单位依据的标准。)
总结:无论是用哪种方案,由于项目的一期已经投产,改动起来会有很大的风险,而且删除页面中单位的方案客户接受的可能性很小,因此改动而引起的工作量也很难让客户认可,所以说这个问题应该算是一个教训,对于中间业务平台提供的接口文档项目组一定要做评估后再接受,而且要培养项目组的怀疑精神,对于需求、设计、接口文档都持有怀疑的态度,这样才能让问题尽早的暴露,降低修改所带来的成本和风险。