求变更在软件项目中是经常发生的，许多项目失败的根源就是需求变更失控；金融行业由于自身的特殊性，对于系统的稳定性、安全性与可用性要求更高。如何管理来源众多、纷繁复杂的需求变更请求，成为每个银行软件项目必须重视的问题。本文针对当前银行软件项目需求变更管理中存在的一些问题，提出福建农信需求变更方法论，并据此总结在有效管控软件项目上的实践经验。
需求变更在软件项目中很常见，设计初期的不合理、后续需求的追加及成本控制等因素都会导致需求变更。每一次的需求变更，对项目成本、软件质量、交付时间而言，都是一次冲击与考验。2004年，美国麻省StandishGroupInternational公司公布了一项调查数据，在已完成的13522个软件项目中，绝对成功的项目仅为29%，彻底失败的项目为18%，受到质疑的项目高达53%。受到质疑的项目包括费用超支、超出工期的项目。在项目不成功原因的调查中提到最多的就是“需求变更”。
由上可知，软件项目需求变更必然出现，影响深远，甚至决定项目的最终成败，故银行软件项目建设过程中要规范管理，根据项目推进过程中越来越丰富的项目认知，不断调整项目开展方向和资源配置，对各方提出的需求变更申请进行汇总管理，方能最大程度地满足客户等相关干系人的需求，避免需求变更失控，提升项目价值。为此，笔者将就银行软件项目的特点，描述需求变更管理基本原则，结合福建农信的特点，提出适合银行乃至二级法人的需求变更方法论。
银行软件项目需求变更的来源和影响
银行软件项目需求变更来源广泛，与传统软件企业需求变更差别在于对稳定性、安全性与可用性要求更高，根据其产生原因将重点几项概括为：
（一）项目需求分析阶段的偏差，包括：产品范围定义的偏差、业务规则不合理，例如网易贷平台项目组对贷后预警功能提出需求变更申请，要求由原来的仅POS贷进行贷后预警改为全线产品进行贷后预警，修改了原有不合理的业务规则，使系统更符合实际需求；
（二）项目实施阶段中的意外状况，包括：应对风险的紧急措施或规避措施、项目执行过程中无可避免的被动调整、团队人员调整、外部事件，例如福万通e平台项目出于规避风险的考虑，新增对每人每月开户次数的控制，提高了风险防控能力；
（三）随项目发展提出的必要变动，包括：市场战略调整、技术革新要求、新政策出台等，例如：福万通e平台项目中电子账户注册时的“四要素认证”根据人行302号文件变更为“五要素认证”，新增了对账户类型的校验，满足了监管的要求。
银行软件项目需求变更对软件开发的影响是多方面的，包括：
（一）增加项目的人员和费用开支，影响开发进度。
在一般的项目计划中，对需求变更都有一定预算，需求变更往往意味着业务规则的重新梳理、代码接口的重新设计、测试工作的反复，大量的、频繁的需求变更无疑会增加项目人员的工作量、费用开支；而需求变更失控往往会导致生产问题无法得到及时解决、经济损失无法挽回、项目延期交付等问题，增加了项目的实施风险，严重时可能直接导致项目的失败。
（二）影响软件质量。
银行软件项目关联系统过多，需求之间总是具有一定关联性，相关需求形成需求链。一个业务规则的变更，小则影响关联交易，大则影响至外围系统。如果变更提出、评审时遗漏需求链中的某些环节，就可能在变更实施中引入一些难以察觉的错误，投入生产后就会出现非但没有优化功能，反而影响到的其他正常交易的情况，比如新增放开电子账户的柜面操作时，就需要对调用到改动的接口的其他柜面交易进行测试，不可影响原有功能的实现。
（三）影响开发部门与业务部门的合作关系。
软件项目是业务部门与开发部门之间的一种相互信任、相互合作的过程。如果二者之间在软件需求变更上产生不同意见，而且没有得到妥善的处理，将会导致二者之间的合作关系破裂，甚至造成软件开发中断等严重后果。
需求变更管理的基本原则
需求管理涉及3个主要问题：将需求进行标识、分类以及组织，为需求建立文档；管理需求的变更，说明不可避免的需求变更是如何被提出、协商、确认的，并且将整个变更过程记录在案；对需求进行跟踪，保持需求和软件产品之间的一致性，及相互关联性。需求变更是缺陷放大的一个体现，若不能正确面对并加以实质性地解决，需求变更未能及时处理所造成的影响将可能被放大，甚至导致不可挽回的严重后果。因此，需求分析人员、软件设计开发人员应当建立需求变更管理的基本原则，主要包括以下方面：
（一）进行项目基准管理
需求变更管理贯穿项目始终，并应用于项目的各个阶段，项目经理对此负最终责任。对于项目管理计划、项目范围说明书和其他可交付成果需要通过谨慎、持续地变更管理。项目计划一经批准，就成为项目执行和考核的基准，也只有经过规定的变更程序才能做出修改。在一般银行项目中，业务是骨，技术是肉；业务是业务规则的制定者，技术是业务规则的实现者，二者相辅相成，缺一不可；技术需要在业务确定系统功能、业务规则的基础上进行程序设计，如果项目计划在一开始就漏洞百出、含糊不清，那么后期业务与开发的沟通势必出现相互推诿，浪费时间与精力，严重影响项目进度。
（二）建立变更控制流程
变更的过程应该有严格的控制，确保只有经过批准的变更才能进行修改。所有的变更请求都必须以书面形式记录，并纳入变更管理以及配置管理系统中，按照变更控制系统和配置控制系统中规定的过程进行处理，保证有迹可循。需求变更可能来自业务部门、开发部门、运维部门，只有将各方需求变更纳入规范化的管理，才能保证业务需求、架构设计的合理性、一致性、完整性、准确性，避免出现矛盾、混乱。
（三）建立变更控制委员会
每项记录在案的变更请求都必须由一位责任人批准或否决，该责任人应该在项目管理计划或组织流程中被指定。必要时，由变更控制委员会（CCB）来决策是否实施整体变更控制流程。CCB应是一个正式组成的团体，包括项目经理、业务代表、开发代表、测试代表，负责审查、评价、批准或者否决项目变更，以及激励和传达变更处理决定，组织验证被修改的配置项。
（四）完整体现变更的影响
变更控制的具体实施程度，取决于项目所在应用领域、项目复杂程度、合同要求，以及项目所在的背景与环境。变更请求得到批准后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致，比如：需求规格、架构设计、成本估算、活动排序、进度日期、资源需求和风险应对方案分析。
福建农信需求变更实践方法
由于福建农信二级法人体制，导致各行社发展不平衡，存在较多个性化需求，一个软件项目总是难以同时满足所有行社的发展需要，在项目开发乃至后期运行阶段就会存在各种需求变更请求，变更申请的管理就显得尤为重要；此外，福建农信系统复杂，特别是涉及外围系统多的项目，每一次的需求变更往往需要其他系统的配合改动，风险较大，在管理上更需严谨。针对这种现状，福建农信提出了项目变更规程，规程通过定义项目变更的全过程，指导项目组有效地控制项目处理进程，保障项目的顺利实施和项目目标的达成。结合需求变更原则，实践的项目的流程如图所示：
（一）项目变更请求。
项目经理收集可能导致项目范围、配置项和/计划调整的变更请求（《需求变更申请单》），对收集的变更申请单，进行初步整理后，提交CCB评估。项目变更请求范围，包括但不限于：
1.项目关键时间点变化，如：里程碑时间点、投产时间点；
2.需求变更；
3.设计变更，如：架构设计、软件设计、数据库设计；
4.因需求或设计导致的代码变更；
5.因需求或设计导致的测试方案、测试用例的变更。
（二）CCB评估。
CCB（CCB即变更控制委员会，成员至少包括项目经理、业务代表、开发代表）对收集的变更申请进行初步判断，提交需求部评审；
（三）需求部评审。
需求部组织对通过CCB评估的《需求变更申请单》进行评审，判断是否接受这些变更，并判断这些变更是否影响了项目的关键时间点：
1.变更涉及到需求规格调整，执行4-更新需求规格；
2.变更涉及到架构调整，执行5-更新架构设计；
3.需要提交计划变更申请，执行6-项目重估算、重计划；
4.涉及其它配置项变更，执行7-更新受影响的配置项。
（四）更新需求规格。
业务代表根据《需求变更申请单》中的内容，组织更新《需求规格说明书》。更新后的《需求规格说明书》应提交需求部进行审核，如审核不通过，应继续进行修改。
（五）更新架构设计。
开发代表根据《需求变更申请单》内容，组织更新《架构设计说明书》。更新后的《架构设计说明书》应提交开发部进行审核，如审核不通过，应继续进行修改。
（六）项目重估算、重计划。
当变更内容导致需要提交计划变更申请时，项目经理应依据变更内容组织进行重估算，并依据估算结果更新项目计划包（含总体计划和进度计划），并作为计划变更申请的输入和附件。
（七）更新受影响的配置项。
一般由项目经理或开发代表指定变更实施人。变更实施人根据《需求变更申请单》内容，检出已经基线的相关配置项，对配置项实施变更操作。
（八）组内计划调整。
当变更内容不需要提交计划变更申请时，项目经理根据需要调整并更新项目计划包（含总体计划、进度计划），并通知组内成员及其他受影响的相关方。
（九）计划变更评审。
项目经理根据需求部评审结果，向计划评审小组提交计划变更申请。计划评审小组根据需要组织相关方对调整后的《项目计划包》和《需求规格说明书》《架构设计说明书》。
（十）变更决策确定。
项目经理根据技术评审小组结论，提交更新后的《项目计划包》给业务部门和科技部领导进行审批。如审批不通过，应进行重新修订。
福建农信项目变更规程严谨定义了从提出变更请求，经需求部评审后并更新受影响的配置项，到涉及项目关键时间点变动时提交上一级管理层进行变更决策的全过程。具体做到了以下几点：
1.流程规范。
该规程正式版于2013年首次发布，要求项目组对需求变更进行带准入的收集整理以及系统化的处理跟踪、各部门严格按照规程对需求变更申请进行规范化的评审，避免杂乱无序的需求变更造成CCB成员负担；避免因未经评审的不合理的变更请求对代码、配置进行随意的改动；避免遗漏对关联需求点的系统改造；确保更新需求规格、更新架构设计、更新受影响的配置项、项目重估算、重计划、组内计划调整等环节未被忽略。
2.评审严格。
CCB对收集的变更申请进行初步判断，需求评审部门在收到书面的需求变更申请单时根据实际情况组织原需求评审人员进行线上或线下的需求评审会，控制时间，保证质量。评审前，要求评审人员对项目原先需求、变更内容以及现状进行深入了解；在评审阶段，评审人员充分听取各部门、各方面意见，例如涉及会计科目变更的，就应要求经过财会部门的审批；需求变更评估要求初步确认需求类型，分析开发资源，分析关联业务的需求合理性、安全性及全面性，确认进度计划，关注变更时间和成本的影响；必要时将项目组提出申请时未考虑到的关联项目关联功能包含进来进行综合评估；综合考虑最终形成处理意见，接受或者拒绝变更请求。
3.基线化管理。
根据项目计划和项目配置管理计划，在项目开发的不同阶段，均有建立相应的基线，将相关的配置项纳入变更管理。同时，将配置状态报告发送给各相关方，相关方都能及时了解项目进展状况，和项目的变更情况。
4.建立变更跟踪机制。
实际研发过程中，往往由于需求变更缺乏跟踪，带来许多问题。软件项目建设中，福建农信通过建立变更跟踪机制来加强管理，建立与维护“需求-开发-测试”的一致性，确保所有工作成果符合项目需求。在《需求规格说明书》完成后，或需求变更通过CCB批准后，需求人员建立《需求跟踪矩阵》，保存到SVN项目文件夹下，以作跟进。
5.进行有效沟通。
项目进行过程中应当强调成员间的沟通，避免不必要的反复的变更增加开发工作量。实际工作中很多变更其实只是由于业务人员与开发人员对需求的理解不一致，而有效的事前沟通是可以降低需求变更的频率的。例如：e平台电子账户登录用例中，对于输入格式错误的登录密码是否计入错误次数等隐性规则是存在疑义的，但经过项目组内有效沟通，最终确定方案就避免了不必要的需求变更。故需求讨论时，开发人员与业务人员应该尽量采取相互理解、相互协作的态度，积极寻求可行的替代方案。既然需求变更是必然的，那项目成员就应当注重采用各种沟通技巧来使各方的利益达到综合的最大值。
变更管理本身并没有一成不变的规则，福建农信根据自身情况，以积极的态度，进行完整而合理的考虑，严格规范执行流程，进行了有效科学的需求变更管理，规避需求脱离控制、产品与预期不符等不利影响；但科技发展的脚步不会停，改革创新的脚步也不应该停，作为农村金融的主力军，福建农信将保持严谨态度的同时，不断完善项目建设规程，使得项目需求明确，开发有迹可循，项目运转有序高效，最终产品才能更加符合客户需求、市场需求，进而提高经济收益。
