一般程序员到了年底除了忙着交货、结案之外，还要考虑的就是今年的绩效如何了。

　　通常的公司都会在每年的年底制定好来年的KPI（Key Process Indication，企业关键业绩指标），我所在公司经营了20年的国际品牌，在这方面更是严谨。恍惚间，依稀记得今年的KPI中有一项就是BUGS/KLOC(K line of code)，翻译成中文就是千行Bug率。

　　一年下来，代码写了不少，翻翻ClearQuest，不由惊呼，Bug这么多！

　　还记得第一次看到的时候都不敢相信这些是自己的Bug:太多了。我对自己的代码水平还是很有信心的，以前曾经用C和C++写过程序。

　　冷静下来后，仔细的对这些Bug进行了分析。这一分析归纳，发现因为纯粹个人失误引起的Bug很少，毕竟写过C代码的人都是很严谨的。发生Bug的原因主要是因为需求的变动；接下来就是因为其他人的接口更改导致的错误；还有就是一些界面方面的问题。也许，这些都可以给我很多理由来说明自己并不是表现的那么差。不过年底了，我要专业答辩，有KPI的指标要求，那我该怎么办呢？会有这个机会给我解释吗？所以我不由得想到主管看到Bug时候会是什么反应。

　　还记得温伯格的书中提到一个笑话：上帝问程序员今年最大成就是什么。程序员说Bug少了一半。上帝听不懂Bug是什么，就去问宰相。宰相耳语一番，上帝大怒，吼到不许再有Bug。自此以后每年朝拜上帝，程序员都说今年没有Bug。上帝很开心，不然的话，只有听到：上帝很生气，后果很严重。

　　听上去是一个笑话，温伯格也把这个归为“字典魔法”。但是我想谈谈当我们不同的角色看到Bug的时候应该有的合适的反应，一家之言！

　　1. 程序员

　　通常说的程序员或者软件工程师，一年辛苦下来看到自己的Bug那么多，正常点的有点羞耻心的都拉不下这个脸。

　　我觉得这个时候最忌讳的就是想尽办法推卸责任或者根本不屑一顾。无论如何，有Bug就表示系统还有缺陷，还不完美，个人还有提升空间，就此提高自己一件好事情。

　　根据从需求、分析、设计、代码、边界、部署等几个方面进行的Bug分类，我发现大多数的Bug其实都是设计错误而非简单意义上的代码错误。我相信一个程序员编程语言用上半年就很少会因为纯粹的语法而导致错误。

　　每个问题都有无数种解决方法，很难简单的划分好与坏。所以通常问题出现在面对需求、面对问题时候我们做出了错误的决断。这些错误决断可能来自根本不成立的假设、根本不了解实际情况、已经发生变化的边界模块或者处理方法的不科学。还有一部分是态度问题，另外就是做事情的方法不科学。

　　我们可以及此来改善自己分析问题的方式，从而提升自己解决问题的能力，扩充个人解决问题的思路和方式。

　　态度方面主要是沟通的不主动。程序员相对而言给人的感觉都是比较闭塞，不愿意跟人打交道。作为一个职业素养较高的软件工程师而言，应该把沟通作为职业技能的一部分。我们在和机器沟通的能力之上还应该搭建一层和人交流的平台。

　　2. 项目经理

　　我个人觉得项目经理对Bug的态度在组织中极为重要。

　　在公司里面下面的人和高层沟通的机会很少，意见都是通过项目经理的报告向上传递。而高层对Bug的反应也是通过项目经理的行为变化间接的影响到下面的日常工作上。

　　我觉得项目经理面对Bug应该表现出最大的冷静以及最宽容的心态。切莫看到Bug数据的时候，简单比对谁对Bug的责任最大就教训谁。毕竟项目中不同模块的难度不一样，哪怕是同一件事情，和不同的人打交道都可能会导致不同的结果。

　　遇到Bug，项目经理应该考虑：是否因为进度问题而赶工导致大家压力太大；是否输入的工件质量太差；是否有很好的沟通平台；是否因为自己做事情太武断，没有听取大家的意见导致基线偏离等等。

　　因为上面这些问题而出现Bug，项目经理改善起来应该不是太难。而且交流得当可以促进项目成员间的磨合。例如，赶工现象严重，可以和大家解释一下市场压力太大，竞争对手太强；输入的工件有问题，可以找到当事人或其主管交涉，争取自己的正当利益；每个星期都坚持开周会；每个人的周报项目经理都仔细查看并提出建议和意见。

　　相反，如果发现Bug大家却不及时沟通，项目经理和项目成员间的抵触情绪自然会变大。毕竟这个也算绩效的一部分。很多事情不及时坦诚的沟通，程序员会认为自己很委屈，认为项目经理只顾自己利益不考虑别人。

　　程序中发现Bug是不可避免的，只有大家通力合作，努力提高产品的质量，程序才能更快更好的完成，成为双赢的局面。