10000+ 代码库、3000+ 研发人员大型保险集团的研发效能改进实践
近年来，云原生、大数据、人工智能等前沿技术广泛运用于保险行业的产品创新、营销、管理等多个方面。本文介绍的实践案例来自某大型保险金融服务集团，旗下拥有多家子公司，集团研发规模迅速增长，当前已达到代码库 10000+，研发团队人员 3000+。
2020 年该集团提出，以业务为中心，以客户为导向，通过不断提升研发效能，实现快速、高质量持续交付有效价值的闭环。为了在规模庞大、层级复杂的集团内保持研效实践思路统一，避免重复造轮子，该集团确定的研发效能改进策略为：在集团组织层面，统筹研发效能管理体系建设，向各一线研发团队输出影响力；在一线研发团队层面，与组织级密切配合，沉淀优秀解决方案，由试点带动全局，实现研发效率与质量的双提升。
本文将涵盖该集团研发效能建设初期的四大关键实践：
组织结构调整
试点调研
效能度量体系建设
探索改进实践
经过谨慎调研、持续验证、稳步推进，该集团在研发效能建设方面已取得阶段性成果：
建立起研发效能度量体系及改进策略，效能数据自动沉淀于数据平台，并向不同角色呈现场景化图表，实现组织级的研效数字化治理；
效率方面：团队反映协作程度提升，从数据上看，人均效率（代码当量）与需求准时上线率指标均呈现连续上升趋势，需求吞吐率趋于平稳。
需求交付趋势分析（代码当量指标来自思码逸深度代码分析系统）
质量方面：以改进部门为例，相比 2021 年数据，一次冒烟通过率提升 9%，严重缺陷占比降低 33%，缺陷密度（加权缺陷总数 / 代码当量）降低 57%。
改进部门的质效趋势关联分析
在开启研发效能提升工作之前，该集团主要存在如下痛点：
效率方面
研发人员的工作量难以量化，管理缺乏数据抓手；
需求颗粒度不一，需求相关的效率数据可信度偏低；
需求交付周期长，准时上线率偏低。
质量方面
研发各环节均受交付时间挤压和成本压力，仅在最后测试环节进行质量控制，成本和压力巨大，留下质量隐患：
部分研发团队提测质量不稳定；
严重缺陷占比均值偏高；
需求实现部分细节不完善，影响用户满意度；
根据既往生产问题根因分析，代码设计和版本发布类根因占比较大；
各子公司质量管理建设进度不一，缺乏完善且统一的质量管理体系（包括角色配置、计划制定、监督和执行规范、考核评价机制等），尽管各子公司均有效能度量指标，但缺乏统一规范。
在推行本轮改进之前，该保险集团的效能建设主要集中在工具链建设与测试环节度量两个方面。
在工具链方面，已通过自建 + 引入工具，搭建起覆盖需求、设计、开发、测试、发布环节的全流程工具链。较高的工具化程度为效能数据的可得性与有效性提供了基础支撑。测试环节度量方面，之前主要关注以下两方面：
测试环节效率：任务关闭率、吞吐量、任务关闭时长、任务按期完成率；
研发质量趋势，包括：一次冒烟通过率，缺陷数量、缺陷严重等级分布；
相关工作推行一段时间后，软件研发质量虽有一定改善，但难以通过测试单一环节推动整体持续提升。为了强化研发过程质量，该集团开始推行测试左移，测试人员由 QC 向 QA 转型，与研发团队配合建立贯穿全流程的质量管理基线。
为了在组织范围内统筹研发质量管理体系的建设，避免重复造轮子，该集团成立了直接隶属于集团的质量管理组。
同时，质量与效率密切相关：一方面，质量低下会导致研发团队忙于救火或反复打回重做，效率降低；另一方面，质量提升也不能以损害效率为代价。因此，同样直接隶属于集团的效率管理组开始统筹研发效率的度量与改进工作。
前文提到，集团设立了组织级的效能专项团队。为了保障效能实践在日常研发中落地，建立组织级 + 团队级的双层结构，效率侧由效率管理组 + 团队级研发效能负责人共同负责，质量侧由质量管理组（组织级 QA） + 团队级 QA 共同负责。
下图以质量侧为例，介绍双层结构的分工：质量管理组承担调研、统筹、指导、支持的专家职责；团队级 QA 则承担在其团队落地质量体系、控制过程质量、持续改进实践的职责。
两者协同，一方面使效能专项团队能够保持相对客观中立的外部视角；另一方面保障研发效能相关战略及时传达至各团队，由专人负责执行，各方目标拉齐，行动步调一致。
质量侧的双层结构示意图
经过调研，该集团采用了由试点起步、点面结合、逐步推进的效能建设策略。
在试点方案的设计思路上，分为关键试点与普遍调研两类。
关键试点的作用是发现问题。组织级效能专项团队会与一线研发团队配合，深入访谈调研。经过讨论，根据以下条件选取关键试点样本：
重点业务
效率方面表现较优
质量方面有提升诉求
主观意愿
普通调研的作用是验证问题是否具有普遍性。因此，样本选取上尽量全面地覆盖各类型团队和系统：建设类、维护类不同阶段；敏捷、稳态不同研发模式；大小版本、按需版本、紧急版本等不同发版类型等。
在关键试点中，通过以下方法进行深度调研：
抽取规模大小不一的若干样本需求，查看研发全流程的关键活动和阶段性工作产品；
以质量为例，各类工作产品
对项目管理、需求、开发、测试、发布环节相关成员进行访谈 ，围绕先前抽取的样本需求，请成员演示流程与要点工作，并邀请成员开放性地反馈研发质量方面的建议；
针对性地观摩业务需求沟通、评审、流水线实操等研发关键活动。
基于以上调研动作，梳理试点团队的研发过程、业务方特征、团队工作习惯、人员结构等信息，总结各环节的优秀实践和改进机会，并与试点团队达成共识 。
从试点团队收集信息后，分析哪些问题在多个试点频繁出现，并通过普遍调研验证这些问题是否存在共性。在调研报告中，以量化数据呈现问题现状，并给出问题详述与相应的优秀实践样例。
从试点和调研中收集高频且影响较大的关键问题后，组织级效能专项团队开始逐步建立效能度量体系，从少数几个指标起步，以量化数据反馈作为管理抓手，驱动改进。
效率方面
研发效率的不可见性与不可预测性是当前最基础的问题，这一问题直接导致了管理缺乏依据，难以开展。
由于各研发团队在需求环节的实践不一，难以将需求相关指标作为组织统一使用的效率指标。而代码行数等工作量传统指标又容易受到噪音影响，度量的有效性难以保证。
效率管理组经过调研，选用了思码逸的代码当量指标来度量开发者的编码工作量。相比代码行数等指标，代码当量能够有效统计代码所包含的逻辑工作量，排除代码风格、换行习惯、注释、格式化操作等因素干扰。
质量方面
质量保障全流程化是当前最关键的任务。为了配合测试左移实践，在既有指标的基础上，增添了缺陷密度指标，带动团队在产量与质量之间取得适当平衡。
量化管理的主要目标是合理提升下限，减少由主观因素引起的低效能问题。该集团的量化管理实践是谨慎选取指标，合理设置基线，并纳入日常管理；各一线团队可以根据实际情况设置内部基线，内部基线的下限不应低于组织级下限。
在通过组织级基线保障执行的同时，给到研发团队灵活调整的空间，鼓励团队在保持积极心态的同时，尊重客观限制、循序渐进。
效率方面
在获得团队共识后，效率管理组选用代码当量作为工作量指标，并设置研发环节的效率基线。
集团内研发团队众多，他们的工作量受业务阶段、业务类型、岗位和需求数量周期性波动等复杂因素影响，一刀切设置基线必然是不合理的。那么如何在尊重研发团队情况多种多样这一客观事实的同时，效率基线实践能够有效推广向整个集团呢？
效率管理组分析了大量历史数据，并与一线研发团队充分沟通后，认为合理的做法是仅设置组织级下限，数值为当前人均代码当量的 30%。下限的设计是为了定位极端的零产和低产情况，以敦促团队层面的改进，而不用于个人的绩效考核。
当某研发团队工作量低于基线的成员超过一定比例、或团队工作量趋势明显下滑时，则要求团队启动自查，说明原因。效率管理组的专家会与团队共同分析，探讨改进方案。
质量方面
基于先前调研发现的共性问题，结合指标认可度和工具支持的便利程度，质量管理组将缺陷密度设置为首个质量基线指标。
基线指标将被逐步纳入到团队考核体系中，引导团队重视效率与质量，但不与个人绩效挂钩。
这里需要留意的是，自上而下设置基线是一种管理手段，那么是否可以不断提高要求，直至实现效能提升？
答案是否定的。量化管理的局限性客观存在。有相当一部分效能问题是由系统性的客观因素引起，管理手段与制度无法解决这部分问题，只能通过工程实践的改进来解决。如果无限制地要求以主观能动性提升效能，成为实质上的“内卷”，即便以开发者超负荷为代价取得了一时提效成果，也不可持续。
效率方面
除了使用代码当量指标度量资源效率（价值产出方视角）外，效率管理组还关注面向业务的交付效率（价值接收方视角），包括需求 30 天上线率、按时交付率、需求交付周期等。
由于各研发团队在需求环节的实践不一，需求颗粒度的差异会影响数据有效性，需求相关的交付效率指标暂不设置基线要求，而由各团队根据实际情况提出目标值。效率管理组会定期观察目标达成情况和环比趋势，关注交付效率指标波动较大或趋势向下的团队。
同时，从组织层面对需求的颗粒度上限提出要求，并在工具中配置阈值，引导研发团队在需求分析、评审环节严格把关，将需求拆分为合理粒度。
质量方面
在研发阶段的缺陷密度指标以外，质量管理组希望将质量度量拓展至全流程，逐步覆盖研发生命周期的不同阶段，并在以下四点指导思路下设计了质量管理基线全景图：
版本节奏化
设计标准化
评审规范化
测试全程化
质量管理基线全景图
在效率方面，效率管理组当前的策略重点以守住基线、保障执行为主。除此之外，效率管理组也鼓励一线研发团队自发探索数据驱动的精细化管理。
在一线研发团队内部，由于数据可比性更高、上下文信息更完整，部分 team leader 正在尝试设立本团队阈值，对效率提出更高要求，并进行研效实践试点，包括：
管理方面
鼓励 Top：对于产能较高的开发者，在团队内进行正向宣导，分享代码和工作经验；
关注 Bottom：对于产能低的开发者，了解工作量、任务难度等实际情况，分析问题并针对性的改进；
工程方面
研发规范：当前选用的效能度量指标，从指标设计上对小步提交、code review、代码复用等优秀实践更有利，团队内部顺势组织培训，推动研发规范落地；
产研协同：当上游需求不足导致研发环节工作量偏低时，研发人员主动沟通产品经理，挖掘产品 / 技术框架的可优化部分。
这些自发实践不仅提升团队效率，也培养了快速获取反馈、及时复盘、自驱改进的团队文化。
根据前文给出的筛选条件，质量管理组选择了多个规模数十人的研发团队进行试点。以下以某试点团队为例，介绍质量管理组与团队共建的质量实践。
2021 年度量数据显示，该试点团队的一次冒烟通过率持续走低，缺陷密度偏高。试点开始后，质量管理组以教练角色深入试点团队，合作开展为期三个迭代的改进实践。在此期间，质量管理组与团队保持高频沟通与交流。
在先前调研基础上，对严重缺陷等概念的定义拉齐认知，由质量管理组明确改进目标。
根据业务阶段及特征的实际需要，质量管理组与团队共同从通用质量要求清单中选取重点，制订可落地的流程规范、文档模板、checklist、版本节奏建议等规范性材料。
以需求文档为例：对于稳定性较高、运行时间较长、被其他多个系统依赖的核心系统，在需求分析和评审环节重点关注是否详尽描述变更对关联系统的影响、对历史数据的影响、异常情况处理逻辑、权限控制等。
需求检查项，高亮为重点关注项
在研发过程中，研发人员主动对照材料进行自查，通过标准化减少对个人能力的依赖，降低实践落地的成本。
质量管理组与研发团队一同参与迭代回顾复盘，追溯问题根因。相关成员需制订改进措施以及类似问题的预防方案，质量管理组会协助复核方案。
例如，针对试点团队一次冒烟通过率下降、缺陷密度较高的问题，复盘发现开发团队提测质量波动较大，测试环节时间紧压力重，提测质量低。针对这一问题，主要在以下两个方面实施改进：
代码评审：要求团队成员按照前一环节制定的评审模板及规范进行评审，评审任务明确分配至每一位开发人员。对于较复杂的需求、先前一次冒烟通过率较低的模块，会在验收会再次评审。硬性要求：评审问题都得到解决后才能提测。
开发自测：开发人员自测范围包含单元测试，以及由测试提供的冒烟用例，严格执行交叉测试与复核，推动测试左移。研发团队和质量管理组会一同持续跟进改进措施的实施情况，直至相关质量指标趋于正常。
在三个迭代的试点周期内，质量管理组参与程度逐步降低。试点结束后，质量管理组人员撤出，团队 QA 接管，主导质量实践持续推行。
根据试点情况来看，研发团队的意识显著提升，能够主动发现问题并积极改进：团队 QA 能够独立制订改进策略、梳理适用于本团队的指导性材料；开发人员主动参与质量内建，进行研发全流程的质量回溯。
在试点结束后，质量管理组会定期回访了解落地情况，一方面给出及时建议，另一方面通过案例不断发现问题、梳理改进方案，持续验证提升措施的有效性，积累优秀实践，为更大规模效能建设做准备。
需要注意的是，所谓改进不能仅着眼于数据的上下波动。数据仅反映改进的效果，而不是改进的目的。
质量管理组参考 openMARI 方法论，建立起常见问题分析与改进实践框架：
1. 借助度量发现问题后，对数据进行多视角的下钻分析与解读，定位关键的薄弱点；
2. 结合其他关联指标和调查方法，追问根因，定位效能瓶颈和优化机会；
3. 将这些洞见落地为明确、可执行、可验证的改进方案，规范研发过程、建立良好研发文化；
4. 持续度量验证改进效果，灵活调整改进方案。
以下以研发过程中常见的“研发的各环节之间，需求相关信息不对齐”这一痛点为例，展示上述框架；
质量管理组梳理了研发流程中的各个环节的常见问题、根因分析与实践建议，并沉淀为组织的知识资产，在与一线研发团队的配合中持续迭代。
该保险集团将在以下方面继续探索研发效能持续提升：
将研发效能度量范围拓展至软件研发全流程和更多岗位
希望将产品、运维、数据等更多软件研发相关岗位纳入效能度量体系，进一步提高研发流程透明度。
一方面，在全局视角下对各个单点的效能进行更深入的评估，避免局部最优反而对全局优化造成负面影响；另一方面，着眼于软件研发端到端的价值交付，避免“效率竖井”，使各产品、项目、团队的效能提升与组织级的业务价值、降本增效、客户满意度等业务成果关联起来，用精益思想驱动业务加速。
优化研发效能数据模型，输出启发性的工程改进建议
希望效能专项团队与一线研发团队继续紧密协作，持续沉淀优秀实践，充实研发效能知识体系，由此建立场景化的效能数据模型，不仅输出规范性改进建议，也给出启发性改进建议。
例如，综合分析需求复杂度、变更影响规模、业务优先级等维度，辅助需求人员进行优先级排序，合理建议需求的拆分和排期，实现更高效的迭代开发。
相关内容
微信扫码咨询专知VIP会员