‍

阅读本文你将获得：

1、金融行业研发效能提升的整体情况

2、金融行业研发效能提升的痛点；

3、研发效能提升实践过程经历；

4、研发效能提升系统方法论；

‍

前言：本案例来自某大型保险金融服务集团，旗下有多家子公司。近年来，云原生、大数据、人工智能等前沿技术广泛运用于保险行业的产品创新、营销、管理等多个方面。该集团研发规模也迅速增长，当前已达到代码库 10000+，研发团队人员 3000+。

‍

研发效能提升项目概述

‍

项目目标

2020 年该集团提出，以业务为中心，以客户为导向，通过不断提升研发效能，实现快速、高研发质量持续交付有效价值的闭环。

‍

项目策略

为了在规模庞大、层级复杂的集团内保持研效实践思路统一，避免重复造轮子，该集团采取的策略是：

• 在集团组织层面，统筹研发效能管理体系建设，向各一线研发团队输出影响力

• 在一线研发团队层面，与组织级密切配合，沉淀优秀解决方案，由试点带动全局，实现研发效率与研发质量的双提升

‍

本案例涵盖了该集团研发效能建设初期的几个关键实践：

• 组织结构调整：保障组织与一线研发团队方向与步调一致

• 试点调研：在一线研发团队深挖问题，在组织层面验证共性

• 研发效能度量体系建设：改善研发过程及制品不透明的现状，推行全组织适用的量化管理体系，保障下限的执行

• 探索改进实践：深度试点，在一线团队的真实实践中探索方向，通过系统性改进提升研发效能上限

‍

经过谨慎调研、持续验证、稳步推进，该集团在研发效能建设初期已取得阶段性成果：

• 建立起研发效能度量体系及改进策略，研发效能数据自动沉淀于数据平台，并向不同角色呈现场景化图表，实现组织级的研效数字化治理

• 研发效率方面：团队反映协作程度提升；从数据上看，人均研发效率（代码当量）与需求准时上线率指标均呈现连续上升趋势，需求吞吐率趋于平稳。

需求交付趋势分析（代码当量指标来自思码逸深度代码分析系统）

‍

• 研发质量方面：以改进部门为例，相比 2021 年数据，一次冒烟通过率提升 9%，严重缺陷占比降低 33%，缺陷密度（加权缺陷总数/代码当量）降低 57%。

改进部门的质效趋势关联分析

‍

金融行业研发效能提升痛点

‍

在开启研发效能提升时，主要存在如下痛点：

‍

研发效率方面

• 研发人员的工作量难以量化，管理缺乏数据抓手

• 需求颗粒度不一，需求相关的研发效率数据可信度偏低

• 需求交付周期长，准时上线率偏低

‍

研发质量方面

• 研发各环节均受交付时间挤压和成本压力，仅在最后测试环节进行研发质量控制，成本和压力巨大，留下研发质量隐患

• 部分研发团队提测研发质量不稳定

• 严重缺陷占比均值偏高

• 需求实现部分细节不完善，影响用户满意度

• 根据既往生产问题根因分析，代码设计和版本发布类根因占比较大

• 各子公司研发质量管理建设进度不一，缺乏完善且统一的研发质量管理体系（包括角色配置、计划制定、监督和执行规范、考核评价机制等）；尽管各子公司均有研发效能度量指标，但缺乏统一规范。

‍

研发效能提升的实践过程经历

‍

前期建设情况

在推行本轮改进之前，该保险集团的研发效能建设主要集中在工具链建设与测试环节度量两个方面。

在工具链方面，已通过自建+引入工具，搭建起覆盖需求、设计、开发、测试、发布环节的全流程工具链。较高的工具化程度为研发效能数据的可得性与有效性提供了基础支撑。

测试环节度量方面，之前主要关注以下两方面：

‍

• 测试环节研发效率：任务关闭率、吞吐量、任务关闭时长、任务按期完成率

