如何看待公司把开发人员 bug 列入考核?

[zhang5388137]

开发人员没有驳回权限, 个人感觉不公

[bobuick]

每个公司、每个团队情况不一样。不要意淫，自己没在那个位置，没在那个场景不要随便评判就是不合理。

你一堆博士，自主能力高高的，自觉性高高的，自驱动更没问题，出几个 bug 都羞愧都不行。这团队当然不用

反之，你往下降几档，降十档你再观摩一下。说不定你来管这团队，你按博士那个团队来管，死都不知道死透了几轮了。

[TransAM]

典型的官僚主义，导致多干多错，少干少错，不干不错。

[lleohao]

我们公司还把前端产出的页面数量当作考核项

[WinnieNumberTwo]

从细节上来看，看需求文档的撰写者的水平了，这个撰写者可能是产品 /项目经理、可能是 BA、甚至可能是个别程序员自己。

需求文档能写好的人其实并不多，尤其是公司的小项目组，这种情况如果要实行 bug 数量作为绩效考核的话，其实困难重重，很容易造成技术人员流动。然后项目经理还会甩锅给下面，其实真正的源头都是需求文档写的烂，然后项目经理直接把给客户和领导的 BRD/PRD 原封不动的扔给程序员去做，这种基本上都是高 bug 率的。在大厂做产品或者功能的团队，需求的细化情况反而会好一些，但感觉楼主这个公司不想大厂。

[ziggear]

开发人员 bug 列入考核，那就要先问：怎么考核？我想无非就是那几种方案，比如常用的“千行变更 bug 率”——这个规则一旦实施之后其实会引发另一个问题：对于模棱两可的 issue，QA 到底要不要提为 bug ？比如前端开发字体过大（即使需求如此？），很多时候 QA 会提为 bug，严格来说应该分类到“体验优化”的 issue 里，但是互联网公司一切都要求快速推进的节奏，我不知道有多少 QA 团队会去细化和贯彻提 bug 的界限、分拣规则，以及后续的无效 bug 打回或转需求等问题。

我所在的团队曾经就面临这样一个恶性循环：领导提出要考核 bug 率 —— QA 提 bug 后频繁被打回 —— QA 开始变得谨慎，提 bug 之前先找开发确认 —— 开发效率降低 —— 代码质量下降。所以我个人认为，bug 列入考核确实不合理，但并不是从不公平角度来看的，真正能很好执行考核流程，还能解决上面我提到的问题的团队，相信都是无论是个人的业务能力还是团队的合作能力都非常到位的团队，自然不用太担心 bug 率的问题。

另外，如果是为了恶心你们，那就另说了。

[xypty]

绩效给员工送钱。。。。那要是从你工资拿一部分出来做绩效的公司呢

[zhang5388137]

@WinnieNumberTwo 是的 非大厂

[lyzy]

@dilu 说的好

[winglight2016]

总体来看，搞绩效、KPI 这种东西，唯一的用途就是生成一堆文档，白白耗费大家的时间。。。

CMM-5 级又如何？须知软件行业，获得 CMM-5 的都是那几家外包公司，真正生产力高的团队从来不玩这些虚的。

上有所好，下必甚焉。老板或者客户喜欢这些，HR 就来折腾程序员，还有舔狗程序员主动迎合，实在是真正的工贼。

[whywhywhy]

那就自己测，可以匿名发邮件给大家，每个人都自己测，每天发日报给公司，当公司觉得这个成本不能接受的时候。

bug 就会被接受。

有的 bug 是业务上的 bug，那就每次提交的时候和需求提出人确认，最好每一行代码都解释一下，让对方盖章 /签名。

这些就是你工作的一部分，你都写上。

另外，别“自愿”加班了，多打几个 12345 电话了解一下劳动法，行政规定，有疑惑就解惑，没疑惑就学习。

“把 bug 列入考核”，那开发人员就有必要确认清楚需求是否和代码一致，你也是公司的一份子，你也可以要求别人。



为什么要这样做呢？不是抬杠，是让别人了解一下，要做到这一条有多难，成本有多难以接受。如果公司都接受了，那你接受一下也没什么，大家是来工作的，尽力吧。

[whywhywhy]

哦对了，自己测 bug 往往难测试出来，开发互相测吧，至少要 3 个人都测试 ok，这样靠谱一点