上周跟三个不同规模的技术团队负责人喝茶，聊到后半夜，三个人都在骂同一件事：花了大价钱搭起来的效能度量体系，最后成了行政和PM手里的考勤表。
先搞清楚，你要的研发效能到底解决什么问题
很多公司一上来就喊要提升研发效能，第一步就是拉专项组、买工具，把代码提交次数、需求交付周期、线上故障数全列成实时看板，每周拉一次会通报大家的指标完成情况。
很多人从一开始就把研发效能的目标搞反了。
不是为了给所有人套上统一的考核标尺，而是要把工程师每天被无意义流程耗掉的精力抢回来。之前碰到个做电商的后端，一个两周的迭代周期，光填各种跨部门审批表单、给不相干的人同步进度、开没有结论的对齐会，就要花掉三分之一的时间，真正能沉下心写业务代码的时间连一半都不到。你说他效能低？他只是被冗余流程绑住了而已。
那些看似正确的效能建设，往往在反向消耗团队
我见过最离谱的一个团队，为了把需求交付周期压到所谓的标杆值，要求所有需求必须拆到2人日以内，超过的不许排进迭代池。结果呢？大家为了凑这个拆分标准，本来一个能一次讲清楚的完整功能，硬拆成三个独立的小需求，每个小需求走一遍完整的提测、部署、上线流程，光测试环境的部署次数就翻了三倍，因为模块拆分太碎产生的联调问题，比之前多了近一半。
说白了，当你把某个指标当成必须达成的硬要求，这个指标就一定会失去参考价值。
麻烦在于，很多牵头做效能建设的人，根本没在一线写过三年代码。他们不知道一个复杂的技术方案评审，需要的是大家对着白板画半小时时序图，而不是对着PPT念10页没有重点的流程规范；他们也不知道，工程师最烦的从来不是啃难写的代码，是写完代码等20分钟流水线才能跑通，等三天审批才能合入主干，出了问题翻半天日志找不到是哪个环节的锅。
真正有效的效能提升，从来都是从一线的小痛点改起
这事没那么玄。
我之前接触过一个百人规模的技术团队，没有买动辄几十万的商业效能平台，就是找了三个每天在一线干活的资深工程师，花了两个月时间，蹲在工位旁边记大家每天抱怨最多的事。比如流水线跑一次要20分钟，他们就把非必要的全量测试环节拆到夜间定时跑，把日常提交的流水线耗时优化到5分钟以内；比如新员工入职要找三个部门的人开各种系统权限，他们就写了个一键申请的自动化脚本，10分钟就能搞定所有权限开通；比如每次线上出问题，大家要在五六个群里来回同步信息，他们就做了个统一的告警聚合页面，不用在各个窗口之间来回切换找线索。
就这些看起来特别细碎的小事，攒了小半年，整个团队的需求交付速度提了近四成，没人被强制考核，也没人觉得自己被系统盯着干活。没人搞什么效能宣讲会，也没人给大家发什么改进倡议书。
说实话，现在圈子里谈研发效能，总喜欢往高大上的方向靠，什么AI辅助编码、全链路可视化、组织级效能模型，听着都对，但你要是刚起步就上来堆这些东西，大概率会变成又一个没人用的摆设。
别迷信工具。
很多团队花了大价钱采购的全链路效能平台，最后打开率还不如工程师自己写的那个用来查接口报错的小脚本。
别一上来就想着要把整个公司的研发体系翻个底朝天。你先去问问一线的工程师，今天上班哪件事最让他觉得烦，把那个事解决了，比你做十份完美的顶层设计都管用。真的，工程师是最实在的群体，你给他减少一点无意义的负担，他自然会把省下来的精力放到真正有价值的事上，根本不需要你拿尺子量他每天写了多少行代码，开了多少次分支。