• 研发质量趋势，包括：

• 一次冒烟通过率

• 缺陷数量、缺陷严重等级分布

‍

推行一段时间后，软件研发质量虽在一定程度得以改善，但难以通过测试单一环节推动整体持续提升。为了强化研发过程研发质量，该集团开始推行测试左移，测试人员由 QC 向 QA 转型，与研发团队配合建立贯穿全流程的研发质量管理基线。

‍

为了在组织范围内统筹研发质量管理体系的建设，避免重复造轮子，该集团成立直接隶属于集团的研发质量管理组。

‍

同时，研发质量与研发效率密切相关：一方面，研发质量低下会导致研发团队忙于救火或反复打回重做，研发效率降低；另一方面，研发质量提升也不能以损害研发效率为代价。因此，同样直接隶属于集团的研发效率管理组开始统筹研发效率的度量与改进工作。

‍

研发质量管理组与研发效率管理组均属于组织级研发效能专项团队。

‍

组织建设：双层结构，保障方向与步调一致

前文提到，集团设立了组织级的研发效能专项团队。为了保障研发效能实践在日常研发中落地，建立组织级+团队级的双层结构，研发效率侧由研发效率管理组 + 团队级研发效能负责人共同负责，研发质量侧由研发质量管理组（组织级QA） + 团队级 QA 共同负责。

下图以研发质量侧为例，介绍双层结构的分工：研发质量管理组承担调研、统筹、指导、支持的专家职责；团队级 QA 则承担在其团队落地研发质量体系、控制过程研发质量、持续改进实践的职责。

两者协同，一方面使研发效能专项团队能够保持相对客观中立的外部视角；另一方面保障研发效能相关战略及时传达至各团队，由专人负责执行，各方目标拉齐，行动步调一致。

研发质量侧的双层结构示意图

‍

试点策略：点面结合，验证共性

经过调研，该集团采用了由试点起步、点面结合、逐步推进的研发效能建设策略。

‍

关键试点+普遍调研，定位问题

在试点方案的设计思路上，分为关键试点与普遍调研两类。

‍

关键试点的作用是发现问题。组织级研发效能专项团队会与一线研发团队配合，深入访谈调研。经过讨论，根据以下条件选取关键试点样本：

• 重点业务：试点团队本身处于战略地位，或系统是集团范围内的核心系统，持续有业务需求进入，对研发效能要求较高

• 研发效率方面表现较优：在研发效率表现较优的团队进行度量试点，这类团队的心态一般更加开放，能对度量体系给出客观、建设性的反馈意见

• 研发质量方面有提升诉求：从数据分析观察到近期呈下滑趋势或长期呈较大波动，经初步分析，研发过程存在一定的研发质量风险

• 主观意愿：团队本身重视，上级有意愿做量化管理

‍

普通调研的作用是验证问题是否具有普遍性。因此，样本选取上尽量全面地覆盖各类型团队和系统：建设类、维护类不同阶段；敏捷、稳态不同研发模式；大小版本、按需版本、紧急版本等不同发版类型等。

‍

深入访谈调研，摸查研发效能现状

在关键试点中，通过以下方法进行深度调研：

• 抽取规模大小不一的若干样本需求，查看研发全流程的关键活动和阶段性工作产品。以研发质量侧为例，工作产品包括需求沟通/拆解记录、业务/系统需求文档、设计文档、测试执行记录、生产问题、缺陷清单等各类输入/输出的文档。根据事先制订的检查项，摸排工作产品是否存在缺失。

以研发质量侧为例，各类工作产品

• 对项目管理、需求、开发、测试、发布环节相关成员进行访谈 ，围绕先前抽取的样本需求，请成员演示流程与要点工作，并邀请成员开放性地反馈研发质量方面的建议。

• 针对性地观摩业务需求沟通、评审、流水线实操等研发关键活动

‍

