商业银行软件外包的管控.docVIP

商业银行软件外包的管控 一、需求管理中的常见问题 （一）来自业务部门的问题 软件工程理论认为，在软件生命周期中，需求分析是最重要的一个阶段。为了准确地掌握业务人员的需要，需求管理人员往往引导业务人员准确表达，再经过综合分析提炼和规范化表述，与业务人员进行书面确认。实际工作中，需求分析往往存在一些问题，给工作造成不便，甚至由于软件重新开发和延迟上线而带来大量的损失。 一是需求表述和传达不够清晰明了。业务人员提出需求时往往使用了专业术语，由于经常处理相关业务，业务人员在提交需求时只是写了大概的要求，许多细节没有详细展开说明，认为开发人员理所当然应该知道，但需求管理人员可能无法准确理解其意思，尤其是开发人员不一定对每一项业务的细节都很了解，造成开发出的系统和预期不一致。 二是需求不够具体细化。有时业务人员提出的需求也只是一个初步设想，特别是针对不熟悉的新业务，业务人员也只能对要开发的系统进行模糊大致的描述，或者没有经过系统完整的思考，在可行性上存在问题。这样容易造成开发人员的盲目性，花费较多时间和人力才能实现业务人员的需要，或者开发出来的系统主要功能实现了，但是一些小问题，给工作带来不便。 三是对《需求分析说明书》的确认不够重视。《需求分析说明书》是开发人员与业务人员进行需求确认的书面说明，是开发人员进行软件开发的依据，也是产品最终验收的依据，因而其准确性、规范性和可行性都要求很高。但在实践中，需求提出人员有时在没有充分阅读文档的情况下就匆忙签字确认，导致开发人员按照此说明书进行开发的系统和业务预期不一致，或者对说明书的权威性不够重视，签字确认前没有经过充分思考，而在系统开发过程中不断更改需求，导致软件开发效率和进度受影响。 （二）来自开发部门或外包公司的问题 一是对需求的理解不深。由于开发人员通常是技术开发的专家，并不一定具备相应的业务背景知识，或者与业务人员出发点不一致，容易造成与业务人员的理解不一致。有的开发人员在对具体业务流程和做法不了解的基础上，仅按照自己的理解去开发，使得开发的软件产品与预期相差较大，有的甚至存在常识性错误，造成大量的返工。有些外包公司为了节省成本，在已开发完成的相似产品基础上进行简单修改，对新用户本地化改造能少就少，导致业务人员使用时才发现毛病不断，也影响软件系统的正常使用。 二是软件交付前的内部测试不充分。部分软件外包公司内部质量控制把关不够严，加上有银行的需求管理部门和人员做测试，容易产生松懈的思想，对交付前的软件产品测试不充分，导致用户方需求管理人员开始测试时发现很多问题，甚至包括显而易见的错误和与需求说明书不一致的地方，增加了用户方的不便。 （三）来自需求管理部门的问题 需求管理部门作为负责新需求从始至终全过程跟踪管理的部门，关系着软件开发的质量、周期和最终效果。但实际工作中，需求管理部门也存在一定问题。 一是需求的全面控制存在局限。需求管理部门需要面对来自多个业务部门和人员的需求，通常从服务银行业务大局的角度，尽可能满足业务部门多种多样的需求。同时，需求管理部门并没有超越其他业务部门之上，对需求管理缺乏足够的控制权，实际中通常受制或依赖于业务部门，需求的跟踪和推动比较困难，对需求开发的进程和规模缺乏控制，对软件的开发改造缺乏系统性，甚至对合理性、经济性和可行性不够的改造需求也不能喊“停”，可能造成不必要的损失浪费。 二是需求管理的规模效应还没有体现。目前，需求管理部门的职能多限于需求的集中化管理，仅充当业务人员和开发人员之间沟通的简单协调，对需求的评估考核、统计分析和信息反馈等工作开展的较少，需求管理也较为零散化，没有实现需求统一管理的规模效益，比如一些软件缺陷常常通过多次需求改造、多次“打补丁”来完善，而需求管理人员在从根本上理顺和完善系统方面没有能发挥应有的作用。 二、需求管理工作改进建议 需求管理需要业务部门、开发部门和需求管理部门等各方的共同努力，尤其是加强需求管理在职责划分、制度流程设计、质量控制体系建设等方面的工作，不断提高需求管理的规范性和效率性。 一是加强与业务人员和开发人员的沟通协调。需求管理在需求的表述和传达过程中，应该不断加强准确性、完整性和真实性。同时，针对需求业务涉及人员多、面广的特点，需求管理人员应当主动了解获取业务方和技术方的知识背景和实际情况，加强与业务人员和开发人员之间的沟通协调，帮助二者之间对需求形成较为统一明确的认识，及时掌握需求形成和软件开发的进程，了解其中的问题和困难，尽量把问题在软件开发完成之前解决。比如在业务人员表述需求时，需求管理人员可以根据经验对相关需求提出合理化建议，一起对项目、特别是需求说明书，进行评审，检查是否满