基于需求产出进行效能度量的探索

 什么是研发效能？
“团队失控了，根本无法控制需求的完成时间，总是一拖再拖，一直在加班，效果也不明显”
“开发速度倒是挺快的，但做完一堆bug要改，质量非常差，影响上线时间，结果还是不尽如人意”
“团队还可以，需求基本都能完成，但总是感觉团队的产出就跟沾了水的海绵一样，压一压还是能压出水出来”

这些都是关于研发效能大家日常感受比较深刻的一些场景，效能最直接的感受就是团队的产出，也就是吞吐量，那这个产出或者吞吐量该如何度量并具象化的表现出来呢？敏捷方法论通过故事点以及燃尽图来展示敏捷团队的开发速率，kanban方法通过限制在制品数量来可视化的展现阻塞团队产出的问题点，传统的软件学方法甚至使用过代码行数来衡量产出，等等还有其他衡量软件产出的方法。这里我们可以看到的是不同方法论用各自的方法来度量或者展示团队的产出，这里并没有对错之分，只有适用的场景以及要解决问题的不同。 

很多同学可能会对用代码行数衡量产出嗤之以鼻，但如果举个例子如上图：一般操作系统的代码行数差不多是在千万的级别，但有些整车软件的代码在亿级别，这个数据会不会还是让不少同学觉得有点意外。

如何衡量大型研发团队的开发速率

回归效能的讨论，对于敏捷团队本身，其实燃尽图已经能比较好的衡量团队的开发速率了，但如果我们将这个效能扩展到更大范围内的技术研发中心，比如公司的技术研发团队接近四五百人，如何去衡量这个接近四五百人研发团队的开发速率是否有所提升？ 

对于技术研发职能部门效能度量的建立，我们从比较传统的工作时间角度来思考，最直观的想法是技术研发部门有多少人P，每个人每天有效工作时间是h, 那 应该是部门每天能够产出的最大工作时间。

基于这个思路来看效能提升的话，似乎提升效能的方法就是增加招聘人数，以及提升每天的有效工作时间（加班996并且不容许带薪拉屎），这个有非常明显的缺陷。

技术研发职能部门的产出，实际交付的一批一批commit的代码，这些代码组合成一个一个的功能，这些功能串联组合起来满足了各种各样的需求，从这个角度来看，从需求角度来看技术产出更加合理一些。

从需求角度来看产研产出，有两个关键的指标，一个是需求的吞吐量，一个是需求的响应时间，如果为了度量效能的变化那还一定要有一个周期的概念。到此我们可以再看结合周期来看这两个指标，一个是一定周期内完成需求的个数N（吞吐量），另外一个是周期内需求完成的响应时间h（响应时间），其实就是这个团队真正对需求产出有贡献的总的有效产出，虽然结果算出来仍然是个时间的概念，这里的时间跟基于人数算出的时间有本质的区别. 可以预见的是一定是小于或者等于同周期时间内计算的*C（周期）。

当然从需求角度来度量一定周期内的产出的时候，还会碰到一些问题，比如这个周期需求完成标准是什么，是开发完成，测试完成，还是需要发布完成，对于完成度是一半的需求应该要按照比例折算到本次周期还是算入下个周期，这个问题其实跟敏捷迭代结束时对于完成定义时碰到的问题是一样的，自己敏捷组迭代是如何定义这些问题的，我们这里也可以参考。

接下来，我们看对于从需求角度看效能提升，有哪些事情可以进行操作提升效能？增加能够完成的需求个数，这个其实就是预期希望能够将需求拆的尽量细一些，小一些，能够在一定周期内完成，看上去跟我们MVP的思路有些一致。降低单个需求的响应时间，除了因为需求量变小自然降低需求响应时间外，完善协作流程，提高开发质量，提升自动化测试覆盖率，实施CICD等等都可以有效的降低需求响应时间。需求维度看效能提升，貌似有更多可以做的事情。

衡量大型研发团队开发速率的探索

再回到最初我们碰到的问题，如何去衡量接近四五百人研发团队的开发速率？

既然已经有了从需求维度来度量团队的产出，那能否将这个概念应用来解决上面这个问题，在应用之前，先将这个模型在小范围实验。我们在酷家乐定制业务线选取迭代周期一致的两个敏捷组，将这两个敏捷组看成一个整体来衡量它的效能数据：