基于以上调研动作，梳理试点团队的研发过程、业务方特征、团队工作习惯、人员结构等信息，总结各环节的优秀实践和改进机会，并与试点团队达成共识 。

‍

从试点团队收集信息后，分析哪些问题在多个试点频繁出现，并通过普遍调研验证这些问题是否存在共性。在调研报告中，以量化数据呈现问题现状，并给出问题详述与相应的优秀实践样例。

‍

研发效能度量体系：由少到多逐步推进

‍

选取少数指标，满足共性需求

从试点和调研中收集高频且影响较大的关键问题后，组织级研发效能专项团队开始逐步建立研发效能度量体系，从少数几个指标起步，以量化数据反馈作为管理抓手，驱动改进。

‍

研发效率方面

研发效率的不可见性与不可预测性是当前最基础的问题，这一问题直接导致了管理缺乏依据，难以开展。

由于各研发团队在需求环节的实践不一，难以将需求相关指标作为组织统一使用的研发效率指标。而代码行数等工作量传统指标又容易受到噪音影响，度量的有效性难以保证。

研发效率管理组经过调研，选用了思码逸的代码当量来度量开发者的编码工作量。相比代码行数等指标，代码当量能够有效统计代码所包含的逻辑工作量，排除代码风格、换行习惯、注释、格式化操作等因素干扰。

‍

研发质量方面

研发质量保障全流程化是当前最关键的任务。为了配合测试左移实践，在既有指标的基础上，增添了缺陷密度指标，带动团队在产量与研发质量之间取得适当平衡。

‍

专项推广，争取共识

让研发团队接纳度量不是易事。当度量体系中出现了陌生概念，则更容易引起质疑。

‍

为了争取各子公司研发团队对“代码当量”这类新指标的共识，组织级研发效能专项团队进行了专项推广：

• 第一步，向子公司核心骨干成员介绍研发效能度量理念、代码当量的原理与优势，获取反馈，再由骨干成员进行进一步推广，同时也设立专门的 Q&A 环节

• 第二步，配合线上定期发布的产能数据及专题分析报告，进行线下调研；结合研发团队实际情况，发现具体问题，并推动管理举措改进

• 第三步，总结推广过程中的实践经验，进一步向各子公司推广和应用；同时在全集团参与的1024程序员节活动中，应用研发效率和研发质量多维度指标，进行综合评价和分析；基于研发效能数据，邀请内外部专家共同探讨写好代码

‍

通过由点及面的推广策略、开放交流的心态和积极的运营动作，逐步取得各研发团队的认同。

‍

设立组织级基线，保障下限执行

量化管理的主要目标是合理提升下限，减少由主观因素引起的低研发效能问题。该集团的量化管理实践是在谨慎选取指标，合理设置基线，并纳入日常管理；各一线团队可以根据实际情况设置内部基线，内部基线的下限不应低于组织级下限。

‍

在通过组织级基线保障执行的同时，给到研发团队灵活调整的空间，鼓励团队在保持积极心态的同时，尊重客观限制、循序渐进。

‍

研发效率方面

在获得团队共识后，研发效率管理组选用代码当量作为工作量指标，并设置研发环节的研发效率基线。

集团内研发团队众多，他们的工作量受业务阶段、业务类型、岗位和需求数量周期性波动等复杂因素影响，一刀切设置基线必然是不合理的。那么如何在尊重研发团队情况多种多样这一客观事实的同时，研发效率基线实践能够有效推广向整个集团呢？

研发效率管理组分析了大量历史数据，并与一线研发团队充分沟通后，认为合理的做法是仅设置组织级下限，数值为当前人均代码当量的 30%。下限的设计是为了定位极端的零产和低产情况，以敦促团队层面的改进，而不用于个人的研发绩效考核。

当某研发团队工作量低于基线的成员超过一定比例、或团队工作量趋势明显下滑时，则要求团队启动自查，说明原因。研发效率管理组的专家会与团队共同分析，探讨改进方案。

