方法论揭秘｜研发数字化转型，这家保险企业做对了什么？
7月27日，FCS 2023 第 7 届中国金融 CIO 峰会（深圳站）如期举行。大会以「洞见·智慧金融」为主题，深度解读中国金融行业数字化转型现状，探讨金融行业信息化趋势、数字供应链金融服务、金融科技创新等问题，期望数智化建设持续推动金融机构转型，让协同更智能，让组织更智慧。
作为企业级研发管理平台的领军者，ONES 受邀出席本次大会。期间，ONES 研发效能顾问董晓红发表了题为「金融企业研发数字化管理实践」的演讲，分享了 ONES 在金融保险行业落地研发数字化管理的实践效果及方法论。
阅读本文，你将了解：
-
保险业研发管理为何要数字化？
-
四个阶段，解读某保险企业研发数字化成功实践
-
三大实践，助力金融企业更快实现研发数字化转型
一、保险业研发管理为何要数字化？
某保险企业成立于2009年，产品体系涵盖车险、企业财产保险、农业保险及人身意外保险等13大类400余险种。在信息系统自主可控的浪潮下，该企业积极响应，在五年战略规划中正式启动了「信息化支持管理提升」，将其提到了「数字化赋能业务发展」的战略转型高度。
在这样的背景下，我们建议该企业通过研发管理的数字化转型，提升产品研发水平和金融服务效率。原因如下：
-
从组织业务视角看，在「信息化」向「数字化」转型过程中，需要整个保险行业快速响应市场，高效迭代产品。
-
从监管视角看，中国银保监会于2022年发布了《关于银行业保险业数字化转型的指导意见》，强调保险机构要着力推动科技敏捷转型，建立快速响应需求的敏捷开发体系，提升金融产品的开发质量和运营效率。
-
从行业自身的发展视角看，保险行业的组织协同复杂性持续加大，对于效能提高的诉求也越来越大。可以说，业务已经在数字化的路上，但研发管理还未数字化。
而后，我们 ONES 服务团队通过资料收集、问卷调查及现场访谈，抽丝剥茧，将该保险客户遇到的问题与挑战归纳为三类：
-
业务数字化转型急需 IT 管理的提升。业务迭代频率越来越高，90% 以上的项目还是采用传统瀑布式的管理方式，交付周期长；同时，费时费力交付的产品并不是客户想要的，质量差、线上故障多，交付模式已经成为瓶颈。
-
团队、不同角色间的协同效率较低。无论是任务的分配还是状态的追踪，都需要通过人工、邮件或会议来反馈，沟通成本高。此外，计划管理使用的是在线文档和开源工具，无法满足大家对于项目管理的诉求。
-
缺乏统一的研发协作和知识库管理平台。需求管理工具分散，各职能工具互不关联，无法形成组织级的整体效应。同时，项目过程文档管理分散，缺少在线文档协同工具，不利于组织资产的沉淀，更不利于管理层对整个组织研发效能的客观判断。
针对上述问题，我们与客户共同制定了此次研发管理升级的总目标：通过搭建组织级研发体系，融合业务和技术，建立快速响应、质量稳健的科技交付底座。当落地方案时，我们也采取了「目标导向为主，问题驱动为辅」的原则，确保改进方向不迷失。
具体而言，研发管理的升级思路分为三个：
-
搭建组织级流程规范，引入提升协作效率的敏捷实践、提升工程效率的工程实践。
-
构建一体化的工具链集成，帮助企业固化流程规范，打造端到端的、可视化的全局视角，驱动效能改进。
-
建立持续改进的机制，形成效能管理闭环。
二、研发管理数字化的四个阶段
有了目标和方向，接下来我们就可以确定整体方法和思路了，可以分为四个阶段。
第一个阶段，搭建组织级流程规范，并引入敏捷 Scrum 相关实践。我们从问题出发，结合现有的流程、工具、痛点，补全、优化，直至最终形成组织级流程规范，涵盖整个项目管理、产品全生命周期管理、需求管理。同时也收集了各部门的最佳实践，形成组织级财富，进行推广复用。
这里我想对两个问题进行补充解释。一是为什么要收集团队内部的最佳实践，因为我们发现内部的实践更符合该组织的文化和土壤，也更容易被团队所接受，推广效果也更好。另一个问题，为什么要先去建立组织级的流程规范？在我们升级思路时，该部门领导也提出过类似的问题。有以下几个原因：
-
流程规范可以在研发资源、研发管理目标之间建立协调关系，有利于目标落地。
-
确保了整个组织能使用相同的语言，有助于形成整体效应。
-
避免各部门再重复建设一套流程规范，减少浪费。
-
有助于沉淀组织的最佳实践，形成组织财富，并加以推广。
第二个阶段，以 ONES 项目管理平台为中心，再结合客户现有工具，形成一体化平台。一方面，通过平台固化流程，落地敏捷 Scrum 实践。另一方面，由于现有的测试质量较差，因此我们决定在客户自研的发布平台上集成一些质量保障手段，让质量与安全协同并进。
归根结底，第二阶段就是要通过各种手段将工具链集成，完全落地组织级流程规范。从图中可以看到，在升级前，工具链是面向职能的专一工具，也就是说各个职能所用的工具又不统一，十分分散，导致项目数据孤立，于是我们决定进行升级。
-
打通 ONES 管理平台，也就是从需求提出到发布上线，取得端到端的集成。
-
在发布平台 CI 阶段就集成质量保证手段，缩小反馈周期。无论是测试阶段还是应用安全阶段，原有的发布平台大都是抛阶式的。开发完了交给测试，测试完了交给运维，然后再做代码扫描，导致整个交付周期变长。而有了质量保证手段，当我们在 CI 阶段提交代码时，就可以同时进行测试和扫描。一旦质量有问题，立即给开发反馈，从而缩短反馈周期。
-
最后我们又做了一个制作平台。企业原有的工具比较分散，因此我们在 ONES 平台做一些项目管理，以及外包账号权限的统一管理，再分发给其他系统，这样一来，其他系统只需要专注于自己的事情就可以了。
第三个阶段其实是在前两个阶段积累的基础之上，以精益思想为指导，以数据为驱动力，建设研发度量指标体系。我们在整个流程设计中其实已经兼顾了度量埋点，因此数据会自然而然地落到系统中，不需要额外通过人工获取数据。最终要达到的目标是建立持续改进机制，让效能管理形成闭环。
还需注意的是，不同视角的关注点是不同的。比如说高层更关心整个项目的产出比是多少；做了这么多需求，业务侧的评价是什么；做了这么多项目，该怎么分配项目奖金。而从开发视角来看，更关心这个需求的完成质量如何，能否给业务带来价值；埋点是否清楚，是否会引发故障；做的业务监控是否有效，等等。因此在搭建度量体系时，我们需要依据不同的主体来创建指标，从而让不同角色确定工作优先级。
前三个阶段我们着重从「事」的层面去改进，那么最后一个阶段就要从「人」的层面来入手了。「人」的方面主要是提升人的认知，在这个阶段，我们帮客户定制了配套的课程，包括导入敏捷理论，导入质量内建、意见理论等系统性课程，扩展团队的升级思路。
三、研发管理数字化的三个关键实践
接下来再分享一下我们用到的三个关键实践。
首先是科技组织架构的优化，也就是根据业务形态和资源规模，将架构由「面向职能型」调整为「面向业务型」，建立与业务线对应的敏捷交付组织。可以参考下图：
在架构调整之前，可能软件研发是一个部门，测试是一个部门，运维是一个部门，主要的管理方式是把人作为资源，分配到不同的项目中去。要知道，工程师如果不停地切换项目，每次切换都会带来资源损耗，降低交付质量和交付效率。此外，这些职能的领导总是忙着协调资源，很难有时间去做整体规划、技术改进等，缺少长期且稳定的运营。
而调整为面向业务的组织架构，就是期望把工作交给跨职能团队，建立长期稳定的团队关系，让团队有共同的目标，从而提升协作效率。
心理学家布鲁斯·塔克曼在「团队发展阶段模型」中也有类似的指出：团队发展遵循一定的周期，要经历组建期、冲突期、规范期、执行期，最后才能产出好的绩效。这也很好理解，就好比你跟自己的同事，需要经过几个阶段的磨合才能产出高的绩效，真正发挥出团队的士气。所以我们强调组建长期稳定的团队，是期望能够沉淀更专业的知识和经验，持续为组织交付业务价值。
第二个实践是建立了统一的需求三层结构，拉通业务侧与产研侧，以促进高效的分工和协作。
「需求三层结构」分别是业务侧的需求全生命周期管理、产研侧的全生命周期管理，以及前后端开发、UI 人员的面向任务层级的需求。这种结构分层的好处是显而易见的：
三层之间可以互相联动。也就是说，产研侧的需求规划至开发侧之后，通过工具的自动化能力来保证状态的实施更新。既减少了人工操作，提升数据准确性，同时也减少了人工的工作量，让他们更专注地去做有价值的事情。
三层结构促进了高效的分工和协作。比如通过管理看板，可以将业务的需求价值流全部可视化出来，让所有干系人能拥有端到端的全局视角：从提出业务需求到业务上线，每个人都能看到过程中的瓶颈以及对业务的影响。
第三个实践是知识管理助力组织赋能。
知识管理对于企业的重要性是不言自明的，甚至可以说是企业最宝贵的资产，因此我们跟客户一同梳理了四个知识管理应用的场景：
-
在个人方面，侧重于培训学习、关键岗位赋能和知识积累，帮助个人提效。
-
在团队层面，侧重于项目协作、项目关联、文档协同等，支持团队知识运营。
-
在管理层层面，侧重于知识资产的共享，比如企业流程、制度、标准等。
-
在业务层面，侧重于业务场景化，包括研发、营销、服务等主题知识模板和知识库建设，达到对业务赋能的效果。
需要强调的是，知识管理也不是一蹴而就的，我们将这个过程分为了四个阶段，并为每个阶段设置了目标，分别是：
-
将显性知识归类，并结构化存储；
-
挖掘隐性知识，进行显性化存储；
-
对整个知识体系进行运营管理，及时补充新知识；
-
最后，用知识真正为业务赋能，为组织带来商业价值。
04 思考与总结
研发管理是系统性工程，需要整体统筹全局规划，才能使各要素之间同频共振发挥最大效益。除了刚才分享的内容外，研发管理也需要技术工程实践，包括组织的数字化、人才培养、文化建设等，从而减少变革阻力，推动变更成功。