一周技术学习笔记(第72期)-研发效能真的是一笔糊涂账吗

我在互联网从业了好多年，也在企业软件行业待过几年，期间经历了jdk版本的更替，也经历了Struts1到Struts2到webwork，还经历了hibernate到ibatis到mybatis，经历了好多类似这样的技术组件的版本升级。

但是这些仅限技术中间件层面的，更让我有感触的是下面这些变迁。

从最初的瀑布研发流程、敏捷到精益，从持续集成、持续发布到持续部署，从实体机、虚拟机到Docker，从本地机器、数据中心到云上部署，从单体应用、微服务再到无服务应用，新的工具、方法层出不穷。

无论是技术层面的变迁升级，还是软件工程或者流程上的变迁升级，它们都只有一个目的：让开发变快。

但是你怎么度量变快。

软件开发是一种高度创造性的活动。

软件开发的灵活性决定了研发效能提升的困难性。

开发的过程中，有了创造性和灵活性的“加持”，想度量它非常困难。

而且是出了名的困难，你听到过哪家互联网公司声称自己有完美的度量研发效能的方法了吗。

似乎没有。

甚至，比如像马丁·福勒等这样的很多软件行业的顶尖大牛都发表过，研发效能不可度量的观点。

可是，人们不愿放弃。

因为，能度量就好管理。

管理学大师彼得·德鲁克曾经说过：“一个事物，你如果无法度量它，就无法管理它。”

研发效能是不是一个事物，显然是。

那我们能不能度量研发效能，如果不能，按照德鲁克所说，我们就没有办法管理研发效能。我不知道哪个团队好，哪个人好。是这样吗。

不过，在《高效研发：硅谷研发效能方法与实践》书中还是举了一个正面的案例。

有一个在进行前后端开发的小组，他们对过去的开发工时进行复盘。发现研发耗时如下：

开发耗时1周；

联调耗时1周；

测试、发布耗时1周；

复盘中分析出来联调耗时1周的原因是，前后端沟通成本太大，接着分析根本原因是前端没有mock服务来使用，于是后来开发了mock service，这样在制定好每一个API之后前端就可以很顺利的进行局部调试，前端和后端之间的沟通语言也变成了API。

之后，研发耗时就变成了如下：

定义和生成mock service耗时1天；

开发耗时1周；

联调耗时1天；

测试、发布耗时3天；

这样就带了”所见即所得“的价值体现，如果以后我们去推广mock service数量这个指标，大家会立马有感觉。

文章刚开始的时候我们提到了创造性、灵活性的两个特点。虽然只有两点，但足以让研发效能度量的难度变成无限大。

1、几乎任何你能想到的指标（比如调测过的代码行数、功能点个数、命令行参数个数）都很容易被“做数字”；

2、我们极少要求两个程序员做完全相同的事情，所以很难获取大型项目的有价值度量数据作为参考

更为”要命“的是，有时候我们为了强推一些度量指标，从而将这些指标跟研发人员的利益绑定，那么研发人员肯定会通过做数据的方式来欺骗度量，欺骗组织。

如果不做绩效绑定，可以想着从用户价值的思考角度出发，比如实现一个效能指标，会带来直观的用户价值是什么，比如上面的联调工时减少。这样一来，研发人员就会有类似”所见即所得“的感受。但是，仍然困难，效能指标度量的是软件产品的生产过程质量，用户价值所体现的是软件产品能否解决用户的实际问题。而这两者之间很难关联。

技术产品输出和用户价值输出之间的沟壑难以打通。

那么最后研发效能是一笔糊涂账吗，我们大概可以做到“尽量公平的主观衡量”。在尽量创造客观的条件下让管理者充分发挥主观性。

参考资料：

《高效研发：硅谷研发效能方法与实践》

----END----

这里记录，我每周碰到的，或想到的，引起触动，或感动的，事物的思考及笔记。不见得都对，但开始思考记录总是好的。