新年又到了，不得不感慨时间过的快啊。不知不觉，也打了本命年。都说本命年难过，可是我这个没啥信仰的人还不知道找谁祈福。无论如何，都祝愿看到这篇blog的伙伴们、同仁们、兄弟姐妹们身体健康。
到了年底除了忙着交货、结案之外，还不得不打小九九的就是今年的绩效如何了。通常上点路子的公司都会在每年的年底制定好来年的KPI，更何况我所在公司20的国际品牌经营，这方面自然流程上很严谨，效果如何再议，起码本人还是持保留意见的。
恍惚间，依稀记得今年的KPI中有一项就是bug of kloc。翻译成中文就是千行bug率。一年下来，不忙不忙，代码好歹也写了一通一堆一什么的。翻翻clearquest，不由惊呼，bug这么多。还记得第一次看到的时候都不相信这个是自己的bug，太多了。我对自己的代码水平还是很有信心的，好歹以前也是写c和c++的。送到军审的阿。怎么这年头用c#反而问题这么多。冷静下来后，仔细的分析这些bug来。
这一分析，归纳，发现因为纯个人失误的很少很少，毕竟写c的人代码风格都是很严谨的。最多的是因为需求改变引起的，接下来就是因为其他人的接口更改导致的N多错误。还有就是一些界面什么的（最恨就是这个）。也许，这些都可以给我很多理由来说明自己并不是表现的那么差，不过年底了，我要专业答辩，有KPI的指标要求，那我该怎么办呢？会有这个机会给我解释吗？所以我不由得想到主管看到bug时候应该会是什么反应。
还记得温伯格的书中提到一个笑话，上帝问程序员今年最大成就是什么，程序员说bug少了一半。上帝听不懂bug是什么，问宰相。宰相耳语一番，上帝大怒，吼到不许再有bug，自此以后每年朝拜上帝，程序员都说今年没有bug。上帝很开心。不然的话，只有听到：上帝很生气，后果很严重。
听上去是一个笑话，温伯格也把这个归为“字典魔法”。而我更想想谈谈当我们不同的角色看到bug的时候应该有的合适的反应，一家之言。
首先当然是写代码的人。通常说的程序员或者软件工程师。一年辛苦下来看到自己的bug那么多，正常点的有点羞耻心的都拉不下这个脸。我觉得这个时候最忌讳的就是想尽办法推卸责任或者根本不屑一顾。无论如何，有bug就表示系统还有缺陷，还不完美，个人还有提升空间，及此提高自己一件好事情。首先做的事情就是给这些bug分分类。从需求、分析、设计、代码、边界、部署等等几个方面进行分类。我发现大多数的bug其实都是设计错误而非简单意义上的代码错误。我相信一个语言用上半年就很少会因为纯粹的语法而导致错误，而且每个问题都有无数种解决方法，根本无法简单的划分好坏。所以通常问题出在面对需求，面对问题时候我们做出了错误的决断，这些错误决断可能来自根本不成立的假设、根本不了解实际情况、已经发生变化的边界模块或者处理方法的不科学。有一部分是态度，还有一部分是水平也就是做事情不科学，其实这事最直接也是最快得发现自身问题的途径，我们可以及此来改善自己分析问题的方式，从而提升自己解决问题的能力，扩充个人解决问题的思路和方式。而态度方面主要是沟通的不主动。程序员相对而言给人的感觉都是比较闭塞，不愿意跟人打交道。的确，但是作为一个职业素养较高的软件工程师而言应该把沟通作为职业技能的一部分。我们在和机器沟通的能力之上应该搭建一层和人交流的平台。
其次，则是项目经理。我个人觉得他对bug的态度在组织中极为重要。毕竟是一个承上启下的人物。在公司里面下面的人和高层沟通的机会很少，意见都是通过项目经理的报告向上传递。而高层对bug的反应也是通过他们的行为变化间接的影响到下面人的日常工作上。所以，我觉得项目经理面对bug应该表现出最大的冷静以及最宽容的心态。切莫看到bug数据的时候，简单比对谁对bug的贡献最大就臭骂谁一通。毕竟项目中不同模块的难度是不一样，哪怕是同一件事情，何不同的人打交道都会导致不同的结果。最典型的就是需求的质量。对bug的影响应该说是最大的。所以，我觉得项目经理应该是首先分析出哪类bug对项目的影响最大，如果缺陷管理工具好的话，这个应该是很容易的。通常而言，大脑中直接反映出来的应该是是否是进度太敢导致大伙压力太大有点赶工，是否是输入的工件质量太差，是否没有建立很好的沟通平台，是否自己做事情太武断，没有听取大家的意见导致基线偏离。如果真的是这些问题，我觉得改善起来应该也不是太难，而且交流得当反而可以促进磨合。例如，赶工现象严重，可以和大家解释一下市场]压力太大，竞争对手太强。输入的工件，可以找到当事人或其主管交涉，争取自己的正当利益。讲好得每个星期的周会是否坚持开了下来，周报是否都看了。相反，如果发现bug多却不及时沟通，抵触情绪自然很大。毕竟这个也算绩效的一部分。而且程序员通常觉得自己很委屈，很多事情不坦诚沟通的话，会认为对方只顾自己利益不考虑别人，其实都是给老板打工，属于阶级弟兄，人民内部矛盾。
