看到Stack Exchange上对于在Bug Report中加入"Person to blame"栏位的讨论，这的确是一个很好的题目，这里面包含了很多的东西。该不该加这个栏位且不说，其实最重要是看动机和目的。
为什么管理者要加这个栏位呢？ 自然是可以方便地统计出哪个组、哪个伙计引入的Bug状况。这可是绩效考核中一项非常有效的KPI(核心绩效指标)，一定能符合SMART原则，随后的奖惩也就有了基础。开发者必然会认真对待，这样也可以提高大家的责任心。这是管理者的思维。可它真得有效吗？如果能读读<<人件>>，或许会理解地再深入些。
首先分析一下管理思维的基础。
管理上是基于X理论还是Y理论呢? 就是认为人本恶还是人本善的问题。认清事情本质是行为的基础，所以要先分析问题（根本原因分析）。不同的理论，会导致不同的结论。比如：Bug是因为人造成的，还是代码造成的? X理论会很容易得出因为人的惰性、马虎、大意而导致了问题。为什么不认真分析所有可能性？为什么没有做好充分的测试？......
而Y理论，则可能会得出可能是因为设计评估不充分、培训不足、经验分享不充分、代码Review不充分造成的问题。为什么没有让开发者事先了解可能的问题呢？为什么没有人或方法可以提前预防呢？为什么编码规范规定了却仍然有漏网之鱼呢?
两者最大的差别在于它们思考时所针对的目标不同。如果焦点在人身上，态度或职业精神就变成了根本原因。反之，焦点如果在流程和制度上，思考的方向就有如上面的例子一样，完全不同。哪一种更有效呢? 什么是可控的呢？难道公司要控制人吗?
再举一个典型的问题，Coding Review是要Review人呢，还是要Review代码？ 可以试着用两种方式思考一下。
再来看看这个指标的真的是可衡量吗?
对软件开发行业而言，想找些有效的量化指标是很困难的事。 引入Bug的数量和解Bug的数量能体现出一个人的开发能力吗? 或者说一个引入了十个Bug的人会比只引入了一个Bug的人技术差吗? 在绝大多数情况下，答案都是否定的。它里面还有复杂度问题、职责问题、经验问题、专业领域问题，最重要的是项目中的行政因素。想想有多少产品是在管理层的压力下上线的？不过是在项目进度的修饰之下罢了。多少功能是硬上的？又有多少功能是求有不求精的？经过多少加班，产品终于上线了，项目终于完工了，但是开发者的苦日子才刚开始。而管理者呢？
(题外话：所以在这个问题上项目经理负责制，有时不如产品线经理负责制来得好。) 如此说来，谁是Bug的真正始作俑者呢？
最后，再看看可能的效果。
上有政策，下有对策。如果只是加个栏位，大家先填着，那就不用说了。当真从制度面推行时，双方的互信必然受到影响。因为相当一部分开发者会感觉已经被置于不被信任的位置。至于如何应对，只有想不到的，没有做不到的。管理者可以做个换位思考，如果头上悬着Bug数的利剑，在冲锋献阵之前是不是要想想有没有可能出师未捷绩效也会一塌糊涂？
总之，加这个栏位前，一定要想好你拿它做什么？ 能不能达到你的目的？ 程序员是开发者，并不是麻烦制造者！
转载请注明出处: http://blog.csdn.net/horkychen