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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

厂商因素：这几个系统是一个厂商开发的，所以放在一起管
个人因素：这个人对这个系统最熟，人换了团队，系统也跟跟过来了

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

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

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

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

公地悲剧。所有业务部门都有冲动去争夺尽量多的科技资源服务自己部门。只有业务部门与技术部门采取相同的价值标准，共同客观的标识需求优先级，科技资源才能尽可能的实现最优化配置。
科技行员逐渐丧失对系统的把控力。需求需要多系统跨团队协协作，将让原本相对紧缺的科技行员每天的工作主要变成了沟通协作。只有优化组织架构让科技行员回到一线开发，加强对系统的把控力。

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

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

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

一人属一小队、一部落

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

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

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

这一过程中需要注意的是，在不违背大原则的情况下，还是需要做一些必要的妥协，有些小队的规模可能由于内编人力不足等各种原因，还达不到最多12人的原则。有些系统跟人走，因为短期知识转移比较困难。

因此，权衡非常重要，不要因为得不到100分的方案而裹足不前。能有一个60分的方案，就可以作为一个不断演进的基础了，最重要的是动起来。

虚拟部落制的优势

另外，由于采用虚拟研发部落。因此，在长沙银行，我们可以快速动起来，不需要申请组织架构调整和岗位调整。而是可以按照部落机制，将最合适的人用在做合适的位置。例如，在长沙银行，我们请几位 IT 规划部的专家，作为部落长，将需求沟通人员纳入部落之内，大大缩短了沟通链路。

部落制本质上是一种产权改革，将1000多人的科技团队，分成六大部落。每个部落150人左右，符合邓巴数原则。

每个部落都会清晰地明确支持一个或几个业务部门，部落有清晰的职责目标，可以明确用数字化的方式管理部落产出。

部落制 VS 资源池模式

行为心理学表明，合适的组织规模和明确的目标可以激发员工的责任感。在这一过程中，科技研发领导必须发现心中的调配感。

之前 Agilean 发现不少科技领导，很喜欢资源池模式，感觉哪里有火就可以派许多人去救火。结果火越救越多，但是，科技领导乐此不疲，因为，感觉自己在不断调配资源，升级打怪。部落制恰恰要求科级领导放下自我，向下授权，构建部落生态却解决研发交付问题。

部落机制建立后，每个业务部门都有唯一对接的需求受理部落，业务科技沟通线路变短，大幅缩短了需求澄清时效。另外，业务有了专属人力，业务优先级排序成为可能，这非常有利于组织集中力量，重点突破。

2.2 数字化人力盘点，人事合一

数字化转型是个长期性、持续性的组织升级工程。未来方向之一是推动业务与科技深度融合，打造内部的数字化生态，这也是我们下阶段的重要目标：提升科技组织结构的数字化管理能力。

通过知微引入数字化研发人力资源管理能力

过往的人力资源管理方式，很难对科技人员能力和效能产出进行数字化评估。我们引入更加灵活开放的数字化人才管理体系——人才地图。通过培训、辅导等一系列赋能手段，结合数字化工具的能力，提升长沙银行人才管理水平。最大化激发员工的创造性和能动性，让人力成本转化为银行的核心资产之一。

实践 1：合作厂商工时分析

长沙银行合作厂商有几十个，要求所有成员每天“点亮”自己的任务卡，系统根据成员考勤数据与点亮任务自动分配产生工时。定期统计合作厂商的任务工时分布，分析对比，可捕获一些异常数据。

实践 2：人力结构管理

科技创新类工作需要新的、更细化的、灵活可变的岗位标签体系，以进行实时人力盘点和人才画像。通过人力结构分析可得出各岗位在团队的比例，为规划决策提供依据。比如项目管理：研发岗位为1：5，就要考虑是否管理成本过高。持续优化组织结构，职责定义，能力建设。

第三场战役，过程透明接触战

