研发效能不是套在开发身上的新枷锁

上次去苏州工业园跟一个做电商后台的Java开发聊,他说公司上个月突然喊着要全面落地研发效能,第一波动作不是买工具不是改流程,是拉着全部门20多个人填了三周的逐小时工时表,连午休出去买奶茶超过15分钟都要在备注栏写清楚原因。

他当时跟我吐槽,说填了三天表就发现,那些没人看的记录,最后只会变成季度考核的时候,拿出来算你“工作饱和度不够”的证据。

先搞清楚大家在怕什么

谁都不傻。

之前太多团队搞研发效能,一上来就把指标对准一线开发,代码提交行数、每日在线时长、构建次数,这些数据摆到台面上,明眼人都知道意味着什么。

说真的,我每次听到这种操作都忍不住想笑。之前见过太多团队,把研发效能等同于监控开发的一举一动,最后搞得大家天天跟防贼一样防着公司的工具,写代码的时候要刻意留够在线时长,下班了还要挂着VPN凑在线数据,这种环境下,谁能沉下心写好代码?

数据是可以凑的。注释拆成单行提交能涨代码行数,把一次完整的构建拆成十几次零散提交能涨构建次数,最后报表做得漂漂亮亮,实际的线上bug没少,交付速度没快,大家花在凑数据上的时间反而多了一大截。

研发团队工位上堆满的工时填写表单
研发团队工位上堆满的工时填写表单

真正的效能提升从来不是盯着人算

很多人对研发效能的误解,就是觉得这是研发部门自己的事。

麻烦在于,你让一群写代码的人在自己的环节里挤效率,就算把每个人的编码速度提20%,架不住前面排着三四个等审批的环节,整体速度还是上不去。

我去年跟一个做企业服务的基础架构团队聊,他们之前也跟风搞过三个月的效能度量,最后翻遍所有流程数据发现,开发真正坐在工位上写业务代码的时间,连整个需求交付周期的20%都不到。剩下的时间呢?等运维排期发版等3天,等安全团队扫描漏洞等2天,等产品改需求来回拉扯等5天,甚至等其他部门的接口文档,都能等整整一周。

80%的时间损耗,都藏在跨团队的等待、重复的流程、无意义的审批里,跟开发本身的产出速度没关系。

他们后来停了所有针对个人的效能指标,转头去改流程:把原来7个节点的发版审批砍到2个,把安全扫描做成每次代码提交就自动运行的流水线,把产品需求评审固定在每周二下午,不准临时插急需求。三个月之后,他们的平均交付周期从21天降到了9天,没人需要额外加班,也没人需要填复杂的效能报表。

DevOps流水线自动触发流程看板
DevOps流水线自动触发流程看板

别把效能提升做成一次性的运动

这事真的没那么玄。

很多公司搞研发效能,就是找个咨询团队来做几十页PPT,拉各部门开两次动员大会,定几个好看的指标,到季度末拉个数据排名,就算落地完成了。

真的很离谱。

我见过最夸张的一家公司,为了落地研发效能,光采购的工具就有七八个,每个工具都要求开发单独注册账号、重复填写相同的进度信息,每天光是在不同工具之间同步状态就要花一个多小时。老板看后台的工具接入率数据很漂亮,觉得效能提升肯定有戏,结果实际的需求交付速度,比之前还慢了15%。

还有的团队,效能提升的动作全是“要求别人”:要求开发提高代码质量,要求测试缩短测试周期,要求产品减少需求变更,从来不想想自己是不是给团队添了不必要的麻烦。之前碰到一个技术负责人吐槽,说他们公司喊了一年要做研发效能,到最后核心的技术债没人拨预算还,线上的监控系统还是三年前搭的,bug告警延迟半小时才弹,开发每天一半的时间在排查线上故障,这种状态下,喊破喉咙说要提效能,又有什么用?

真正的研发效能,从来不是让大家在更短的时间里塞更多的活,是把那些挡在做事路上的石头一块块搬开。

上周约之前聊过的那个苏州的开发吃小龙虾,他说他们团队最近总算把之前的逐小时工时填报系统停了。现在每周一早上拉20分钟的短会,每个人只说一件上周卡了自己最久的事,能当场协调解决的就当场拍板。上周他们把核心模块之外的代码审核要求从两个审核人改成了一个有三年以上经验的开发,光这一项,每周就省出了差不多12个小时的等待时间。

他现在下班不用卡点填工时,到点就能走。

挺好。

免责声明:市场有风险,选择需谨慎!此文仅供参考,不作买卖依据。如有侵权请联系删除。
文章名称:研发效能不是套在开发身上的新枷锁
文章链接:https://m.itcdj.com/it/206.html