寻找合适的研发效能度量指标（上）

最近几年 “软件研发效能” 成了业界的热词 ，频繁出现在各个行业大会，被各大厂、传统行业数字化部门、追求高效能的团队不断的提及并迭代，比如阿里的效能改进211愿景，腾讯的智研平台，百度工程能力白皮书。

那么为什么软件研发效能会成为热词，有哪些合适的软件研发效能指标呢? 本文想尝试回答这两个问题。(本文是此系列的上篇，后续两篇将尝试构建一个根据团队上下文的软件研发效能推荐指标图表，和一些实际度量指标的案例。)

为什么软件研发效能会成为热词？

咱们先看看现有的问题， 与传统制造业相比，软件研发行业还很年轻，并没有达到传统行业的大规模流水线的生产方式，这解释了为什么没有一种统一的，被广泛认可的方法来衡量开发人员或研发小组的效能。研发效能的度量很大程度上取决于公司的类型，规模，文化，与之合作的项目类型以及其它诸多因素。 甚至某些小而精，依靠聪明才智和资深经验的创业团队，不用度量研发效能，团队依然非常高效。

很显然，10年前使用代码行数(Lines of code)来度量研发效能的方式已经不适用现代敏捷过程对软件研发的理解了。以前关注代码产出，而不是业务成果，以前关注个人绩效，而不是团队效能。例如: 随着公司和开发人员向着价值驱动和基于团队开发方向的转变，代码行数不再具有任何意义。100行代码是否比20行好？行数是否告诉你取得了良好的进展，还是只是一个没有上下文的抽象指标？软件企业都在寻求其它有效的指标来度量研发效能。

同时，如今的软件行业已经不再是“以大吃小”的时代了，而是转变成了“以快吃慢”的时代。对于很多大型软件企业、传统行业的数字化部门。原本“大”是优势，现在却陷入了“大船难掉头”的尴尬。如何破局？研发效能具体来讲就是从需求转化成软件或者服务的能力。改善研发效能从某种方面也在试图解决“大船难掉头”的尴尬。

研发效能试图在解决度量和让研发变快的问题，那为什么会成为热词? 为什么最近几年各大厂、传统行业数字化部门、追求高效能的团队，都纷纷开始在研发效能领域发力，我认为这背后的原因有以下四点：

• 从外部技术视角来看：研发效能的土壤和环境已经就绪，类似高速移动网络的普及为智能手机和