导入敏捷实践，研发端到端和资源投产管理

3.1 建立统一的三层需求任务精细化管理体系，统一价值交付口径，初步建立研发效能评价体系

部落小队的建立打下了研发组织精细化管理的骨架，但是，还需要明确研发组织里面每天流动的血液是什么，这样才能对研发组织进行真正的精细化管理。

在目前城商行的研发管理体系当中，大多数都已经自建了一个用于业务和研发接口的需求管理平台，这个平台负责接受需求，有的也用于外包管理，外包付款等。再进取一点的城商行，会尝试对研发过程进行管理。

但是，大多数的思路是计划管控型的，需要研发人员填写一堆信息，不填写，不给上线。面对这种粗暴的研发流程管控，研发人员的真实反应往往是绕开，在上线最后一天，突击补充一堆信息，表面满足管理要求，其实只是浪费了时间，留下了一堆垃圾数据。

为了解决这个问题，让研发组织的精细化管理成为可能。首先需要从方法论上，统一思想，统一度量衡。明确全行是如何把业务需求，逐层分解到个人。为此，我们引入三层需求任务分解体系：「业务需求-系统功能-个人任务」。

三层需求任务分解体系，要求业务需求必须一次上线，系统功能拆到 10 人天以内（单系统、可反馈），估算的复杂度有所降低。系统功能明确主办部落和主办小队，个人任务拆到 1-3 人天左右，是希望任务能每天流动。这样小队站会同步时，每个人每一天的工作都有目标有进展，每个人对自己的目标负责。再由个人任务关联到系统功能再到需求，整体进展就不在是“大概估计”。小队长根据成员报出的风险与进度，反推到需求都有明确的跟进处理事项与优先级，使决策更有依据，管理更加细致。

为了让组织能够接受三级体系，一开始，并不需要对业务需求做太多变化。根据长沙银行的实际数据统计，全行每年交付2000个左右业务需求，这个数据基本是稳定的。如果我们把业务研发组织想象成一个有机体，这个组织实际上有自己的行为习惯。经过这个组织产生的需求，虽然看起来有大有小，但是，从统计上，规模实际上是均匀的。只不过由于马太效应，参与者会记住极大需求和极小需求，从而加剧需求颗粒度不稳定的偏见。

导入三层分解体系的重点难点

导入该体系的重点和难点，反而是系统功能的拆分，其对应业界的用户故事拆分。在长沙银行，Agilean 团队通过培训、工作坊、现场辅导等方式，先从标杆小队突破，然后老带新，再推广到全员。

需要注意的是，其实不存在唯一的拆分方式，只要拆出来的系统功能，测试有黑盒办法验收就可以。让全行接受系统功能拆分，Agilean 团队初步花了3个月的时间，不过，这个习惯也需要后续不断夯实坚持。拆分的核心目标，就是可以通过通过测试的系统功能数量来客观反应需求进展，来反应小队产能。

个人任务的拆分主要的目标是将系统功能分解到个人，解决多人协作过程中职责明确的问题。

在 Adapt 框架中，我们要求个人任务控制在1-3人天即可，在长沙银行则要求更高，个人任务规模要控制在1人天左右。但是由于长沙银行在外包工时结算过程中，明确要求工时要绑定到个人任务上，所以，个人任务的推广相对阻力比较小。

需求面向业务侧，对应一次上线；系统功能面向科技侧，对应一个系统；个人任务则面向个人，是每个成员自己的研发任务。这三层需求任务体系就像书同文、车同轨一样，为后续的研发数字化管理打下了基础。

3.2 数字化站会，数字化研发管理的活水源头

在长沙银行，面向全员推行了基于看板的电子化站会。所以，个人任务的推广相对阻力比较小。但是，由于每天同时召开的100个并行站会，长沙银行银行使用的知微数字化研发管理系统经过优化可以做到压力下秒开，目前知微系统已经稳居长沙银行访问量最高的内部系统。

