虚拟部落 线上贷款产品成功“出圈”，如何提升科技侧响应力？

▼

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

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

（一）对接核心企业谈判状况不明确，对接能力参差不齐，需求缺乏合理调度和规划，导致大量并行开发任务，需求交付频繁延迟。

(2)相关系统较多，跨系统通信效率低； 开发和测试质量堪忧，多系统联调测试压力巨大。

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

想要借助这款网贷产品成功“突围”行业，如何提高技术端的响应能力是一个无法回避的问题。

下面从团队作战组建方面介绍华润银行如何以网贷产品为突破口，打造一支高效率（需求交付前置时间缩短20%以上）、高素质交付研发团队、沟通机制等，为银行维护差异化竞争策略的过程，旨在为行业内类似情况的银行提供一些参考。

从“位面作战”到“立体作战”

作为一种创新的数字化产品，该网贷产品的业务实现逻辑对系统和平台的依赖程度较高。 其目录下的研发需求涉及多个系统、多个平台，往往需要多个团队密切协作才能完成交付。 在华润银行技术部传统的需求响应方式中，各个系统以资源池的形式支撑产品研发。 产品需求需要拆分为系统需求，然后分配到相应的系统。 各系统独立进行需求调度和人员投入分配。

系统建设资源池模式虽然可以灵活调配资源，但也存在较高的沟通协调成本。 由于网贷业务涉及多个系统，产品经理需要与多个系统的管理者沟通，协调多条线的需求调度。 但从系统角度来看，需求来源多样，每个产品都有渴望上线的新需求。 系统需要对需求进行协调和优先排序，关键产品的研发能力无法得到保障。 再加上人员的调配和流动（厂家人员的流动性问题在银行业很常见），前期沟通的交付承诺往往无法实现，需求延迟交付在所难免。 同时，由于系统之间相对独立，高昂的通信成本也导致各个系统之间形成信息孤岛。 原本相互关联甚至相互依赖的系统需求的研发进度彼此不可见，给开发联调和测试带来了很大困难，导致产品研发和交付陷入泥潭。

显然，这种“沟通一次，默默祈祷准时交货，实际上却常常适得其反”的状态，完全无法满足业务拓展的需求。 传统独立运作的研发管理体系的“扁平化运作”无法适应复杂产品的高频研发。 协作需求。 当务之急是整合资源，运用部落主义，组建跨体系端到端投递队伍，形成“海陆空”多体系协同特种部队，支撑境内高效率、高质量投递。采取“立体作战”的方式。 图17-1为网贷产品研发部落结构图。

图1-1 网贷产品研发部落

在开发网贷产品的过程中，为了解决各系统之间协调困难、调度混乱带来的交付问题，我们引入了虚拟部落系统——将人员划分为不同系统、不同职能、不同角色，都为产品服务。一起。 在保留原有功能线的基础上，我们将打通研发价值流，形成具有端到端交付能力的虚拟团队。 多个团队组成一个部落，可以独立消化产品的大部分需求。

在这样的组织编队设计下，我们将部落内各个系统成员的工作站搬到了同一区域，大大减少了跨职能、跨系统带来的沟通成本。 建立一个相对稳定的团队，可以让团队成员有更大的归属感和荣誉感，进一步促进部落内部的合作与协调，提高协作效率。

在建立产品部落的基础上，我们实施需求预估和跨团队（系统）的需求调度活动，建立部落内统一的交付节奏。 在每次迭代开始之前，每个团队都会梳理下一次迭代的系统需求，并给出每个系统需求的优先级和预期迁移时间。 部落内的团队领导能够充分沟通，分析需求关联性和依赖关系，从整体角度考虑，提出更合理的系统需求开发计划。 在这个“作战计划”的指导下，系统需求交付错位的可能性大大降低，避免了跨系统联调时的长期阻塞和等待。 有节奏、稳定的需求交付也极大地缓解了需求测试和验收的压力，让整个研发团队工作有条不紊。 工作项目多而不乱，多系统协同的“立体作业”取得了丰硕成果。

从“疲惫”到“有序行进”

网贷产品作为明星产品，需要消化各个版本中各方面的需求。 转型实施前，业务在版本开发过程中频繁添加“紧急需求”，导致版本范围不断扩大，研发团队压力巨大。 当发布窗口临近时，一些需求刚刚开发完成，留给测试的时间窗口极其狭窄，测试人员必须加班加点才能赶上测试进度。 虽然发布系统中设置了“封印”时间点，但迫于交付压力，研发团队不得不反复“解封”版本，将需求填写到版本中。 这些“紧急需求”未经充分测试就匆忙上线，带来极高的质量风险。

随着时间的推移，业务与IT之间的信任已经耗尽——业务方认为技术团队的交付经常逾期，交付质量难以保证； 技术方认为业务团队的需求规划不合理，研发团队已经难以满足交付要求。 。 在敏捷转型过程中，为了打破业务与技术协同的泥潭，我们在原有的发布节奏的基础上，建立了如图17-2所示的“月版本列车”：

图1-2 网贷产品版本火车

在商业与技术合作的困境中，关键问题是研发能力的不透明。 通过版本训练，规范团队的研发节奏，建立稳定的迭代时间窗口。 只需几次迭代，研发团队就可以明确自己的迭代研发能力，并建立所需交付数量的基线。 只有让团队的迭代研发能力透明化，才能重新建立业务与技术之间的信任。

在迭代能力透明的前提下，业务与技术达成了新的契约。 业务方需要对各个版本的需求进行优先级排序，在添加“紧急需求”时需要考虑替换低优先级的需求。 这种优化机制保证了迭代工作量能够维持在研发团队可以接受的范围内，大大减少了研发团队为了追求发布日期而造成的低质量交付； 技术团队的工作节奏也更加稳定。 可以更加从容地安排需求研发工作，减少并行工作量，形成稳定的需求交付流程，实现高时效、高质量的需求交付。

