写点什么

错过直播?快收藏详实回顾!Get「研发效能管理」7 步实践指南与案例剖析

作者:极狐GitLab
  • 2023-07-14
    天津
  • 本文字数:7366 字

    阅读完需:约 24 分钟

错过直播?快收藏详实回顾!Get「研发效能管理」7 步实践指南与案例剖析

近日,在极狐 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 模型是一种信息处理模型,作用在于帮助人们理解和利用信息。它提供了一种框架,将数据与知识和智慧联系在一起,帮助人们从海量的数据中提取有用的信息,并转化为实际应用和决策。



  1. 数据层:数字、文字、图像、符号等未经加工的原始数据建立起的“数据库”;

  2. 信息层:经过加工处理后有逻辑的数据,对决策有价值;

  3. 知识层:信息的集合,提炼信息之间的关系,形成属于自己的体系;

  4. 智慧层:表现出来的一种独有的能力,是收集、加工、应用和传播知识的能力,能够辅助决策,进行预测。


举个生活中的例子:


  • 家庭月收入、支出等数据,即“数据层”;

  • 将这些数据分门别类,得知每个月花费的主要类别以及每种类别的总金额和比重,即“信息层”;

  • 进一步从这些信息中总结出结果,例如哪些是必要支出/非必要支出,哪些是可优化的花费等,即“知识层”;

  • 最后根据知识,制定家庭预算计划,合理分配支出,做出更理性的消费决策,更好地掌握财务情况从而获得更舒适、幸福的生活。这就是“智慧层”。


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


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


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


高层管理者



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


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


  1. 需求交付速度怎么样?

  2. 项目有什么潜在风险?

  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 了解到团队中的代码评审流于形式。针对这种情况,列了两个改进方案:


  1. 文化方面,给团队宣传代码评审的文化;

  2. 总结代码评审的评审范围等最佳实践,把代码评审内容制作成 checklist 发给团队作参考。


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



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


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


蔚来自动驾驶团队


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


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


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


  • 数据采集无感知:基于极狐 GitLab 完成数据采集和处理,因此部署非常简单,数据采集零感知,无缝实现 DevOps 效能度量;

  • 数据可度量:完全满足蔚来研发场景需求的数据可视化体系,轻松实现数据度量与数据洞察;

  • 研发效能体系化:帮助蔚来 1000 + 人研发团队,建立标准研发效能管理体系,极狐星统一企业内不同部门、不同角色的「研发效能语言」,实现企业上下明确目标、统一口径、了解现状、科学决策,用研发驱动业务增长。


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


使用至今,极狐星以其数据采集无感知、数据度量可视化、研发效能体系化等诸多优势,已帮助蔚来实现用数据度量研发效能,后续蔚来内部会有更多团队使用极狐星,无需多言,极狐星产品本身就是最好的推荐。


🌟 极狐星(TowerFox)是基于极狐 GitLab 的一站式企业 DevOps 智能分析管理平台,提供从数据驾驶舱、效能管理、项目分析到合规管理的一体化解决方案,能够全行业、多场景、全软件生命周期的满足企业研发管理需求,让研发效能看得清,算得准,成就企业精英效能管理。


极狐星 🌟 现开启免费试用

限时 50 席,点击图片立即申请


发布于: 刚刚阅读数: 8
用户头像

极狐GitLab

关注

开源开放,人人贡献 2021-05-19 加入

开放式一体化DevOps平台,助力行业高速协同增长!

评论

发布
暂无评论
错过直播?快收藏详实回顾!Get「研发效能管理」7 步实践指南与案例剖析_gitlab_极狐GitLab_InfoQ写作社区