本期 DevData Talks 直播活动邀请到的重磅嘉宾是思码逸高级咨询专家陆春蕊老师。陆春蕊老师曾就职于Oracle，在软件质量、项目管理方面有着丰富的经验，在思码逸为上百家客户提供了研发效能体系、数据分析、实践落地等方面的咨询。

陆春蕊老师与我们聊了聊研发效能度量落地中的一些典型难题。在研发流程梳理和工具基础设施建设告一段落后，研发团队可能会发现，效能度量依然难以落地——有时候，收集了一堆度量指标，却不知道给谁看，也不知道如何理解；有时候，度量指标的计算方法与研发实际流程不符，有效性受到质疑；比较好的情况下，数据被用来解读效能现状，但依然无法指引改进的方向，仅仅作为汇报工具存在……

这些问题是否有解决方案呢？

在直播中，陆春蕊老师对效能落地中的难题进行了剖析，并提供了解决思路建议。如何让数据说话，how to let the DevData Talk？

以下内容根据陆春蕊老师的部分演讲内容整理：

通过 GQM 方法构建研发效能度量体系

指标收集了一大堆，用不起来，从何看起？

出现这类问题，可能是因为团队把“指标收集”当成了效能度量的第一步。如果没有思考过为什么而度量就匆忙开始，相当于做好了锤子再四处找钉子，难免会有茫然之感。

我们可以通过 GQM 方法，构建系统化的研发效能度量。

G ，即Goal，我们首先需要明确计划达成的目标，然后根据这个目标再去思考需要解决的问题。

Q，即 Question，我们可能会有“需求交付有多久？”、“随时间变化趋势？”、“流动效率是否正常？”等问题

M，即 Metric，根据问题找到对应的指标，逐步分析以解决问题。聚焦特定的目标，自上而下层层推进，最终解决问题，驱动研发效能度量。

GQM 方法强调先向内追问度量的根本目标，再面向清晰具体的目标，自上而下拆解，通过问题建立研发度量模型，进而拆解出用于回答问题的一系列指标。

借助 MARI 方法论层层推进研发效能分析

指标体系怎么分层、如何下钻？

在度量落地的过程中，这类问题也十分常见。要解决这个问题，第一步要对数字祛魅：数字本身不是效能度量的目的，也无法直接带来效能改进。

陆春蕊老师与我们分享了 M 度量 - A 分析 - R 回顾 - I 改进 - M 度量的闭环，让度量转化为可落地的改进行动，而改进的效果由下一轮度量来快速验证。借此，研发团队能够小步快跑探索改进措施，找到最适合的提效路径。

其中，回顾是度量洞察转化为有效行动的关键环节。回顾需要团队成员参与进来，基于量化数据和洞察进行复盘，找到少数关键点（例如表现异常的时间段乃至任务项），追问根因，尝试回答有哪些因素影响了研发效能。如果回顾会上无法立刻判断影响因素是否成立，可以对度量体系进行补充设计，对这些存疑的影响因素进行验证。

研发效能度量分析案例

在介绍了 GQM 和 MARI 方法论后，陆春蕊老师从交付速率、交付质量的场景为例，为我们展示了可落地使用的研发效能度量看板的特征：度量有明确目标、支持下钻分析、支持自定义指标以匹配团队实际流程、有简洁直观的数据解读。

在这样的数据看板支持下，研发团队就可以更加专注于度量目标的定义、数据结果的复盘等环节，让效能度量能够真正落地，提升研发团队的效能表现和开发者体验。

---

『关于DevData Talks』

DevData Talks 是一个开放分享研发效能实践经验与方法论的系列栏目。

我们会邀请行业专家分享研发效能提升、数字化管理等相关先进实践与深入思考，持续沉淀优质干货内容。与伙伴们共同探讨研发效能领域的实践与思考，一起交流、学习、成长。

独行者速，众行者远。