南方某大型基金研发数字化转型案例

基金行业科技团队面临的挑战

近年来，基金行业为了进一步满足金融市场多样化的配置需求，提升基础金融服务水平与效率，大数据、云计算、人工智能等创新技术快速发展，资产管理行业将数字化战略提升到了新的高度¹。这一转型不仅提高了基金行业的运营效率，也为投资者提供了更加精准和个性化的服务。

随着业务快速发展，业务和信息系统的数量呈爆发式增长。一方面，基金公司规模发展迅速、创新业务层出不穷、合规越来越被强调、中后台专业化分工日益精细，导致金融科技需求井喷式爆发，组织要求IT团队交付产能保持只增不减的同时对交付质量与交付时效也提出了更高的要求。另一方面，随着业务量的快速增长，业务系统架构日趋复杂，运维对象和边界不断拓展，运维工作量快速增加，对IT运维团队的业务系统运维能力也提出了更高的要求²。

2023年年初，中国证券投资基金业协会向基金公司下发了《基金管理公司网络和信息安全三年提升计划（2023-2025）》征求意见稿，对基金公司的网络、信息安全、IT建设提出了很多切合实际、完整全面的工作思路、建议和内容³。这些对于未来几年基金行业的IT建设提供了很好的参考，同时也提出了更高的期望。

然而，在数字化转型的过程中，基金行业也面临着一些挑战。过去十年，公募基金账户数从不到4000万快速增长到15.22亿，增加了17倍取得了阶段性成果⁴。但我们同时也发现支撑业务发展的科技团队越来越力不从心。很多组织意识到了其在研发规范、质量、效率等方面存在诸多不足，一些组织开始探索敏捷开发模式，但未完全执行到位，研发效率和质量管理环节薄弱，原有研发工具体系割裂零散，开发-测试-运维环节的协同效率不高，进而难以满足业务提出的持续快速响应和稳定提供服务的诉求²。

基金行业业务数字化程度很高，但是科技支撑数字化程度远远落后于业务数字化程度，这种“灯下黑”的情况，在各家投资机构均不同程度的存在。有些甚至影响了业务的发展，业务不满意，科技成为业务发展的瓶颈和阻塞点⁵。因此，基金行业亟需启动研发数字化进程，提高自身研发效能。

南方某大型基金公司一马当先，重新梳理研发管理流程，构建跨职能的研发效能改进组织，建立一套自上而下驱动改进的效能管理长效机制和组织文化，建设一套具备持续集成、持续部署、持续运维能力，覆盖研发、测试、部署、运维、运营全场景的规范体系与一体化平台，持续推进一线研发团队目标驱动、自我持续改进，并通过组织级平台驱动来提供持续赋能。南方某大型基金打通了IT研发运维工作流和业务产品需求端到端价值流，快速响应公司数字化转型战略，满足业务需求高效、高质、快速实现，助力公司高质量发展。

下面从团队作战阵形、交付节奏、沟通协同机制、价值聚焦、平台工具等层面，介绍南方某大型基金如何以2个数字化转型试点作为突破口，构建高效率（需求响应时效缩短30%以上）与高质量交付的研发团队。爱捷为南方某大型基金提供差异化竞争策略保驾护航的过程，也可以为业内类似处境的基金公司提供些许参考。

从“特种兵作战”到“集团军作战”

过去十几年，随着基金行业的发展，科技团队的规模也在不断扩大。一些大型基金公司甚至建立了数百人的IT团队，以支持其业务运营和创新发展⁶。同样，南方某大型基金的IT团队也经历了这个过程，最初是十几人到几十人，基本能够满足业务的交付需要，在科技支撑上多采用能力比较强的全栈单兵作战——我们称之为“特种兵作战”模式，但是随着业务规模发展迅速、创新业务层出不穷，IT团队也从当初的几十人发展为现在的几百人规模，同时厂商人员比例也在不断提高，增加了管理难度。虽然系统建设资源池的模式能灵活调配资源，但同时也存在较高的沟通、协调成本。由于基金业务之间通常会涉及多个系统，因此产品负责人需要和多个系统的负责人沟通，存在多线协调需求的排期问题。但从系统的角度来看，需求来源多样，各产品均有急于上线的新需求，系统需要统筹安排需求优先级，重点产品的研发产能无法得到保障。再叠加人员的调配与流动（在金融科技领域中厂商人员的流动性问题十分普遍），往往导致前期沟通的交付承诺无法达成，需求延期交付不可避免，或者出于无奈就“脚踩西瓜皮，滑到哪里算哪里”。同时，由于系统之间相对独立，较高的沟通成本也导致各个系统之间形成信息筒仓。原本相互关联，甚至相互依赖的系统需求的研发进度互不可见，给开发联调和测试工作都带来了极大困难，导致产品研发交付陷入泥潭。

