看懂这5幅图，研发效能分析和改进就容易了

摘要：当你把这 5 幅图看懂了，研发效能分析和改进就容易了。作为 CTO 或企业管理者，我们如何去了解和衡量研发团队的研发效能呢？作为 PMO 和效能负责人，我们该从哪几个维度来回答关于研发效能的问题呢？如何通过效能数据分析，帮助企业管理者透明化研发效能水平和变化趋势，分析效能问题根因、指导改进行动、衡量改进效果。

成都创新互联专业为企业提供赞皇网站建设、赞皇做网站、赞皇网站设计、赞皇网站制作等企业网站建设、网页设计与制作、赞皇企业网站模板建站服务，10年赞皇做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。

作为 CTO 或企业管理者，我们如何去了解和衡量研发团队的研发效能呢？

作为 PMO 和效能负责人，我们该从哪几个维度来回答关于研发效能的问题呢？

带着这两个问题，我们进入到研发效能分析的场景，聊一聊我们如何通过效能数据分析，帮助企业管理者透明化研发效能水平和变化趋势，分析效能问题根因、指导改进行动、衡量改进效果。

注：以下内容分为视频版和文字版，读者可自选学习。

观看地址：https://v.qq.com/x/page/j3324np3qir.html

在云效效能洞察 Insight 中，我们可以从 3 个维度衡量和分析团队的研发效能：

• 看交付速率：单位时间内，团队能够交付多少需求，即需求交付的吞吐量；
• 看响应能力：需求从提出到交付上线的时间长短，即需求交付周期；
• 看交付质量：交付过程中缺陷发现和修复的及时性，以及缺陷数量的多少。

看交付速率

在云效Insight的效能分析场景报表，通过「需求交付速率」指标卡，我们可以：

• 看到在单位时间内的需求交付量，及所选时间段内平均单位时间需求交付量；
• 看到需求交付速率趋势，根据近期交付量来合理安排团队将来的交付节奏和对外的承诺。

图片来源：云效效能洞察Insight

需求交付速率：横坐标为时间，以周为单位，纵坐标是需求的数量（个），柱子高低代表一周交付需求数量的多少，柱子的颜色分布分别对应交付周期的长短分布。

注：按需求个数统计的方式，因需求大小不一致会出现一些统计偏差，因此期望做需求交付统计时能够将需求粒度拆分的相对较小且均匀。

在「需求交付速率」指标卡中，我们可以深入分析：

1. 根据团队交付速率，评估团队交付能力

我们可以根据团队近期的交付速率，预测团队将来的交付速率，以便更好地安排团队未来可接纳需求的工作量。比如最近 6 周，每周交付需求数量为 10，12，15，13，11，17，平均值为 13，我们可以预测团队每周可交付需求数量在 13 个左右，当我们知道这个数据时，可以更好的安排需求交付的节奏和时间，并对外部承诺。

2. 通过观测发布频率，推进团队持续交付

如果每周都有柱子，说明每周都有发布，如果柱子有间隔性，即每两周有一个柱子，说明是两周一次发布，以此类推。

看响应能力

通过云效Insight效能分析报表中的「需求交付分布」、「需求累积流图」指标卡，我们可以看响应能力。

首先，在「需求交付分布」指标卡中，我们可以：

• 看到各需求上线时间的分布情况，反映团队的需求发布频率；
• 看到需求交付周期的趋势，反映团队对需求响应能力及变化趋势；
• 通过历史数据分析，预测将来的响应能力。

图片来源：云效效能洞察Insight

指标卡中数据含义：

需求交付分布，也叫需求控制图，横坐标为时间，纵坐标为需求交付周期（天），图中：

• 圆点：代表一个已交付的需求，它所在的横坐标为交付时间，纵坐标为该需求交付时长；
• 折线：代表需求交付周期的滚动均值，取该点以及前后各1/3/5/7/9 点（随区间事项数变动）的平均值；
• 面积：蓝色阴影区域代表滚动标准差，即实际数据与滚动平均值的偏差量；
• 横线：所选时间区间内，需求交付周期的平均值。

在看到「需求交付分布」的数据时，我们可以从 5 个方面进行理解和分析：

