会不会 越是提前消灭 bug ，就越是没有绩效？

我觉得把一个项目带得非常的平稳，每天风平浪静的，才是真的有水平。各种风险都在萌芽阶段搞定了，不会等出现大坑了，才去想办法填坑。

项目做得每天都像在惊涛骇浪里行船，看起来表面上很忙，每天过的担惊受怕、烧香拜佛，每个人都不舒服吧，聪明一点的BOSS也不会喜欢每天看惊涛骇浪吧？

所以需要懂技术的boss。

所以需要懂技术的boss。

撸起自己的袖子，露出洁白的双手，勇于去擦别人肮脏的屁股

管理是一门深奥的学问，同时也是艺术
过度依赖 KPI 的管理手段，毫无疑问都是失败的

跟领导个人风格关系不大，这是公司考核制度里的KPI设定不合理。我们对于bug的要求是，项目内网测试期间有很多bug或者很少bug都无所谓，不考量这个；项目外网正式上线之后，一旦有bug，则视为外网漏出bug，影响绩效，跟你是否立即修复无关。因为原则是最终质量越高越好，用户用到的产品需要保证质量。

@Numbcoder 好例子，很应景。

两个例子：
1.扁鹊三兄弟，大哥治未病，二哥治病刚出现时，扁鹊治病最严重的时候，因此扁鹊的名声最大；
2.辛亥革命，袁世凯佯装久攻不下，以达到养匪自重的目的，否则难逃兔死狗烹的下场。

我这里KPI属于放在那里看得那种 等到扣钱了 就发挥作用了 就我的情况简单回答LZ问题： 是

@xatest 这个也会悲剧
A、B两人职位相同、层级相同，A能力较强，做比较复杂的项目、做得比B多，是B的3倍，B做简单的，工作量也小。A出错的概率会比较小，但是耐不住工作量基数大、难度大，出错的 *数量* 可能比B多。结果A因为Bug影响绩效，B升职了、A辞职了。留下的都是庸人

这个问题比较专业。

之前的经理，不懂技术，但是50块钱奖励，一个 bug 扣一块钱，扣完为止。

那次得了 30 块钱，现金哦，哈哈。

个人觉得大部分老板还是希望少看到 bug 的。

记得看杜拉拉升职记中有这么一场景，杜拉拉是这样解决的：把所有工作进度都报给上司，（让上司明白你天天在干吗，最主要是要让上司明白你在他的掌握之中，一切都在有序进行中，）并且遇到难点与上司一起讨论，并提出自己观点！（让上司明白你为工作处理哪些难题，）

要同绩效管理战斗的程序员真是悲剧

@zealot @xatest
A, B两人职位相同，C是他们的leader。A接到项目后，从架构设计到代码编写稳扎稳打。B接到项目，从来不管什么性能，扩展性之类的，就开始写代码。最终B比A略快的完成了项目原型。两个项目上线后，B的项目频繁现各种bug，但是B每次都摆出一副视死如归的架势，通宵改bug之类的，C感动的内牛满面。。
最终的结果是B越来越受重用，而A渐渐被淡忘。原因是B执行力高，做事不怕吃苦。由于B有改不完的bug，和因为系统架构缺陷，系统被一次次推翻重做，所以开始出现人手不够，然后开始招小弟，B的队伍开始慢慢壮大，职位也逐步上升。而苦逼的A最终也只能选择走人了。。

所以我总是建议程序员每写一行代码就扣他20块钱。

@zealot 你把话题范围扩大了，这里仅仅说的是bug的评估。对于评估人的能力和项目的复杂度，A的能力更强，如果在我们这，职位和层级上跟B是不一样的。

@Numbcoder 所以我说制度需要保证“上线漏出bug就会影响绩效”，而不是看是否立即修复，就算出问题也是将功赎罪而已，并不是没有罪。如果领导不制定、理解、遵循这样的管理方法，是领导糊涂。
孙子曰：
　　 夫用兵之法，全国为上，破国次之；全军为上，破军次之；全旅为上，破旅次
　　 之；全卒为上，破卒次之；全伍为上，破伍次之。
　　 是故百战百胜，非善之善也；不战而屈人之兵，善之善者也。故上兵伐谋，其
　　 次伐交，其次伐兵，其下攻城。攻城之法，为不得已。

老子也说：大白若辱，大方无隅，大器晚成，大音希声，大象无形。
善战者无赫赫之功，所以最NB的将领是很少有“战功”的，不战就可以屈人之兵，上线不用修补bug就可以稳定运行。

技巧就是让 该出bug的是时候出bug 。 看见bug 不管 研究好大致解决办法，等领导发现bug 在去改。

当然太大的漏洞 除了那是要命的。

@Numbcoder @xatest leader关心的是什么时候上线（多少有点不可控）。而有很多bug则在l预期之内。作为工程师，能保证进度而又能不给l惹麻烦（太严重的阻断型bug）等于帮l解决了首要矛盾，他心中自然会记住你的好。工程师之间比较bug多少。。。则完全不在l的维度雷达之内。。。。//再重复一遍：客服组和测试组不就是解决bug的嘛。不能按时上线简直是要命哇。

看了楼上诸君的回复，顿感理想与现实又疏远了很多。