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

很好的方案，软件的 BUG 少了，测试人员的绩效也少了。大大节省公司成本

@myd 然后软件开发部门就是光杆司令了。更加节约成本了

主要看能不能体现总体工作量。
不然就是 “不做不错”

请他先定义什么类型的属于 bug，产品想不到的东西不要把锅甩来甩去

这样的方式，已经在我司实行半年了，颇有成效，挺好

方法可以但是不能一刀切，不然就会出现多做多错、少做少错的情况。

如果非要启用这种绩效考核方式，最起码有一件事需要保证就是绝对不能压工期，同时插入了别的需求就一定要延长工期。

同时统计 bug/工时比，我 5 天 5bug，他只有 1 天的任务但是就 1 个 bug，两人的绩效应当大体一致。

同时应当对 bug 定等级和影响，文案不一致。颜色不一致、位置不一致这种要轻一些。

测试期间测出的 bug，和上线期间出现的 bug，以及上线很久出现的 bug 定级绝对不能一样。

不然最后就会变成公司扣钱的一种方式而不是真正的绩效考核。

顺便说一句，绩效考核的目的是给员工送钱而不是给员工扣钱。

老板们要明白一句话，重赏之下必有勇夫。你钱给的不够，眼前他们不会说什么，有机会一定会跑的。

前提是明确工期是否合理

@dilu "绩效考核的目的是给员工送钱而不是给员工扣钱"

赞这一句

突然想起来按代码行数算钱的搞法
很多管理人员就根本搞不明白怎么管理程序员，这不是搬砖小工搬一块是一块，可以随便量化的

如果整个生产流程严谨, 未尝不是个好办法，但是大部分公司都是催命+无脑修改需求的方式来开发业务。。这种要实行这个模式....

我们把代码行数当做贡献量。。

@MangozZ #3 +1.不考虑工作量只考核 BUG 那就是耍流氓。

@longbowape 怎么解释很多私企领导人对待下属的态度 "你怎么怎么就扣钱奥" 我第一家实习的公司还每个人每个月的工资都是部门经理写在一张表格上的 所以你想想看好了 你的生杀大权都在他手上

这样的只有一种结果，大家结果都是打酱油，相互敷衍，而不是把事情做好。

１．评估工期极可能长
各种可能都要考虑到

２．把自动化测试都自己搞起来
开发个小模块小功能，没事慢慢把所有用例过一遍＼两遍＼三遍，确认没问题再提交测试


其实一句话就是，把测试的工作顺手就做了，而且要反复多做．测试会轻松很多，建议内部转岗测试

之前有讨论，t/625556#reply44

BUG 数量能够和绩效持钩，突然想起以前报道那个军方的写了多少 G 代码的美女程序员。。。

找个降薪的理由，要么忍要么滚

需要一套科学的计算方法，否则就是不做。

不写代码 岂不是啥 bug 都没 美滋滋~

少干少 BUG 多干多 BUG
项目中不会存在 BUG
BUG 会与所有人有关
产品会简单的同时更复杂

bug 分级制度，
bug 所产生环境，
bug 指派人，实际产生人，实际区分人的定位
个人工时，
bug 是一个考核因素。
不能做全面的考核因素

兄弟，早点下班吧。

每天划划水，做慢点，写的越多错的越多。

时间拉长了，单位时间的 BUG 量不久少了。

代码总量少了，单位代码的 BUG 总量不就下来了么。

这分明是福利。。

多好啊 哪来的不公？

简单粗暴的 BUG 考核就是对开发的及其的不公。

这个标题没有完整的描述清楚，如果是针对一个需求测试反复测出问题来，说明开发的质量存在问题，那么这一类信息如果纳入考核指标内我觉得没毛病

不写 bug 的程序员 还是个好程序员吗？

看怎么评价

我司的绩效考核里也有 bug 评价，但仅限于很恶质、低级、完全可预防或者应该在 merge 到正式分支前自己检知出来的 bug。

这部分有些有定性或者定量的标准，有些则是需要小范围评审之后决定。

至于说绩效是给员工送钱，话是没错，但是人家不要你也没办法。

赏罚不分明，一刀切大锅饭就是对表现优秀的人不公平…

我们也用 BUG 考核，但是只考核线上的 BUG，功能上线之后出 BUG 就要扣绩效分。

把日报质量列入考核咋样？还占 20%！！！

我们公司有一个专门做项目管理的人员，整天就是发布审核下，催我们写工时，写日报。最近又自己开发了一个软件，准备每天给开发人员打分（根据提交代码行数，bug 数）。

一个月工作 330 多个小时 , 临时救火匆忙上线需求, 测试都没测完就上线, 出了 bug,绩效降了一档, 直接少了 4000 多块, 再这么拼, 我就是狗

武汉活生生的例子，让领导看一下不允许出 bug 是什么后果

如果类似外包，东西都设计好了只要程序员老老实实对着做，这个 bug 数量本来就要管理的，作为绩效没什么问题
如果自己做产品，设计比较粗放，需求经常改，很大程度依靠个人技术水平的，一般作为参考吧。只要不是大量低级 bug，常规流程中的 bug，复杂一点的功能有几个 bug 也没人会说什么。

不要只看老板怎么怎么样，想象你的同事给你的接口全是 bug，反反复复都改不好，你都看出来了他就是改不好，该判断的异常情况都不判断，搞得自己都没法干活的话，你会觉得外部力量来控制这种情况是有必要的。
关键看怎么执行的，执行得不好什么绩效都是没有用的

因为这些，所以还是能去 BAT、TMD 就去吧

不写代码就没有 bug

赞成

建议写在合同里

上家公司就这么做，然后倒闭了。

bug 纯粹看数量还是还得判断什么类型的 bug

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

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

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

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

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

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

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

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

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

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

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

@WinnieNumberTwo 是的 非大厂

@dilu 说的好

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

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

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

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

bug 就会被接受。

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

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

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

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



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

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