摘要： 我们要利用数据，不要被数据所利用。
作者：石磊，阿里巴巴产品专家，2014年加入阿里巴巴，负责过阿里巴巴测试平台Kelude，持续集成服务引擎CISE，阿里巴巴研发协同平台Aone以及阿里云云效率等产品， 对研发协同、测试、交付、效能度量领域都有很深的见解。
背景
如何提升组织效率一直是阿里巴巴追求的目标之一,云效作为企业一站式协同研发云，积累了丰富的研发活动相关数据，如何利用这些数据，来助力于组织的研发效能提升，也是企业一直思考的问题。从2016年开始，云效（在阿里内部叫Aone）就开始逐步的对组织的研发数据，从团队，组织，项目等各个维度，按照研发实践流程进行改进的思路，结合了敏捷和过程改进的理念，逐步沉淀出云效的度量产品。并且真实的在不少阿里的团队，通过数据驱动的方式，辅助了团队效能提升。
1. 效能度量的基本思路和理念
1.1 如何透明研发效能 - 主观预测 VS 确定分析
云效度量产品的基本思路是: 透明研发效能,诊断研发瓶颈，辅助研发提效。 就像医生看病，首先得找到问题，才能解决问题。
我们追求的高效研发： 更好的质量，更短的交付周期，更高的效率，更准的承诺兑现。但往往我们都很难去定量的描述，我们的质量，效率，交付到底如何。 所以，就像一个镜子一样，将研发效能透明出来，通过数据化的方式来定性的分析，是我们研发效能提升的第一步，也是最重要的一步。
通过数据化的手段，可以让我们从主观的预测转变成确定性分析。 那哪些指标对于我们定性的去分析是非常有效的指标呢？
1.2 有效的研发度量指标 - 质量，效率，进度，人员
我们从度量的需求中会把指标分为4各大类：质量，效率，进度，人员。
（1）需求的吞吐量 – 大体反应出团队的产出趋势。
（2）需求的平均完成时长 - 需求从创建到终态的平均时长，时间越多，需求交付粒度越小效率越高。
（3）新增缺陷的数量 - 统计时间段内团队被新增指派的缺陷数量，结合存量缺陷以及缺陷平均解决时长，反应团队产品的质量以及对于缺陷解决的效率。
（4）缺陷的平均解决时长 - 缺陷从创建到解决的平均时长，表征解决缺陷的效率。
（5）线上发布的成功率 - 线上发布成功次数与总次数之比，越高证明产品上线质量越高。
（6）缺陷的reopen率 - 缺陷被reopen的次数与缺陷数目之比，该值越高证明修复缺陷的质量越差，reopen率是表征产品质量的一个重要指标。
2 怎么用数据 -- 一个案例分享
我们会用2016年张冠楠同学在阿里的某事业部内部通过Aone的度量产品推动效能提升的过程来给大家具体的介绍一下，拿到了这些数据，我们会怎么样去用数据来帮助我们分析瓶颈并找提升的关键的。
我们利用数据通常会有以下4个步骤：
1）通过团队效能趋势透明当前团队的效能现状
2） 通过具体的人员分析来定位效能瓶颈
3）针对具体的瓶颈给出改进策略
4) 通过持续的度量来确定是否改进生效
2.1 通过团队效能趋势透明当前团队的效能现状
阿里某研发团队，20+人问题：交付老Delay,团队士气不高，老加班，质量差。 让我们来看看当时他们的度量数据：
上面几张图比较容易看出来这个团队明显特征是
（1）3月份完成需求数明显上升，且团队负载较重
（2）质量不高 - 缺陷数、reopen率以及线上发布成功率
（3）需求平均完成时长特别长 ，很多需求都是很久之前的3月份才完成
（4）突增故障
2.2 通过具体的人员分析来定位效能瓶颈
带着数据，走进了团队，和团队一线研发人员进行访谈，也对整个数据中的具体数据去做了细分，我们可以看到整个团队存在的问题：
1）到底需求时间长，是卡在PD，还是开发还是测试？ 是否相应的团队可以去改进。
2）任务负载重，是否可以将任务分配更合理。 分配不均，单个人容易成为整个团队的瓶颈。
3）质量差，原因是什么？
通常这些瓶颈的定位是不能通过趋势来告诉我们，必须的深入到团队中，这个时候按照人员分布的度量报表就能方便的帮助我们定位到瓶颈人员。
2.3 针对具体的瓶颈给出改进策略
当我们发现了瓶颈和问题，就要针对性的进行改进。 具体的改进方法，敏捷有很多的实践，这里不做多阐述，文章的最后加了不少集团敏捷团队的最佳实践传送门，大家可以参考
2.4 通过持续的度量来确定是否改进生效
最后，我们要持续的关注度量数据来帮助我们进行跟踪，是否我们的改进能够真正的解决问题。 如果我们改进得体， 团队整体效率和质量提升必然会在度量数据上有所体现。
3. 关于数据的一些注意事项
3.1. 数据只是手段，是帮助我们去诊断，而不是衡量。
可能有的人会质疑，度量的数据是不是要去衡量一个人，其实，这个不是数据度量的目标，目标是找到我们怎么去做改进。所以轻易拿度量的数据来衡量人，尤其对于不同的团队和研发模式，其个人的研发数据往往会有较大的区别
3.2. 学会利用数据，不要被数据所利用
之前听云效的敏捷教练张迎辉分享在yahoo做的一个活动，为了调高研发质量，要求所有的研发必须在提交代码之前通过UT，结果就有的团队直接写空的UT，还有的无论UT是成功或者失败都直接在UT中返回成功。这个和数据度量是类似，如果大家都追求数据好看，肯定有各种方法把数据做好看，但是这不是我们所追求的，数据是面镜子，只是用来发现问题，所以，还是那句话，我们要利用数据，不要被数据所利用。
最后
数据驱动本质是数据，配套的工具支撑也会更加容易落地，云效的度量新功能也在云效公有云正式上线，是提供给大家方便使用数据进行驱动的工具。
扫码立即免费体验云效度量新功能