9 月 27 日思码逸 DevData Talks 邀请到了京东科技测试架构师刘刚。他以《研发效能度量之大体系小实践》为主题，分享了如何以集团的研发效能度量体系作为指引，在所属部门落地适应自己团队和业务特点的度量体系，并取得有效的改进成果。其中他还详细分享了团队分 5 个阶段，一步步建立研发效能度量体系和工具平台的过程。

由于篇幅有限，本文仅整理总结了演讲亮点，如果大家希望了解更多细节，可在文末扫码获取PPT、观看视频回顾。以下为文字回顾：

我是来自京东科技的刘刚，很高兴给大家分享《研发效能度量之大体系小实践》。我们部门属于科技体系下 to B 业务的一个部门，我们已经做了两年左右的研发效能实践，收获了不少成果，也走过不少弯路，借这个机会跟大家分享、交流。我的分享分为五个部分：

1. 集团研发效能度量体系介绍

2. 研发效能小实践前置动作

3. 定制化度量体系

4. 持续改进&持续实践

5. 总结

集团研发效能度量体系介绍

首先，如下图所示，是京东集团的研发效能度量体系。集团的度量体系的核心是产研价值驱动，例如让团队将构建的系统与具体的业务目标相关联，从而凸显出研发为业务带来的价值。

我们的研发效能度量体系有四个维度：收入、成本、效率、体验，形成一套量化模型，再结合管理机制来有效地度量我们的研发效能，核心就是刚刚说的产研价值的驱动。基于此也带来一个命题，就是“正确地做事情”。通常在一个项目开始的时候，业务主管会确定项目的方向，到研发团队这一层的时候我们要考虑的就是“正确地做事情”，拆解下来就是回答三个问题：

• 产研资源投入到哪里去了?

• 投入产出是否合理?

• 产研资源如何更有效调配?

如果我们能解答这三个问题，我们不仅可以达到研发效能的目标，还可以给业务带来更有效的支撑。

对于研发效能来讲，我们倡导从管理视角出发，分桶划分基于产研如何管理投入、如何衡量价值。对于不同的研发团队的研发效能目标，我们划分出了三大类、六小类，如下图所示。举个例子，你的团队所做的业务是对内的还是对外的？对内的很好理解。比如我们的统一登录系统，它服务于其他业务系统，在其中有百分之多少的价值是由登录系统体现的，那就是它的价值。对外的业务实现就比较直接了，可以理解为对外直接输出产品，营收就是直接价值的体现。

另外两类就是技术布局、基础支撑，这两个都对内部产生的价值更大。比如京东有很多中间件，需要很多研发团队去支持，它其实并不直接与业务挂钩，但对我们的业务有重要支撑作用。

整个集团的度量框架可以用这样一张图表示，如上图所示，从外往里看，客户和价值是相对优先级更高的，因为我们整个研发体系就是为客户服务的，客户既是出发点，也是终点，只有服务好客户，研发工作才更有意义。再向图的内部看，更多的是产品团队成熟度如何？敏捷成熟度如何？DevOps 的成熟度如何？大家工作积极性如何？针对日常的产出，我们有从多、快、好、省四个维度进行衡量。我们的效能衡量有几个原则：

• 聚焦价值流系统优化而不是局部优化

• 聚焦成果而不是某阶段工作输出

• 聚焦敏捷团队而不是个体贡献者

• 数据是客观的

• 异常数据不是被剔除的，而是被用来识别和分析的

研发效能小实践前置动作

目前根据我的理解，在部门中，驱动研发效能的基本上有两类角色，一类是项目管理，他们驱动整个研发效能度量，另一类是测试 QA，他们本身就在产研流程中，对每个环节都比较清晰，而且能第一时间快速感知到研发效能的提升点在哪里。QA 本身需要建立质量保障流程，保障好研发的代码质量、需求质量。当 QA 成为研发效能的驱动者之后，就需要从“聚焦质量”的视角，上升至“产研全生命周期”的视角，然后介入每一个环节，促进团队效能的提升。同时，做研发效能其实也是对 QA 自身价值的提升。这是在做研发效能实践之前的前置动作之一，就是观念与自身定位上的改变。

