GQM 概述：构建研发效能度量体系的根本方法

来源 | 经授权转载自 思码逸研发效能 公众号

降本增效，迫在眉睫

几年前，随着粗放式增长的红利见顶，降本增效成为企业内的高频词汇；近两年在疫情冲击和经济下行的背景下，更是成为不得不重视的议题。美团亦将系统性的降本增效作为 2022 年度的三个关键命题之一。

软件研发团队作为许多科技企业的成本中心，同样需要更精细化的管理来降本增效。过去高速成长期用不着关注、来不及关注的低效点，如今都已是不能承受之重。

研发团队如何在精打细算的同时，依然高效率、高质量、可靠且可持续地交付价值，支持业务侧去应对快速变化的市场？研发效能这一概念由此开始进入许多先进组织的视野。

效能度量的底层逻辑

从 2019 年推出研发效能分析平台以来，思码逸帮助众多研发团队构建起效能度量体系，服务于科学的研发管理与工程改进，也与客户、行业专家们一同沉淀了许多效能实践经验和思考。

每个组织的效能改进，都是由其自身的特质和目的所决定。他人的实践固然有参考和学习意义，但也很难原封不动照搬。

俗话说，授人以鱼，不如授人以渔。在汇集了如此多经验之后，我们希望从中抽象出可复用的底层逻辑：

💡什么是构建效能度量体系的根本方法？

我们接下来介绍的这套方法来自学术界，后来在学术界、产业界都得到广泛应用，被称为研发效能度量方法的『事实标准』。

GQM 方法

GQM（目标 - 问题 - 指标 ）方法最早由 Basili 提出，发表在软件工程领域权威期刊 IEEE Transactions on Software Engineering 上。GQM 当初是为软件工程研究中的数据收集和分析而设计的，其基本思想是：

• 自上而下定义，每个目标划归为一组可量化回答的问题，每个问题通过若干特定的指标来回答

• 通过提出问题，建立和表达隐式模型，解决研发难以定义数学模型的困难

• 自下而上分析解读，数据的收集和分析都服务于清晰明确的问题，进而达成定义的目标图片

接下来我们分别介绍目标 Goal、问题 Question、指标 Metric 这三个核心概念。

目标

目标阐述了组织对研发效能的信息需要，包含四个要素：

• 对象：研发的过程（Process）、产物（Product）和资源（Resource）中的一种；每种对象都可能存在层级结构

• 维度：目标聚焦的角度或对象的属性。参考《软件研发效能度量规范》对认知域的划分，速度、质量、价值、成本、能力都是维度

• 目的：了解（Understanding）、评价（Evaluation）、改进（Improvement）、控制（Control）和预测（Prediction）中的一种或多种

• 角色：组织中关注该目标的角色接下来我们以一个真实案例来示意如何定义目标。

某大型组织当前面对的痛点是规模大、部门多、业务杂，无法准确评估各部门的人力负载情况，无法判断部门人力增补需求的合理性，也无从实现部门间人力调配及合理流动。

该组织当前的目标是控制项目人力成本，那么这个目标的四个要素如下：

梳理四个要素，能帮助我们用一系列标准标签来对阐述目标、拉齐共识。

问题

根据目标提出的一系列问题，主要用于刻画目标；通过提问，建立起一个在目标维度上刻画目标对象的模型。

提问环节需要注意以下两点:

• 先做加法：尽可能多地提出问题，使模型尽量全面、充分、有效，避免数据收集后才发现遗漏或者无效；完备的问题列表一方面可根据实际需要做裁剪，另一方面可提供多种模型可支持度量结果的交叉验证

• 结合实际情况：在提问环节，需要结合研发团队的实际情况与特征，补充问题的所需信息

例如，在项目人力成本的目标下，我们可以提出以下（但不限于）几个问题：

接下来就需要结合研发团队实际情况，补足模型的一些信息，使问题具备可操作性，例如：

• 如何定义人力负载的合理区间？

• 如何定义关键事务？

• 项目划分为哪几个阶段？这些阶段人力投入的典型特征是？

• 项目划分为哪几个类型？

指标

一个问题可能需要多个指标共同回答，这里可以采用技巧——先将问题转化为假设，然后思考：要充分、可靠地证实或证伪这个假设，最关键的是哪些指标，还需要哪些指标做支撑，哪些指标作为制衡。

接着前面项目人力成本的问题，我们可以提出以下（但不限于）几个指标：

在这些指标的基础上，可以根据目标中的具体目的，使用多种分析方法：

• 分类分布：将对象的组成部分分类后，进行统计分析；该方法在了解对象组成部分的场景下应用广泛

• 帕累托分析：将组成部分或影响因素的指标排序，定位影响最大或最主要的部分，常用于改进或控制

• 相关分析：运用各类统计方法找到指标间的正负相关性，常用于改进或控制

• 拟合建模：运用各类统计方法找到有效预测指标的数学模型

