万字长文，细说长沙银行的数字化研发管理转型之路

4月17日，长沙银行信息技术部陈宝生总，与Agilean 首席咨询顾问吴穹博士在2021 DevOps Days 大会上，共同作了《长沙银行数字化研发管理之路》的分享。

限于大会现场分享时长，很多细节无法展开详述，我们特将该主题分享整理成文，详细介绍长沙银行这三年数字化转型过程的“三个阶段、七场重要战役”。

从2019年7月到2020年12月，长沙银行已进行了近两年、两个阶段的数字化转型实践。目前整个数字化研发管理体系高效运作，取得了研发交付时效优化30%，研发吞吐量提升35%的阶段成果。

长沙银行数字化转型阶段成果

组织的数字化转型是一个持续提升、不断迭代的过程，本文将从长沙银行数字化转型过程的“三个阶段、七场战役”出发，对其数字化转型之路进行全面复盘和解读，分享推进过程中的思考和经验教训。

长沙银行数字化转型的三个阶段、七场战役

第一场战役，新核心攻坚战

夯实信息化，打破核心系统性能瓶颈

众所周知，存款业务和贷款业务是银行最基础、最核心的两项主营业务，底层信息系统架构对这两项业务的支撑能力，直接影响全行的业务运营水平。在长沙银行数字化转型初期，第一步要走的攻坚战就是核心系统的改造。

2018 年，长沙银行新核心项目成功上线，完成了新存款系统与老存款系统的业务更替，实现了交易与核算功能分离。

第一阶段：新核心系统改造，夯实数字化转型基础

2019 年 3 月，长行多个部门联合成立项目组，正式启动核算子系统迁移项目。

长行打破核心系统性能瓶颈过程案例

对公信贷和零售信贷业务系统的核算功能与其他业务系统交互紧密，涉及系统多，系统间关系复杂，迁移前后数据一致性对开发的要求高，工作量大，且对各系统间的协同开发有较高的要求。

面对诸多困难，交付团队迅速组成由研发+测试+业务的跨职能小队，快速迭代反馈。活用新核心项目建设时的经验，组织三轮次系统验证测试（SIT），三轮次业务验证（UAT）和三轮次高强度、高质量的投产演练，采用时序图、上线指令发布等一系列项目工具。

2019 年 8 月，终于顺利完成了对公信贷系统流动资金贷款和固定资产贷款迁移、零售业务系统个人经营产品和个人消费贷款产品的迁移。

核心系统成为新核心系统双线后，只稳定由6-8人的开发人员维护，移除了关联项目进度瓶颈和系统性能瓶颈 ，为后续长沙银行的敏捷数字化转型打下了坚实的基础。

第二场战役，部落划分遭遇战

部落制引入与数字化研发人力资源管理

2.1 部落结构划分，建立对齐业务部门的虚拟研发部落

传统城商行的研发团队都是以系统为中心的，一个团队负责几个系统。虽然系统也有业务属主的概念，团队负责系统也会掺杂许多其他因素：

• 厂商因素：这几个系统是一个厂商开发的，所以放在一起管

• 个人因素：这个人对这个系统最熟，人换了团队，系统也跟跟过来了

这种情况下，业务部门和科技团队往往会形成一个多对多的对应关系。

转传统职能型组织为纵横网状部落式结构

传统城商行研发组织的两大痛点

传统城商行业务部门与科技团队“多对多”的模式，或者说传统职能型组织，存在两个痛点：

1. 公地悲剧。所有业务部门都有冲动去争夺尽量多的科技资源服务自己部门。只有业务部门与技术部门采取相同的价值标准，共同客观的标识需求优先级，科技资源才能尽可能的实现最优化配置。

2. 科技行员逐渐丧失对系统的把控力。需求需要多系统跨团队协协作，将让原本相对紧缺的科技行员每天的工作主要变成了沟通协作。只有优化组织架构让科技行员回到一线开发，加强对系统的把控力。

为了解决上述问题，长沙银行科技领导下定决心，在现有组织架构不变的前提下，强力推行面向业务的虚拟研发部落制架构，将千名科技人员（含合作伙伴）划入了六大部落，并设立部落长，小队长对需求交付端到端负责。

初步建立对齐业务的敏捷科技部落

这一过程中的一个强制要求：任何人只允许对应一个小队，一个部落，不允许跨部落，跨小队。

一人属一小队、一部落

这一过程中的一个强制要求，是任何人只允许对应一个小队，一个部落，不允许跨部落，跨小队。这一要求对于原有组织，就像撕裂一样，导致了强烈的反弹。

但是，这个要求也避免了和稀泥的情况，充分地把各种不合理的问题暴漏出来。例如，某一个人只有他熟悉二代支付系统，但是，他需要进入对公部落，但这个系统其实属于运营条线等等。

Agilean 顾问团队和长沙银行的项目管理部一起，本着一事一议的原则，做了大量的沟通、升级、决策工作，抽丝剥茧，逐步将每个人、每个系统落入部落和小队。

这一过程中需要注意的是，在不违背大原则的情况下，还是需要做