对于将测出的 bug 数作为对测试人员绩效的评价标准大家怎么看？

是这样，最近公司突然提出要以提的 bug 数作为绩效的考量标准。大致的考量规则如下：

1、对于在测试过程中发现 bug 的数量&质量排名前 5% 的同学，春季薪酬调整时不论是否晋升，调整幅度确保在前 20%；——适用于所有人
2、对于反馈产品线上有效问题数量&质量方面排名前 5% 的同学，春季薪酬调整时不论是否晋升，调整幅度确保在前 20%；——适用于所有人
3、对于在产品问题的分析、跟进、解决方面表现突出的同学，我会在技术职称评定中以尽我所能，以最强烈的方式建议晋升；——适用于技术类工程师
4、对于在第 1、2、3 条上表现突出的外包同学（前 20%），优先于社招&校招，转为正式员工；——适用于所有外包工程师
5、对于反馈产品线上有效问题的数量&质量方面排名后 10% 的同学，不建议参加技术或管理晋升；——适用于所有人
6、被反馈有效漏测问题数量最多的前 60% 的线上产品，其主管绩效不能是 1 和 2；——适用于所有管理类和实习项目经理

大家对这种评价标准有什么想法？

先说一下我的吧，我个人觉得，首先以 bug 数做为评价标准是一种很不公平的做法，对于不同的产品线、产品类型，客观上会影响产生的 bug 数，老的成熟的产品线 bug 肯定相对少一些，新的产品 bug 必然会多一些，有些走敏捷开发的产品线可能 rd 和 qa 很紧密的沟通，有问题直接解决了，也不会提 bug。所以这个评判标准我觉得首先是不公平的。
抛开公不公平，这种以提 bug 的方式来考量绩效我也觉得并不合理。第一，大家可能工作本身已经相当饱和，而提 bug 肯定需要有个流程。我觉得一些重大的，值得后续注意的的确很需要记录下来，但是一些简单的代码错误，或者完整性判断，或是上线步骤的一个错误路径等等，可能本来和 rd 提一句就能搞定，但是一这样鼓励提 bug，可能所有的测试人员天天就提 bug 了，不利于工作进展。第二，我觉得开发人员和测试人员应该是很协调的两种角色，事实上目前我们的团队中也就是这样的，但是这样把 bug 引入绩效，很容易造成测试人员与开发人员的对立。到时候本来商量一下改改的问题变成了这是不是 bug 的互相扯皮，很不利于团队的关系。第三，对于线上 bug 的发现，我觉得的确很重要，可以让大家更关自己的产品，提高产品质量。但是如果把这个当成如此大的一个考评指标，我觉得会让测试人员天天就盯着线上了，一天到晚就去搜线上问题呗，反而无心去关注实际项目的进展。我觉得这种方式对于一个正在发展的团队是很不利的。回顾线上问题是一方面，另一方面我们还是要多关注于那些新项目，新的测试方法，开发新的测试工具或者研究新的测试流程，这样才能推动发展。
当然以上只是我个人的一点不成熟的想法，希望大家可以讨论下哈~~~