通过版本训练的实施，该产品的需求交付周期从改进前的82天逐渐稳定到42天，生产缺陷数量大幅下降。 仅通过增加需求优化，该企业就实现了更短的交货时间和更高的产品质量。 同时，版本列车建立的稳定的交付节奏也使得产品的相关系统在联调时变得异常便捷。 网贷产品研发团队逐渐成为明星团队，为机构后续敏捷、规模化推广奠定了坚实的基础。 基础好。

从“黑暗的眼睛”到“透明”的战场

华润银行实施的传统项目管理体系严重依赖报告材料，团队领导需要整理复杂的项目计划和流程文件。 项目计划文件可操作性差，流于形式； 而项目周报则没有实质内容，成为团队的负担。

网贷产品作为明星产品，在团队管理上获得了一定的自主权。 然而，在传统的项目管理框架下，团队负责人仍然只能通过团队成员的日报和周报来了解团队的研发进度，这通常需要维护额外的项目进度表来跟踪事务。 日报、周报延迟、风险记录遗漏等问题，导致一些关键阻塞问题无法及时暴露，导致需求按时交付的风险急剧上升，研发团队往往要付出代价通过加班来做到这一点。

即使研发团队的负责人对自己团队的研发进度有如此掌控力，但跨团队协作时，想要跟进进度就更加困难了。 同时，产品开发对于产品经理来说几乎是一个“黑匣子”，不可能指望在业务和技术之间建立信任来兑现承诺。

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

图1-3 网贷产品需求体系及价值流程

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

跨团队协作时，快速浏览相关团队的需求板将告诉您相关需求的状态。 测试团队还可以参考相关需求的开发进度来安排测试计划，及时暴露测试压力和交付风险，避免版本末期突然增加的繁重测试任务让测试团队不堪重负。

“透明”使得团队的每一个成员都能了解当前迭代中遇到的问题和瓶颈，鼓励团队成员在工作过程中发现问题、提出问题，然后利用团队的力量解决问题，大大缩短了时间。 team's time 遇到问题时的阻塞时间。 团队领导的工作不再是简单地分配工作，而是协助团队协调外部资源，帮助解决阻塞问题。 “透明”让团队的自主权得到最大化。 管理者不再需要跟踪每件事情的细枝末节，而是实行“放手、看”的管理模式。

工欲善其事，必先利其器

该网贷产品的研发团队外包比例较高。 如何提高产品交付质量是团队面临的一大难点。 组长经常强调自测开发的重要性，并要求开发人员在移动测试时提供自测的截图，以保证自测开发。 针对这些情况，虽然制定了详细的工作规范，但收效甚微。

在实施转型过程中，为了提高团队素质，我们增加了桌面检查活动作为质量关。 即在开发和迁移测试过程中，测试人员提供与需求对应的核心功能验收案例并准备测试数据，开发人员针对核心案例进行功能演示。 通过桌面检查的演示，让测试人员对功能的实现有更直观的了解，同时可以从测试的角度提醒开发人员可能存在的质量风险； 开发人员可以在交付早期发现缺陷，从而显着减少缺陷。 维修成本大大提高了产品交付质量。 成熟到可以进行桌面巡检的团队自发邀请UI人员加入桌面巡检，进一步保证了产品风格的还原和交互的流畅。

同时，我们基于行业基础设施，优化了代码审核流程，完善了“提交-扫描-审核-改进”的代码质量改进周期。 开发者提交的代码会触发质量扫描，扫描报告会推送到平台，供团队在代码审核时参考。 当团队在平台上进行代码评审时，评审意见可以直接注释在代码上，让开发人员快速定位优化点。 系统化的代码审查工具链与质量访问控制相结合，不仅提高了团队的代码质量，也留下了研发质量活动的痕迹。 既满足了银行对代码审核等质量活动记录的审核要求，又减少了研发团队整理资料的需要。 负担。 如图17-4所示。

图1-4 代码质量改进周期

随着团队交付能力的提高，对工具的要求也会越来越高。 让工具匹配团队的交付节奏，积累研发数据和业务数据，建立“持续交付-持续改进”的迭代循环，是打造优秀团队的必由之路。 随着敏捷转型的大规模推进，基础能力建设也成为华润银行的重点战略目标。

刀刃上用的是好钢

虽然部落系统可以极大提升技术团队的交付能力，保证需求交付的及时性，但部落系统带来的资源锁定对于资源有限的中小银行来说也是一个不小的挑战——识别聚焦重点业务，集中优势资源，把“好钢”用在“刀刃上”，你更有可能在竞争的红海中脱颖而出。 在打造部落的同时，我们还应该不断完善研发工具链，构建流畅的工作流程，强化内在的质量要求，在持续交付的过程中实现流程优化和人员能力培养。 “集结精兵，打硬仗”，通过产品部落体系的应用，交付团队能够与产品一起不断成长，实现业务的突破和蓬勃发展。

结尾

本文摘自《软件研发行业创新实践案例分析》。 本书旨在洞察各企业在工程创新、管理创新、产品创新、技术创新、效率创新等方面的最佳实践，以及案例的分析和总结。 其他公司提供一定的参考和借鉴，帮助大家更快的解决遇到的问题。

本书共包含22个实践案例，涵盖研发效率提升、数字化实践、敏捷转型、研发管理、人才培养、AI可视化分析引擎搭建等软件研发各个方面。 适用于软件研发行业的各个方面。 管理者和实践者。