关于在软件开发过程中建立三道风险防线的想法

最近在工作的过程中，遇到了一些“本不应该”出现的问题（相对而言的，没有什么问题是“

应该”出现的） --- 开发完的功能，经过开发人员的单元测试、测试人员的“反复”测试，提

交给客户后，客户马上就会发现很多业务功能上（非代码质量上）的问题，做的东西得不到客

户“心目中”中的那个“完美度”。

既然非代码质量问题，那么就转到需求上了，这里问题就出现了：
1.业务人员和客户当时讨论需求时的想法和意见一致了吗？
2.开发人员是“按需求”写的代码吗？
3.测试人员是“按需求”测试的吗？

懂银行风险管理的朋友应该都知道，当前银行在进行风险管理的时候有三道防线，即:
处于第一道防线的业务部门；处于第二道防线的资产监控部门、合规部门、信用评级部门等；

处于第三防线的审计部门（或稽核部门）；业务部门处于风险的最前沿，要严格按照法律法规

、规章制度办事，能做的业务就做，违反规章制度的业务一定不做；合规部门处于第二道防线

中，要严格监督检查各部门所依照的规章制度、规则准则是否合规；而审计工作放在最后的防

线，对银行内控的重要措施，对防范风险起到重要作用。经过这三道防线，理论上对风险管理

会有质的提高！

再回到我们的软件开发过程中，
首先讨论上面遇到的第一个问题 --- 1.业务人员和客户当时讨论需求时的想法和意见一致了吗

？

相信大部分情况下，我们“认为”肯定是一致的，需求还没定下来的情况下，我们谁又会去开

展开发工作呢？！（受自己工作范围的制约--俺只是一位普通的程序员，还没得到讨论需求的

级别，俺在这里也想不出很好的在这个环节进行风险控制的好措施，还望大拿们多给些建议。

遇到的第二个问题，这个我就比较熟悉了，问题的答案肯定是：“没按要求”！那么真的是开

发人员素质低（能力、道德）没按要求去做吗？未必。首先，我要问，你的要求是以什么形式

给予开发人员的？有没有严格的流程控制来确保需求的明确性？不要告诉我你是以口头的方式

哦！但以简单的口头方式授予需求，然后开发人员就下手写代码的情况还真的大有存在（特别

是开发流程不规范的中小公司），这样导致的后果，就是什么情况都有可能发生（何况是做非

所需呢）!

我们再放开一步讲，即使有了第二种风险的存在，那么开发的功能怎么又会逃出测试人员的眼

睛，流到客户那里呢？是测试人员不负责吗？答案是未必吧（又替打工仔说话了）！首先在这

里我们是不是要确认下，测试人员对要测试的功能很熟悉了吗？他们对需求的理解度和业务人

员、和客户是一致的吗？如果是一致的情况下测试人员又没测出来，那么这里的测试组可以直

接拔掉了！但往往这里很多人给不出一个肯定的回答。因为没人来保证测试人员真真的熟悉了

需求（实不相瞒，我遇到的情况就是，开发完了，直接让测试人员来测试了，他们至此还不知

道自己要测试一个什么，这种情况又往往多出现在客户要求我们对部分功能的优化上，因为要

改的范围小，我们很容易就放松了要求，业务人员匆匆对开发人员一讲需求，然后开发人员就

着手开发了---这样就导致我们在此环节把风险遗留了下来。那么我们怎么保证测试人员非常熟

悉开发人员要做的是什么呢？那就是让测试骨干参与前期的需求讨论！这是非常重要的一点！

也是测试组的生命所在！因为不理解业务的测试组就谈不上是一个合格的测试组，不熟悉需求

的测试组就是一个报废了的测试组！在国内很多中小型的软件公司，流程都还不是很规范，但

我强烈建议大家要重视起这一点，调整开发流程，把测试人员调整到前期需求讨论阶段，而非

开发时或开发后告知，因为这是我们提交给客户产品最后的环节！

有时候我在想，一个开发人员是否应该承担起软件质量的全部责任。因为很多时候我们遇到的

情况追根揭底都是程序的问题，即使是需求不一致的情况！再比对一下银行经营中的风险管理

，对于银行经营中的风险损失我们都很清楚是“业务流程中的某个环节存在风险或有漏洞”，

那么针对软件开发过程中的问题，我归结为是我们的“开发流程的某个环节出现不完善或有漏

洞”，这个道理大家都懂，但执行力往往不够，“时间太紧、修改范围小”都是我们推辞的理

由，但为了我们团队的声誉，为了我们良好习惯的形成，举手之劳，将受益永远！

---受制于眼界的狭隘性，以上想法不一定适应于每一个团队，这个只是针对我遇到情况的一种很好处理罢了，大家有则改之，无则加勉。也真诚的希望大家给予更好的建议。。