从没见过有这种考核方式

N 年前的考核方式了，现在早淘汰了

沙比但是完美，对于某些管理体系下的管理者，即便水平再高也只能这么来

简单但是有效啊。如果团队比较大的话，看这个数据也没什么问题吧。
当然如果加一个线上 BUG 数，然后和测试 BUG 数相除得到一个系数。这个系数越小得分越高或许更好一点。

简单、粗暴、有效

之前我司有使用 bug 数量做参考，打分制，但是不是单纯按照数量来计算的，不同等级的 bug 有不同分值

线上 bug 数目 + 案例执行效率 +bug 案例比 +bug 阶段分布比（bug 在 stg1，stg2，回归应该有比较合适的比例）+ 延期率
然后算出一个总分，但是这个也依赖于开发的质量，所以是作为版本的质量参考，不作为强制的绩效考核

我们现行的策略如下，欢迎大家批评指导：

绩效考核 = 当月工作量 X 质量评分 X 团队合作评分

• 当月工作量：由主管按照统一标准评定，标准是提前制定和公告的，主要是根据用例数等等

• 质量评分：计算公式=(线上缺陷数量系数/（线上缺陷数量 + 测试阶段缺陷数量)系数)，根据缺陷的严重程度，系数为致命 10、严重 5、 一般 1。没有任何线上问题即判定为 1，有任一致命问题即判定为 0.5~0.8（主要根据问题责任划分）；

• 团队合作评分：大部分时候都是 1，这部分无法量化，所以就行为化，由主管主观决定。主要根据与项目内其他同事的合作情况锚定，如果有一些分享会额外加分。一般有加分或者减分，主管都应该表扬或者批评。

简单， 粗暴，低效，无价值

写的越多有 bug 的可能性越多，有可能会产生大家不敢写代码，或者都去写那种一个个烟囱的代码，不引用别人的（怕别人的有坑）。

如果只有这个指标，就太简单粗暴了。

简单粗暴，而且没啥意义，人为制造测试开发对立，对提高质量没有任何帮助，非常愚蠢！

bug 可以作为团队近期开发质量的参考，但是无论是团队还是个人的绩效考核，看这个毫无意义。打个比方，一个人 1 个月的东西要 1 周做完，他出了 100 个 BUG，一个人 1 周的东西 1 个月做完，他就 10 个 BUG。第二个人更好？

至于上面绩效考核 = 当月工作量 X 质量评分 X 团队合作评分，人少干同一件事还行，人多了工作情况复杂了，就工作量这个，就没啥可比性，除非团队进行标准化的任务拆分。质量评分也挺扯的，质量是共建的，并不是某个人的事。另外什么团队合作评分，考核这个东西，加了一个主观条件，那么考核就是主观的，还不如弄些目标，大家都达成了，光明正大的用主观来评。

考核是引导团队方向的，单纯以考核来考核，是管理水平低下的表现。

以 BUG 数量考核，引导团队多点 BUG？

1、我们是小团队，就三四个人。
2、质量不是一个人的事情，但是每个人的工作质量还是会有区别的。
3、主观难道就不光明正大了么...而且也有说，一般不会有太大区别。

我们这个考核主要用来决定年度绩效的，但是只是其中一个指标，还有项目贡献、职位、在项目的时间等等。也不会影响到开发那边，所以不存在导致测试开发对立。
匿名吐槽完，过了嘴瘾，好歹也给楼主提供点有建设性的建议？

简单 粗暴 直接 有效 完美的方式
一般人受不了，太累了。

每个公司不同，团队大小不同，内部氛围不同，考核指标也不是一成不变。考核其实挺复杂的，需要迎合公司或者团队近期发展，以后的规划等等。我在这里也就是打打嘴炮吐个槽。

单月度考核，团队小的话，建议主观考核即可，比如工作量、态度等等（数据作为参考），列一个红线——线上缺陷数。

线上缺陷数可以作为强制指标，另外如果出了线上问题，开发测试一样背锅，这样可以减少甚至避免开发不自测，改 bug 疯狂引入新 bug，你帮他找到问题，还不乐意改的情况。

至于其他，都根据自己团队的来，你之砒霜我之蜜糖，不过很多时候可以从考核里看到管理者和团队的成长。