从中行网银问题看软件开发流程

我有中国银行借记卡一张、信用卡一张，希望能通过网银手动从借记卡还款到信用卡。这个功能很常见，相信招行、工行、建行的用户都能实现。于是我兴冲冲开始了一个噩梦之旅。

首先到中行柜台办了借记卡网银业务，拿到一个动态口令牌。问小姐如何关联信用卡，答曰从网上直接关联。回家后从中行首页“登录新版网上银行”进入，一切顺利，能管理借记卡了。但是根本没有地方进行信用卡关联。在打过3个不同的800或400中行咨询电话后终于闹明白必须到柜台办理管理。我#@￥%！

隔段时间又到中行柜台关联信用卡，小姐说不能关联，斩钉截铁就是不能！@#￥×（！

回来后继续电话、上网站查，应该能啊！又去，这回小姐说她们从来没关联成功过，原因不详。但是愿意试一试，只是必须让我带上动态口令牌。啊，没带！@#%￥&×！

第二天老实带上动态口令牌继续拜访中行，小姐倒腾了半天，也没问我要口令牌就说还是不行，不过这回给了理由：我的借记卡是新身份证办理的，信用卡是老身份证办理的，位数不匹配，所以系统认为这两张卡是俩不同的主，不能关联！……%￥#@×！

这回我彻底服了，中国银行作为国内银行的老大，不仅是几大银行中最晚推出网银的（今年才有真正意义上的网银，而我99年就用招行一网通网购图书了！），营业员业务是最不熟的，网银系统也是做得最烂的，连个新旧身份证匹配都没做。从软件开发流程来看，犯了以下若干错误：

1，需求缺陷。显然开发人员没有通过Use Case详尽分析各种用户使用情况（Scenarios），遗漏掉同一用户可能使用新、旧身份证办理不同卡的情况。这是错误的开始。
2，设计阶段严重失误。就算需求遗漏了，任何一个系统设计人员在设计关联时，如果需要比较身份证是否匹配，就应该想到身份证有新、旧之分即长度之分。这是常识啊，地球人都知道。所以我只能想像设计人员考虑到了但是因为觉得既然需求没写，就可以不管。其实这在软件开发中，属于非功能性需求或隐含需求，没有写出来也需要实现。当然最好写出来。总之错误流传了下去。
3，代码阶段严重失误。就算需求和设计都遗漏了，任何一个代码开发人员在定义身份证变量时，首先就应该考虑长度问题，同样，常识啊。所以我只能想像代码开发人员考虑到了但是因为觉得既然设计没写，就可以不管。由于代码开发人员的疏忽或失职让错误继续前进。
4，功能测试不足。对于复杂系统，仅仅依据需求说明书进行测试还远远不够。Monkey Test或Expert Test都能发现一些交互的、隐藏得很深的、需求说明书不能完全覆盖的问题。显然由于没有足够的功能测试，这个错误再次向用户逼近。
5，Beta测试没有或无效。所谓Beta测试就是在系统正式发布前让部分最终用户先行体验，进而发现问题并及时修改。Beta测试不是软件开发必须的，但是对于复杂系统是强烈推荐的。所以，我严重怀疑中行网银没有进行Beta测试，就算有，也无效，因为没有发现这个严重问题。Beta测试几乎是软件面对用户前的最后一道关口，没有Beta测试或无效的Beta测试最终让问题暴露在用户面前。

如果中行在网银开发的上述5个流程中任何一个发现并报告这个问题，并及时修正，就不会让我如此郁闷（想必还有不少用户有同样的遭遇）。可惜的是没有一个环节堵住了这个问题。要么是流程还有漏洞，要么是执行者（开发设计人员）缺乏经验或责任心，毕竟，再好的流程都是人在执行。

更可怕的是，从我发现问题到现在又过了快两月了，问题依旧。所以，我郑重决定，从此不用中行卡。