知微看板+站会确保步调一致，透明过程、加强执行

另外，在长沙工时记录工作也是在站会完成的，研发同学只需要在站会上点亮自己工作的卡片，其他工作都由系统自动完成。每周四，管理员会上传上周经过修订的钉钉工时打卡数据，然后系统根据上周每天点亮的工作任务，自动将工作分钟数平均分配到工作任务上。如果研发人员觉得有必要，可以自己再手工调整工作任务的具体时间，但是，实际上很少有人这样做。

使用知微加强工时管理，透视资源投产情况

绝对精确的工时管理只是一厢情愿

有些同学可能会觉得这样不够精确，希望像秒表一样，每个人可以准确记录，登记每个任务的实际工时分钟数。这实际上只是一种一厢情愿，实际情况是研发人员每周选一个任务，填满所有工时，其实连正确性都保证不了。目前知微这种做法，已经是我们在经过多次实验之后，找到的可以被千人团队接受的，相对最准确的工时记录方式了。

这样的三层需求任务分解体系，再集合敏捷四会机制，基本上将整个需求研发发布全过程牢牢地绑定在知微工具上。从而，在知微系统上，留下了相对真实的研发过程数据，工时数据，这为后续的研发效能数字化管理打下了坚实的基础。

3.3 导入行之有效的各项敏捷实践

与此同时，我们引入合适的科技敏捷实践，双管齐下，以保证需求交付质量和效率持续向好。

第一阶段导入了多项行之有效的敏捷实践

比如上文提到的每日站会，结合数字化看板工具，进行每天工作进度和优先级的对齐，需求状态与阻塞情况一目了然。

再如在迭代末期的回顾会，全小队成员对度量数据和改进项完成情况进行整体回顾，形成未来的优化建议，共同制定行动项和跟进负责机制。

长行科技侧需求数字化管理数据呈现

目前，长沙银行科技侧的需求管理以数字化的方式高效运行。每天通过数字化工具访问需求和任务达 7500 多次，在站会等敏捷活动期间，每分钟就有约 38 个需求和任务被访问。每周有 7200 个需求和任务的进展通过数字化工具进行更新，有近 100 个跨任务协作中的障碍被清除。

3.4 建立基本的研发效能监控体系，建立改进反馈闭环

建立研发效能体系数据闭环，就有了研发组织里面流动的血液，研发组织就是一个通过不断接受交付需求来交付价值的有机体。

因此，我们依托Adapt框架“多快好赞”度量体系，在长沙银行部落级、小队级建立起了研发效能度量体系。

同时，我们用知微为每个部落，每个小队都构建了数字化大屏，让每个部落、每个小队都拥有了自己的研发管理驾驶舱。

知微的数字大屏是多层级、可追溯的定制化管理大屏。所有数据都可以直接下钻，从一个汇总结果可以直接下钻到最底层。如果修改了底层数据，这些大屏都是实时计算的，更新了卡片，几秒钟后，大屏就会刷新。

长行某部落数字大屏（部分）示例

要真正做到端到端价值交付体系的落地，其中一项重大目标就是构建数字化管理体系。切实做到源头可追溯，过程可控制，成效可度量。

为此，我们对需求进行全流程管理，需求全流程的计划和管理变得透明，业务和科技有明确的共同定义和每个状态的完成标准，沟通时可以快速达成共识，科技团队能够聚焦于手头任务的完成，并且对变化进行了快速响应。

小队的两大重要价值

前面曾经提到过「小队」，小队既是独立的价值交付团队，也是效能分析单元——这是需求管理体系的另一个重要内容：对价值交付的各项指标进行统计分析，从而实现数字化管理。

通过工具的分段统计能力，科技侧能够对各阶段的时效数据，例如需求澄清、排期、研发、整体交付等时效进行分析，从而了解阻塞点在哪里，分析问题成因，制定优化手段，跟进优化效果。

