阅读本文你将收获：
1、研发效能度量有哪些误区和坑点？
2、如何构建研发效能度量的 MVP 框架
3、MVP 方法应用实例及原则
研发效能度量有哪些坑点？
谈到研效度量，理想和现实的状态可能会有一些差距。我们期待的度量是灵活、可靠、端到端、高大上的；而现实中却通常是受限、低效、噪音大、体验差的。古德哈特定律、眼镜蛇效应也证明了不恰当的度量体系会带来怎样的负面牵引作用。在复杂的场景和协作中，研发效能的度量也更具挑战性，可能会遇见诸多坑点，我们将实践过程中常见的、高频的坑点进行了整理，总结出了盲目跟风、忽视特性、求大求全、简单陈列等坑点。
那么，在度量设计中该如何避免这些坑点呢？
避坑指南一：要目标驱动，不要盲目跟风
一定要采用目标驱动法，这里的 GQM 三层分析法是自上而下去定义指标的方法。
第一层我们要去确定目标，明晰我们的目标是什么，在实践中，这个“目标”也不必过于复杂，可以是战略目标，也可以是某一个部门的目标、某一个场景的目标。
第二层是基于特定的目标来提出问题，提出的问题应当能够对目标的达成情况进行衡量。第三层是定义度量指标，也就是选择确定能够回答问题的相应的度量指标。GQM 三层分析法自上而下是从确定目标、到提出问题、再到解决问题的过程，而自下而上是通过指标来解释目标的达成情况、进展情况的过程。
避坑指南二：要灵活取舍，不要忽视特性
在一个组织当中，指标的结构一定是需要不同维度的视角的，比如高层、中层、基层对于指标的需求是不一样的，不可能通过一套大而全的指标满足所有岗位的需求。所以，指标在具有关键核心的作用和效率质量的共性要求之外，也需要具有特性，以满足不同角色、不同业务、不同阶段的需求。
避坑指南三：要少而精，不要大而全
大而全带来的问题其实是非常多的，我们在生活中、实践中通常是在做加法，通过增加某个新功能来实现产品的更新，虽然这种加法是很容易实现的，但需要注意的是，一旦做加法变得庞杂了，那么则容易导致效率较低。所以我们在进行度量指标的设计时，需要思考如何合理地做减法。
这里我们引入奥卡姆剃刀原理——“如无必要，勿增实体”，也就是尽量用简洁的方法去实现目标，我们增加的活动、文档、指标都应当具有相应的价值，解答关键问题。同时我们也要考量获取指标的成本和度量带来的收益哪个更高，从而做出合理而精细的操作。
避坑指南四：要建立标尺，提示异常，不要简单陈列
这里的两张图都显示了产能增长的走势，右图看似简洁，但通过这张图得到的结论很少，无法解答走势斜率是否健康这样的问题；而左图给出了行业对比的标尺，能够洞察到有效的信息，从而起到提示异常的作用。
如何构建研发效能度量的 MVP？
度量体系是产品而不是项目
很多公司会把度量体系当作一个项目来做，而其实度量体系的设计不是一个项目，它是一个需要不断演化、迭代更新的产品。度量体系设计的核心原则是：从最终用户可见的价值内核开始，进行持续迭代。
研发效能度量 MVP 版本的构建框架
关于研发效能度量 MVP 版本的构建框架，这里我们给出了一个模型。它包含目标驱动、构建原型、获取反馈、迭代演进四个关键动作。目标驱动的意义在于选出最核心的指标，构建原型则是使用低成本的方式来展现它，通过这样的设计：
第一可以清晰地梳理度量设计者的思路，
第二用可视化的方式交付能够与业务方、数据消费者建立起一致的认知。同时有了这样的原型和设计思路，我们也可以快速获取短周期反馈，进而实现迭代演进。
MVP 方法应用实例及原则
实例背景
实例公司背景情况如下，包含17个业务部门，业务差异较大，代码仓库9000+，研发工具数据分布于不同的工具、平台，项目模式有敏捷有瀑布相对复杂。
这样一个环境复杂的组织使用思码逸产品的主要诉求有三个：
·借助代码当量，打开开发黑盒，建立满足研发效能管理需求的度量体系。
·为不同角色提供数据抓手，判断现状，识别异常。
·部门生产压力大，聚焦做真正有价值的事情。
基于此，思码逸采取的措施是：
- 为研发效能管理提供数据抓手
- 建立各部门北极星指标
- 快速落地、闭环验证
MVP 度量版本实现的 5 步法
Step 1：挖需求
通过深度访谈，挖掘管理痛点，聚焦核心需求。在深度访谈环节，会进行设计和筛选，选出不同的角色视角、不同的特性团队作为访谈对象。同时，我们基于所有的业务部门分析了业务特征，发现这么多业务部门的典型特征其实可以总结为三大类：产研团队、实施交付中心、资源中心（为各个项目调配人力，调控资源的合理流动）。基于此，我们可以将访谈限定一个范围，不需要去做大而全的访谈，而是聚焦重点，确定核心诉求。在访谈问题的设计方面，我们也会设计开放性问题和封闭性问题不同类型，以满足个性化需求。为了获取到关键的信息，我们会在访谈中引导访谈对象进行关键的思考：1.思考最重要的三个需求是什么？2.需求背后的动机是什么？。从而顺利挖掘到核心需求。
Step 2：做减法
MVP 是最小可行化产品，那么我们也要对关键问题进行思考：首先是哪些需求具有导向性，其次是哪些场景是信息及管理需求的最小集。
从角色维度看，部门经理：关注哪些要素
从场景维度看，不同部门的关注点也是不一样的，比如资源中心关注工作饱和度、产研团队关注效率、实施部门关注的更多的是质量。
在关键角色、关键场景这些信息的基础上，我们可以尝试去定义指标，使用哪些指标来回答场景的问题。
Step 3：建原型
在建原型这一步骤，我们将部门经理仪表盘进行了图形化的设计，在这个设计当中，我们可以看到仪表盘包含工作饱和度、效率和质量三大部分。在工作饱和度方面，采用代码活跃度和投入产出比两个指标来去回答工作是否饱和，人力资源是否冗余以及我们在开发过程中是否存在空闲和等待的情况；对于效率，我们采用人均生产率，也就是人均的产出情况进行衡量，从而对交付结果进行预测。在质量方面，我们看代码发版质量和代码内建质量两个关键指标。
同时，这个仪表盘的设计也需要回答两个关键思考：
- 价值和结果是否做到可视化了？
- 是否提供了识别问题、判断结果的标尺？
Step 4：听反馈
首先，当业务方看到我们的指标设计时，是否能够得到想要的结论；其次是，当业务方看到视图时，是否还需要更多的上下文的解释来理解指标和指示器，以及视图能否为其数据的抓取和价值的获取提供结论。
Step 5：做优化
MVP 构建的第五步则是根据用户的体验和反馈进行优化，以终为始。
在线客服.png)
