ONES 出席产业互联高峰论坛，分享金融企业研发管理实践

11月13日，第二届产业互联高峰论坛暨2022国际互联网产业科技创新大会（上海站）如期举行，大会围绕「构建数字经济文明共同体」这一主题，聚焦企业数字化发展的方式、实战效果、人才发展等问题，期望通过充分讨论数字经济文明的趋势、IT 深度与业务结合的案例，成为推动数字经济文明的重要力量。

作为企业级研发管理工具的领军者，ONES 受邀出席本次大会，并同时斩获「2022年度数字经济科技创新最受欢迎品牌奖」和「2022年度行业科技创新解决方案奖」两大奖项。

会上，ONES 研发效能顾问董晓红发表了题为《金融企业研发数字化管理实践》的主题演讲，分享了 ONES 在金融保险行业落地研发数字化管理的实践思考及洞见。

以下是董晓红演讲的精华内容。

研发管理数字化转型的背景

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

在这样的背景下，我们建议客户做研发数字化管理。可以从三个视角看：

从组织业务的视角看，信息化向数字化转型过程中，需要整个科技快速响应市场以及保险产品的高效迭代。

从监管视角看，中国银保监会于2022年发布了《关于银行业保险业数字化转型的指导意见》，指出保险机构要着力推动科技敏捷转型，建立快速响应需求的研发运维体系和一体化平台，以提升产品开发水平和金融服务效率。

从行业自身的发展视角看，保险行业的产品链路、技术应用、组织协同的复杂性持续加大，企业对于效能提高的诉求也越来越大。可以说，业务已经在数字化的路上，但研发管理还未数字化。

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

业务数字化转型，急需 IT 项目管理的提升。业务迭代频率越来越高，90% 以上的项目还是采用传统瀑布式的管理方式，交付周期长；同时，费时费力交付的产品，并不是客户想要的，质量差、线上故障多，导致现有交付模式已经成为瓶颈。

团队、不同角色间的协同效率较低。无论是任务的分配还是状态的追踪，都需要通过人工、邮件或会议来反馈，沟通成本高。此外，计划管理使用的是在线文档和开源工具，无法满足大家对于项目管理的诉求。

缺乏统一的研发协作平台。没有统一的协作工具，就无法形成组织级的整体效应。同时，团队也缺少在线的文档协同工具，文档都存档在项目经理的电脑里，非常分散，不利于组织资产的沉淀和归档，更不利于管理层对整个组织研发效能的客观判断。

综合上述问题，我们与客户共同制定了此次研发管理升级的目标，包含如下四个：

首先是研发管理体系化。我们需要站在组织的视角去建立研发管理体系，提升研发数字化管理能力。

其次是项目管理生命周期流程化。依托「数字化规划」，结合信息化建设基础现状，构建统一项目管理平台支持敏态、稳态等多种类型项目管理模式，涵盖立项、启动、执行及控制、收尾等全流程阶段。

目标三是打造一体化研发管理平台。具体到科技，他们是以业务价值流为导向，因此就需要将 ONES 项目管理平台，与科技自研的发布系统、自动化测试工具、统一身份认证、审批系统、统一待办等工具集成，形成端到端的一体化平台。

最后是研发过程精益度量化。以精益思想为指导，在采集管控所需的各类数据的基础上，诊断各产品交付过程中的质量现状，实现交付过程质量指标实时跟踪，最终逐步实现产品交付活动的全面精益管控。

研发管理升级思路

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

第一个阶段，搭建组织级流程规范，并引入敏捷 Scrum 相关实践。我们从问题出发，结合现有的流程、工具、痛点，补全、优化，最终形成组织级流程规范，涵盖整个项目管理、产品全生命周期管理、需求管理。同时也对标了行业的敏捷成熟度模型，引入敏捷 Scrum 和看板实践，进行敏捷试点，提升组织整体的敏捷程度。

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

流程规范可以在研发资源、研发管理目标之间建立协调关系，将目标落地。
确保了整个组织能使用相同的语言，有助于形成整体效应。
避免各部门再重复建设一套流程规范，提高部门间的协同效率。
最后一点，正如我们刚才所说，有助于沉淀优秀组织的实践，并加以推广。

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

在这个阶段，说到底就是要将工具链集成。升级前，工具链是面向职能的专一工具。也就是说各个职能所用的工具不统一，十分分散，导致项目数据孤立，于是我们决定进行升级。

首先是打通 ONES 管理平与企业的发布平台，也就是从需求提出到发布上线，取得端到端的集成。

其次是在发布平台 CI 阶段就集成质量保证手段，缩小反馈周期。无论是测试阶段还是应用安全阶段，原有的发布平台大都是抛阶式的。开发完了交给测试，测试完了交给运维，然后再做代码扫描，导致整个交付周期变长。而有了质量保证手段，当我们在 CI 阶段提交代码时，就可以同时进行测试和扫描。一旦质有问题，立即给开发反馈，从而缩短反馈周期。

最后我们又做了一个底座平台。企业原有的工具比较分散，因此我们在 ONES 平台做一些项目管理，以及外包账号权限的统一管理，再分发给其他系统，这样一来，其他系统只需要专注于自己的事情就可以了。