3.5 长行效能分析指标案例

效能分析是促进团队相信能够获得成功的信念所激发的团队成员在工作中付出更大努力的有效手段。部落的研发效能分析主要侧重于以下几个维度：

Lead Time（前置时间）：业务感知效能的重要指示灯，是指从业务提出需求到最终发布上线的时间间隔（自然日）。主要衡量研发团队需求交付速度，它反映了研发的快速响应能力。
需求分段时效：用于展示需求在各阶段的耗时，如需求分析、设计、研发、测试、验收等各状态分别停留时长。通过需求分段时效可以分析耗时较长的阶段，具体改进此阶段的流程，持续观察变化趋势。

图 / 使用知微进行的分段时效分析

需求月度吞吐量：表示一个月内团队完成的需求个数，是最直观粗暴的研发产能度量指标，表述通常为「上个月完成了XX个需求」。此项指标不仅可以观察团队的需求完成数，还可以作为月度需求排期的重要参考指标。
需求漏斗：基于精益数据分析中的漏斗分析方法，将需求分为各个阶段，鼓励持续进行价值优选。根据部落需求吞吐量作为基准值，各阶段乘以不同的系数与实际值作对比。可以发现需求流动断层，并行量过高，或是资源不足等问题。

长行使用Adapt框架的需求漏斗进行需求分析

生产事件：将生产事件分类，分等级可视化看板管理。统计出不同时间周期，不同团队的生产事件，该指标主要检视生产环境质量情况。

数字化转型是一项浩大工程，研发过程可视化，开启了长沙银行数字化转型的第一篇章，结合部落制运作的各项数据，实现了跨职能协同和团队的自组织自管理。通过工时数据与需求依赖关系，为部落结构优化，减少跨部落需求，提供了高可用的数据，为后续深入融合奠定了数据基础。

第一阶段成果

科技时效降至104天，需求吞吐量稳步提升

上述三场战役，组成了长沙银行数字化转型的第一个阶段。在这一阶段，长沙银行夯实了信息化和数字化基础，取得了初步成效。

首先是业务需求交付时效的优化。受疫情影响，2020年2月开始出现了需求积压，业务交付时效最高时达到近170天。经过一段时间的存量需求梳理，到2020年7月初，交付时效已逐步降低至104天。

第一阶段转型业务交付时效明显优化

产能方面，除2月因疫情影响，常规上线窗口全部取消，导致吞吐量降低外，整个2020年上半年，平均月度需求吞吐量为216个，较之2019年第四季度166个的平均月度需求吞吐量，取得了明显的提升。

第一阶段转型需求吞吐量稳步上升

第四场战役，业务渠道整合战

部落结构优化，业务渠道精细化管理

从第四战开始，长沙银行的数字化转型进入了以“规模推广、全面提升”为主的第二阶段。

第一阶段运行的部落制，是针对转型初期问题进行的设计，现今的情况已经大为不同。因此，我们将根据前期积累的工时数据，重新优化部落结构，将手机银行和渠道研发团队分拆，前置给业务研发团队（如零贷），减少跨部落耦合，进一步额提升研发交付效率，缩减小队人数规模，进一步精细化管理。

对部落和人员结构进行调整，减少过程沟通成本，让业务和技术人员更为聚焦。考虑系统复杂度，科技侧也将从需求颗粒度、业务系统架构等方面，配合优化跨系统研发。

4.1 找到强耦合的系统

在三层需求体系当中，有一层叫个人任务，在长沙银行部落制的运作中，我们要求成员每天对个人任务进行“点亮”报工。即某人今天在做个人任务 A，则点亮 A 任务，完成则取消点亮。每天的点亮时长结合打卡考勤系统，会计算出工时。最终工时会通过个人任务关联到系统功能/需求/部落/小队/负责人/系统/厂商中。于是，我们可以取到各个系统在某一周期内产生的工时情况。

