最近在这方面思考了下，有一点想法，马克下来。

度量和直接开做的选择：

效能提升实践两条路径：

• 梳理价值流->度量->发现瓶颈->识别改进方向->引入改进实践
• 梳理价值流->快速发现很可能的瓶颈->引入改进实践

第一种方式更系统，特别是对于一个有一定的基础的团队，常见的先进一些的互联网公司的团队，或者对于一个整个公司级的改进，这种情况下，我们无法很快的发现真正的瓶颈，那就用度量数据来说话。（见注2，避免陷入陷阱）

比如某集团从CTO角度要做效能提升，此时我们需要数据支撑说明现状和改进方向，而每个团队的瓶颈点可能不一样，即使是教练走访团队，虽然能发现一些瓶颈，但是缺少数据的情况下，光依靠交流，得出的结论不够严谨，另外就是太慢了。如果先搭建度量体系的话，那么面对上百个团队，可以很快得出结论。

第二种方式更快，适合基础弱一些的团队，他们的最大瓶颈很明显，或者没有合适的度量体系的团队（合适的度量体系见注解1）

比如我们给一个小团队做辅导，或者去一些小型公司辅导，我会粗暴的通过交流+看一些他们仅有的基础信息（比如jira上的报告，git上的记录等），给一些意见，此时客户不可能给你时间搭建度量体系。

 比如他的测试周期比较长，没有自动化测试导致回归测试一塌糊涂，那这瓶颈就很明显。

注1：度量体系没有拿来主义，创建度量模型，度量数据，度量体系需要较长的时间和技术基础，比如数据需要自动化获取就需要技术作基础，度量模型又需要基于公司业务模式创立，并且面对的团队，往往他们的开发方式差不太多，比如硬件开发和软件开发，价值流差很多，用同一个度量模型就不合适，即使是在同一家公司，对于这种情况，也要有不同的度量模型，确保度量模型适合你的团队。

注2：比较赞同何免老师在云效对外的讲解里的说法，不能为了度量而度量，否则就陷入了Good-heart陷阱。度量的目的，是为了解决核心问题。比如说，我们对产品质量比较看重，想知道产品当前质量如何，哪里需要改进，那这就是我们的核心问题，为了这个目的，我们思考了下质量体现在哪里，比如说线上缺陷密度，变更成功率，此时可以以这个指标作为结果指标，通过它来看我们的核心问题的结果如何。