案例背景

自上而下的研发效能度量建设

本案例来自某大型保险金融服务集团，旗下有多家子公司。

近年来，云原生、大数据、人工智能等前沿技术广泛运用于保险行业的产品创新、营销、管理等多个方面。该集团研发规模也迅速增长，当前已达到代码库 10000+，研发团队人员 3000+。

2020 年该集团提出以业务为中心、以客户为导向，通过不断提升研发效能，实现快速、高质量、持续交付有效价值的闭环。由集团层面牵头，带动旗下公司开启了研发效能度量建设。

但具体如何建设？如果让各子公司一线研发团队分别探索，可能会导致目标不清或重复造轮子，浪费资源；如果将研效建设的决策权收回到组织层面，又难以用同一套方案满足一线团队多样多变的改进需求。

基础设施建设：设立上下协调的的双层组织结构

企业规模庞大，如何调动上下研效建设思路对齐、步调一致，同时又能在一线团队真正发挥作用？该保险集团的思路是先从组织结构入手，建立组织级+团队级的双层结构。

组织级的效能专项小组承担调研、统筹、指导、支持的专家职责；一线研发团队则承担试点探索、实践落地、持续改进职责。组织级的统筹治理与一线研发团队的改进实践密切配合，从关键试点中摸索最佳研发实践，并沉淀为知识，将最佳实践快速传播复制到整个组织范围。

基础设施建设：建立共用的研效度量平台

该保险集团还积极推进研发数字化建设，将效能数据自动沉淀于平台。一线研发团队就无须为度量投入额外资源，避免了工具的重复建设。

以统一平台和标准化的研发数据集，去支持不同角色、不同视角、不同场景下的效能数据需求。效能专项小组观察到瓶颈可以及时介入；一线团队遇到困惑可以及时求助。这提高了研发过程及成果的可见性，帮助组织上下拉齐信息、达成共识，为协同推进研效实践打下了基础。

思码逸解决方案

精中选精，选定组织通用的北极星指标

考虑到业务线众多、项目阶段/性质不一、效能建设路径长阻力大的现状，该保险集团在组织选取组织通用的北极星指标时，尤其关注以下几点：

• 满足不同研发团队共性需求，能够用于回答较普遍的问题
• 不依赖于研发流程规范性和成熟度，这意味着不需要为了度量而改变团队的工作习惯，度量成本较低
• 有效性经过验证
• 具有正向牵引的效果

效率方面，该集团选取了思码逸的代码当量指标为研发工作量指标。代码当量的计算方法是从代码中直接解析代码修改的逻辑量与复杂度。因此，代码当量与开发环节强相关，而与项目属性弱相关，可广泛适用不同阶段、不同业务属性的研发项目的效率度量。但在横向对比时，还是要留意加以区分，避免简单粗暴的一刀切。

质量方面，基于质量保障全流程化、测试左移的思路，该集团选取了加权缺陷密度、一次冒烟通过率等指标，带动研发团队在产量与质量之间取得平衡。

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

该大型保险集团不仅用数据来报告研发效能现状，也希望数据能够启发研发管理或研发实践的改进。

该集团的思路是将数据用于合理提升下限，减少由主观因素引起的低效能问题。通过复盘代表性项目的过往效能表现，合理设置效率基线，并纳入日常管理。此基线的度量尺度是研发团队和项目，目的定位极端的零产和低产情况，以督促团队层面的改进，而不用于个人的绩效考核。

自上而下要求团队将效能数据用于量化管理时，更需要慎之又慎。举个例子，该集团效率管理组分析了大量历史数据，并与一线研发团队充分沟通后，认为合理做法是仅设置组织级下限，数值设置为当前人均代码当量的 30%。当某研发团队中效率低于基线的成员超过一定比例、或团队工作量趋势明显下滑时，则要求团队启动自查说明原因，效率管理组的专家会适时进入团队，与研发成员共同分析，探讨改进方案。如果一线团队发现达到组织级效率基线比较轻松，还可以根据实际情况设置内部基线，内部基线不应低于组织级基线。

借助以上措施，该集团在通过组织级基线保障执行的同时，给到研发团队灵活调整的空间，尽量规避效能度量和量化管理带来的负面影响。效能度量不是为了归罪甩锅，而是为了改进，这是效能文化的基石。因此，在集团范围内自上而下推动效能建设时，尤其需要注意鼓励团队保持积极心态，尊重客观限制，循序渐进，避免陷入内卷的漩涡。

方案收益

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

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

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