Bug数能否做为技术人员考核的KPI？
source link: https://mp.weixin.qq.com/s?__biz=MzIwMjE3MDIwMA%3D%3D&%3Bmid=2247486336&%3Bidx=1&%3Bsn=8553b053a06250cb334f223a1ba526b2
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
作为以代码为生的软件开发人员，可用的功能与Bug总是相生相克。有次产品迭代回顾会上，我提出低级Bug数量要作为KPI之一进行绩效考核，私底下某些小伙伴反响挺激动：写怎么可能没有Bug，怎么会有这么傻X的要求？如果真的是Bug数量的多寡来考核写代码的开发同学，相信大家都会疯，这是制度上的缺陷，不利于组织的发展。
题图 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无小事，质量意识心常存。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK