效能提升，无论企业规模大小，研发效能管理不可或缺

头部大厂

腰部厂商

中小型企业

研发效能管理 GDAI 模型，监管与迭代相辅相成，效能螺旋上升

研发效能管理 7 步走，明晰 6 大角色场景，有的放矢，步步精进

Step 1：数据采集

Step 2：指标定义

高层管理者

人力总监

项目负责人

基层管理者

合规经理/ IT 经理

运营经理/市场经理

Step 3：持续监控

Step 4：数据可视化

适当的图表类型

正确的色彩设计

慎用 3D 图形

避免信息过多

尽量从 0 开始

正确的数据层级

Step 5：产出洞察

人肉洞察

自动洞察

Step 6：改进方案

Step 7：实施运行

案例：2 周代码质量提升 10% ，蔚来标准研发效能管理体系

某新医药企业

蔚来自动驾驶团队

近日，在极狐GitLab TechTalk 上，极狐星产品经理刘静进行了《研发效能管理的双模模型》主题直播，从研发效能管理痛点出发，分享研发效能管理 7 步走与GDAI 经典方法，基于「蔚来」、「某新医药企业」等客户案例，提供实践指南，帮助企业让研发更高效、过程更透明、协作更流畅。

以下内容整理自本次直播，你也可以点击点击👉观看视频回放或下载 PPT。Enjoy～

软件行业发展迅速，业务复杂度不断增长，软件规模和复杂性随之增加。很多软件企业发现，尽管人员数倍扩张，但业务需求交付量并没有同比增加，反而因为沟通成本等因素，交付时间比之前还长，研发效能日趋下滑。

在竞争激烈的市场环境下，软件企业不得不思考：如何才能以更科学和可持续的方式，实现研发降本增效？这，正是研发效能管理要回答的问题。

效能提升，无论企业规模大小，研发效能管理不可或缺

为提升研发效能，大、中、小规模企业都在积极探索和追逐研发效能提升：

头部大厂

人员规模越大，效率和效能问题越早显现。因此，互联网大厂较早关注研发效能管理，希望通过持续高效的产品交付，应对日趋复杂的业务需求。

例如腾讯、百度、阿里、美团、字节等国内大厂，都设立有专门的研发效能职能部门，如研发效率部或研发管理部，专注于研发流程优化、系统效能提升等工作。