基础数据是通过系统拿到的，如底下例子，我们设置了resolution time定制化字段，记录需求从创建到关闭的流转时间，以此作为需求的响应时间，其中数据是以分钟作为度量单位：

汇总两个敏捷组数据，之后进行统计计算后得出的数据如下：

我们统计了接近一个Q五个迭代的数据，汇总得出这两个敏捷组基本稳定的产出时间在3w min左右这个级别，其中第四个迭代周期出现了时间突增的情况，这个其实是因为需求都堆积到迭代结束才关闭造成的，不能计入有效的数据内，但通过这样一个趋势图，大致能够显现的展示出这两个敏捷组作为一个整体在效能上的数据情况。这里需要明确的是，统计数据更多的是同一团队不同周期内通过调整不同参数，比如（实施流程优化，增加CICD等）调整后通过数据印证调整的结果，可视化而非感性的评判团队的效能情况。当然，我们也需要了解，数据受到很多因素的影响，比如我们这个例子中的需求关闭时间，工具操作习惯等，但对于一个整体的团队，在非外界刺激下，我们认为这些影响数据的因素在多个周期内应该大致是稳定，在这个假设情况下，通过数据来可视化的展示出当前团队的效能情况，并基于这样的数据基线来印证实施不同效能措施后的结果。

我们拿另外一个数据做对比2个敏捷组共计16.5人， 16.5（人）X8（小时）X10（周期天）X60（分钟） = 79200min。

团队能够物理投入的时间是79200min，实际在需求上的时间是30000min左右，这两个数据直接直接相比其实并没有什么意义，但另外一个侧面可以看出来，对于软件研发类的效能度量是绝对不能用物理投入时间来计量。

经过将两个敏捷组组合成一个整体来看需求上的投入时间，可以得出两个有价值的结论：第一个是这个整体团队在2周这样的周期内平均效能大概在3w min左右。第二个是这个3w min可以作为一个效能基线，可以用来衡量各种效能提升措施的效果。

至此，从需求维度来衡量团队的效能，似乎是可以行得通的。再回到最初的问题，能否用这个数据衡量四五百人研发团队的效能呢？看起来答案应该是可以的！

总结

通过小范围将两个不直接相关的敏捷组作为一个整体来度量，统计一定周期范围内的需求完成数据，经过连续几个周期数据的累计，我们基本可以看到数据还是呈现出一定稳定的情况，这个也是从需求完成角度度量团队的效能数据。如果将这个概念扩展下，其实并不要求敏捷组的周期一定是一致的，只要确定一个统计周期，在这个周期内将各个敏捷组在这个周期内具备DOD的需求完成数据汇总起来，随后在后续连续的周期继续统计这个数据，就可以获取到固定统计周期内任意多个敏捷组作为一个整体的效能数据。这个数据就可以作为这个团队整体的效能基线。

下来我们看采用这种方式统计效能数据的优势是什么。

优势：

1. 能够组合任意多个敏捷组，最小可以是一个敏捷组，最多可以覆盖整个技术研发中心的N个敏捷组；

2. 统计周期灵活，并且不要求所参与统计的敏捷组迭代周期一致，建议3到4周作为一个统计周期。太短的话统计成本过高，太久会使得效能数据受到外部因素影响偏差过大（比如人员变更，组织结构调整等）；

劣势：

1. 需要定制化的项目管理工具支持。我们需要获取到统计周期内每一个需求启动到完成的时间，覆盖的敏捷组越多，需要统计的数据量越大，所以一定需要工具来完成这个数据的积累而非手工；

2. 因为是汇总团队消耗在需求上的时间，而非最终交付内容产生的业务价值，所以只能作为团队在功能产出上的时间成本，无法与最终业务产出联系起来；

最后，我们建立效能度量数据的主要目的在于度量团队的产出，明确效能基线，并能够通过调整影响产出的方方面面从而提升效能。这里需要特别明确的是，效能提升的衡量标准一定是对同一团队在不同周期内的衡量，而不能用在同一周期内不同团队的衡量，并且因为数据受到非常多因素的影响，我们需要关注的不是这个数据的具体数值，而是环比的周期变化。