华润银行敏捷转型案例

原创 刘雨哲 中智凯灵 2023-09-11 09:03 发表于北京

▼

在经营环境复杂多变、产品服务同质化、竞争加剧的行业背景下，针对缺乏规模优势且资源有限的城市商业银行，如何在激烈的市场竞争中分得一杯羹？

华润银行选择另辟蹊径，集中资源打造线上贷款领域的明星产品，运用“田忌赛马”的思维来提升与巩固其行业优势。该产品的亮点在于，客户在线即可完成所有业务的操作，对系统、平台等科技资源有较强的依赖性，客户体验在很大程度上取决于科技侧的响应水平。该产品在设计完成并成功运行一段时间之后，却又逐渐暴露出科技资源的瓶颈。

（1）对接的核心企业洽谈情况不明、对接能力参差不齐、需求缺少合理的排期和规划，导致大量开发任务并行，需求交付频繁延期。

（2）关联系统繁多，跨系统沟通效率低下；开发提测质量堪忧，多系统联调测试压力巨大。

（3）科技团队当下的工作模式不仅无法高效响应业务需求，同时导致技术债务快速积累，存在潜在的质量风险。

若想借助该线上贷款产品成功“出圈”，如何提升科技侧的响应力是绕不开的一个难题。

下面从团队作战阵形、沟通机制等层面，介绍华润银行如何以此线上贷款产品为突破口，构建高效率（需求交付前置时间缩短20%以上）与高质量交付的研发团队，为该行的差异化竞争策略保驾护航的过程，旨在为业内类似处境的银行提供些许参考。

这款线上贷款产品作为创新型的数字产品，业务实现逻辑高度依赖系统与平台。其目录下的研发需求涉及多系统、多平台，往往需要多个团队密切协作才能完成交付。在华润银行科技部门传统的需求响应方式中，各个系统以资源池的方式支持产品研发，产品需求需要被拆分为系统需求后再分配到对应的系统，由各个系统独立进行需求排期和人员投入分配。

虽然系统建设资源池的模式能灵活调配资源，但同时也存在较高的沟通、协调成本。由于线上贷款业务涉及多个系统，因此产品负责人需要和多个系统的负责人沟通，多线协调需求的排期问题。但从系统的角度来看，需求来源多样，各产品均有急于上线的新需求，系统需要统筹安排需求优先级，重点产品的研发产能无法得到保障。再叠加人员的调配与流动（在银行业中厂商人员的流动性问题十分普遍），往往导致前期沟通的交付承诺无法达成，需求延期交付不可避免。同时，由于系统之间相对独立，较高的沟通成本也导致各个系统之间形成信息筒仓。原本相互关联，甚至相互依赖的系统需求的研发进度互不可见，给开发联调和测试工作都带来了极大困难，导致产品研发交付陷入泥潭。

显然，这种“沟通一次，心中默默祈祷按时交付，实则常常事与愿违”的状态已完全无法满足业务拓展的诉求，传统研发管理中系统各自为政的“平面作战”，也无法适应复杂产品研发的高频协作需求。整合资源，使用部落制的方式组建跨系统的端到端交付团队，形成“海陆空”多系统协同的特种部队，以“立体作战”的方式支持高效率、高质量的交付势在必行。图17-1所示为线上贷款产品研发部落的结构图。

图1-1  线上贷款产品研发部落

在线上贷款产品研发过程中，为了解决各个系统协调困难、排期混乱导致的交付问题，我们引入了虚拟部落制——将不同系统、不同职能、不同角色但是都共同服务于该产品的人员划分出来，在保留原有职能线的基础上，拉通研发价值流，组建具备端到端交付能力的虚拟小队。多个小队组成一个部落，该部落可独立消化产品的绝大多数需求。

在这样的组织阵型设计下，我们将部落中各个系统成员的工位调整到同一个区域，大幅降低了跨职能、跨系统带来的沟通成本。建立相对稳定的团队，让团队成员更有归属感和荣誉感，也进一步促进了部落内的配合协调，提升了协作效率。

在建立产品部落的基础上，我们推行了需求估算和跨小队（系统）的需求排期活动，旨在建立部落内统一的交付节奏。在每个迭代开始前，各个小队对下一个迭代的系统需求进行梳理，给出每个系统需求的优先级和预期移测时间。部落内的小队长得以充分沟通、分析需求关联性和依赖性，从整体维度进行考虑，给出更合理的系统需求研发计划。在这份“作战计划”的指导下，系统需求错位交付的可能性被大大降低，避免了跨系统联调时的长时间阻塞和等待。需求有节奏的稳步交付也大大缓解了需求测试和验收的压力，使得整个研发团队的工作得以有序进行。工作项多而不乱，多系统协同的“立体作战”收效颇丰。

