阅读本文你将收获：
1、为什么要做研发效能分析？
2、怎么分析研发效能，效能分析模型方法论是什么？
3、研发效能分析有哪些需要注意的误区
作者简介
熊玉辉，10余年互联网测试开发与质量管理经验。曾就职于腾讯，带领团队进行DevOps实践，致力于软件工程效能提升。在移动端自动化测试、工具平台建设、研发效能度量等领域有非常丰富的经验，多次在MTSC、TICA等行业大会上进行专题分享。2020年加入快手，现任快手多媒体质效中心快影质量负责人，负责团队质量与研发效能度量建设，旨在通过合理的研发效能度量驱动研发效能提升。
本文来源：熊玉辉老师的研发效能系列文章，本文全篇收录于QECon组委会发布的白皮书之《研发效能实践指南》
研发效能分析概述
建立一套完备的研发效能度量指标体系是研发效能提升实践的第一步。如果不针对这些指标采集到的数据进行分析，那就无法做到研发效能度量闭环，那么指标体系也就毫无意义。从指标数据中提取出关键信息，找出研发效能改进项的这一过程，就是研发效能分析。
针对指标体系建立研发效能度量分析模型，进行系统性的分析问题，避免陷于“数字游戏”、“反映部分事实”等困境，是研发效能分析最重要的价值所在。研发效能分析在整个研发效能改进闭环中占据非常重要的一环。
研发效能分析模型
研发效能分析模型，是指如何对研发效能问题进行分析的一系列方法论的表达。在讨论分析模型之前，先回到研发效能分析最初始的问题：研发效能是否有提升？研发效能问题在哪？所以在研发效能分析时也常常分两步走：
●第一步：定性分析——利用研发效能判定表，判定研发效能度量周期内研发效能是否有提升
●第二步：定量分析——如果研发效能有提升，则利用本指南推荐的分析方法找到哪些措施有优化效果；如果研发效能有下降或者持平，则利用各类分析方法找到问题所在，规划下一步改进措施
图1：研发效能分析模型示意图
研发效能诊断分析
研发效能判定表
有效的研发效能提升，可以拆分为3个目标：
●在不降低交付质量的前提下，增加单位研发成本的交付价值。若仅考虑人力成本的情况下，简单可以理解为“需求吞吐量/人力”
●在不降低交付质量和需求吞吐量的前提下，降低单位交付价值的交付时长，即降低需求交付周期和线上问题修复时长
●在保持单位研发成本的交付价值不变的情况下，提升交付质量根据以上拆解，下面举例给出“研发效能提升是否有效”的简单判定表
趋势分析
从研发效能判定表中可以看到，各个维度的阐述都是用趋势变化来代替绝对值。通过观察某一指标按照固定周期的变化趋势，更容易帮助我们发现问题。
图2：举例—线上缺陷修复时长趋势分析
上图是某业务线上缺陷修复时长在2021年1月～2021年10月的趋势图。可以看到，从2021年2月～ 2021 年 6月份之间，线上缺陷修复时长随着时间的推移，持续处于上升趋势，即缺陷修复越来越慢。其实在进行研发效能度量分析之前，客服团队曾说过他们主观感觉到最近线上问题解决变慢，因为他们需要不停地推进和询问问题解决进展，给客服工作带来了难度。
从上面的趋势图，可以看出客观数据与客服团队的主观感受是一致的。 最后经过系统的问题分析，团队从7月份开始进行了干预与改进优化。从上图也可以明显看到线上缺陷修复时长持续下降。此外，即使是同一个公司，也会有多种业务类型。业务类型不同，团队的状态也不同。如果对研发效能度量指标进行绝对值的横向比较，往往会造成所谓的“不公平”，也很难令人信服。所以纵向分析对比，观察研发效能度量指标随时间的变化趋势更有意义。
研发效能优化/问题分析
在做研发效能分析汇报的时候，常见的情况是，我们给出了研发效能提升目标达成or未达成的结论性判断。但是再往进一步，老板问是什么原因造成这样的变化？很多人往往无法非常自信地给出确切、肯定的回答，这时候就需要对数据进行深入挖掘了。常见的研发效能优化/问题分析方法有：
●逻辑树分析
●下钻分析
●相关性分析
逻辑树分析
逻辑树又称为问题数，演绎树或者分解树，是麦肯锡公司提出的分析问题、解决问题的重要方法。它的形态像一颗树，把已知的问题比作树干，然后考虑哪些问题或者任务与已知问题有关，将这些问题或子任务比作逻辑树的树枝，逐步列出所有与已知问题相关联的问题。这非常适合研发效能分析。
我们常常使用“鱼骨图”来辅助进行逻辑树分析。举例下图就是针对“需求交付周期上升”的一个拆解分析过程，将“需求交付周期”映射为 相关联的各项过程指标中去
图3：需求交付周期持续上升逻辑树分析举例
下钻分析
下钻分析，其实是逻辑树分析的一种。下钻的思路需要遵循从宏观到微观、一层层往下细分的逻辑，它可以帮助我们从表象到根因逐层排查问题，找到影响研发效能的瓶颈点。下钻的维度有非常多种，常见的研发效能下钻分析包括：
●按时间维度下钻（针对价值类与质量类指标）：在实际研发效能度量过程中，研发效能指标数据在往往是波动的。在一个大的时间范围内没有变化，不代表更小时间维度没有变化。研发效能度量分析也经常按（周/月/季）甚至更长时间去进行进行上一周期和本周期的对比。
●按研发阶段下钻（针对交付周期类指标）：如果研发部门被业务部门抱怨说交付速度太慢，第一反应很可能是：再多招聘一些开发人员吧！但有可能是交付流程中其他因素，限制了全局流动效率的潜能。但这个约束具体是在哪个阶段，就需要我们根据研发阶段进行下钻进行分析。如下图所示：整个需求交付周期13.4天，在需求完成后的集成发布周期就花费了7天多。从这里我们就可以将“如何降低集成发布时长”作为优化方向了
图4：需求交付周期下钻分析举例
●按任务类型下钻（针对价值类与质量类指标）：在实际研发生产活动中，研发工作基本可以概括为三类：业务需求开发、技术需求（技术债和主动技术升级）和线上问题闭环。业务需求、技术需求与线上问题在研发流程、技术难度与复杂度上都有较大差异，各项研发效能指标的基准线也肯定不一样。因此在研发效能度量分析实战中，也可以将“业务需求开发、技术需求、线上问题闭环”任务类型作为一个下钻维度来分析。
相关性分析
为什么要做相关性分析呢？那是因为研发效能本身就受到很多因素的影响，各个因素之间往往并不是我们想象的因果关系。比如说代码提交量、提交频率与部署频率之间是否有某种关联？部署频率与客户满意度之间又是否存在着某种关联？代码行数和代码质量到底有多大关联？代码质量的好坏与团队稳定性是否存在着某种联系？这都是“相关性分析”可以回答的问题。
我们可以针对大量的历史数据分出中这种相关性，然后通过实验的方式进行探索，找到能够切实驱动研发效能提升的因素进行持续干预。正如下图(1)所示这个案例中，可以对比看出“需求交付周期”到底与哪些指标是存在正相关性的，与哪些指标是存在负相关性的。对已被数据证明存在相关性的活动和过程指标实施干预。
但是也要注意，我们可以对比“量化数据”与“研发效能专家”的经验，对有出入的指标进行检视与反思，分析是实践无效还是数据失真导致的误判，并在下个周期中进一步增加实验进行持续探查。
图5：需求交付周期相关性分析举例(1)
研发效能分析的误区
●不要只罗列指标数据，要通过分析指标数据反映其背后的问题
●针对单一或单一类型指标进行分析，很容易陷入局部思维，
比如：为了提升提测质量，开发花很多时间自测，导致需求延期交付比上升。这种情况下就不能单看提测质量这一个指标，研发效能提升追求的是交付速度不下降的情况下提升自测质量。
●比起不同产品之间横向对比，更应该关注不同时间相同产品的纵向趋势分析
●没有什么研发效能度量指标体系一开始就是完美的。研发效能度量分析要注意持续性与连续性，不要做一次性研发效能度量分析，迭代归纳很重要。 归纳成果的目的是迭代优化研发效能度量体系，进行反思：○是否在向目标靠近○指标设计与定义是否合理，是否需要修正○改进路径是否有效
在线客服.png)
