Bug数能否做为技术人员考核的KPI?

作为以代码为生的软件开发人员,可用的功能与Bug总是相生相克。有次产品迭代回顾会上,我提出低级Bug数量要作为KPI之一进行绩效考核,私底下某些小伙伴反响挺激动:写怎么可能没有Bug,怎么会有这么傻X的要求?如果真的是Bug数量的多寡来考核写代码的开发同学,相信大家都会疯,这是制度上的缺陷,不利于组织的发展。

Bug数能否做为技术人员考核的KPI?_第1张图片

题图 from pixabay

他确实曲解了我的用意,我不是要考核Bug数,而是考核低级Bug数,什么是低级Bug?写过几年代码,大概都分的清Bug的严重程度。

  • 界面上的样式问题,格式不统一、错乱、错别字

  • 极简单的空值判定问题,稍微自测就能暴露出来

  • 常用代码使用不规范,

  • 系统上线数据库连接错乱

  • 完全复制别人的类似代码不加思考直接据为已用

  • ......

相信还能罗列很多,这种写出来的没有技术含量的Bug,摆在台面上,相信自己都会脸红,这些问题不需要有很好的技术水平才会犯。低级问题都有很好的套路可以避免:遵循普遍的代码规范,单元自测,遵照特定的流程,细心+认真。

为什么要考核低级Bug数,低级Bug数不是考察你的技术能力高低,它反映的是一个人的工作态度问题。一个好的工作态度胜过一个不负责任的技术大牛,那为什么不考核Bug数?Bug的多寡源自于代码开发量的多寡,做的多,错的就多。做的少,就错的少。不做就不错。如果按这个标准走,对大家是不公平的,这个组织就不会有长足的发展。一个学习型组织的成员,必须抱着成长的心态向前走,而不是怕出错误就不往前走。

还有一个Bug数指标也可以做为KPI项考核呢?Bug重复打开率。一个Bug被Fixed掉之后,过段时间又被再次打开,说明没有彻底解决掉,在某些场景下依旧存在。或者当前问题解决了,引发了另外的Bug,在另个的Bug被解决掉之后,当前的Bug又被重新打开了,也就是大家常说的“改好一个,坏了仨”,越改,Bug越多。

当大家不重视代码质量,无感Bug数的时候,团队就会形成一种潜意识——Bug无所谓,出现了改就是了,如此而来的产品质量肯定不会高到那里去。当然也不能高压控制Bug,出现一个扣多少多少钱,只会让团队萎缩不前。因Bug导致的生产事故,依据大小,是可以进行处罚,相信大家也不会太大怨言。

Bug无小事,质量意识心常存。

你可能感兴趣的:(数据库,编程语言,java,bug,软件测试)