线上贷款产品作为一款明星产品，每个版本都需要消化来自各个方面的需求。在转型实施之前，业务在版本研发过程中频繁追加“紧急需求”，导致版本范围不断扩大，研发团队压力巨大。当临近发版窗口时，部分需求才刚刚研发完成，留给测试的时间窗口极窄，测试又不得不加班加点追赶测试进度。虽然在发版制度中设置了“封版”的时间节点，但迫于交付压力，研发团队不得不反复“解除封版”，向版本中填充需求。这些“紧急需求”没有经过充分测试就匆忙上线，存在极高的质量风险。

长此以往，业务与IT之间的信任感被消磨殆尽——业务方认为科技团队交付屡屡逾期，交付质量难以保证；科技方则认为业务团队的需求规划不合理，研发团队为达到交付要求已疲于奔命。在敏捷转型中，为破解业务和科技协作的泥潭，我们基于原有的发版节奏建立了如图17-2所示的“月度版本火车”：

图1-2  线上贷款产品版本火车

在业务-科技协作困境中，关键问题在于研发产能情况的不透明。通过版本火车规范团队研发节奏，建立稳定的迭代时间窗口，只需要几个迭代运行，研发团队就能明确自身的迭代研发容量，建立需求交付数量的基线。只有将团队的迭代研发容量透明化，才能重新建立业务和科技之间的信任。

在透明迭代容量的前提下，业务和科技达成了新的契约。业务方需要对每个版本的需求进行优选，且在追加“紧急需求”时需要考虑替换低优先级的需求。这样的优选机制保证了迭代工作量可以维持在研发团队可接受的范围内，在极大程度上减少了研发团队追赶发版日期的低质量交付；科技团队也因此具备了更稳定的工作节奏，能更从容地安排需求研发工作，减少并行工作量，形成稳定的需求交付流，实现高时效、高质量的需求交付。

通过实行版本火车，该产品的需求交付前置时间从改进前的82天逐步稳定至42天，生产缺陷数大幅下降。仅仅通过增加需求优选，业务就获得了更短的交付时效和更高的产品质量。同时，版本火车建立的稳定交付节奏也使得该产品的相关系统在联调时获得了极大的便利，线上贷款产品的研发团队也逐步成为明星团队，为组织后续的敏捷规模化推广建立了良好的基础。

华润银行施行的传统项目管理制度高度依赖汇报材料，团队负责人需要整理繁杂的项目计划和过程文档。项目计划文档可操作性差，最终大多流于形式；而项目周报则言之无物，反而变成了团队负担。

线上贷款产品作为明星产品，虽然在团队管理上获得了一定的自主性，但在传统的项目管理框架下，团队负责人还是只能通过团队成员的日报、周报掌握团队的研发进度，通常需要额外维护一张项目进度表来进行事项的跟踪。日报和周报的汇报延迟、风险记录遗漏等问题，使部分关键的阻塞问题未能及时暴露，导致需求按时交付的风险陡增，研发团队往往不得不通过加班为此买单。

研发团队负责人对自己团队的研发进度掌控尚且如此，跨团队协作时的进度跟进就更为困难。同时，产品的开发对产品经理而言几乎就是“黑盒”，期望在业务和科技之间建立交付承诺的信任更是无从谈起。

为支持业务和科技协作，破解“研发黑盒”，我们基于原有的需求术语在部落中建立了“意向需求-SR”的两层需求体系，并梳理了与之匹配的需求价值流，实现了对业务和科技双层价值流动的精细化管理。如图17-3所示。

图1-3  线上贷款产品需求体系和价值流

如图3所示，我们围绕意向、SR价值流建立了双层看板，通过可视化的方式记录需求的流动情况。通过每日站会机制推动团队积极对齐项目进度，将项目进展、阻塞直观地在看板上展现出来。开发进度不再是团队负责人手中疲于维护的“战况简报”，而是快速更新、对团队成员透明可见的“战场实况”。意向需求作为较粗颗粒度的需求，更新频率偏低，可以用于观察产品需求所处的具体阶段；系统需求的颗粒度更细，更易于在看板上流动，能快速反映需求的研发状态和阻塞情况。