接下来是在前两个阶段积累的基础之上，以精益思想为指导，以数据为驱动力，建立研发度量指标体系。我们在整个流程设计中其实已经兼顾了度量埋点，因此数据会自然而然地落到系统中，不需要额外通过人工获取数据。最终建立起持续改进机制，让效能管理形成闭环。顺便说一句，最新出炉的《DevOps 状态报告》也指出，这种具有持续改进理念的组织的绩效，明显高于不具有持续改进理念的组织。

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

前面我们着重从「事」的层面去改进，最后我们还要在「人」的层面进行优化改善。「人」的方面主要是提升人的认知，我们帮客户定制了配套的课程，包括导入敏捷理论、质量内建等系统性课程，扩展团队的升级思路。

三个关键实践

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

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

在架构调整之前，可能软件研发是一个部门，测试是一个部门，运维是一个部门，主要的管理方式是把人作为资源，分配到不同的项目中去。要知道，工程师如果不停地切换项目，其实很难在团队建立归属感，相应地也不能很好地发挥个人价值。此外，如果这些系统由多个人维护，一定程度上相当于有人生没人养，毕竟系统需要的是长期且稳定的运营。而调整为面向业务的组织架构，就是期望把工作交给跨职能团队，建立长期稳定的团队关系。

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

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

「需求三层结构」分别是业务侧的需求管理、产研侧的需求管理，以及前后端开发、UI人员的面向任务层级的需求管理。这种结构分层的好处是显而易见的：

各视角关注各自的价值流。比如业务侧只需要关注业务的整个价值流就可以了，产研也是一样。

三层之间可以互相联动。举个例子，产研侧的需求规划至开发侧之后，通过自动化能力来保证状态的实时更新。这样一来，既减少了人工操作，让数据的准确性得到了提升，同时也减少了人工的工作量，让他们更专注地去做有价值的事情。

拉通了业务侧与产研侧。如下图所示，这是一个业务需求管理看板。

通过看板，可以将业务需求从提出到上线的全生命周期可视化出来，有利于发发现瓶颈，优化工作流动。比如业务侧的需求可以直接跳转到所关联的产研侧需求看板，实现消息互通。当产研侧需求变动或者属性变动的时候，也会自动更新业务侧需求，从而提升双方的满意度。

第三个实践是知识管理助力组织赋能。知识管理对于企业的重要性是不言自明的，可以说是企业最宝贵的资产，因此我们跟客户一同梳理了四个知识管理应用的场景：

在个人方面，侧重于培训学习、关键岗位赋能和个人知识积累，帮助个人提效。

在团队层面，侧重于项目协作、项目关联、文档协同等。

在管理层层面，侧重于知识资产的共享，比如企业流程、制度、标准等。

在业务层面，侧重于业务场景化，包括研发、营销、服务等主题知识模板和知识库建设，达到对业务赋能的效果。

需要强调的是，知识管理也不是一蹴而就的，我们将这个过程分为了四个阶段，并为每个阶段设置了目标，分别是：将显性知识归类，并结构化存储；挖掘隐性知识，进行显性化存储；对整个知识体系进行运营管理；最后，用知识真正为业务赋能。

七个配套管理原则，助力方案落地

在我们对接客户时，发现他们很多管理理念都很棒，但一落到实际工作中就不容易推行实施，这是研发管理改进时经常遇到的问题。归根结底，这跟推行的方法有着密切的关系。我们结合实践经验，总结了七个配套的保障方法：

一是上下兼顾。管理变革并不是单纯的自上而下或者自下而上的过程，而需要组织里每个人的参与。比如在设计流程规范时，不仅要兼顾管理层的诉求，更要真正为执行层考虑。

二是需要配套的组织结构和绩效方案。除了统筹管理外，还需要打通部门之间的功能墙，调整组织架构，制定配套的绩效方案，为客户真正创造价值。

三是标准化兼顾创新。标准应该是底线，标准的建立应该尽量在方向上引导，但同时也要注意放宽执行细节，鼓励团队做自己的创新。当发现了好的方法，就可以在原有标准的基础上迭代。

四是重视培训的力量。培训既是一种仪式感，同时也可以统一组织整体的语言和思想，推动变革的进行。

五是先守、后破、再离。也就是说，先遵守，再在执行的过程中感知和体会，逐渐深化、理解其精髓，最后再慢慢创新。

六是试点团队先行。变革中大家有抵触心理是很正常的一件事，那么我们可以先走进试点团队，在试点团队中逐步解决所出现的问题，看到成效后再推广到其他团队。

最后是改进专人化，进展可视化。小到数据的收集分析，大到方案的推进落地，都需要专职人员来完成，而不是由其他人员兼顾。进展可视化，指的是通过看板将进度、问题、改进情况等可视化出来，在无形的氛围影响中鼓励团队参与和改进。

思考与总结

研发管理是系统性工程，需要整体统筹全局规划，才能使各要素之间同频共振发挥最大效益。除了刚才分享的内容外，研发管理也需要技术工程实践，包括组织的数字化、人才培养、文化建设等，从而减少变革阻力，推动变革成功。