‍

研发质量方面

基于先前调研发现的共性问题，结合指标认可度和工具支持的便利程度，研发质量管理组将缺陷密度设置为首个研发质量基线指标。

基线指标将被逐步纳入到团队考核体系中，引导团队重视研发效率与研发质量，但不与个人绩效挂钩。

这里需要留意的是，自上而下设置基线是一种管理手段，那么是否可以不断提高要求，直至实现研发效能提升？

答案是否定的。量化管理的局限性客观存在。有相当一部分研发效能问题是由系统性的客观因素引起，管理手段与制度无法解决这部分问题，只能通过工程实践的改进来解决。如果无限制地要求以主观能动性提升研发效能，成为实质上的“内卷”，即便以开发者超负荷为代价取得了一时提效成果，也不可持续。

‍

持续完善，反向推动工具与实践改进

‍

研发效率方面

除了使用代码当量指标度量资源研发效率（价值产出方视角）外，研发效率管理组还关注面向业务的交付研发效率（价值接收方视角），包括需求30天上线率、按时交付率、需求交付周期等。

由于各研发团队在需求环节的实践不一，需求颗粒度的差异会影响数据有效性，需求相关的交付研发效率指标暂不设置基线要求，而由各团队根据实际情况提出目标值。研发效率管理组会定期观察目标达成情况和环比趋势，关注交付研发效率指标波动较大或趋势向下的团队。

同时，从组织层面对需求的颗粒度上限提出要求，并在工具中配置阈值，引导研发团队在需求分析、评审环节严格把关，将需求拆分为合理粒度。

‍

研发质量方面

在研发阶段的缺陷密度指标以外，研发质量管理组希望将研发质量度量拓展至全流程，逐步覆盖研发生命周期的不同阶段，并在以下四点指导思路下设计了研发质量管理基线全景图。

• 版本节奏化：结合“版本火车”机制，明确迭代中关键节点的活动完成时间，设置版本冻结点，利用封版后时间进行投产就绪评审，严控时间节奏

• 设计标准化：定义不同类型的设计模板及内容要求，防止设计遗漏

• 评审规范化：严格执行各阶段评审要求，做好预评审，保留评审记录，评审问题跟踪闭环，提高评审有效性

• 测试全程化：测试左移，参与到研发各环节，从测试角度把控异常极端情况的处理，逆向场景的考虑；测试右移，协助业务进行验收测试，验收问题跟踪闭环

‍

随着工具链自动化程度和团队对研发效能数据的认可度都进一步提高，研发质量管理组会把更多指标纳入基线，牵引研发团队从全流程视角关注研发质量保障。根据关键活动的度量要求，形成工具支持需求，反向推动工具链持续改进。

研发质量管理基线全景图

‍

研发效能提升改进实践

‍

研发效率：多方向探索精细化管理

在研发效率方面，研发效率管理组当前的策略重点以守住基线、保障执行为主。除此之外，研发效率管理组也鼓励一线研发团队自发探索数据驱动的精细化管理。

‍

团队自发的研效实践试点

在一线研发团队内部，由于数据可比性更高、上下文信息更完整，部分 team leader 正在尝试设立本团队阈值，对研发效率提出更高要求，并进行研效实践试点。实践包括：

• 管理方面

• 鼓励Top：对于产能较高的开发者，在团队内进行正向宣导，分享代码和工作经验

• 关注Bottom：对于产能低的开发者，了解工作量、任务难度等实际情况，分析问题并针对性的改进

• 工程方面

• 研发规范：当前选用的研发效能度量指标，从指标设计上对小步提交、code review、代码复用等优秀实践更有利，团队内部顺势组织培训，推动研发规范落地

• 产研协同：当上游需求不足导致研发环节工作量偏低时，研发人员主动沟通产品经理，挖掘产品/技术框架的可优化部分

‍

