研发效能从来不是算出来的报表数字
上周跟一个在大厂做了7年后端的朋友吃饭,他把手里的冰可乐捏得哐哐响。说最近团队又上了新的效能平台,要求每天填的工时颗粒度要到15分钟,连等代码评审的时间都要单独选标签。我当时夹菜的手顿了顿,想起前几年见过的一堆把研发效能搞成填表工程的团队。
研发团队git提交记录杂乱截图
麻烦在于很多管理者把“看得见的数字”等同于“真实的产出”。就像你不能靠一个人每天在工位坐了多少小时,判断他写了多少能稳定上线的代码。有人坐满12小时,一半时间在刷技术帖摸鱼,真正沉下心写代码的时间可能不到3小时;有人每天准点下班,手里接的需求从来没延期过,线上故障率比团队平均水平低一大截。这种差异,根本不是靠填几张报表就能算清楚的。

研发团队CI/CD流水线配置界面截图
有次跟一个前端负责人聊天,他说他们团队之前为了赶版本,大家连续三周每天加班到11点,结果版本上线之后,因为赶工写的代码没做封装,后面每加一个小功能,都要把之前的老代码翻出来改一遍,前后花了两个月的时间补之前欠下的技术债,算下来整体的产出比不加班慢慢做还要低。说白了,效能不是看某一个时间点冲出来多少量,是看你整个团队从需求进来,到代码上线,再到后续维护的全链路里,有没有反复走冤枉路。
算出来的效能,多半是假的
很多团队一开始推研发效能,第一反应是拉一堆可量化的数据做看板。提交代码的次数、需求从进入排期到上线的周期数、线上故障的触发次数,挨个列出来,给每个研发算贡献分,好像分数越高,团队的效能就越好。 有个团队之前真的这么干过。把代码提交量直接算进个人效能考核,结果没到半个月,大家为了凑数,把本来可以一次提交的功能拆成七八次小提交,git log翻开来全是“修复格式”“调整注释”“补个空格”这种无意义的记录。最后真的要排障的时候,翻提交记录找问题找半小时,反而比之前大颗粒度提交的时候效率低了一大截。 所有可以被人为凑出来的指标,本质上都跟真实的研发效能没有关系。效能提升的核心是减少无意义的内耗
真正的研发效能提升,从来不是逼着大家多挤时间写代码,是把那些本来不该研发花精力的事给砍掉。 之前接触过的一个早期创业团队,一开始没有搭统一的CI/CD流程,每次上线要找运维、测试、产品三个人拉群对时间,光等排期就要等两三天。研发真正写代码的时间,其实只占整个交付周期的20%不到。后来他们花了两周时间把自动部署的流水线搭好,测试环境自动触发回归用例,上线只要点一下按钮,整个交付周期直接砍到原来的三分之一,所有人的加班时间直接少了一半。根本没逼着大家提速,就是把那些卡流程的堵点给通了。 很多团队一开始搞效能建设,上来就买一堆昂贵的管理系统,要求每个人填各种维度的报表,反而给研发加了新的负担。你给研发加的每一项非必要的填报要求,本质上都是在消耗原本可以用来写代码的精力。