总    结

GQM 从目标梳理，到提问建模，再到指标体系的做法，能够避免构建度量时盲目求大求全、堆砌指标、成本过高等问题，使每一个指标都是为了服务具体场景而存在，也能真正产生有价值的信息。

Q&A

以下是研发效能专家茹炳晟老师与本文作者任晶磊针对 GQM 方法展开的讨论，为了帮助大家更加深入地理解 GQM，在此补充。

茹炳晟：在讨论的开始，请晶磊先简单概括一下 GQM 方法的概念？

任晶磊：GQM 是一套软件研发效能度量的方法，最早是来自于学术界，后来在企业内也有广泛的应用，被称为效能度量方面的事实标准。

GQM 三个字母分别代表目标、问题和指标，从这三个概念就能看出 GQM 方法最重要的主张：度量的起点是目标的清晰定义，接下来是将目标拆解为不同问题，针对每个问题设计多个相关指标。GQM 方法强调效能度量建设时自上而下定义，使用时则按照收集数据 - 度量指标 - 回答问题 - 达成目标的路径自下而上做聚合。

茹炳晟：度量是相当敏感的议题，稍有不慎就会踩坑，最近我也写了一篇文章讲研发效能度量中的那些坑。

在实践中，很多公司就是为了度量而度量，一上来就从指标出发开始收集数据，而不是从具体明确的目标出发，这是一个很常见的坑点。而 GQM 方法把度量设计的大基调给定下了，就是目标和问题导向、自上而下。

除此之外，效能度量中还有哪些坑是我们容易忽略、容易走弯路的？

任晶磊：茹老师的点评一针见血。现实中确实有许多团队做研发效能度量是从指标开始，梳理出大量指标后开始纠结数据怎样取得更多更精确，投入了很多精力但没能解决实际的问题。没有方向感，效能度量走的路可能从一开始就是错的，这个是最关键的坑，也是 GQM 方法着力解决的。

除此之外，还有一些小的坑点能够通过 GQM 方法的梳理来避开。例如在效能度量中，改进是关键目的之一，例如我们希望构建时长是越短越好，这反映了研发工具链的自动化水平。但我们也需要留意改进不是度量的唯一目的，度量目的还包括了解、控制、预测等。比如开发者的生产率，可能控制在合理区间内是最理想的，不需要也不能够无止境地提高。我们常常听到的“内卷”，实质上就是不合理地追求指标持续提升，乃至于反生产的程度，这也是效能度量中的一个坑。GQM 方法帮助研发团队在设计度量方法的前期，就搞明白这些目的之间的差异，做好区分，避免大家在无谓的“改进”中浪费精力和资源。

茹炳晟：这个例子特别好。度量的本质价值来自于发现研发背后的问题，找到解决方案，而度量动作本身是没有价值的。顺着这个话题，在 GQM 的方法下，效能度量的落地有什么具体的实践经验可以与大家分享？

任晶磊：有一个效能度量方法论的文档类项目 openMARI（https://www.openmari.dev/），沉淀了研发效能行业专家对度量落地的思考，包括该如何制订目标、如何提出问题、每个问题有哪些常见的相关指标、这些指标之间的关系如何、如何分析这些指标、如何定位问题的关键所在、如何回顾并调查问题的根因、如何设计有针对性的改进措施等等。这个项目是开源运作的，也非常希望有更多行业专家能参与进来共建，共享经验。

与这个方法论相匹配，有一系列开源工具致力于解决效能度量建设中的种种问题，包括研发工具链的建设和整合（CNCF DevStream）、研发数据的汇集治理（Apahce DevLake）等，也有基于深度代码分析的产品来解读数据中的种种信号，获取效能洞见。

大家在落地效能度量的过程中，可以先借助方法论的框架厘清思路，再借助工具建立起坚实基础设施。

茹炳晟：这是一个互相衔接的完整路径，不止于一个单点，而是建立起了支持研发效能管理和改进的武器库。

任晶磊：是的。我认为数据将会成为软件研发行业中新的基础设施，也会是驱动研发效能提升的关键要素。

茹炳晟：没错，近期行业内也改称度量为洞察了，从度量中发掘出洞见的金矿，才是最有价值的。

今日好文推荐

在中国 ToB 市场选一个对的供应商太难了

搞不定移动端性能，全球爆火的 Notion 从 Hybrid 转向了 Native

离开谷歌的副作用：外面很难找到这么好用的开发工具

字节将大幅压缩招聘规模；滴滴被罚 80 亿，违法行为持续 7 年；各国软件开发者薪资统计：中国上榜全球开发者薪酬最低国家名单 | Q 资讯

活动推荐

我们致力于寻找“能引领行业发展的领头羊”。无论你是否是专业博主，只要你能写、会写、敢写，愿意分享自己的学习和实战中的经验，就有机会加入我们！InfoQ 百位优质创作者签约计划第三季等你加入！