4.2 四种解耦策略

由于银行业务种类众多，系统设置也相对复杂。各系统都有自己明确的定位，不同系统解耦策略也各不相同。总结下来，分为四个策略：

四种策略推动部落系统依赖解耦

4.3 按新策略升级部落小队划分

系统工时反推系统人数，通过各系统在一定周期内的工时以及周期内的工作时间，计算出所需资源与岗位，进行各小队的资源划分调整。

工时反推系统人数

4.4 领域细分，与团队校准，方案形成

部落的优化以细分业务领域，对齐分管行领导，减少跨部落协作为目标，根据工时数据调整系统划分，小队人数也可通过系统工时反推出来。这样部落优化的调整方案就明确出来了。此时与部门领导人对齐，部落细分是否符合业务扩展方向，明确部落长与小队长人选。再与具体部落对齐新的方案，是否存在客观问题，现阶段不适合拆分或合并的地方，进行相应的调整。

最终进入实施阶段，开展相关的系统交接工作，提前通知到业务部门。

第五场战役，全行协同联合战

统一研发模式和版本机制，加强跨团队协作

在能够定期组织与业务方的需求优选与排期后，接下来要做的是需求制品过程管理。

需求制品过程管理，通常会遇到一个问题：需求进度不可见，制品周期长，风险暴露晚，以致于常常交付延期。

需求制品过程管理问题的解决

为了解决上述问题，长沙银行导入了敏捷迭代研发的实践，根据需求计划上线时间做倒排期，制定系统功能迭代计划。迭代周期一般为两周，迭代内对系统功能进行分步移测。

团队通过每日站会来对齐迭代进展与风险，有效的提前反馈，降低风险，适应变更，并通过数字化管理工具，以多维度度量研发产能，透明全流程管理问题，逐步让团队自己具备分析和改进问题的能力，从而加快交付时效。

值得注意的是，我们一直在强调“在制品控制”，即同一时刻，并行的需求数不能过多，优先聚焦业务价值更高的需求，实现MVP“最小可行性产品”交付原则。

版本迭代双维管理，系统100%纳入版本规划

除此之外，在探索适应长沙银行现状的业务与科技融合之路上，导入版本火车发布机制，业务和科技共同参与排期，统一的版本发布节奏，设置专人维护系统版本的发布等也成为此阶段的主要方向。

版本火车节奏

总体来说，上一阶段的转型聚焦在科技侧能力提升，下个阶段将在科技侧持续优化的同时，将目标转向前、中、后台的协同数字化转型。

唯有如此，长沙银行才能成功实现全方位、多角度、跨层次的数字化转型，在这场通向未来的必经战役里取得胜利。

第二阶段成果

科技交付效能每月稳定提升 30%

2020年下半年，长沙银行完成了数字化转型的第二阶段，通过前五种战役的组合落地，长沙银行初步建立了科技敏捷机制，科技转型在全行开始规模化推广，通过对整体机制进行建模，确保每位同事都能看到这个体系如何运作，以及与自己相关的待处理信息。

机制建立不是终点，更重要的是维护机制持续运行和不断优化演进。在这点上，同步运行的数字化管理工具发挥了重要作用，让我们能够实时了解机制运行情况，并在过程中及时纠偏。迄今为止，我们可以自信地说，转型已经取得了不错的效果：

“业务-部落-小队”的端到端需求交付流程落地，大幅改善了科技同事身兼多职的问题。科技侧聚焦于优选和排期后的需求，流程中插队的情况也明显减少；
业务需求有明确的P1-P4优先级机制，每个业务需求的责任指定都会细化到小队的主办负责人，确保过程可跟踪、可管理；
从Excel，到使用知微电子看板工具进行更为精细化的管理。得益于工具的强大特性，每个月在产能、交付速度、管理效率等方面都有看得见、可量化的进步，这也增强了我们对转型成功的信心。