bug 数和测试同学的认可度决定开发的绩效是否合理

[lifesimple]

个人感觉可以占比一小部分吧，占大部分不太合理，因为不同项目开发时间 业务复杂度等不同 容易出的 bug 数量也不一样吧。大家又不是做一模一样的事 如果都是写同样的东西 这个变量控制一样那么确实谁 bug 少谁优秀。各位大佬公司是否也这样呢

[whypool]

我这绩效不和任何开发测试挂钩，只和公司营收挂钩，效益好年终系数高，不好系数低

[lifesimple]

@whypool 这个肯定也会有影响

[potatowish]

以前待过一家是这样，和你说的差不多，有很大部分比例是看 bug 数量和测试同学的打分，这种不合理的规则很明显是不怎么写代码的人制定出来的，不仅不考虑需求复杂度，就连前人留下的坑也算到你头上，每月绩效都会扣一部分，还好没多久我就跑路了

[potatowish]

@potatowish 让测试给开发打分这个机制也很无语，测试提工单，开发来修复，本来是没有管理上的关系的，但前司会以开发是否积极和测试沟通作为评分项，意思就是你光是线上沟通不行，要经常去找测试同学唠唠。现在想想真庆幸脱坑了

[lifesimple]

赶紧脱坑 太沙皮了 需求没写明确 提测预演时候临时改的一堆要优化的点，结果都给你提成 bug 吐血