研发效能的本质不是代码行数，而是持续、刚猛地实现业务价值！

彭友们好，我是老彭啊。前两天，彭友会的一个小群里，讨论一个很深的的问题：数据团队的研发效能怎么管控？

这个问题还真不好解答。有些没经验的哥们会简单粗暴的设一个KPI，或者是单纯的写周报。

群里有个哥们说他们主管给的KPI是“代码行数”...唉，too naive too young啊~~~

要多写点代码，那还不简单...跟玩儿一样~~~把函数重写一遍、不考虑复用啥的就行了！一天给你造几万行你信不信？

研发效率公式

算了，扯回来。简单来说，效率可以是用这个公式表达：

研发效率=研发成果/研发投入时间

所以我们在工作中一定要对有效完成的结果做一个明确的衡量指标，什么样的结果才是我们要的有价值的结果，特别是刚刚开始做新的项目的时候特别的关键和重要。

群里之所以讨论这个问题，也是因为研发效能是目前互联网企业和传统软件企业都高度关注的领域：

一线互联网企业希望通过“研发效能”实现持续的研发能力提升以应对日趋复杂的产品开发；

腰部中型企业厂商则希望通过“研发效能”实现弯道超车，充分发挥后来者居上的优势；

更多中小企业看到国内一线互联网企业不约而同地在这个领域重点投入，纷纷也是摩拳擦掌准备在效能领域发力。

效能是衡量工作结果的尺度，效率、效果、效益是衡量效能的依据。效率强调资源的有效率利用，指以最小的投入，得到最大的产出，就是把事情做好。

而现在人力成本居高不下，已经是各大部门头疼的核心问题。所以，现在大家都把视线聚焦到高效能交付上，期望提升研发效率，降低成本，强化竞争力。

高效交付

我们如何看待高效交付？或者说研发效能的本质是什么？简单来说，可以从研发、用户和业务三个视角去拆解这个问题。

先放一张图镇楼：

1.首先，我们从研发自身的角度去看，不管是大型还是小型的组织，我们都认为去问公司里面的各个部分，各个职能或者各个部门或者每个人，大部分都会认为自己的效率不错，我写代码效率不错，我测试的效率不错，我需求设计的效率也不错。

但是这个判断，是从内部资源的角度去看待，我们称之为局部效率，每一个局部效率都很不错，这是研发内部资源的视角。

我把这称为“自嗨模式”，这肯定是不够的！因为你完全没有把真正的“用户”放在眼里啊！

2.现在我们换一下，从用户的视角进行观察，看到的就是另外一回事：

用户希望开发团队能高效、持续地交付，实现业务需求，解决业务问题。在这个视角，用户感知是不一样的：局部效率≠高效的交付。

我们作为一个组织，是不是能把各个局部的效率转化为高效的交付，这是研发效能面临的第一个问题，当然这里面涉及我们协作怎么样？我们中间过程质量怎么样？是不是很多返工？

开发最喜欢做的事情就是“集中开发”、“敏捷开发”、“封闭开发”，用极短的时间去解决一些难题。但是做过开发的彭友们都知道，这种形式，刚猛有余，但是持久不足啊！

用户就像鞋柜里永远少一双鞋的女人，不但现在就要，以后也得要！因此，高效交付还得加上持续交付！

3.OK，假设，我们已经全部满足了，既刚猛，又持久，把我们内外部用户伺候的丝滑无比，我们是不是已经无敌了？

NONONO！

回去看看上图中最上面的一条：业务成功。

我们现在要再切换一个视角：业务视角，或者价值视角。也许我们一直在努力地建设，但是如同在数码相机的时代，仍然钻研胶片相机一样，你的技术也许无法在这个市场创造任何价值：

无法解决终端用户的问题，无法帮助公司占领市场，无法构建起一个可以持续的商业模式。

那么，无论你所谓的“研发效能”有多厉害，那都没有意义。

小结

所以高效研发效能的本质，其实就是：

1、我们希望局部分效率可以带来高效的交付，为此我们要最小化这其中的过程的浪费，不管是互相的等待，互相协作的绩效，或者是过程中的返工，我们要最小化过程的浪费达到的目的是顺畅高质量的交付；

2、我们希望高效交付能够带来持续的高效，这就是持续的效能提升，不管是工程的还是技术的，保障我们持续效能的提升，所以我们在下面的这句话上面再加上持续的顺畅高质量的交付；

3、我们希望高效的交付带来业务的成功，为此我们要最大化用户的价值或者我们业务的价值。

通过解决“局部效率≠高效交付”、“持续高效≠高效交付”、“业务成功≠高效交付”这三个不等于的问题，最终带来的是持续地、顺畅高质量地、实现有效价值的高效研发效能。

简单来说，就是刚猛、持久地不断满足终端用户的需求！