老板天天要效率，效率如何衡量？90%的人都理解错了

在很多公司发现一个共同的现象：老板要求提高效率，但是，效率到底是指的哪些，如何衡量？却没有定义。提高效率虽然进入了每个人的意识，弥漫在空气中，形成一种凝重的气氛，但是如果没有定义如何衡量效率，改进效率也就无从下手。

1、如何度量效率

现代管理学大师彼得·德鲁克曾说过：“如果你不能衡量它，就不能管理它”。

效率度量分为价值交付效率度量和工程效率度量。价值交付度量是以交付的价值为单位度量，帮助团队判断价值交付过程中的问题，及时采取管理措施纠正。但是，价值交付效率并不能告诉团队工程效率有多快。比如，团队在回顾会议上总结到，我们这个迭代有两个用户故事没有完成测试，导致无法交付，我们需要提高测试自动化的程度。但是我们现在的自动化效率是多少？我们需要提高到多少？如何判断自动化的投资是否达到预期效果？这些都需要工程效率度量来解决。

2、价值交付效率

价值交付效率的首要度量是周期时间（Lead Time），即从一个Idea提出起，到交付上线给用户使用为止的时间长度。这个时间是用户可以感知到的时间，时间越短，对用户的感受越好。

精益生产系统之父大野耐一曾经说过：“我们所做的一切，就是关注从客户给我们订单的时候起，到我们卖出钱为止的整个周期内，通过消除不增值的浪费，持续缩短交付周期。”

从客户价值的角度度量时间，这是很多团队没有具备但是必须具备的视角。客户关注的正是从一个他提出所面临的一个问题起，到解决方案交付给他为主的时间有多快。任何产品和服务本质上都是解决客户的某个问题。

周期时间不仅反应了价值交付效率，也反映了对客户的响应速度。当我们洞察到一个新机会，需要多久把机会转化为解决方案，并投放到市场上，这个时间越短，组织在市场上的竞争力越强。在瞬息万变的数字时代，组织的响应力有时候比效率更加重要。

除此之外的价值效率度量，都为辅助度量手段，比如：团队的交付速率。交付速率指的是团队对一个迭代周期里完成的工作的度量，单位可以是用户故事的点数，或者是用户故事的数量。一个迭代结束的时候，团队应该统计实际完成的速率与计划的速率的对比，并且对没完成的用户故事做回顾，需要采取什么改进措施，如下图所示。

相对于价值交付周期，交付速率之所以次要，是因为用户或客户在意的不是一段时间内产品上了多少功能，而是关注他所期待解决的问题有多快被解决。一个版本你交付了上百、上千个功能，但是如果不是用户所期待的，那么对用户也没什么卵用。
但是遗憾的是，笔者所看到的很多管理者，仍旧是从企业的内部视角看效率，即：仍旧关注的是团队产出的功能的量，而不是从外部视角看效率，即：客户所关注的高价值的功能的交付周期。

3、工程效率度量

工程效率度量没有标准的定义，各个企业依据自己的需要定义。一般来说，常用的工程效率度量有以下几种:

(1) 编译效率

编译效率一般用开发人员从启动个人构建，到获得构建结果反馈的时间来度量，包括的活动有：代码提交+编译连接+静态检查+单元测试。

(2) 版本构建效率

版本构建效率一般用从启动版本构建到获得可运行版本的时间来度量，包括的活动有：版本编译+静态检查+冒烟测试。

(3) 回归验证效率

回归验证效率一般用完成一轮产品回归验证所需的时间来度量，即：迭代内修改了旧代码后，重新进入测试以确认修改没有引入新的错误，或导致其他代码产生错误的一轮测试时间。回顾验证包括手工和自动化测试，但是应该尽量全自动化测试，手工的回归验证无法满足频繁发布的要求。

(4) 全量功能验证效率

全量功能验证效率一般用覆盖版本已开发特性的全部功能测试用例的一轮测试执行时间，包括手工和自动化测试，自动化测试的程度越高越好。

(5) 非功能性验证效率

依据产品的测试计划，有些版本需要开展性能测试、安全测试、压力测试等非功能性测试。这些测试需要用专业的工具完成，经常是模拟大数据量、模拟长时间运行的测试，因此，非能性验证效率成为测试效率的重要部分。

案例：

下表是某互联网企业定义的研发效率提升的度量项和提升目标：

指标项	目标
开发者编译构建时间	1-3分钟
版本集成时间	10-15分钟
回归测试时间	1-2小时
全量回归测试时间	1天
特性平均周期时间（Lead Time）	3-5天