1、纵向上，交付需求的圆点越向下越好，反映出周期时间越短、响应能力越快，可预测性越好；

2、横向上，交付需求的圆点分布越密越好，反映出需求在频繁地交付，即发布频率越高；

3、横向上，交付需求的圆点分布越均匀越好，反映出需求在持续稳定地交付，更趋向于持续交付；如果圆点分布间断而交付集中，可反映出是批量地交付需求；

图片来源：云效效能洞察Insight

注：每个批量的间隔时间比较长（譬如2周或1个月以上），可采取减少需求进出的批量和增加发布窗口的措施。

4、交付周期线，代表在所选时间段内，交付周期的一个基本水位，该水位越低越好；

5、动均值折线，展示需求交付周期的变化趋势，期望是有往下走的趋势，代表团队的响应能力在持续地提升。

「需求交付分布」可以反映出团队是否已具备持续快速交付需求的能力，帮助团队回顾和分析队的效能情况，并根据历史效能情况，设定团队的效能目标。其次，对业务人员来说，可随时查看交付团队的效能情况，预测需求的上线时间。

「需求交付分布」是针对交付的结果进行度量，如果需要对整个交付过程进一步了分析，我们可以中点关注「需求累积流图」，可综合反映了前置时间（交付周期）、在制品数量、交付速率等指标，并体现了团队协作、计划和交付需求的模式，常用以发现系统性的改进机会，下面就对该图进行进一步介绍。

通过「需求累积流图」指标卡，我们可以：

• 看平均交付周期：需求在各阶段的停留时长之和，指需求交付之前，从开始到结束所经历的时间；
• 看在制品数量：需求在各阶段的停留数量，可以反应出处理需求批量大小和并行度情况；
• 看交付速率：发布阶段曲线的整体斜率，可以反应出团队的需求交付速率。

图片来源：云效效能洞察Insight

指标卡中数据含义：

累积流图：横坐标为日期，纵坐标为各个阶段累积的需求数量；从左到右的每个阶段，都是需求按顺序变化的阶段，相应的，曲线对应的分别是这些阶段的累积完成的需求数量。

「需求累积流图」同时具备整体性和动态性，它既反映了团队整体的协作模式，端到端的动态交付过程，同时还反映了交付模式和交付能力的变化趋势。我们可以从累积流图中，分析团队的协作和交付模式，并发现改进机会。我们从下面 3 个方面进行分析：

1. 团队的计划模式

主要看需求进入开发阶段的数量和频率，如一个项目中，进入开发阶段的批量大，而且频次低（譬如每月一次），往往是大批量的输入，很容易出现大量需求并行，导致需求交付周期变短。反之，如果是小批量，多频次的输入，让在制品数量变低，缩短需求交付周期；

2. 需求的转测模式

需求大批量转测，带来的问题是，开发完成的需求，要等待较长时间才开始测试，导致更多在制品，并延长了需求交付周期；

3. 需求的发布模式

需求发布会出现阶梯状，阶梯的间隔越长，代表发布的频率越少，也就是每个发布的间隔时间比较长。同时也可以看出来，发布间隔越长，则每次发布需求的数量就越多，而发布的难度随着需求的增加而增加。

看交付质量

通过云效Insight效能分析报表中的「缺陷趋势」和「缺陷修复分布」指标卡，我们可以：

• 看到缺陷被发现和修复的趋势，反映团队的交付模式；
• 看到存量缺陷的变化趋势，发现与修复分布是否趋于合理，反映项目的质量状况；
• 看到缺陷修复周期的变化趋势，反映团队对缺陷的及时修复能力。

首先，我们来看一下「缺陷趋势」，如下图：

图片来源：云效效能洞察Insight

指标卡中数据含义：

缺陷趋势图：横坐标为日期，纵坐标为缺陷数量，横坐标上方红色柱子代表这一天发现缺陷数量；横坐标下方绿色柱子代表这一天解决的缺陷数量；橙色曲线代表缺陷存量。

在「缺陷趋势」指标卡中，我们可以分析：

1. 看团队的交付模式

