方法论揭秘｜研发数字化转型，这家保险企业做对了什么？

2023-08-02
广东
本文字数：3883 字
阅读完需：约 13 分钟

7 月 27 日，FCS 2023 第 7 届中国金融 CIO 峰会（深圳站）如期举行。大会以「洞见·智慧金融」为主题，深度解读中国金融行业数字化转型现状，探讨金融行业信息化趋势、数字供应链金融服务、金融科技创新等问题，期望数智化建设持续推动金融机构转型，让协同更智能，让组织更智慧。

作为企业级研发管理平台的领军者，ONES 受邀出席本次大会。期间，ONES 研发效能顾问董晓红发表了题为「金融企业研发数字化管理实践」的演讲，分享了 ONES 在金融保险行业落地研发数字化管理的实践效果及方法论。

阅读本文，你将了解：

保险业研发管理为何要数字化？
四个阶段，解读某保险企业研发数字化成功实践
三大实践，助力金融企业更快实现研发数字化转型

一、保险业研发管理为何要数字化？

某保险企业成立于 2009 年，产品体系涵盖车险、企业财产保险、农业保险及人身意外保险等 13 大类 400 余险种。在信息系统自主可控的浪潮下，该企业积极响应，在五年战略规划中正式启动了「信息化支持管理提升」，将其提到了「数字化赋能业务发展」的战略转型高度。

在这样的背景下，我们建议该企业通过研发管理的数字化转型，提升产品研发水平和金融服务效率。原因如下：

从组织业务视角看，在「信息化」向「数字化」转型过程中，需要整个保险行业快速响应市场，高效迭代产品。
从监管视角看，中国银保监会于 2022 年发布了《关于银行业保险业数字化转型的指导意见》，强调保险机构要着力推动科技敏捷转型，建立快速响应需求的敏捷开发体系，提升金融产品的开发质量和运营效率。
从行业自身的发展视角看，保险行业的组织协同复杂性持续加大，对于效能提高的诉求也越来越大。可以说，业务已经在数字化的路上，但研发管理还未数字化。

而后，我们 ONES 服务团队通过资料收集、问卷调查及现场访谈，抽丝剥茧，将该保险客户遇到的问题与挑战归纳为三类：

业务数字化转型急需 IT 管理的提升。业务迭代频率越来越高，90% 以上的项目还是采用传统瀑布式的管理方式，交付周期长；同时，费时费力交付的产品并不是客户想要的，质量差、线上故障多，交付模式已经成为瓶颈。
团队、不同角色间的协同效率较低。无论是任务的分配还是状态的追踪，都需要通过人工、邮件或会议来反馈，沟通成本高。此外，计划管理使用的是在线文档和开源工具，无法满足大家对于项目管理的诉求。
缺乏统一的研发协作和知识库管理平台。需求管理工具分散，各职能工具互不关联，无法形成组织级的整体效应。同时，项目过程文档管理分散，缺少在线文档协同工具，不利于组织资产的沉淀，更不利于管理层对整个组织研发效能的客观判断。

针对上述问题，我们与客户共同制定了此次研发管理升级的总目标：通过搭建组织级研发体系，融合业务和技术，建立快速响应、质量稳健的科技交付底座。当落地方案时，我们也采取了「目标导向为主，问题驱动为辅」的原则，确保改进方向不迷失。

具体而言，研发管理的升级思路分为三个：

搭建组织级流程规范，引入提升协作效率的敏捷实践、提升工程效率的工程实践。
构建一体化的工具链集成，帮助企业固化流程规范，打造端到端的、可视化的全局视角，驱动效能改进。
建立持续改进的机制，形成效能管理闭环。

二、研发管理数字化的四个阶段

有了目标和方向，接下来我们就可以确定整体方法和思路了，可以分为四个阶段。

第一个阶段，搭建组织级流程规范，并引入敏捷 Scrum 相关实践。我们从问题出发，结合现有的流程、工具、痛点，补全、优化，直至最终形成组织级流程规范，涵盖整个项目管理、产品全生命周期管理、需求管理。同时也收集了各部门的最佳实践，形成组织级财富，进行推广复用。

这里我想对两个问题进行补充解释。一是为什么要收集团队内部的最佳实践，因为我们发现内部的实践更符合该组织的文化和土壤，也更容易被团队所接受，推广效果也更好。另一个问题，为什么要先去建立组织级的流程规范？在我们升级思路时，该部门领导也提出过类似的问题。有以下几个原因：

