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