研发效能从来不是KPI堆出来的账面繁荣

上周连跑三个二线城市的技术团队，聊到后半夜。没人聊情怀。全在骂之前搞的那套效能改造。有人花了大半年时间搭度量体系，最后出来的数字全是给老板看的，一线开发根本不关心。有人为了追所谓的行业最佳实践，把团队的协作流程拆得七零八落，最后大家每天花在填系统、走流程上的时间，比写代码还多。

先搞清楚你要的效能到底是啥

很多团队一提到提效能，第一反应是买流水线工具，搞代码覆盖率统计，把每个环节的耗时拆到分钟级。但你拆得越细，越容易把手段当成目的。

之前碰到过一个做电商系统的团队，为了把代码评审的平均耗时从2小时压到40分钟，直接给评审人设了超时未点通过就自动驳回的规则。最后为了不触发驳回，大家扫一眼代码就点通过，三个月里出了三个P1线上故障，光排查和回滚花的时间，比之前慢悠悠做评审的时间多了三倍都不止。

说白了，你盯着流程上的数字使劲压，最后省下来的那点时间，全得赔到线上事故里。算总账，半毛钱好处没有。

很多人对研发效能的误解，就是把它等同于“流程跑的越快越好”。但实际上，你跑的快的前提是方向对。如果需求本身就是错的，你流程跑的越快，错的越远，浪费的资源越多。这部分的损耗，从来不是靠压流程时间能补回来的。

工具从来不是救命稻草

聊到最后大家的共识是，之前踩的最大的坑，就是把工具当成了效能提升的全部。

有个做工业软件的团队，去年花了小几十万采购了一套号称行业领先的DevOps平台，要求所有需求从提交到上线的全流程，必须在平台上填全所有字段，从需求来源、客户对接人到每个模块的验收标准，填完才能进入开发环节。结果开发同学为了过流程，随便找个之前的模板把字段填满，到最后上线的时候，需求文档和实际做的功能差了十万八千里，客户那边验收卡了快一个月。

麻烦在于，工具是死的。你团队的协作习惯是活的。

真正拉低效能的从来不是工具不够先进，是你团队里藏了太多没有价值的协作环节。比如一个需求从产品提出来，要过三个部门的审批，每个审批人其实都没仔细看内容，只是按流程签个字，这部分的时间成本，你买再贵的工具都省不下来。更别说那些每周固定要开的跨部门对齐会，会上说的内容全是上周已经同步过的信息，大家坐那熬俩小时，啥决策都没做。这种无效内耗，你接多少条自动化流水线都解决不了。

别拿加班时长当效能的参考值

太扯了。

很多团队的管理者，看效能的方式特别简单：看代码提交记录的时间。晚上九十点还在提交代码的，就觉得团队干劲足，产出高。但你真跟着坐一天就知道，那些经常晚上十点还在改代码的团队，多半是白天的需求评审没说清楚，到了开发快结束了才发现理解错了方向，连夜赶工调整。这种产出，算哪门子的效能。

之前跟一个做基础架构的团队负责人聊天，他说他们团队去年啥新工具都没买，就是把所有没有明确价值的汇报、跨部门对齐会全砍了，每个开发每天的有效编码时间从之前的2小时涨到了5小时。当年上线的需求数量没减，线上故障数降了六成。没加人，没加钱，就是把那些没必要的流程全砍了。

真正的高研发效能，是你团队能在正常的工作时间里，把该做的事做完，上线之后不用半夜爬起来改bug。

很多人聊研发效能，总喜欢拿行业标杆的案例往自己身上套。忘了自己团队现在的阶段，能把流程跑顺就不错了，别上来就抄人家的百万级流水线配置。

这事没那么玄。你坐下来跟着开发同学跑一周的流程，看看他每天的时间都花在哪了，哪些事是完全没必要做的，砍掉。比你买十套工具都管用。

对了，别最后算来算去，把大家的休息时间算成了效能提升的成本。那账，算不对的。