这些自发实践不仅提升团队研发效率，也培养了快速获取反馈、及时复盘、自驱改进的团队文化。

‍

研发质量：组织级与团队级深度共建

根据前文给出的筛选条件，研发质量管理组选择了多个规模数十人的研发团队进行试点。以下以某试点团队为例，介绍研发质量管理组与团队共建的研发质量实践。

2021 年度量数据显示，该试点团队的一次冒烟通过率持续走低，缺陷密度偏高。

试点开始后，研发质量管理组以教练角色深入试点团队，合作开展为期三个迭代的改进实践。在此期间，研发质量管理组与团队保持高频沟通与交流。

‍

对齐认知

在先前调研基础上，对严重缺陷等概念的定义拉齐认知，由研发质量管理组明确改进目标。

‍

有侧重地制订规范

根据业务阶段及特征的实际需要，研发质量管理组与团队共同从通用研发质量要求清单中选取重点，制订可落地的流程规范、文档模板、checklist、版本节奏建议等规范性材料。

以需求文档为例：对于稳定性较高、运行时间较长、被其他多个系统依赖的核心系统，在需求分析和评审环节重点关注是否详尽描述变更对关联系统的影响、对历史数据的影响、异常情况处理逻辑、权限控制等。

需求检查项，高亮为重点关注项

在研发过程中，研发人员主动对照材料进行自查，通过标准化减少对个人能力的依赖，降低实践落地的成本。

‍

挖掘根因，针对性改进

研发质量管理组与研发团队一同参与迭代回顾复盘，追溯问题根因。相关成员需制订改进措施以及类似问题的预防方案，研发质量管理组会协助复核方案。

‍

例如，针对试点团队一次冒烟通过率下降、缺陷密度较高的问题，复盘发现开发团队提测研发质量波动较大，测试环节时间紧压力重，提测研发质量低。针对这一问题，主要在以下 2 个方面实施改进：

• 代码评审：要求团队成员按照前一环节制订的评审模板及规范进行评审，评审任务明确分配至每一位开发人员。对于较复杂的需求、先前一次冒烟通过率较低的模块，会在验收会再次评审。硬性要求：评审问题都得到解决后才能提测。

• 开发自测：开发人员自测范围包含单元测试，以及由测试提供的冒烟用例，严格执行交叉测试与复核，推动测试左移。

‍

研发团队和研发质量管理组会一同持续跟进改进措施的实施情况，直至相关研发质量指标趋于正常。

‍

在三个迭代的试点周期内，研发质量管理组参与程度逐步降低。试点结束后，研发质量管理组人员撤出，团队QA 接管，主导研发质量实践持续推行。

‍

根据试点情况来看，研发团队的意识显著提升，能够主动发现问题并积极改进：团队QA 能够独立制订改进策略、梳理适用于本团队的指导性材料；开发人员主动参与研发质量内建，进行研发全流程的研发质量回溯。

‍

通过实践不断沉淀方法论

在试点结束后，研发质量管理组会定期回访了解落地情况，一方面给出及时建议，另一方面通过案例不断发现问题、梳理改进方案，持续验证提升措施的有效性，积累优秀实践，为更大规模研发效能建设做准备。

需要注意的是，所谓改进不能仅着眼于数据的上下波动。数据仅反映改进的效果，而不是改进的目的。

研发质量管理组参考 MARI 方法论，建立了常见问题分析与改进实践框架：

• 借助度量发现问题后，对数据进行多视角的下钻分析与解读，定位关键的薄弱点

• 结合其他关联指标和调查方法，追问根因，定位研发效能瓶颈和优化机会

• 将这些洞见落地为明确、可执行、可验证的改进方案，规范研发过程、建立良好研发文化

• 持续度量验证改进效果，灵活调整改进方案

‍

以下以研发过程中的三个常见问题为例，展示上述框架：

‍

问题1：研发的各环节之间，未能对齐需求相关信息

• 根因：

