1. 引言
2022年1月，银保监会发布《关于银行业保险业数字化转型的指导意见》，提出金融机构数字化的总体要求，深化数字化能力建设、促进数字化转型已成为金融机构组织建设的重要任务。商业银行数字化转型的核心就是要以客户为中心，敏捷组织则是快速响应市场变化和客户需求的基础保障 [1]。近年来，国有大行和股份制银行已逐步探索出适合自身的敏捷模式以及转型路径，但对大多数中小银行来说，尚需结合实际情况参考同业对敏捷转型的方向路径进行优化调整。
2. 中小银行敏捷转型难点分析
2.1. 系统多，关联程度高，难以闭环
目前中小银行新业务及产品的研发过程中，主要涉及以下几类系统。一是渠道类，包括微信银行、手机银行、开放银行平台、柜面及自助机具等；二是数据决策类，如自动授信系统、三方数据接入平台、数据分析平台、反欺诈系统、报表系统等；三是流程控制类，如信贷系统、ESB企业服务总线等；四是支付核算类，如核心系统、支付系统等。一个产品创新需求，往往会涉及以上多个关联系统的开发工作。当关联系统功能出现问题或多个版本功能并行开发时，易出现开发测试阻塞。其中关联程度最高、产生影响最大的主要有ESB企业服务总线、信贷系统、自动授信系统等。
2.2. 开发测试上线流程较长
中小银行开发流程传统上以瀑布开发过程为主，有以下劣势难以满足产品创新需求的快速迭代：一是开发周期长，串行流程多；二是需求、开发、测试人员在开发过程中难以及时沟通变化，需求人员往往只有在整体需求接近开发完成时才可以看到成果，对进度缺乏掌控；三是各项需求间缺乏优先级排序的标准，变动频繁的线上产品需要与变动相对较少的非线上产品一并排队。
2.3. 人力与资源缺少整合
一是开发人员有限，内部自有开发力量不足，外部开发力量也缺乏稳定，现有开发人员在使用分配上多以系统为边界，易出现外围系统开发完毕后等待关键节点系统开发的情况。二是专职测试人员数量较少，同时专职需求人员更多考虑的是正向流程，特殊流程及边界条件难以充分测试。三是测试数据缺乏，测试数据往往主要依赖测试人员手工通过具体交易进行准备，数据的完整性和有效性难以得到保证。四是基础环境薄弱，各个系统在测试流程中往往仅有一套环境，多个需求交叉时版本切换与冲突难以避免，测试环境不稳定也可能导致整体进度延迟。
3. 敏捷银行的概念
3.1. 相关定义
“敏捷(Agile)”概念最早为软件开发人员提出，2001年《敏捷软件开发宣言》在美国犹他州发布，提出了敏捷软件开发所遵循的四个核心价值和十二条原则，如开发模式快速迭代，组织结构灵活自主，技术工具与时俱进，企业文化以人为本等。为更好应对日益动荡的外部环境和市场竞争，越来越多的传统企业(包括银行)开始向创新型科技企业学习，开启敏捷转型之路 [2]。敏捷银行是指借助智能化、数字化等现代高科技手段，快速为不同的客户群体提供具有鲜明特色的个性化服务的银行机构。一般来说，敏捷银行应具备五个方面的特征 [3]，一是移动性和互联网性特性更显著，二是更加注重客户体验感，三是具有更强的数据驱动性，四是具有更强的合作意识，五是更加注重高科技创新。
3.2. 银行敏捷团队架构及角色
中小银行可参照国内外先进金融机构及互联网公司的敏捷组织实践情况，打造以项目为纽带，打破部门条线壁垒的端到端敏捷团队，实现从业务需求到投产运营的敏捷产品研发模式转型。参考互联网行业的敏捷团队组成，一个建议的银行线上产品敏捷团队架构如图1所示：
Figure 1. Diagram of the structure of agile team
图1. 敏捷团队架构图
各角色的详细职责如表1所示：
Table 1. List of roles and responsibilities
表1. 角色职责一览表
3.3. 基于敏捷模式的银行部门职责
除了设置产品团队，为解决跨部门协调问题，还需进一步明确各部门的相关职责。线上产品管理部门一是负责牵头线上产品敏捷机制建设，组建项目组；二是负责逐步完善立PO、APO选拔机制及资源库；三是负责为线上产品项目组提供相匹配的产品设计、用户设计、数字风控、项目经理等人员支撑；四是负责牵头基于线上产品的框架合同签订。技术部门一是负责组建并提供全功能敏捷开发团队；二是负责打造适应敏捷上线的测试环境及上线机制；三是负责行内开发人员的培养和储备。业务部门及其他相关部门负责为创新工场项目组提供相匹配的专业化人员支撑。考核部门负责牵头实施创新工场项目组成员的穿透考核。
敏捷试点沟通机制上，以召开月度例会或重要事项复盘会议的形式，回顾敏捷运转过程，调整不足点，挖掘提升空间。会议原则上由线上产品管理部门召集，技术部门联系人、各产品PO、APO和事项关键人员参与。同时在敏捷试点保障机制上，可建立敏捷转型办公室，对各敏捷团队的运转提供机制保障，积极探索利于敏捷运转的各项机制流程，不断提升数字化转型效率。
4. 中小银行敏捷转型的执行路径
根据前述方式对架构和团队进行调整后，中小银行可从以下方面改进具体执行路径。
4.1. 思维创新，从以客户为中心出发思考
一个创新产品，不管是应用新模式，还是应用新技术，要想一次就设计完美，是非常困难的，更何况市场需求还在高度变化之中，如何实现产品的快速迭代，并在不断迭代中提高响应客户需求的能力，是创造成功产品的制胜关键。
目前中小银行的某些产品在需求阶段更多的倾向于罗列一些交易功能，在单一渠道或系统中实现；这属于简单的面向功能的设计，缺乏客户思维。以客户为中心的思想，应该是以多渠道协同服务，共同参与客户接触的全生命周期过程，包括营销、预约、签约、授信、支付、服务和沟通反馈等。同时多渠道协同营销，利用大数据加强在各个客户接触面的精准营销能力，实现营销线索在渠道间的适时推送和转介。比如通过微信渠道进行授信流程，在非手机银行客群中起到营销推广引流的作用；授信后客户再通过手机银行进行支用还款，在此过程中即可引导客户进行手机银行及信用卡产品的相应开立，进一步扩大客群。
4.2. 重视客户体验，以体验反馈作为产品创设的重要评价
可从以下几方面考虑完善相应机制，一是对内以大数据应用体验、对外以创新产品使用体验为重点。二是开展行内体验师选拔，在条件适当的分支机构设置金融科技信息中心，以新产品接受程度高，参与意愿强的分支机构员工为主力。三是体验反馈通过制定统一的报告模板，使用技术工具从而提升规范化。四是通过适当的正向激励与反馈说明，提升行内体验师的参与度与成就感。五是适时逐步扩展到行外体验师。通过不断提升客户体验，为全行创新产品的快速迭代及精准迭代提供有力指引。
4.3. 系统开发按多模式划分管理，推动双速IT
产品创新的需求特点是研发周期短、需求变化多，就目前中小银行产品创新的研发过程来看，需求变化频繁，开发速度要求快的主要集中在线上渠道类与数据决策类系统上。流程控制类与支付核算类系统的需求变化相对可控。因此，可把线上渠道类与数据决策类系统划分为敏态系统，把流程控制类与支付核算类系统划分为稳态系统；同样亦可将技术团队划分为敏态团队与稳态团队。在具体实施中，可按双速IT的管理需求将产品创新相关系统的开发模式划分为以下三类：
I类模式，由稳态团队统一组织系统平台及功能开发，在产品创新流程中优先配置开发资源，保障开发进度。该模式适用的情况是系统平台属于稳态系统，需求变化相对可控的，如核心系统、支付系统等。
II类模式，由稳态团队建设系统平台，具体产品功能可由敏态团队在平台的统一框架下实施敏捷开发。该模式适用的情况是系统平台属于稳态系统，但涉及的创新产品功能需求较频繁，需要配合敏捷开发的，如信贷系统等。
III类模式，由敏态团队统筹业务及开发，自主建设系统平台，组织功能迭代。该模式适用的情况是系统平台属于敏态系统，直接面向客户，响应速度要求高的，如微信银行、三方数据系统平台等。
敏态团队应整合建立创新产品实施小组，指定专人负责II、III类模式中的创新功能实施，从而将平台运维及非功能性需求与线上业务功能的建设分离，减少排队情况。同时今后需逐步优化或升级全行各类系统平台架构，实现创新功能的快速实现及影响隔离。特别对线上线下业务能明确划分开的，系统间关联耦合较低的还可使用新建系统接管或替换原系统功能。
4.4. 敏捷流程优化，重点关注测试与上线环节
一是功能上线应遵循小步快跑原则，避免贪多求全增加复杂度从而导致工期延长。以最小可交付为标准，快反馈快迭代。二是业务功能模块上线也可按双速设计，如稳态系统按两周一次上线，敏态系统在支撑产品创新流程中可按需由敏态团队灵活组织上线，或采用火车版本的形式。三是需求与测试人员在开发过程中全程保持参与，及时确认开发成果，避免在上线前最小可交付需求仍存在反复情况。四是开发测试闭环流程优化，建议产品创新流程中SIT、UAT环节均可考虑由创新产品实施小组统一组织测试验收。
4.5. 重视人力、资源和数据优化整合
人力方面，一是可考虑行内挖潜，从各部门及分支机构汇集相关人力。二是外包流程增加敏捷通道，创新人力外包机制，敏态团队可考虑牵头以框架形式采购外包开发、测试、数据人力，减少针对单个产品或单个项目的采购活动，以节约商务流程上耗费的大量精力与时间。
资源方面，敏态团队应与稳态团队共同搭建敏捷相关重要系统的环境，适应敏捷发布测试节奏，避免已开发功能在测试环境的排队等待，设置专人保障该环境运行稳定与版本的及时更新。
数据方面，一是可考虑建立测试数据脱敏机制，定期从生产系统同步脱敏数据供开发测试验证，利用自动化技术手段，建立铺底测试数据库，优化测试数据的制造手段，能对测试效率的提升起到较好的效果。二是依托数据治理工作，建立全行大数据平台，将行内数据与外部数据进行整合，加强实时分析与决策能力。
5. 具体案例实践
以对公线上开户业务为例，在传统的银行业务中，对公开户业务存在办理时间较久、客户需要多次到网点现场、申请信息填写复杂等业务痛点。对此某地方银行组织敏捷团队，按以上路径启动了对公开户旅程数字化再造项目 [4]，通过整合线上资源和线下柜面服务，形成线上线下一体化办理模式，提升客户申请便利度。
一是组建全功能团队，提升整体效率。对公开户流程较长、关联系统较多、业务交互较复杂，项目组由技术创新部门和业务部门作为双牵头部门，其中以技术创新部门作为产品负责人(PO)，项目组成员包括来自公司业务部门、电子银行部门、科技信息部门等多位业务、技术专家成员，采取固定时间、固定地点的集中办公模式开展需求识别、方案设计、迭代交付等工作。
二是从用户痛点出发快速识别客户需求。在本项目中，主要基于用户画像分析方法对用户痛点进行识别。项目组将现有业务流程进行拆分，以客户体验为中心，分别列出各个流程的具体内容、客户开户时需要填写的材料以及相应的等待时间，从而识别用户痛点以及可供改进之处。
三是从基于场景的用户故事地图开展方案设计。在本项目中，为避免单一视角的限制，分别设定监管视角、客户视角、办理人视角、授权人视角等多视角，并用故事地图的形式进行可视化展示和充分讨论，从而让项目成员能快速决策改进方案的有效性及可行性，减少沟通成本。
四是利用看板推动迭代运作和交付。本项目未采用传统的瀑布模型，而是采取敏捷迭代上线的模式。通过敏捷看板，将具体的任务划分为待办、分析(处理中)、分析(已完成)、开发(处理中)、开发(已完成)、测试(处理中)、测试(已完成)等多个状态。每天早晨进行状态同步以及分派工作，将任务按实际情况移动至“处理中”或者“已完成”列。看板将现有工作进行状态可视化的展示，对于可能延期风险的任务放置到风险区域以提示风险，各个成员可以清楚地知晓自己需要承担的工作以及各个工作事项所处状态，从而达到结果可衡量、变化可控制的效果。
通过以上敏捷实践方法，该项目较以往同类型项目的整体工时缩短一半左右，大幅提升研发效率。项目上线后显著改进了对公开户业务的客户体验，客户到店次数由原来至少3次变为1次，办理时长平均由150分钟缩减为35分钟左右。在基本达到原定业务需求目标的同时，项目的实际建设时长也明显减少，有力地提升了开发上线效能。