上周在南京软件大道跟几个做了快十年后端的老同事撸串，有人吐槽说公司去年花了近两百万上了三套研发管理平台，季度复盘时研发效能的数字涨了30%，实际迭代该卡还是卡，需求排期到上线还是要磨俩月，出了故障还是各部门甩锅。
流水线的数字骗了太多人
说到这就来气。很多团队对研发效能的第一认知，是CI/CD流水线跑一次要多久，是代码提交到合并的平均耗时，是迭代周期里完成的需求点数。上周碰到一个团队，把流水线里跑单元测试的环节从15分钟砍到3分钟，就因为把测试用例覆盖率从80%降到30%，最后季度效能表上的数字好看得很，上线之后连续三个版本出线上事故，回头算下来，排障、回滚、用户投诉处理的时间，比当初省的那点流水线时间多了十倍都不止。
很多人觉得研发效能就是开发环节的提速，其实根本不是。真正的研发效能，是从用户提出一个需求的想法开始，到这个功能最终上线被用户用起来，整条路上没有不必要的等待。很多团队把精力全砸在开发环节的提速上，压根没算过，需求从产品提出来到排期进迭代中间等了多久；开发完了等测试环境部署等了多久；测试提了bug改完重新部署又等了多久；上线之后等运营配置权限等了多久。这些堵点上耗的时间，比你把流水线从10分钟压到2分钟的收益大太多了。
流程里的隐形成本从来没人算
麻烦在于，很多团队的流程设计是十年前人少的时候定的，现在团队规模翻了五倍，还是照着老流程走。比如一个普通的功能上线，要产品写评审文档，开发写设计文档，测试写用例，运维写部署方案，每个文档都要过三四个领导审批，哪怕这个功能只是改个页面上的错别字。
没人算。这些文档写出来之后，除了应付审计，根本没人看。之前接触过一个做ToB的团队，光上线前的审批流程就要走7个节点，每个节点平均等12小时，算下来光审批就要耗掉近4个工作日，就为了走个流程。这些没有被记录在工时表上的等待时间，才是吃掉研发效能的最大黑洞。后来这个团队做了个小调整，把上线审批的节点从7个砍到2个，给核心模块的开发团队一定的自主上线权限，第一个月就把平均上线周期从12天压到5天，没买任何新工具，没给团队加任何KPI，就是把那些没必要的流程堵点拆了。
不过话说回来，也不是说所有流程都要砍。比如涉及到资金、用户隐私的模块，该有的审核环节一步都不能少。关键是要分清楚，哪些流程是真的在防风险，哪些流程是当初为了应付某次审计加的，十几年过去了没人敢动，就一直留着当挡箭牌。很多团队现在谈研发效能，第一反应是买工具，是做培训，是搞什么效能度量体系，从来没蹲下来在工位旁边待上三天，看看开发人员一天到晚到底有多少时间是真的在写代码，多少时间是在找环境、传文件、改配置、跟不同部门的人扯对齐的事。
别让度量本身变成新的负担
之前碰到过一个很荒诞的事，某公司为了度量研发效能，要求开发人员每天在系统里填每个小时在做什么，是写代码，是开需求评审会，是处理bug，还是帮别的团队排查问题。最后算下来，开发人员每天要花40分钟填这个表，算上季度复盘的时候整理数据的时间，全团队一年花在填报表上的时间，够多做两个核心功能的迭代了。
度量研发效能的初衷是找到堵点，不是给开发人员套上更细的考核枷锁。很多团队走偏的地方就在这，一开始是想通过数据找到哪里效率低，慢慢就变成了拿数据卡人，哪个开发的代码提交量少了，哪个的bug率高了，哪个的迭代完成率没到100%，就拉出来谈话。最后大家为了把数字做漂亮，开始拆小提交、写没有实际价值的测试用例、把大需求拆成凑数的小需求，整个团队的精力全花在怎么应付度量上，真正给用户创造价值的事反而没人上心。
这事没那么玄。我见过做得好的团队，从来不会把研发效能挂在嘴边当口号。他们就是每个迭代结束之后，拉上产品、开发、测试、运维的人坐一块喝杯咖啡，聊聊上次迭代的时候哪个环节卡得最难受，是测试环境老是部署不上去，还是产品需求改来改去没有定数，还是跨部门的接口对接老是拖进度。找到一个堵点，就集中精力解决一个，慢慢迭代的速度就上来了，上线之后的故障也少了，大家不用天天加班补窟窿，自然就有精力做更有深度的技术优化。
真的别再信那些卖工具的厂商说的，上一套系统就能把研发效能提升50%的鬼话。工具只是帮你把流程跑顺的辅助，不是万能药。你要是流程里全是堵点，大家天天在里面绕圈子，就算买再贵的平台，也不过是把这些堵点搬到线上而已，该等还是等，该甩锅还是甩锅，对吧？上次那个撸串的老同事，后来回公司跟老板提了个建议，花了两周时间把所有研发流程上的堵点挨个捋了一遍，砍掉了三个没必要的审批节点，把测试环境的部署权限下放给了测试团队，这个季度算下来，迭代的平均周期比之前短了快40%，也没多花一分钱买新工具。他说最明显的变化是，现在下班之后大家不用再蹲在公司等审批上线了，到点就能走。