看到这样标题，我的第一反应是反对老板这样做。作为开发人员，我讨厌有人指着我的鼻子说：这是你的责任，你写的代码出了问题。我通常会争辩，有时会恼羞成怒。但如何能用充分的论据来证明这样做法是不合适的呢？我还真没有系统的考虑过。所以，当看到有这样的一个讨论时，我马上被吸引住了，群众的力量是巨大的，群众的思想放光芒，我从讨论中学到了不少知识，有了这些论据，当日后不可避免的遇到指责时，至少心里能找到不少安慰。

　　下面先看看这个伟大讨论的发起人对自己遇到的问题的描述吧：

　　在近的制度改革中，老板要在我们的 bug 跟踪单模板中加入“谁的责任”项，他认为这样能提高程序员的责任感（跟踪单上已经有地方指明 bug 是属于哪个功能/用例的）。我认为这样会打击程序员的士气，导致人们相互指责，而且对于一些由于需求问题而被当成 bug 的情况无法填写。

　　有没有其它的能反驳这种做法的有效方法？有谁知道哪里有关于这方面问题的文章可参考的？我希望能拿这些给团队的同事和老板看。我认为这种文化是不可接受的，希望能在实施前阻止它。任何建议我都十分感激。

　　有网友一针见血的指出这样做的弊端，是：

　　如果有人认为“谁的责任”项要填的是自己的名字，他不会报告这个 bug。这个会导致团队的 bug 数减少。

　　对这样一个问题，我欣赏的回答是下面一条：

　　对于这样的做法，我首先要做的是问你的老板他这样做究竟想解决什么问题。有很多显然更好的方法能解决他想解决的问题。

　　对于一个事情，真的需要有一个人站出来承担责任吗？如果是这样，那你的老板可能在其它什么地方出了问题。一个好的工作流程是需要多人共同参与的，在软件正式发布前，它需要经过分析人员，开发人员，代码审查人员，测试人员。如果你们没有经过所有的这些步骤，那么严格按照这些步骤开发将是解决你的老板的问题的好方案。如果你们已经是按照这个流程去做了，那么，哪个个人应该为此承担责任呢？也许谁都不应该，也许应该谴责的是这些历史遗留的代码。

　　让人们背后议论、相互指责会引起很不好的后果，千万不要随意给人涂黑点，一旦做了很难挽回。这样做解决不了任何问题。很少有人会故意的大意犯错误。你的老板应该自我反思，看看问题究竟是出在什么方面，看看如何能让这种错误不再发生。

　　这样做了后，你能清楚的看出，如果有人在不断的犯错，这很可能是完全不同另外一个问题。

　　但是指 stackexchange 网站上受欢迎的回答却是下面一个：

　　告诉他，这外行人对内行人所说的问题根源的外行叫法(如果没有专门的项来描述这个，一般会使用注释来替代)。

　　你可以在网上搜一下软件 bug 根源分析等内容，你能搜到丰富的资料来证明你的观点1， 2， 3， 4， …。

… 一个软件 bug 的根源通常不是在某个单个的开发人员身上(填写此项时特别要注意这点)…

　　这清楚的说明了为什么“问题根源”是专业的，而“谁的责任”是外行的。能说明个人责任当然很好，但有时候问题的根源会产生在开发团队“外部”。

　　告诉你的老板，如果需要指明一个承担责任的人，“问题根源”项应该写成这样：“编码错误由鲍勃提交，版本号是 1234，吉姆在代码审查中疏漏了此错误，审查号是 567”。“问题根源”项的目的是要记录这样的内容，包括一些在开发团队之外的原因。

　　例如，如果一个 bug 是由于硬件引起的(受到谴责的应该是开发团队外的购买/测试硬件的那个人)，用“问题根源”能很好的描述这个问题，而“谁的责任”会导致问题跟踪线索中断。

　　对于其它的开发团队之外的人导致的错误也能这样记录 —— 测试错误，需求变更，管理决策问题等。比如，如果管理部门决定不投入资金制备灾难应急硬件设备，在数据中心停电宕机事件上填写“哪个程序员的责任”将毫无意义。

　　你遇到过这样的事情吗？你对此有何见解？