显然，这种“靠几个精神领袖引领的特种兵部队交付”的状态已完全无法满足业务拓展的诉求，传统研发管理中系统各自为政，靠个别特种兵频繁拉通起来的方式，长期看是无法适应复杂产品研发的高频协作需求的，团队也疲于奔命导致交付质量下降，有时候不得不停下来启动“修桥修路修车”的工作（如：重构）。在这种情况下，南方某大型基金选择整合资源，使用“部落制”的方式组建跨系统的端到端交付团队，形成“海陆空”多角色多系统协同的集团军部队，业务、产品、开发、测试、运维等不同兵种以“集团军作战”的方式支持高效率、高质量的交付方式。图1所示，为部落制的结构图示意图。

图1-试点部落组织结构示意图

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

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

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

从“消防员模式”到“领航员模式”

A试点团队作为一个被业务方高度依赖的项目，其需求来源是多样的，每个版本都需要消化来自各个方面的需求压力。在转型实施之前，业务方在原本就“超级旺盛”的需求列表中，追加新的“紧急需求”，导致版本范围不断扩大，研发团队压力巨大，经常面临从别的团队临时“借调人手”干活的情况。当临近发版窗口时，部分需求才刚刚研发完成，留给测试的时间窗口极窄，测试又不得不加班加点追赶测试进度。虽然在发版制度中设置了“封版”的时间节点，但迫于交付压力，研发团队不得不反复“解除封版”，向版本中填充需求，导致“封版”变成了摆设。这些“紧急需求”没有经过充分测试就匆忙上线，存在很高的质量风险；也有一些原本已经“承诺好的重要紧急需求”因此被“挤出版本”导致需求方的不满。

长此以往，IT团队越来越像是消防员，业务与IT之间的信任感被消磨殆尽——业务方认为科技团队交付屡屡逾期、“不靠谱”，交付质量难以保证，做出来的东西不是业务方想要的；科技方则认为业务团队的需求规划不合理，研发团队为达到交付要求像消防员一样不断灭火，已经很“委屈”了，但费力不讨好。

在敏捷转型中，为破解业务和科技协作的泥潭，我们基于原有的发版节奏建立了如图2，3所示的“版本迭代双维管理节奏”：

图2-A试点小队版本迭代双维管理节奏

图3-B试点小队版本迭代双维管理节奏

在业务-科技协作困境中，要解决一个很关键的问题：研发产能情况的不透明。通过版本迭代双维管理规范团队研发节奏，建立稳定的迭代时间窗口，研发团队在人数相对固定的情况下，只需要几个迭代运行，就能明确自身的迭代研发容量，建立相对稳定的需求交付数量的基线。只有将团队的迭代研发容量透明化，才能让业务看到一段时间研发的真实交付能力和趋势，重新建立业务和科技之间的信任。

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

通过实行版本迭代双维管理，A试点小队的需求响应时效从改进前的162天逐步稳定至90天左右，生产缺陷趋势逐渐下降。通过实施需求优选机制，开发团队能够集中精力处理价值更高的需求。这不仅降低了需求返工的比例，还减少了研发过程中的并行需求数量。这些改进最终缩短了业务的交付周期，并提升了产品的质量和一致性。同时，版本迭代双维管理方式建立的稳定交付节奏也使得该产品的相关系统在联调时获得了极大的便利。B试点小队也从原来的“版本发布时间不固定不可预测”，逐渐将交付节奏稳定到需求响应时效在80天左右。A小队和B小队也逐步成为样板团队，为组织后续的敏捷规模化推广建立了良好的基础。