如果长时间没发现缺陷，而到某一段时间集中新增大量缺陷，能够反映出是瀑布交付模式。如果缺陷被持续发现和持续解决，且存量缺陷处于较低水位，这种情况更容易形成持续交付模式。

2. 看存量缺陷的多少，判断交付质量

需求在上线前，一般需要把缺陷数量清零，如果项目的存量缺陷一直处于较低水位，反映出交付质量比较高。

举一个从小瀑布模式向持续交付模式转变的例子，如图：

图片来源：云效效能洞察Insight

左半部分

团队属于小瀑布的开发模式。前期，团队集中设计、编码，引入缺陷，但并未即时地集成和验证。缺陷一直掩藏在系统中，直到项目后期，团队才开始集成和测试，缺陷集中爆发。越到后期发现的缺陷，修复难度大幅提升，修复成本大幅增加。

小瀑布模式下，过程质量差，带来大量的返工、延期和交付质量问题。该模式下，产品的交付时间依赖于何时缺陷能被充分移除，无法做到持续交付，也无法快速响应外部的需求和变化。并且，这一模式通常都导致后期的赶工，埋下交付质量隐患。

右半部分

团队开始向持续交付模式演进，质量得到控制。在整个迭代过程中，团队以小粒度的需求为单位开发，持续地集成和测试它们，即时发现和解决问题。缺陷库存得到控制，系统始终处于接近可发布状态。这一模式更接近持续发布状态，团队对外的响应能力随之增强。

接下来我们来看「缺陷修复分布」：

图片来源：云效效能洞察Insight

指标卡中数据含义：

缺陷修复分布，也叫缺陷控制图，横坐标为时间，纵坐标为缺陷修复周期（天），图中：

• 圆点：代表一个已修复的缺陷，它所在的横坐标为修复时间，纵坐标为该缺陷的修复时长；
• 折线：代表缺陷修复周期的滚动均值，取该点以及前后各1/3/5/7/9个点（随区间事项数变动）的平均值；
• 面积：红色阴影区域代表滚动标准差，即实际数据与滚动平均值的变偏差量；
• 横线：所选时间区间内，缺陷修复周期的平均值。

在看到「缺陷修复分布」图的数据时，我们可以从 4 个方面理解和分析：

1. 纵向上，代表已修复缺陷的圆点越向下越好，反映出修复周期越短、修复能力越快；
2. 横向上，代表已修复缺陷的圆点数量越少越好，越少代表缺陷的数量越少，开发提测的质量比较高；
3. 平均修复时长线，代表团队缺陷修复周期的一个基本水位，越低越好。很多团队会设定缺陷修复目标，譬如缺陷要日清，即缺陷要在发现后的 24 小时内修复；
4. 滚动均值折线，展示缺陷修复周期的变化趋势，期望有往下走的趋势，代表团队修复缺陷的速度越来越快。

缺陷修复分布图，对于团队来说，可用于在回顾会上分析团队过去的质量情况，也可根据历史的情况，来设定团队的缺陷修复目标。

整体回顾

我们可以从产能、效率和质量 3 个维度来观测团队的研发效能现状，并进行针对性分析，重点观测 5 幅图：

• 需求交付速率：反应团队历史的需求交付吞吐量，可对未来的交付产能进行预测；
• 需求交付分布：反应团队历史的需求响应能力，可对未来的需求交付速度进行预测；
• 需求累积流图：反应团队整体的协作模式，可分析团队的交付模式和交付能力；
• 缺陷趋势图：反应团队历史的过程质量情况，可分析团队的交付模式和质量状况；
• 缺陷修复分布：反应团队历史的缺陷修复速度，可对团队的缺陷修复速度进行预测。

如果需要更多数据进行分析，也可以参考：需交付时长按阶段分布、 需求累积流图、存量缺陷按成员排名、存量缺陷占比等。

不管在阿里内部，还是我们接触的大部分客户，大家通常以缩短需求交付周期为目标。阿里提出的“ 211” 目标中，第一个 2 就是要把需求交付周期缩短到到两周。

如果你想要体验云效Insight 的敏捷项目度量场景报表，点击下方链接，前往云效Insight 即可「免费试用」。

https://www.aliyun.com/product/yunxiao/insight?channel=yy_yc