• 需求文档内容过于简单，用户场景、业务流程、功能模块、异常处理等没有详细说明

• 需求评审执行不到位，缺少记录，评审中发现的问题没有后续跟踪

• 需求变更后未及时同步

• 实践建议：

• 在需求分析环节基于GWT（Given+When+Then）对业务场景提供清晰描述，包括正向流程和异常流程，明确验收规则

• 增加预审环节，需求分析人员需提前思考，对照检查项准备各项说明，评审环节加强信息跟踪与确认

• 加强需求文档规范性，例如定期对缺陷进行复盘，若发现缺陷的根因是需求文档中信息遗漏，则建议增加相应的需求检查项

• 建立各环节信息同步渠道

‍

问题2：负责关联系统的其他团队，未能对齐需求相关信息

• 根因：

• 需求方案设计时没有与关联系统团队充分沟通

• 需求文档内容过于简单，当次变更对关联系统可能造成的影响没有详细说明

• 评审环节缺少关联系统团队参与互评

• 实践建议：

• 需求分析环节与关联系统团队充分沟通，共同确认各方职责、边界与协作方式

• 需求评审环节明确说明是否影响其他系统，需求方案是否与关联方达成共识，系统间的调用关系是什么，谁是主责系统，是否可独立上线，关联系统的相关排期和责任人

• 如暂未达成共识，则需求分析成员需继续跟进，并由需求负责人或项目经理与关联系统团队协调，告知开发测试需联合推进

‍

问题3：开发阶段自测不充分，导致过多 Bug 流入测试环节

• 根因：业务场景复杂，考虑不充分，导致实现与需求不符，自测覆盖度低

• 实践建议

• 加强全程沟通，测试左移，减少测试环节压力与后期问题修复成本

• 在设计评审环节，开发与测试共同梳理并与需求进行确认，明确业务流程-功能设计-数据模型的对应关系，明确设计方案与需求的一致性

• 重点需求提测前由开发组织showcase，由需求确认实现与需求的一致性

• 根因：代码提测研发质量不高，自测不充分

• 建议开发加强提测前代码评审+ 静态代码扫描

• 要求开发自测覆盖冒烟测试用例

‍

研发质量管理组梳理了研发流程中的各个环节的常见问题、根因分析与实践建议，并沉淀为组织的知识资产，在与一线研发团队的配合中持续迭代。

‍

展望

‍

该保险集团将在以下方面继续探索研发效能持续提升：

• 将研发效能度量范围拓展至软件研发全流程和更多岗位

希望将产品、运维、数据等更多软件研发相关岗位纳入研发效能度量体系，进一步提高研发流程透明度。

一方面，在全局视角下对各个单点的研发效能进行更深入的评估，避免局部最优反而对全局优化造成负面影响；另一方面，着眼于软件研发端到端的价值交付，避免“研发效率竖井”，使各产品、项目、团队的研发效能提升与组织级的业务价值、降本增效、客户满意度等业务成果关联起来，用精益思想驱动业务加速。

• 优化研发效能数据模型，输出启发性的工程改进建议

希望研发效能专项团队与一线研发团队继续紧密协作，持续沉淀优秀实践，充实研发效能知识体系，由此建立场景化的研发效能数据模型，不仅输出规范性改进建议，也给出启发性改进建议。例如，综合分析需求复杂度、变更影响规模、业务优先级等维度，辅助需求人员进行优先级排序，合理建议需求的拆分和排期，实现更高效的迭代开发。

• 研发效率与研发质量管理组加强配合，针对研发团队特征，输出质效综合提升方案

以更低成本、更高研发效率、过程可控、结果可度量为目标，以研发效能主线为基础，以交付巡检为过程，以数据度量为抓手，实施专项优化，打造研发效能管理的标杆生态。向研发团队输出符合其个性化需求的实践改进方案，围绕交付研发效率、交付研发质量、交付能力，建设全方位的研发效能数字化之路。

‍