研发效能从来不是厂商包装出来的生意

上周跟几个在南京做研发的老伙计在软件大道边上吃鸭血粉丝，聊到最近公司要推研发效能平台，所有人第一反应都是“又要搞考核了”。

先把概念的遮羞布扯下来

很多人一提研发效能，第一反应就是买一堆流水线工具，算每个开发的代码提交数，bug数，需求交付周期。说白了，这些东西算出来的数，除了给领导做汇报PPT，对一线团队半毛钱用没有。

没人傻。

大家都知道怎么凑数。为了凑提交数，把本来一次能写完的代码拆成十次提交；为了缩短交付周期，把还没测完的功能先塞上线，后面再补补丁。代价是什么？线上故障变多，团队加班变多，真正能用来打磨核心功能的时间被挤得一点不剩。

我之前见过一个团队，一开始觉得研发效能低，是因为没有统一的CI/CD平台，花了大几十万买了商业工具，搭了三个月，把所有流水线迁过去。结果呢？开发本来本地写好代码点一下就能跑的流程，现在要过七八个卡点，填三个表单，等流水线跑完要二十分钟。团队的交付速度反而比之前慢了30%。

麻烦在于，大家一开始默认工具投入等于效能产出，从来没停下来问过，现在团队的效率瓶颈到底在哪？是代码合并冲突太多？是测试环境永远被占满？是产品需求天天变？还是跨团队对接的时候要等三天才能拿到接口权限？这些问题，买再贵的工具都解决不了。

真正的效能提升都是从抠细节开始的

我见过真正把研发效能做上去的团队，从来不是先上来买工具，而是先蹲在开发的工位旁边，记一周的时间开销。算下来，一个开发每天要花两个小时在等环境启动，一个小时在找各个团队要文档，四十分钟在跟测试对齐bug的复现步骤，剩下的时间才是写真正的业务代码。

那要提效能，先把这些碎时间抠出来。比如把测试环境做成一键拉起的，把所有接口文档统一存到一个大家都能找到的地方，把bug流转的流程从“开发提测-测试找开发-开发复现-改完再提测”改成测试直接在平台上拉取开发的本地调试环境。这些动作花不了多少钱，甚至不用买什么商业工具，就是几个开发抽点时间写点小脚本，搭个简单的内部页面，就能把每天两三个小时的无效时间省下来。

你说这叫研发效能吗？当然叫。比那些花几百万搭的所谓效能平台实在多了。

很多团队做研发效能的时候，容易走极端。要么觉得效能就是压榨开发，把每个人的工作时长都算得明明白白；要么觉得效能就是放任，只要开发能把需求做完，什么流程都不要管。这两种都不对。

说白了，研发效能本质上是给团队松绑，不是上枷锁。之前有个团队，为了减少代码审查的时间，把所有代码评审的流程都取消了，结果三个月下来，线上的代码烂到没人敢动，后来花了整整一个月的时间重构，反而把之前省的时间全都赔进去了。代价是什么？就是你在流程上省的每一步，最后都会变成技术债，连本带利地找你要回来。

别把效能做成领导眼里的数字游戏

现在很多厂商卖研发效能的解决方案，上来就给你列一堆指标：需求交付周期缩短多少，部署频率提升多少，故障恢复时间缩短多少。这些指标本身没什么错，但问题是，这些数字是给领导看的，还是给一线团队用的？

比如你为了把部署频率从一周一次改成一天三次，把本来需要做的集成测试环节砍掉，最后线上故障变多，开发天天半夜起来接告警，这算哪门子的效能提升？

没人吃这套。

一线团队的感受最真实。如果所谓的效能提升，最后落到每个人头上是更多的考核，更多的表单，更多的无效对齐，大家只会想办法绕开所有的流程，最后你搭的所有平台，最后都会变成没人用的僵尸系统。

我去年在南京徐庄软件园碰到过一个做工业软件的小团队，一共二十多个人，没买什么昂贵的效能平台，就是大家每周抽一下午的时间，一起聊这周做项目的时候碰到什么麻烦。有人说测试环境经常被占，大家就一起花两天时间搭了个简单的容器调度系统；有人说写重复代码太费时间，就一起整理了一套内部的通用组件库；有人说跟客户对接需求的时候反复改，浪费太多时间，就一起定了个需求变更的确认机制。半年下来，他们的交付速度比之前快了近一倍，没人觉得有负担，反而觉得干活比之前顺多了。

这才是真的研发效能。不是哪个领导拍脑袋定的目标，也不是哪个厂商卖的解决方案，是团队里每个人都能少点无效劳动，把时间花在真正有价值的事情上。核心是减少团队的无效时间消耗，而不是给每个人套上更密的考核网。

最近又听到有人说，今年是研发效能落地的元年。笑死人。这事从来就没有什么元年。你愿意蹲下来听听一线开发的真实麻烦，愿意把那些挡在路上的破流程拆了，愿意把省下来的时间还给团队，效能自然就上来了。对吧。