从“研发黑盒”到“透明战场”

传统项目管理方式中，业务和研发之间各管各的需求“小账本”，团队负责人基本只能通过团队成员滞后的日报、周报中掌握团队的研发进度，通常需要项目助理额外维护一张项目进度表来进行事项的跟踪。日报和周报的汇报延迟、风险记录遗漏、协同信息滞后等问题，使部分关键的阻塞问题未能及时暴露，导致需求按时交付的风险陡增，研发团队往往不得不通过加班为此买单。研发团队负责人对自己团队的研发进度掌控尚且如此，跨团队协作时的进度跟进和与业务团队的进展同步就更为困难。同时，产品的开发过程对业务人员和产品经理而言几乎就是“黑盒”，期望在业务和科技之间建立交付承诺的信任更是无从谈起。

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

图4-南方某大型基金样板间需求体系和价值流（需求、任务、版本）

如图4所示，我们围绕产品需求、系统任务价值流建立了双层看板，通过可视化的方式记录需求的流动情况。通过每日站会机制推动团队积极对齐项目进度，将项目进展、风险问题阻塞直观地在看板上展现出来。开发进度不再是团队负责人手中疲于维护的“战况简报”，而是快速更新、对团队成员透明可见的“现场直播”。产品需求作为较粗颗粒度的需求，更新频率偏低，可以用于观察产品需求所处的具体阶段；系统任务的颗粒度更细，更易于在看板上流动，能快速反映需求的研发状态和阻塞情况。同时，团队每位成员在站会前点亮自己当天的工作内容，方便小队长了解人员负荷情况，及时调整资源平衡。同时我们也建立了缺陷可视化看板，并且将缺陷和系统任务相关联，方便团队日常了解需求开发过程的过程质量现状，开发人员及时跟进解决、测试人员及时验证关闭。

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

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

将军赶路不追小兔，好钢用在刀刃上

虽然部落制能大幅提升科技团队的交付能力，保障需求交付时效，但部落制伴随的资源锁定对中小企业有限的资源也是不小的挑战——甄别重点业务，将军赶路不追小兔，集中优势资源，将“好钢用在刀刃上”，才更有可能在竞争的红海中脱颖而出。在建设部落的同时，也应该持续打磨研发工具链，构建流畅的工作流程，强化质量内建要求，在持续交付的过程中实现流程优化和人员能力的培养。根据我们创建的管理信息架构模型，根据南方某大型基金试点小队现状梳理的业务产品分类和系统需求分类，落在我们的知微工具中，能够很直观的实时展示组织资源投入各业务占比情况和科技底盘能力建设投入情况，“集精兵、打硬仗、建能力”，通过应用产品部落制让交付团队伴随产品持续成长，实现业务的突破和蓬勃发展。

图5-管理信息架构模型示意图

图6-需求分布示意图

工欲善其事，必先利其器

如何提升产品交付质量是团队的一大难点。团队负责人频繁强调开发自测的重要性，并为确保开发自测而要求开发人员在移测时提供自测的截图或录像。虽然针对这些情况设置了详细的工作规范，但因为截图和录像为事后留痕，缺少团队成员之间的实时互动，所以沟通周期较长，效果依旧收效甚微。

在实施转型的过程中，针对团队质量的提升，我们增加了“桌面检查”活动作为质量门禁。即在开发移测时，由测试提供对应需求的核心功能验收案例（通常称为P0案例）、准备测试数据，由开发人员对照核心案例进行功能演示。通过对桌面检查的演示，测试人员、产品经理和业务人员对功能的实现有了更直观的认知，同时也能以测试的视角提示开发人员可能存在的质量风险；开发人员能在交付早期识别缺陷，大幅降低了缺陷的修复成本，很大程度上提升了产品交付质量，将质量“左移”，大大降低交付时出现业务和产品“这不是我想要的需求”的情况。同时，桌面检查增加了交付团队成员之间的面对面沟通交流和相互之间的磨合，熟悉彼此工作方式让工作产出更高质高效。

图7-南方某大型基金桌面检查实践

