当我看到这样标题，我的第一反应就是我要反对老板这样做。因为作为一名开发人员，我最讨厌的就是有人指着我的鼻子说：这是你的责任，因为你写的代码出了问题。我通常都会争辩，甚至有时会恼羞成怒。但是如何能够利用充分的论据来证明这样做法是不合适的呢?好吧我还真没有系统的考虑过。所以，当我看到有这样的一个讨论时，我瞬间就被吸引住了，而群众的力量自然是巨大的，群众的思想也能够绽放光芒，我能够从讨论中学到了不少知识，而有了这些论据以后，当我在日后不可避免的遇到指责时，那么至少在我的心里能找到不少安慰。下面就让我们先看看这个伟大讨论的发起人是如何对自己遇到的问题进行描述吧：
在最近的制度改革中，老板要在我们的bug跟踪单模板中加入“谁的责任”项，他认为这样能提高程序员的责任感(跟踪单上已经有地方指明bug是属于哪个功能/用例的)。我认为这样会打击程序员的士气，导致人们相互指责，而且对于一些由于需求问题而被当成bug的情况无法填写。
有没有其它的能反驳这种做法的有效方法?有谁知道哪里有关于这方面问题的文章可参考的?我希望能拿这些给团队的同事和老板看。我认为这种文化是不可接受的，希望能在实施前阻止它。任何建议我都十分感激。
有网友一针见血的指出这样做的弊端，就是：
如果有人认为“谁的责任”项要填的是自己的名字，他就不会报告这个bug。这个会导致团队的bug数减少。
对这样一个问题，我最欣赏的回答是下面一条：
对于这样的做法，我首先要做的是问你的老板他这样做究竟想解决什么问题。有很多显然更好的方法能解决他想解决的问题。
对于一个事情，真的需要有一个人站出来承担责任吗?如果是这样，那你的老板可能在其它什么地方出了问题。一个好的工作流程是需要多人共同参与的，在软件正式发布前，它需要经过分析人员，开发人员，代码审查人员，测试人员。如果你们没有经过所有的这些步骤，那么严格按照这些步骤开发将是解决你的老板的问题的最好方案。如果你们已经是按照这个流程去做了，那么，哪个个人应该为此承担责任呢?也许谁都不应该，也许应该谴责的是这些历史遗留的代码。
让人们背后议论、相互指责会引起很不好的后果，千万不要随意给人涂黑点，一旦做了就很难挽回。这样做解决不了任何问题。很少有人会故意的大意犯错误。你的老板应该自我反思，看看问题究竟是出在什么方面，看看如何能让这种错误不再发生。
这样做了后，你就能清楚的看出，如果有人在不断的犯错，这很可能是完全不同另外一个问题。
但是指stackexchange网站上最受欢迎的回答却是下面一个：
告诉他，这外行人对内行人所说的问题根源的外行叫法(如果没有专门的项来描述这个，一般会使用注释来替代)。
你可以在网上搜一下软件bug根源分析等内容，你能搜到丰富的资料来证明你的观点1, 2, 3, 4, …。
… 一个软件bug的根源通常不是在某个单个的开发人员身上(填写此项时特别要注意这点)…
这清楚的说明了为什么“问题根源”是专业的，而“谁的责任”是外行的。能说明个人责任当然很好，但有时候问题的根源会产生在开发团队“外部”。
告诉你的老板，如果需要指明一个承担责任的人，“问题根源”项应该写成这样：“编码错误由鲍勃提交，版本号是1234，吉姆在代码审查中疏漏了此错误，审查号是567”。“问题根源”项的目的就是要记录这样的内容，包括一些在开发团队之外的原因。
例如，如果一个bug是由于硬件引起的(受到谴责的应该是开发团队外的购买/测试硬件的那个人)，用“问题根源”就能很好的描述这个问题，而“谁的责任”就会导致问题跟踪线索中断。
对于其它的开发团队之外的人导致的错误也能这样记录 —— 测试错误，需求变更，管理决策问题等。比如，如果管理部门决定不投入资金制备灾难应急硬件设备，在数据中心停电宕机事件上填写“哪个程序员的责任”将毫无意义。
你遇到过这样的事情吗?你对此有何见解?