当跨团队协作时，只需快速浏览一下相关团队的需求看板就能了解关联需求所处的状态。测试团队也可以参考关联需求的开发进度来安排测试计划，及时暴露测试压力和交付风险，避免测试团队在版本末期后知后觉，被陡然增加的繁重测试任务压垮。

“透明化”使得团队中的每个成员都能了解当前迭代遇到的问题和瓶颈，鼓励团队成员在工作过程中发现问题、提出问题，进而利用团队的力量解决问题，极大缩短了团队在遇到问题时的阻塞时间。团队负责人的工作也不再是单纯的工作指派，而是协助团队协调外部资源，为解决阻塞问题提供帮助。“透明化”使得团队的自主性发挥到极致，管理人员不再需要追踪各个事项的细枝末节，转而实施“双手放开，两眼紧盯”的管理模式。

该线上贷款产品的研发团队有较高的外包占比，如何提升产品交付质量是团队的一大难点。团队负责人频繁强调开发自测的重要性，并为确保开发自测而要求开发人员在移测时提供自测的截图。虽然针对这些情况设置了详细的工作规范，但依旧收效甚微。

在实施转型的过程中，针对团队质量的提升，我们增加了桌面检查活动，作为质量门禁。即在开发移测时，由测试提供对应需求的核心功能验收案例、准备测试数据，由开发人员对照核心案例进行功能演示。通过对桌面检查的演示，测试人员对功能的实现有了更直观的认知，同时也能以测试的视角提示开发人员可能存在的质量风险；开发人员能在交付早期识别缺陷，大幅降低了缺陷的修复成本，很大程度上提升了产品交付质量。成熟运行桌面检查的小队自发邀请了UI人员加入桌面检查，进一步保障了产品样式的还原和交互的流畅。

同时，我们优化了代码评审流程，基于行内的基础设施完善了“提交-扫描-评审-改进”的代码质量提升循环。开发人员提交的代码均会触发质量扫描，扫描报告会被推送给DevOps平台，供团队在代码评审时参考。当团队在DevOps平台进行代码评审时，可将评审意见直接批注在代码上，便于开发人员快速定位优化点。成体系的代码评审工具链结合质量门禁不仅提升了团队的代码质量，且能将研发质量活动留痕，既满足了银行对代码评审等质量活动进行记录的审计要求，又减少了研发团队整理材料的负担。如图17-4所示。

图1-4  代码质量提升循环

随着团队交付能力的增强，对工具的要求也会越来越高。让工具匹配团队交付节奏，沉淀研发数据和业务数据，建立“持续交付-持续改善”的迭代循环，是建设卓越团队的必经之路。随着敏捷转型的规模化推广，DevOps的基础能力建设也成为华润银行的重点战略目标。

虽然部落制能大幅提升科技团队的交付能力，保障需求交付时效，但部落制伴随的资源锁定对中小行有限的资源也是不小的挑战——甄别重点业务，集中优势资源，将“好钢用在刀刃上”，才更有可能在竞争的红海中脱颖而出。在建设部落的同时，也应该持续打磨研发工具链，构建流畅的工作流程，强化质量内建要求，在持续交付的过程中实现流程优化和人员能力的培养。“集精兵、打硬仗”，通过应用产品部落制让交付团队伴随产品持续成长，实现业务的突破和蓬勃发展。

本文节选自《软件研发行业创新实战案例解析》，本书旨在通过各个公司在工程创新、管理创新、产品创新、技术创新、效能创新上的最佳实践，以及对案例的分析和总结，为其他公司提供一定的参考和借鉴，以帮助大家更快速地解决所遇到的问题。

本书共包含22个实战案例，涵盖了研发效能提升、数字化实践、敏捷转型、研发管理、人才培养、AI视觉分析引擎构建等软件研发各个领域的多个方面，适用于软件研发行业中的各类管理人员和从业者。

想要了解更多软件研发行业创新案例？那就快来看看这本书吧！

获得京东软件工程类图书排行榜第一名

点这里↓↓↓记得关注标星哦~

中智凯灵中智凯灵是国内领先的专业人力资本服务供应商，为企业提供从人力测评、关键岗位人才培养、版权课程设计与输出、人才培养体系设计与开发等一系列的人力资本专业服务。本平台致力于为企业提供人才培养方面的内容分享。102篇原创内容公众号