近日,在极狐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 团队负责人孔毅表示:
使用至今,极狐星以其数据采集无感知、数据度量可视化、研发效能体系化等诸多优势,已帮助蔚来实现用数据度量研发效能,后续蔚来内部会有更多团队使用极狐星,无需多言,极狐星产品本身就是最好的推荐。
极狐星(TowerFox)是基于极狐GitLab 的一站式企业 DevOps 智能分析管理平台,提供从数据驾驶舱、效能管理、项目分析到合规管理的一体化解决方案,能够全行业、多场景、全软件生命周期的满足企业研发管理需求,让研发效能看得清,算得准,成就企业精英效能管理。点击此处,免费体验~
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。