随着团队交付能力的增强，对工具的要求也会越来越高。让工具匹配团队交付节奏，沉淀研发数据和业务数据，建立“持续交付-持续改善”的迭代循环，是建设卓越团队的必经之路。随着数字化转型的规模化推广，DevOps平台的基础能力建设也成为南方某大型基金的重点战略目标。相信未来的规模化推广工作加上DevOps平台工程的加持，将会进一步提升整个组织的研发效能，为规模化数字化转型打好坚实的基础。

图8-工具平台方案示意图

未来规划：延续规划路径，全面推进数字化、数据驱动决策、实现投产价值分析

南方某大型基金数字化转型试点整体周期6月有余，自主运行3个多月，2个试点小队转型成效明显：

A试点小队产品需求响应时效（需求优选至需求上线发布）由原来的160多天（2023年10月）提升至90天左右（2024年4月），各阶段时效分配较合理，研发节奏相对稳定）；A试点团队研发产能基线已基本建立，迭代规划能力稳步增强；质量方面缺陷管理初步线上化透明化，需持续观察缺陷解决时效的提升空间；业务方也对研发团队的交付时效、交付质量的满意度有所提高。

B试点小队由原来（2023年10月）的没有固定交付节奏提升至产品需求响应时效80天左右（2024年4月），研发时效基线已形成；质量检查实施活跃，缺陷管理规范化、线上化程度有所提升，达到业内良好水平。

总结下来，我们通过1套机制，促进系统性提升；3个支柱，优化协作基础；1个平台，打造“多快好省”的度量体系，提升长期延续性和延展性。转型成效获得了IT团队内部和业务部门的双重认可：

• 通过职责清晰划分、系统标准化和规范化，业务部门反馈业务需求管理和跟踪得以规范，产品质量显著提升；

• 透明化和线上化变革解决了许多“黑盒”问题，业务和IT团队一致认为，明显提升了协同效率，降低了沟通成本；

• 业务部门与IT部门更加融合，双方形成融合团队，工作效率及准确率大幅提高，对价值交付的理解进一步达成一致。

  

图9-改进方案：在保持组织快速响应力的同时，形成科技统一治理

2023年，我们同该基金客户一起完成了研发管理数字化“样板间”工程，建立试点研发效能基线；2024年，我们会继续陪跑客户沿着数字化研发管理进阶路径，在广度上“全面线上化，建立效能基线，提升响应力；在深度上打造外部DEVOPS认证标杆，以评促改，提升核心研发团队以及未来组织的工程实践和研发管理水平；未来实现全面数字化、数据驱动决策，实现投产价值分析，助力企业全面数字化管理。

图10-研发管理数字化三年规划路线图示意图

本文利用KIMI协助整理，引用信息来源如下：

1.陈一昕：基金行业数字化转型实践与对策建议｜《产业转型研究》专刊报道2022-06-14

https://www.iii.tsinghua.edu.cn/info/1121/3068.htm

2. 如何打造“聪明的”基金公司 启动数字化引擎已成不二法门

2022年11月21日08:53 中国经济网

https://finance.china.com.cn/money/fund/20221121/5904004.shtml

3.引导资本流向科技创新领域 私募基金行业进一步助力服务实体经济

2023年07月12日09:16 | 来源：

证券日报http://finance.people.com.cn/n1/2023/0712/c1004-40033879.html

4.【基金业数字化转型专题】华夏基金数字化转型探索与实践

时间：2022-11-07

https://www.amac.org.cn/industrydynamics/huiYuanDongTai/202211/t20221107_14147.html

5. 公募基金第二战场：发力金融科技 赋能投资全生命周期

2022年05月30日00:40

证券时报https://finance.sina.com.cn/am/fund/2022-05-30/doc-imizmscu4067855.shtml

6. 中国证券业协会：2021年金融科技领域投入布局不断加大 证券行业数字化转型全面加速

胡雨 中国证券报·中证网2022-09-27 20:24

https://www.cs.com.cn/qs/202209/t20220927_6300408.html

本文作者：

孙伟娜，Agilean资深咨询顾问

审阅：

吴穹，Agilean首席顾问

熊小龙，Agilean首席顾问

陈泽荣，Agilean高级顾问

刘雨哲，Agilean高级顾问

点分享

点收藏

点在看

点点赞