IT企业把BUG做为评定开发人员绩效的一个指标合适吗
开发人员的 performance 不应该由任何数据化的 KPI 评定。参见：UI 设计部门如何绩效？
■网友
这是不得已而为之的。因为代码的好坏、高效与否，必须经由高水平的人、花很多时间来review才能作出评定，这个成本过于高昂，无法承受，所以只能退而求其次，追求其他的可以更加简单获得的指标：例如代码行数（意味着承担的功能更多），BUG数（意味着质量）等等。这些指标当然有问题，比如代码行数多可能意味着编写效率低下，反之BUG多也可能仅仅是承担了很多责任的后果。但是企业总要在成本和收益之间，取得一个妥协，方法无所谓，总归必须要有指标——————所以各种管理方式、质量体系，就层出不穷了。任何一种质量体系，都不是万能的。所以BUG数可以用，但是也需要其他的指标（工作量、难度等等），来平衡一下，避免出现“多做多错、少做少错、不作不错”的消极态度。
■网友
bug天天有，改也改不完QA发狠写出个奇葩case，程序崩溃，改协议变动/客户需求变动/版本更新，连带regression，改一条预编译bug几年都没跑到，今天更新IDE/发布环境，出包崩溃，改二义else，二义{}，多余的*/，换个compiler/linker，崩溃，改...喏~你还要不要程序员赚钱吃饭了？
■网友
可以作为条件之一，但是要把相关准则都明确，比如怎么界定bug和功能，怎样界定bug的归属，在开发期怎样界定bug的严重程度。举个例子来讲，每个人的项目组中总有那么一两个救火队员型的员工，负责了超过系统内几乎全部的底层模块，然后某应用层需求A在底层模块开发的过程中没有被设计进去，而做应用层开发的人在沟通不够的情况下通过各种黑暗设计做出了一个有很多bug的实现，然后测试报bug。要完全修复肯定要从底层进行，但是具体的开发工作又是由上次的程序员进行的。在这种情况下，这个bug算应用层bug还是算底层需求？bug提给应用层程序员是不是要扣绩效？底层人员花时间修复了是不是要加绩效？等等等等把这个例子里的情况解释清楚了，也就差不多了···
■网友
作为指标之一没什么问题。虽然没人能避免bug，但是良好的编程习惯和优秀的程序结构设计以及保持UT的好习惯，能很大程度降低程序出现bug的几率。
■网友
首先，bug的界定，我估计就很有分歧
■网友
【IT企业把BUG做为评定开发人员绩效的一个指标合适吗】 蠢。大家开发同样一段程序吗？象高考一样，试题是一样，答案才能一样。程序的多少，长短，难易程度，又怎么来判断，BUG和BUG也不同吧。我这个外行都明白的道理，不知道谁弄来这种幼儿园级别的考核指标。
推荐阅读
- 服贸基地■江苏认定首批服贸基地和服贸重点企业
- 浙江“最美建设人”丁泽成：青年企业家传承浙商品质
- 文旅上下游企业“抱团”助力旅游市场回暖
- “十三五”期间新增减税降费累计将达7.6万亿元左右——为企业减负 为创新加油
- 『黄金时间』请认准这个蓝色的标志！ 黄金时间丨同行业中用水最少的企业
- 黄金时间■黄金时间丨江苏企业节水改造缺钱？快来申请“节水贷”
- 黄金时间■黄金时间丨你喝过和纯净水口感一样的海水吗？企业用风能代替网电加工淡化海水
- 无锡市惠山区境内外主板上市企业达11家
- 接待日|省生态环境厅来通开展“企业环保接待日”
- |淮安区国资办推进国有企业 退休人员社会化管理工作