流程规范可以在研发资源、研发管理目标之间建立协调关系，有利于目标落地。
确保了整个组织能使用相同的语言，有助于形成整体效应。
避免各部门再重复建设一套流程规范，减少浪费。
有助于沉淀组织的最佳实践，形成组织财富，并加以推广。

第二个阶段，以 ONES 项目管理平台为中心，再结合客户现有工具，形成一体化平台。一方面，通过平台固化流程，落地敏捷 Scrum 实践。另一方面，由于现有的测试质量较差，因此我们决定在客户自研的发布平台上集成一些质量保障手段，让质量与安全协同并进。

归根结底，第二阶段就是要通过各种手段将工具链集成，完全落地组织级流程规范。从图中可以看到，在升级前，工具链是面向职能的专一工具，也就是说各个职能所用的工具又不统一，十分分散，导致项目数据孤立，于是我们决定进行升级。

打通 ONES 管理平台，也就是从需求提出到发布上线，取得端到端的集成。
在发布平台 CI 阶段就集成质量保证手段，缩小反馈周期。无论是测试阶段还是应用安全阶段，原有的发布平台大都是抛阶式的。开发完了交给测试，测试完了交给运维，然后再做代码扫描，导致整个交付周期变长。而有了质量保证手段，当我们在 CI 阶段提交代码时，就可以同时进行测试和扫描。一旦质量有问题，立即给开发反馈，从而缩短反馈周期。
最后我们又做了一个制作平台。企业原有的工具比较分散，因此我们在 ONES 平台做一些项目管理，以及外包账号权限的统一管理，再分发给其他系统，这样一来，其他系统只需要专注于自己的事情就可以了。

第三个阶段其实是在前两个阶段积累的基础之上，以精益思想为指导，以数据为驱动力，建设研发度量指标体系。我们在整个流程设计中其实已经兼顾了度量埋点，因此数据会自然而然地落到系统中，不需要额外通过人工获取数据。最终要达到的目标是建立持续改进机制，让效能管理形成闭环。

还需注意的是，不同视角的关注点是不同的。比如说高层更关心整个项目的产出比是多少；做了这么多需求，业务侧的评价是什么；做了这么多项目，该怎么分配项目奖金。而从开发视角来看，更关心这个需求的完成质量如何，能否给业务带来价值；埋点是否清楚，是否会引发故障；做的业务监控是否有效，等等。因此在搭建度量体系时，我们需要依据不同的主体来创建指标，从而让不同角色确定工作优先级。

前三个阶段我们着重从「事」的层面去改进，那么最后一个阶段就要从「人」的层面来入手了。「人」的方面主要是提升人的认知，在这个阶段，我们帮客户定制了配套的课程，包括导入敏捷理论，导入质量内建、意见理论等系统性课程，扩展团队的升级思路。

三、研发管理数字化的三个关键实践

接下来再分享一下我们用到的三个关键实践。

首先是科技组织架构的优化，也就是根据业务形态和资源规模，将架构由「面向职能型」调整为「面向业务型」，建立与业务线对应的敏捷交付组织。可以参考下图：

在架构调整之前，可能软件研发是一个部门，测试是一个部门，运维是一个部门，主要的管理方式是把人作为资源，分配到不同的项目中去。要知道，工程师如果不停地切换项目，每次切换都会带来资源损耗，降低交付质量和交付效率。此外，这些职能的领导总是忙着协调资源，很难有时间去做整体规划、技术改进等，缺少长期且稳定的运营。

而调整为面向业务的组织架构，就是期望把工作交给跨职能团队，建立长期稳定的团队关系，让团队有共同的目标，从而提升协作效率。

心理学家布鲁斯·塔克曼在「团队发展阶段模型」中也有类似的指出：团队发展遵循一定的周期，要经历组建期、冲突期、规范期、执行期，最后才能产出好的绩效。这也很好理解，就好比你跟自己的同事，需要经过几个阶段的磨合才能产出高的绩效，真正发挥出团队的士气。所以我们强调组建长期稳定的团队，是期望能够沉淀更专业的知识和经验，持续为组织交付业务价值。

第二个实践是建立了统一的需求三层结构，拉通业务侧与产研侧，以促进高效的分工和协作。