第二个前置动作就是做充分的调研，尽量避免踩坑。在业内有大量的书籍和文章可以学习，从中我们能了解有哪些坑需要规避，有哪些做度量的方法论可以借鉴、学习，如何建立指标体系等，当认知提升后，可以避免走弯路。

还有一个前置动作就是在小团队内建立共识。我建议先分析团队当前遇到的问题。因为每个人对研发效能的理解不同，甚至怀疑它的有效性。那么你可以先找出目前团队比较突出的问题是什么，然后试图通过一些相关指标来对其进行客观衡量。因为对“问题”的主观看法千差万别，但当我们将它客观量化之后，就会更容易让大家对问题有清晰、客观的认知，更容易形成共识。当大家关注于客观指标，并围绕它进行改进后，也就会意识到研发效能度量的意义。那么这对于后续深入做研发效能会更容易让团队接受。

另一方面，在实操上，我建议最开始的时候可以采用一些低成本的方式，比如先用一个 Excel，统计一些数据，然后汇总加工形成一些图标，当这种简单的方式运行一段时间后，达到一定效果了，或者是团队对项目度量有更高要求的时候，再去找一些低代码平台搭建数据大屏。当研发效能工作进展到一定层次后，如果需要做更多维度的度量，那么再考虑是否要自建系统处理数据，并引入 BI 平台。

定制化度量体系

我们团队是依据集团的研发效能白皮书定制了研发效能度量体系。指标分为两类：

• 北极星指标，为我们指引方向，每个维度会有 1-2 个北极星指标，后续会给大家展示。

• 群星指标，由于北极星指标可能只有一个，你无法确定问题具体出现在哪方面，那么就需要群星指标给你指引，下钻发现问题。同时，群星指标也可以起到多维验证的作用，比如需求吞吐量上升了，结合质量指标，来判断是否效能处于健康水平。

在实践过程中，我们给自己团队定了一个命题：什么是好的团队。我们从五个维度来考虑这个命题，包括团队、效率、价值、质量、产能。

产能维度上，由于我们是 To B 的业务，所以我们的目标是交付更多需求，支持业务的快速发展。结合 GSM 的方法，这样的目标可以拆分为几个信号：

1)需求规模基本一致下，单位时间上线更多的需求

2)项目无等待时间人员充分利用，节奏感好

3)产品、用户满意度高

4)很好的支撑满足业务发展规划

最终我们定的北极星指标有两个，一个是人均需求吞吐量，还有一个需求吞吐率。我们也定制了群星指标来作为辅助，具体如上图所示。

在效率维度上，我们的目标是快速交付，交付周期稳定，能快速响应变化。北极星指标我们定了两个，一个是产研交付周期，就是以需求从产出到交付的周期时长来度量；另一个是发布的频率，主要看每周发布数量，它可以客观反映出敏捷程度。具体的指标如上图所示。

质量维度上，如上图所示，我们定了四个北极星指标：

1)故障新增数

2)故障平均恢复时长

3)缺陷新增数量

4)冒烟通过率

其中我们测试会非常关注冒烟通过率，如果通过率差，不仅说明质量差，而且会影响研发的效率，以及整个版本的质量。

团队方面我们的目标是提高组织活力，建设高效团队。在图中可以看到我们定了三个北极星指标，其中目前用的比较多的就是“团队心情指数”。我们每次版本提测时，主开发来评估团队在开发这个版本的过程中心情如何，是比较低迷还是一般，通过这个反馈，我们来观察整个团队的健康情况。

最后一个维度就是“价值”，它属于研发效能度量中比较难度量的一个维度。因为有时候度量周期短，业务目标还未实现，那么就很难去判断是否有业务价值的转化。所以这需要每个业务线去因地制宜，找到适合自己的度量技巧和方法。