国外互联网大厂更是如此，基本都设有 EP(Engineering Productivity）部门。如微软，在 2020 年时，其 EP 部门就多达 3000 多人。

腰部厂商

腰部厂商则希望通过高效能研发，实现弯道超车，充分发挥后来者居上的优势。

中小型企业

尽管相比大公司，中小企业在研发效能管理上可能还不够成熟，但研发效能关系到其生存与发展，非常需要高效能研发为其创造更强的竞争优势。

尽管不同规模的软件企业，或多或少进行过研发效能相关实践，但依然面临“灵魂拷问”：

研发效能提升了吗❓

提升了多少❓

怎么进一步提升❓

研发效能管理 GDAI 模型，监管与迭代相辅相成，效能螺旋上升

研发效能管理双模模型是极狐GitLab 基于多年 DevOps 实践经验提炼而来。如下图所示，双模是指运营监管和探索迭代，两种模式相辅相成、循环往复。

该模型的理论基础包含四大部分，简称 GDAI 模型：

G 目标设定：明确研发效能场景、目标，设置统一、可度量的数据维度
D 数据采集呈现：研运全链路数据采集、持续可视化监控呈现
A 分析洞察：数据驱动分析、洞察研发效能卡点
I 优化改进：针对卡点明确改进方案，持续实施、优化，获得反馈

如何将 GDAI 模型落实为行动？

我们进一步细化分解为七个落地步骤，既「研发效能管理七步走」：数据采集→定义指标→持续监控→数据可视化→产出洞察→改进方案→实施运行

接下来为大家一一拆解，并分享每个步骤的最佳实践。

研发效能管理 7 步走，明晰 6 大角色场景，有的放矢，步步精进

Step 1：数据采集

彼得德鲁克说，无法度量就无法管理。效能管理同样如此。度量效能的第一步就是采集数据，别看只是第一步，也卡住了不少团队。

数据采集难在哪里？我们调研了许多企业和团队，发现以下情况：

研发运维过程没有自动化，数据无法采集

举个例子，有些团队没有用需求管理工具，而是使用一些在线管理文档来管理需求。那么就无法采集到于需求分析、需求设计时间等数据。

研发运维过程数据需要人工录入，准确度低

这个问题体现在两个方面：

如上述例子：需求分析时间无法采集，就无法进行后续分析等工作。因此只能通过人工录入，准确度可能受影响；

可能为了好看的数据，或忘记填写，后续填补大概的数据。无论初衷如何，都会致使数据丧失真实性。
数据散落在不同工具链中，多个数据孤岛

这个现象更加常见，大部分企业在不同研发阶段使用不同工具，过程数据存储在不同工具中，难以形成联系。

API、日志、队列等多种形式，学习成本高

不同工具链的数据获取方式不同，同一工具链不同部分的数据获取方式也可能不同。这对数据采集人员而言，是巨大的挑战，学习成本和采集成本都很高。

那么，好的数据采集过程应该是怎样的呢？我们总结了如下几点：

自动化采集，提高数据置信度

摆脱人工录入，确保数据真实性是数据采集的基础。

自动、无感知采集，降低学习成本

无感知的自动采集既能够降低学习成本和人员投入，还能够进一步保障数据真实性。

数据清洗，数据有效聚合

对数据进行清洗及有效聚合是更高一层的数据采集要求，使数据在确保真实性的基础上，又得到了有效性。

虽然很难通过完全自动的方式，解决数据散落在不同工具链的问题，但如果单工具做到自动采集，那么整体关联难度和工作量也会降低很多。

当然，如果企业能应用研发一体化平台来管理端到端更好，一方面是效能管理的数据采集环节受益；另一方面，越少的工具切换，就对应越少的时间浪费和精力消耗。

Step 2：指标定义

在第一步中，我们采集到了研发过程中的原始数据，它们是客观的、离散的、未经处理的事实描述，而且也并非所有数据都是有价值的。

这些原始数据应该怎么用起来，驱动效能有效管理呢？可以用 DIKM 模型来指导：

DIKW 模型是一种信息处理模型，作用在于帮助人们理解和利用信息。它提供了一种框架，将数据与知识和智慧联系在一起，帮助人们从海量的数据中提取有用的信息，并转化为实际应用和决策。

数据层：数字、文字、图像、符号等未经加工的原始数据建立起的“数据库”；
信息层：经过加工处理后有逻辑的数据，对决策有价值；
知识层：信息的集合，提炼信息之间的关系，形成属于自己的体系；
智慧层：表现出来的一种独有的能力，是收集、加工、应用和传播知识的能力，能够辅助决策，进行预测。

举个生活中的例子：

家庭月收入、支出等数据，即“数据层”；
将这些数据分门别类，得知每个月花费的主要类别以及每种类别的总金额和比重，即“信息层”；
进一步从这些信息中总结出结果，例如哪些是必要支出/非必要支出，哪些是可优化的花费等，即“知识层”；
最后根据知识，制定家庭预算计划，合理分配支出，做出更理性的消费决策，更好地掌握财务情况从而获得更舒适、幸福的生活。这就是“智慧层”。

再看软件研发领域，第一步采集到的研发过程数据、日志，甚至代码本身都属于数据层，为了达到有效管理研发效能的目标，需要进一步从数据层识别筛选，定义出信息层的度量指标。

数据合理组织形成指标，并没有一个放之四海而皆准的原则。在企业中，不同角色可能讨论的是研发效能不同层次，对效能有不同诉求，搞清楚目标，才能定义出有效的指标。

接下来，我们针对不同角色场景，应用 GQM （Goal、Question、Metrics，目标问题指标）方法来定义出样例指标。

高层管理者

对于 CEO、CTO、研发负责人等高层管理者而言，他们的目标和关注点不是细节，而是组织级别，例如组织级项目产能稳定、组织级项目风险可控、组织级项目质量有保证等。

针对这 3 个示例目标，可以反推出 3 个问题：

需求交付速度怎么样?
项目有什么潜在风险？
项目质量问题多吗？

根据这 3 个问题，再来定义指标：

项目的活跃度、需求吞吐量、需求交付周期，回答的是需求交付速度怎么样；
项目的成熟度、告警数，回答的是项目是否有潜在风险；
线上问题数、问题率，回答的是项目质量问题情况。

这样定义的指标有明确的目标性，才能够带来价值，而不是为了展示数字而收集。以此类推，其他场景指标定义如是。

人力总监

人力总监、HRBP 的目标和关注点显然不再是项目风险或者项目质量，他们的目标可能是让新员工能更快融入和产出、制定更合理的招聘计划等。

由这两个目标继续去反推问题：

新员工产出如何？
团队工作饱和度如何？

回答这两个问题的指标包括：

人员有效代码量；
人员代码质量问题数/问题率；
人员活跃度；
人员投入产出比。

项目负责人

PMO 或跨项目负责人关注自己管辖的项目风险、质量，资源是否合理分配。在这个场景下我们发现，PMO 关注点和 CTO 有很多重合，区别在于 PMO 关注的粒度更细一点。

同样的，反推出问题：

需求交付速度怎么样？
项目有什么潜在风险？
项目质量问题多吗？

相应的，拆解为指标：

团队代码活跃度；
团队技术栈；
需求吞吐量；
需求按时交付率；
项目告警数；
线上问题数/率。

基层管理者

基层管理者期待的是研发过程全盘数字化，能够看到细致、覆盖各维度的效能数据，基于数据排查出问题，并能将数据作为抓手，指导改进行动。

对于 Team Lead 而言，他们的目标更具体，时间范围更短，是保证代码评审有效展开、代码质量、迭代交付。

反推出问题：

Code Review 认真做了吗？
代码质量如何？
迭代交付速度怎么样？

相对应的指标粒度也会细一些，避免 Code Review 流于形式，把握迭代速度：

MR 的合并时间；
MR 的评审时间；
MR 的评审人数；
代码质量问题数；
迭代需求吞吐量；
迭代需求按时交付率。

合规经理/ IT 经理

除了在研发效能领域备受关注的角色外，还有两类对象场景虽然关注度很低，但与研发效能管理的落地也息息相关。

一类是合规经理/IT 经理。

在企业们埋头建平台和自动化工具时，可能会忽略软件研发效能成功的标准是客户的成功，而不只是按时上线，若没有安全合规保障，业务将处于风险之中。所以，安全场景也应该是效能管理的一部分。

合规经理/IT经理的目标是 IT 资产安全、代码安全、软件操作的规范性等。

反推出问题：

代码有没有泄露风险？
代码是否合规？
代码是否有漏洞？
代码访问权限是否合理？

拆解为指标：

代码库安全度；
代码库下载克隆数；
代码许可证合规率；
代码漏洞数\率；
代码库权限数\比；
运营经理/市场经理。

运营经理/市场经理

第二类关注度很低的角色场景是运营经理/市场经理。他们的目标是产品快速发布，提升占有率。

反推出问题：

产品发布速度如何？
产品发布速度如何？
开发成本如何？
用户使用情况如何？
用户满意度如何？

拆解为指标：

需求发布频率；
需求交付周期；
线上问题数/率；
产品投入产出比；
产品使用率；
客户满意度。

以上 6 种角色场景可能只涵盖大企业中的很小一部分，或者比小微企业的角色场景多很多，没关系，只要把握「场景→目标→问题→指标」的方法，度量指标基础就是有效的。

Step 3：持续监控

针对研效指标的观测需要持续监控，这自不用多说，因为大部分问题很难立刻、全面暴露，问题的发现往往由趋势得来，而不是一些绝对数字。

需要重点提示的反而是度量指标也需要持续监控，持续关注指标健康度，通过规范乃至自动化流程保障指标能够反映研发的真实情况。

Step 4：数据可视化

在前面的步骤后，我们拿了数据，分析了角色场景，定义了相应的度量指标， Who 和 What 已经比较清晰了，下来需要解决 How 的问题。

通常来说，人们读图表比读文字要快 3 倍左右，所以图表能更简单有效地表达。数据可视化 BI 本身是一个很大的话题，但在效能管理领域，数据可视化只是一小部分，可以先投入适当精力，把握住以下原则，问题洞察将事半功倍：

适合的图表类型；
正确的色彩设计；
慎用 3D 图形；
避免信息过多；
尽量从 0 开始；
正确的数据层级。

接下来举一些例子，帮助大家获得更深刻的理解。

适当的图表类型

看团队当月 Top10 代码贡献人，应该用什么图表？明显是柱状图比饼图更加清晰有效。

饼图的重要作用是表达不同类别或部分在总体中的占比关系，如果看需求的类别占比，饼图很合适。该例子中有没有这个需求，所以饼图并不合适。只要转化为简单的柱状图，就更容易区分结果。

正确的色彩设计

上图左侧彩色柱状图可能看起来挺好看，但会让人摸不着头脑：它想表达什么意思？

使用颜色越多，可视化效果就越难理解，更多颜色 = 大脑必须处理的类别更多。颜色的作用是突显我们想要的信息，例如突出代码贡献第一的人，上图右侧柱状图是更好的表达。

慎用 3D 图形

如上图，3D 图形除了感觉很酷，通常难以阅读，这使它们带来的麻烦超过了价值。

可视化是为了有目的的表达信息，不是为了好看，因此慎用 3D 图形。

避免信息过多

当我们想看团队当月的人员效能，负责效能数据展示的同学给出了上图左侧图表。

这张图表需要关注的视觉信息太多了，图形表示不同的人，还展示了合并请求数量、提交次数、评审时长、开发时长等信息，观看者很难找出任何实质洞察，在视觉上也缺乏吸引力。

更好的做法是把图表信息进行拆分，如上图右侧图表，把同一类信息放在一起，例如与开发效率有关的数据放在一起，与评审相关的数据放在一起等，一目了然。

尽量从 0 开始

假如我们想看团队 6 月 1 日到 6 月 16 日质量问题数。看到上图上方图表，可能会受到惊吓：怎么质量问题增长这么快？已经准备叫人来问责了。

但细看只是由于 Y 轴不是从 0 开始，让人误认为质量问题数线性增长，风险很大。当 Y 轴从 0 开始，可以看出实际上涨幅非常小，处于正常范围的波动。

因此，我们制作图表时， Y 轴尽量要从 0 开始，避免误会。

正确的数据层级

以 2022 年公司需求吞吐量为例，当选好了图表类型、色彩、展示信息以后，这里要用到第二步的角色场景。所以，明确角色场景不止对定义指标很关键，在展示时也同样重要。

对于高层的管理者而言，不需要看到特别细节，看到季度数据、所有项目总趋势、是否可控即可；但对于基层管理者来说，细节数据是洞察问题的关键，需要看到每个月的情况，不同项目的需求图吞量趋势等。

正确的层级关系的确定，与指标定义一样需要目标导向。

Step 5：产出洞察

完成可视化后，要怎么看、怎么产出洞察呢？

人肉洞察

可视化图表展示出数据后，需要观测人员去发现问题，继续以上文公司需求吞吐量为例：比如我作为一个团队负责人，负责五个项目。我能明显从下图趋势线看出，橙色项目三在 7 月、8 月份的吞吐量持续上升；蓝色项目一在 7 月、8 月份的吞吐量持续下降。

作为负责人，可以继续去下钻数据，从更细节数据上找到原因。当然，线性数据只能表现现象，发现问题，还无法反映原因，因此就需要人为线下调查原因，这都属于人肉洞察的一部分。

自动洞察

当数据量非常大，关联维度很多时，靠人眼很难发现问题，效率低，并且非常依赖个人经验。此时，就需要自动洞察。

一方面是自动化化一些人肉洞察，例如上述例子，可通过设定需求量变化率的基线，当项目需求吞吐量低于/高于历史基线，进行洞察预警、洞察报告等。

另一方面是定义好指数模型，去自动发现问题。指数模型可以洞察出指数组成的细节问题，比如极狐GitLab 的项目成熟度会从项目代码库状态、分支、合并请求、流水线、质量等方面综合评估。

Step 6：改进方案

在研效管理中，度量是手段，洞察是过程，推动产生有价值的决策，促进有效的改进才是目的。改进方案和洞察两者应该相结合，洞察的问题是改进的主体。

例如在人肉洞察中的项目需求吞吐量例子，发现项目一和项目三问题，结合人员效能分析，发现 7 月毕业季人员调整后，项目一新增了过多毕业生，而项目三都是经验丰富的研发，因此产生项目需求吞吐量的差别。

针对性改进方案就是去调整两个项目中的人员比例，既能满足稳定输出需求，还能以合适的配比进行“老带新”，让新人快速成长。

改进方案和洞察相结合，也将进一步迈向智能诊断分析。

Step 7：实施运行

终于拿到了方案了，但方案的最终落地执行，也不是那么容易。

小范围工程实践改进类相对简单，比如：编译时间过长，则进行分布式编译，或提前缓存依赖等；代码质量问题多，则加强评审等。

随着基础工作越来越好，单一领域效能的提升或稳定的边际效应会逐渐递减，全局优化变得非常关键。此时需要进行跨部门流程优化、资源调整、人员招聘等，这些都需要借助管理层力量才能有效推进。

单元工程实践与组织支持两者缺一不可。

案例：2 周代码质量提升 10% ，蔚来标准研发效能管理体系

接下来，我们通过一些极狐GitLab 客户案例来深化研发效能管理 7 步走的落地。

某新医药企业

以某医药企业 Code Review 场景为例，该客户的 Team Lead 要保证团队代码认真评审，这也是绝大部分Team Lead 的普遍诉求。

该客户本身就用极狐GitLab 作为一体化 DevOps 平台，同时应用效能管理产品极狐星。

首先，数据采集步骤十分顺滑，极狐星自动收集极狐GitLab MR 过程数据。

接着，针对 Code Review 场景，Team Lead 选了多个指标：代码质量问题数、MR 评审时长、人员活跃度等。例子里我们用 MR 评审时长来看「研发效能七步走」的落地。

经过一个迭代的观察，Team Lead 通过评审时长分布图发现 Code Review 时间都非常短，如下图所示，80% 都不到 30 分钟。

结合详细数据，进一步发现 80% MR 评审过程都不到 10 分钟，也几乎没有任何建议。

Team Lead 了解到团队中的代码评审流于形式。针对这种情况，列了两个改进方案：

文化方面，给团队宣传代码评审的文化；
总结代码评审的评审范围等最佳实践，把代码评审内容制作成 checklist 发给团队作参考。

同时结合极狐GitLab MR 的辅助能力，设置了标准化规则（如下图），确保代码评审更规范的落地。

过了两周后，Team Lead 反馈：千行代码质量问题数 8.1 下降到 7.3，在短时间内就提升了近 10%，很有信心通过后续的持续改进获得更大的效果反馈。

这个案例完整呈现了效能管理七步走，希望大家能有所借鉴和收获。

蔚来自动驾驶团队

新能源汽车头部企业「蔚来」自动驾驶团队，同样应用极狐GitLab + 极狐星，打造了标准研发效能管理体系。

蔚来自动驾驶团队比较年轻，但发展非常迅猛，目前已有超 1000 人规模。在快速发展过程中，蔚来发现缺少一套 DevOps 数据度量平台，作为部门工程效率的基础设施之一，准确、统一、清晰地度量研发效能。

为此，蔚来选择极狐星产品，使用至今，已满足蔚来研发团队使用场景：

数据采集无感知：基于极狐GitLab 完成数据采集和处理，因此部署非常简单，数据采集零感知，无缝实现 DevOps 效能度量；
数据可度量：完全满足蔚来研发场景需求的数据可视化体系，轻松实现数据度量与数据洞察；
研发效能体系化：帮助蔚来 1000 + 人研发团队，建立标准研发效能管理体系，极狐星统一企业内不同部门、不同角色的「研发效能语言」，实现企业上下明确目标、统一口径、了解现状、科学决策，用研发驱动业务增长。

蔚来自动驾驶 DevOps 团队负责人孔毅表示：