有公司把 Bug 数量作为绩效考核的吗？我们刚来了个经理把 Bug 数量作为绩效考核。

[lietoumai]

领导：忙什么呢？
撸主：忙着写 Bug 呢

[cong]

@lietoumai 哈哈，我们不生产 Bug,我们是 Bug 的搬运工。

[Risin9]

我们公司要出个根据解决 bug 修改文件的提交记录追溯 bug 的责任人的系统，有点扯...

[oott123]

bug 越多工资越高吗

[opengps]

有参考意义：
bug 太少可能存在隐含问题开发私吞了等原因
bug 太多则可能是业务复杂或者水平不够等情况
但是 bug 数量一定不能用来形容项目质量好不好

[learnshare]

总要找个办法裁员嘛

[anteros]

想想，为啥这种人都可以做经理。
你细品。

[Frank520]

我们 CTO 看 bug 数量评绩效

[q8515620]

你还没说经理的考核标准。
越多越好：说明工作量饱和？
越少越好：说明代码质量高？

是哪种呢？当然，这两种情况都不应该作为考核标准。

[cong]

@php01 我没觉得我们经理有问题，这个事我也说不清好坏，想听大家各个角度讲讲。但是您的逻辑好像有点不对，一个人做了一件脑残的事，不能说这个人做啥都脑残。

[golden0125]

只有惩罚,没有奖励的机制都是耍流氓

[coderluan]

如果你签合同时候不涉及绩效相关内容，就没任何问题。否则的话，就不好说了，可能是单纯的作为绩效标准，只要不是唯一标准问题就不大，也可能是为减薪或者裁员做铺垫和找理由。

[Rwing]

那么如何统计 bug 数量呢？是不是可以徇私？

[bkmi]

所以你们没一个人能提出异议，并且怼回去，就这么执行了？

[anteros]

@cong 在这个遍地是机会和选择的时代，选择一叶知秋观人法是性价比最高的办法。
特别是当你脑袋里的样本库足够大，分好类的时候。
比如，据我观察，中医的拥趸者，大多也对反转基因有兴趣。比如大多数基督徒和佛教徒是伪善的，不可交，满嘴谎言，话不可信。
虽然会有误伤，但是性价比高。

[wuhanchu]

有啊。 测试部门还以此来发奖金，有一个刚毕业的测试妹子，同一个 bug 给我提了 5 次，然后我不干了。

[cong]

@bkmi 最起码是上下级关系，忒回去没用，还可能今后给你找麻烦。后续再看看能不能有别的解决办法。

[beidounanxizi]

拿这个 来当做绩效裁定 也不会被劳动仲裁部门 支持的呢 需要你确认同意

[fhsan]

就和 kpi 一样，最大多数人的最大价值相对可靠的计算方法

[fen]

BUG 不能作为唯一标准。
但 BUG 多的人，要么需求理解有问题，要么水平真不行。

[NonClockworkChen]

@fen 难道不能是需求本身不合理或者文档不够清晰吗

[xcstream]

考核 2 个字就是有恶意的，不管什么指标

[Leigg]

@wuhanchu 你也是牛批

[chinuno]

bug 数量做考核没有，但是以前有过提交 patch 数做绩效考核，要求每个人每周至少提交十几个 patch

[jrtzxh020]

我们公司，bug 是 kpi 一个指标哦，当然是指生产上的 bug。。

[aut0man]

这不应该是..很正常的吗。我司一个后端，我来的时候她就在了，开发个模块，bug 不断，提了改，改了提。一周过去了，刚把一个模块写好（一般人 2-3 天吧），我看了眼 sql，一言难尽。你说这种的你不考核一下，年底了，她和别的开发又快又好的领一样的钱，别人不难受？那不成了劣币驱逐良币？（当然我入职后没俩月她被辞退了）

[dcsite]

@php01 是的，比如你的帐号里有 PHP 这字样，我就认为你很菜，反正我只管联想，不需举证。

[luckbbs]

对测试部门来说很正常

[aoboco]

不扣钱就行了

[zjl03505]

这需要看 bug 的权重以及是否是唯一的绩效考核点来评判，若并不是唯一的且不是占据主要权重并没有什么不可接受

[anteros]

@dcsite 是的，你怎么想，那是你的事，不是我的事。

[flankechen]

其实，怎么衡量程序员的工作量就是一个天大的难题，不知道有没有管理大师研究过这个问题了

[lagoon]

没啥好说的。所以那么多人，要爬到管理位。
人家权力大，就是为所欲为。

[cong]

@jrtzxh020 线上 bug,这个是测试的指标吗？

[cong]

@aut0man 那个。。这个后端要开除了吧。。是能力不行吧。这种要除外吧。

[hantsy]

哈哈，那些开源项目，要是这样评价就完了。

一个开源项目是否活跃，流行，Bug 数据是最基本的依据。如果你关注一些国外的技术大会，经常在介绍一些新兴项目的时候，他会给一个统计图，我们 BUG 数量从去年的 XXX 增加到今年的 XXX，来说明这个项目关注的人数急剧的增加。一个没有 Bug 的软件，只能说这个软件没有人用，只要有人用怎么会不提 BUG。

有这种想法的公司说明领导可能以前真的是搬砖的，认为软件和 BUG 都是死的，就和砖一样，搬了一块少一块。

[hantsy]

@Frank520 你们 CTO 应该不是做软件出身的。

[cong]

@hantsy 你好，我看到你是自由职业者，我挺想和你聊一下的。方便加你微信吗？

[tabris17]

以后就不叫 bug 了，叫 feature 吧

[DarrenLuo]

我能说有公司拿代码行数来玩的麽

[Erroad]

可以作为指标，但是要综合开发量、工期、任务难度才行

[frantic]

我之前有家公司是这样，结果有个牛逼的同事写复杂点的逻辑都直接 catch Exception

[jason19659]

少写少错？

[aut0man]

@hantsy 我之前是认可 bug 数量统计这一套的。看了你说的觉得很有道理...那什么维度评价开发才是一个比较合理的评价体系呢？（喜欢可以说详细点，忙的话随便点我两下，printf “thx (σﾟ∀ﾟ)σ..:*☆”；）

[Mmdhejx]

好像之前看过类似的帖子……

[300]

快年底了

[zhiguang]

我不写不就没 bug 咯