持续改进与持续实践

首先我们在做研发效能之前，要建立一些认知：

• 指标体系不是一日建成的

• 效能认知不是短时间能提升的

• Leader的支持非常重要

• 指标的展示方法和逻辑需要多轮次迭代

• 效能实践需要各角色共同参与

• 团队Open的氛围对效能实践成败非常关键

我们团队的实践经历了 5 个环节，如上图所示。首先是初步尝试，如开头所说，我们就是在 Excel 中简单罗列了几个指标，然后进行度量，如下图所示。我们每周会进行评审，回顾这些数据，包括代码新增量、各团队代码评审情况等。同时我们梳理了团队对京东行云 DevOps 平台的使用规范、安全问题、技术债等。

随着指标改进效果的显现，我们发现 Excel 已经无法满足当前的需求，我们就通过一个低代码的平台做了数据大屏，如下图所示。

第二版相对第一版来讲，我们将指标划分出了三个维度，包括规范的维度、质量的维度、效率的维度，针对每个维度展示相关指标。同时，我们还设计了项目健壮度雷达图。为了让相关项目负责人了解项目还存在哪些地方可以提升，我们增加了指标明细、趋势和下探分析功能。

第三版大屏中，我们的度量维度增加到了五个，包括产能、效率、质量、团队和价值，也就是我们最开始讲到那几个维度。在第三版效能大屏建设过程中，我们也增加了北极星指标的评判标准。另外，也引入了五步分析法，引导和规范大家如何去看指标、分析指标以及推进后续改进。

在经历了两年研发效能的建设后，指标度量体系已相对完善，而数据加工处理的逻辑也变得更复杂了，我们在这时候选择开始自建平台。虽然集团内部有一个度量平台，但它只能提供部分数据，无法满足部门的个性化需求，所以我们需要自己搭建一个平台来收集指标，结合 BI 快速定制图表。同时，我们将底层数据开放给各个团队，他们可以基于数据和自己团队的特点进行更多图表定制和分析，以满足更多场景。

我们数据收集的方式比较多元，一方面会通过爬虫的方式收集数据，比如安全工单的数据，另一方面我们京东行云也会提供开放接口，我们通过这个接口会拉取一些需求数据、提测数据、缺陷数据等。另外，还有一些很难收集的指标数据是通过手工录入的。整体的架构如下图所示。

总结

简要总结一下有五点建议：

1、深入理解公司集团层面研效度量体系：对于比较大的公司，肯定是有自己的一套集团的研发效能度量体系，那么就重点参考这套体系，然后结合自己团队的一些特点再形成适合自己团队的度量体系。

2、学会借力，避免自行一套：不要重复造车轮，如果公司内有可用的指标、体系、平台或其他工具，那就用起来，外部有类似的可用的工具也要用起来，不要全都自建。

3、分析团队和现状，循序渐进：要在度量过程中分析团队现状，循序渐进，特别是正向引导团队的认知。

4、保持耐心，不断复盘：当你提供了一套数据之后，肯定会有研发同事提出各种疑问，你要耐心地去解答，并且不断复盘，寻找适合自己团队的改进方法。

5、成功的两个重要因素:一个是要努力去塑造一个开放的团队，探索创新的改进方法。如果你的团队不是很开放，或者老板不open，那么在做研发效能的时候就需要做出一些取舍，比如有的指标需要舍弃掉，避免引发不必要的问题。如果老板清楚知道某些指标的逻辑，那还好，如果他不清楚指标背后可能存在的坑，就很容易出问题。比如千行缺陷率这个指标，它本身是有一些坑的，并不能很好地去衡量不同研发人员的代码质量情况，如果老板不清楚这些细节，他过于看重这个指标，那就会把团队往一个错误的方向引导。

*由于篇幅有限，以上为节选内容，如希望回顾完整讲座，请扫描文末二维码，或点击文末「阅读原文」观看回顾视频