上周六和云大一起聊了研发度量的那些事，最近几年也基本上都会在不同的团队以不同的角色去设计研发度量指标和模型，整理下自己的一些最新感受和想法。

关于度量指标的选取和度量体系的构建，当前已相当成熟，不再赘述，有兴趣的可以看下之前的相关文章，如研发效能度量指标的陷阱思考、度量平台落地实践等。这次聊了一些针对度量数据如何消费的感受。

01 度量的双刃：向内求己，对外伤人

一提起研发度量，大部分人的反馈就是非常抵触，造成这种现象的原因还是管理者对度量数据的使用不正确引起的，还有个底层的原因是，大部分人，都害怕透明。

其实，度量是中层管理团队非常好的一个抓手，它可以带来以下好处：

识别系统性风险：日常团队成员反馈的风险基本上都是点状的、零散的。通过有效的度量指标体系建设，可以很直观的发现团队存在的的系统性风险，如项目进度、瓶颈点及可能的风险项（累积流图就是个非常有效的报表）。

量化跟踪团队成员工作项：当团队成员超过 10 人时，管理者是很难清晰的知道每个成员的工作量及工作内容。通过度量体系，可以更好地反馈这些信息，方便进行资源整合和调配，并发现团队成员的亮点。

为团队改进做指导：通过构建度量体系，洞察、提升团队效率，制定改进方向。优化团队效率不等于裁员或者处罚成员，团队要提升，必然需要不断改进。度量能够提供对应的方向和数据支持。

以上优点，只有当管理者把度量当成团队改进时，才有用。但事情往往会往另一个方向发展，也就是度量可能带来的坏处，也是度理被大家抵触的原因：

是不是要裁我：突然的度量往往会引发恐慌，叠加现在的大环境，团队一定突然搞度量，大家就会因此生出别样的心思。所以需要管理者强调好度量的目标。

是不是要 PUA 我：是不是要根据指标做末尾淘汰？是不是想让我做更多的事？等等。提升效率不等于压榨员工，团队的效率核心是保持稳定，而不是极限压榨。

为了数据更好看，我要做些什么：不论度量指标如何设计，本质上都是数据，那都有造数的空间。当度量使用不当时，大家都尝试去造数据，让数据更好看。让管理者迷失在数据的洪流中，造成 “过程很好看，结果很意外” 的现象。

如标题所写，度量是把双刃剑：向内求己，对外伤人，它的实际效果取决于管理者对数据的使用态度。

02 不能只停留在结果数据，需要有过程数据分析支持

那么，如何更好地使用度量数据，减少 “伤人” 的情况发生呢，笔者有以下几点经验：

结果数据只是表现，需要过程数据洞察根因：比如提交的代码行数、千行代码缺陷率、生产问题逃逸率等，这些都是典型的结果指标。这些指标并不能直观的反馈个人的效率和质量。需要结合过程指标去分析可能的原因，比如：需求大小、复杂度、负责需求数等结合来看。

流程需要运营：度量指标的数据来源基本上都是基于系统自动采集的，但这并不意味着数据就是真实的。比如从数据上看，研发交付周期是 3 天，但是实际上其实远大于这个值，核心可能是大家都在需求快完成的时候，快速翻转状态引起的。所有的研发流程其实都需要运营和跟踪（有机会再展开说）。

多维评估而不是一刀切：不能根据某个指标，就判定某个成员不好，需要综合的评估指标的内在联系。需要有结果指标，更需要有过程指标来指导分析。同时指标体系建设也是个不断改善优化的过程，需要持续投入。

构建健康的团队梯度：不可能团队内所有人都是优秀的。通过度量指标，识别团队成员的不同分工和要求。更好的制定激励手段，也是度理指标的另一个意义。

数据消费本身也是一种能力，如何通过不同的指标组合，快速识别和分析问题，是每个管理者需要具备的能力，笔者之前也尝试过将数据分析能力做为模型固化下来，但是效果并不好。只能说千人千面，大家的经验不一样，看待同一些数据的敏感度也不一样。

03 对事不对人，让冲突出现好过被隐藏

所有的问题和风险并不会因为隐藏而被消除，只会爆发的更加激烈。在度量实践的过程中，有时候会设计一些不同角色之间的制衡指标（比如千行代码缺陷率和缺陷发现数，就是典型的开发、测试制衡指标，当然还有其它的）。笔者之前分析过此类现象，可以参考那些 “被消失” 的缺陷。

对于研发度量，笔者是保持支持态度的，通过透明团队的工作内容，识别系统性风险，还是利大于弊的。对于度量指标的使用，笔者建议只开放给中高层管理者，辅助日常团队管理即可，而非面向全员的 KPI 考核。不希望把度量当成一把砍向基层员工的 “利刃”。

共勉。