我的老板决定在每个错误报告中都添加一个“负责人员”字段。我怎么能说服他这是一个坏主意？

#1 楼

告诉他们这只是专业人员使用的“根本原因”字段的业余名称（当问题跟踪程序没有专用字段时，可以使用注释）。

在网络上搜索类似软件错误的内容根本原因分析，有足够的资源证明这种推理1、2、3、4 ....



...缺陷的根本原因并非总是一个开发人员（这是该领域的重点）...


这就是为什么“根本原因”是专业的而“应责之众”却是业余的。个人责任制非常好，但是在某些情况下，它只是位于开发团队的“外部”。

当要怪一个开发人员时，告诉老板，根本原因字段肯定会解决这个问题（“鲍勃在1234号提交中犯的编码错误，吉姆在评论567“中错过了）。使用根本原因一词的目的是涵盖类似的情况，以及超出开发团队范围的情况。

例如，如果该错误是由硬件故障引起的（ （应该责怪的人是购买并测试了该工具的团队之外的人），根本原因字段可以解决这一问题，而“应归咎于单个开发人员”只会破坏问题跟踪流程。

这同样适用于由开发团队以外的人员引起的其他错误-测试人员错误，需求变更和管理决策。说，如果管理层决定跳过对灾难恢复硬件的投资，那么“责怪单个开发商”就不会在数据中心停电。

#2 楼

此类策略的另一个可能结果是，如果人们认为自己可能是“应责怪的人”，则不会举报错误，因此实际上会减少团队报告的错误数量。

#3 楼

我要用来反对它的主要论据是问他想解决什么问题。几乎肯定有解决同一问题的更好方法。

一方面，难道真的只有一个人要受责吗？如果存在，则说明您在做其他错误。一个好的过程需要花费分析师，程序员，审阅者和测试人员的大量工作，然后才能投入生产。如果您没有完成所有这些步骤，那么也许就是老板要解决的问题的解决方案。如果是，那应该归咎于谁？

让人们back咬和指责，试图避免黑标一旦消失就不会消失，这不是很好组。它什么也解决不了。很少有人恶意疏忽。您需要进行适当的回顾，看看出了什么问题以及可以做些什么来确保它再没有出错。

从中您可以清楚地看到一个人是否经常有过错，并且这可能是另一个要解决的问题。

阻止经理建立问责制的诀窍是免费提供，但实际上对您有意义。

#4 楼

该领域至少存在三个问题。

第一个问题是，指责人们不利于士气。好。但是，也许他并不在乎士气，而是想解雇糟糕的开发商。很难争辩。

第二个问题是，正确地解决这一难题将非常艰巨，而且会耗费大量时间。这比仅找出谁编写了不良代码要复杂得多。并且任何难以找出的潜在信息都可以被沙袋/欺骗。但是，也许他准备支付这笔费用并审核信息。很好。

更根本的问题是，该领域并不是采取行动的好标准。当然，他的代码将导致最多的缺陷，这将是一个不错的排名。但是，猜猜谁将排在榜首？可能是公司的创始人，或者也许是缺陷率非常低但效率很高的顶级开发人员，因此他编写了不成比例的代码。因此，他要么最终解雇了他最好的开发商，要么放慢了自己的速度，以至于他不再是他最好的开发商。而每个月写一行代码（最好是评论）的人可能会因其缺陷数量少而得到回报。

另一个软件度量标准失败。

#5 楼

现场缺陷的根本原因永远不会是一个人。尽职尽责的人会犯错误，而期望他们做到无误的过程是不合理的。如果您没有在部署之前通过手动或通过自动测试来验证对生产系统的更改，那么错误是不可避免的。

错误：


Bob忘记检查输入，程序除以零就崩溃了。


右：


在部署之前未检测到易被零除错误的代码。
已添加新的测试用例，以验证对无效输入的正确处理。代码已更正，所有新的测试用例都通过了。

#6 楼

将“应责怪的人”更改为“要赞美的人”

修复错误的主要人员会在上面标明自己的名字。

#7 楼

简单的答案。

“责备”字段将仅用作替罪羊和指责，士气将暴跌，团队信任将被破坏，每个人都将试图找到方法来证明某事不是他们的错修复它。人们也更倾向于对错误保持沉默而不是报告错误，因为他们不希望同事遇到麻烦。这完全适得其反。

更重要的是，由于诚实的错误而使人受害，或者尽快解决问题？

您的老板似乎认为错误是懒惰或草率的标志。他们不是。他们是生活中的事实。微软一年推出多少补丁？

#8 楼

如果您需要一点公民抗命，请让团队同意为每个错误列出该领域的所有开发人员。如果不合适，请写“我是斯巴达克斯！”代替。当然，重点是，您应对所有错误负责，而对指出任何一个错误的个人感到不满意。

另一种选择：一起玩。无需特别做任何事情-做好工作，并在几个月内尽可能准确地填写该字段。然后向老板解释，为每个错误分配责任会使团队中的每个人都不高兴和不自在。告诉他，大家都觉得所创建的错误与其他任何东西（技能，努力，理智）之间没有什么关联。 （如果您可以运行一些数字来表明确实没有相关性，这将有所帮助。）

甘地公民抗命：在每个字段上都贴上您的名字（除非其他开发人员加紧努力并提出他们的要求为他们的错误命名），并为每个错误（无论是不是您自己的错误）负责。没有什么比这更使该领域或怪罪某人的想法了。如果您的老板问您在每个领域的名字为何，那么您可以做出解释：“因为我认为发展不是责备游戏，如果您真的需要人们责备和钉十字架，那就把我钉在十字架上，然后让我的团队和平共处。”

#9 楼

我曾经让老板实施一个与此非常类似的系统，尽管它不是编程（这是日报的印刷设计），但概念和适当的响应是相同的。

她做了什么她没有在我们的文书工作中添加“责怪人”字段，而是给每个设计师提供了一组彩色贴纸。每个设计师都得到了一个不同的彩色贴纸，并被告知必须将所有在贴纸上使用甚至触摸过的设计都添加到该设计的文书工作中。确定部门所有错误的来源（文书工作中的错误，误装，不良副本，实质上是与错误等效的印刷品）

我们所做的事情是给了每个其他设计师四分之一的贴纸，以便我们每个人都有所有颜色，而不仅仅是在每个设计上都放我们的颜色，而是放上所有四种设计师的颜色。

不要只在[Blame]框中输入您的名字-每个人的名字都在团队/项目中，并确保整个团队都这样做。彼此有关，最终大大减少了错误。她虽然是位经理，但并没有意识到自己的主动性最终使我们团结起来并提高了生产力，而是束手无策，解散了不干胶标签系统，并宣布它是失败的，并正式谴责我们所有人。

#10 楼

这将惩罚他最多产的程序员。奇怪的是，一两个人可能是从事最多项目的最好的员工。如果您在一个10人的部门中只有一个编码员，他只是输出的源泉，并且他编写了60％的接口代码，那么60％的错误将在他的代码中。

说明这个系统会让看起来写最多代码的人是最糟糕的程序员，写最少代码的人是最好的程序员。

#11 楼

这听起来很像斯科特·亚当斯（Scott Adams）指出迪尔伯特（Dilbert）的尖头毛发老板的Bug赏金失败的智慧。沃利宣布他要去“给他写一辆新的迷你货车”。

迪尔伯特漫画书发行于1995年11月13日，来自官方迪尔伯特漫画书库。我记得有一次，当Snow Snowing有人指出“不跌倒”并不是高手滑雪的征兆；但是，常常有一种迹象表明，它什么也不做（或者根本不滑雪）。

错误的编程和糟糕的设计可能会在代码中引入错误。但是，它们也可能是编写大量困难代码的结果。叮叮产生最多错误的人与叮叮那些不良生产力的开发人员一样，叮叮那些高效率的错误开发人员。

听起来您的老板可能对缺陷数量感到沮丧。团队中的人是否对质量充满热情？为原因创建一个“ what”字段而不是一个“ who”字段可能会更有效率。例如：需求变更，设计缺陷，实施缺陷等。除非有一个集体来提高产品质量，否则即使失败，也会失败。

#12 楼

也许您应该将其视为“谁最有能力修复bug？”我的一部分也觉得，你弄坏了，修好了。应该有一些责任感。

我不同意保持某种评分。有些人会创建更多的错误，因为他们需要处理代码的更复杂的部分。如果代码行不是一个有用的指标，我怀疑每行代码的bug会更好。代码永远都不会被检入。

在某个时候，经理应该知道谁在做自己的工作，谁没有做，以及谁做得更好，因为团队的其他人都在做。

#13 楼

您的实际问题是，在说服老板说将一个人归咎于错误报告后，这是一个坏主意，这是您离开公司之前如何改变文化的一个好主意。但是当然改变文化要求他真正了解为什么这是一个坏主意。

这是一个很高的要求。除了改变主意之后变脸的问题之外，还有一个基本问题是，主要考虑个人责任的人通常会在这种思维定势中考虑解决方案。

您要求撰写有关此主题的文章，然后想到了Peopleware。在产出难以衡量的情况下，如何管理从事创造性工作的人员受到高度重视并以一般术语进行讨论。问题是您阅读本书并没有多大帮助，您的老板必须阅读本书，并至少相信其中一些内容。

奇怪的是，因为这里的问题更多是关于人而不是错误报告，它比程序员更可能属于Workplace。但是软件项目的成功通常很大程度上可以追溯到人类的社会互动，因此，真正的答案通常主要是关于超越软件的事情。

我唯一的另一半建议是（（或说服一位同事说（因为您计划离开）您愿意为项目的成功承担全部责任，并且您的名字应该始终在现场，因为即使其他人直接犯了错误，您仍然负责确保团队中的每个人都做好质量工作。

当然，这是胡说八道，您怎么能支持它，但是有些人（尤其是那些受到很大责备的人）真的把东西吃光了。罗纳德·里根（Ronald Reagan）曾经每次都在其政府中的任何成员陷入丑闻时公开承担个人责任（而且有很多人），而且每次政治上实际上都做得很好。对您来说最好的部分是责任通常没有任何实际后果，他们只是认为您是承担责任的自立人。

这也许不是责任的根源。这对我来说根本没有任何意义，因此我很难预测它什么时候会起作用，但是我亲眼目睹了它似乎没有生意的时候能起作用（在工作场所，不仅仅是里根的例子）。 >

#14 楼

奇怪的是，以前没有人提到过：
在bug跟踪器中添加这样的功能会激发员工尝试玩系统的游戏。

对于像提出的问题，以及其他类似的想法（按代码行数支付，按bug数支付）。这将鼓励许多人专注于获得良好的成绩，而不是解决与他们正在使用的软件有关的问题。 ，然后将其推给其他人，可能会导致开发人员误解了问题的原因（或者将工作交给了另一位开发人员，该开发人员不知道代码的这一部分，而该部分的代码最多，最不了解，错误的主要原因）导致花费更多的时间和精力来解决问题。

#15 楼

人们不会去犯错误，而是制定了任何策略专门针对可能是或不是人为错误的行为负责，这是荒谬的-更不用说非常不专业了。

至少，分配一个负责并“解决”问题的“负责方”，或者提出跟踪和/或防止发生类似事件的计划，将是很好的。有时解决方案不过是额外的培训。我曾在许多公司中工作过（这是您的职位描述的一部分），以获得“公司薪水/公司时间”教育。甚至有一个地方建立了一个完整的“培训中心”，当地的大学有时会借用它们的“工业技术”课程。错误不仅会导致错误，还会在物理上破坏事物，和/或更糟糕的是，它们会使人们受伤。但是，在每个制造领域都表现出色的一个恒定因素是，在任何情况下都不会有人应责。因为这是系统的缺陷，简单明了，而不是人员的缺陷。以这种方式看待-拼写检查器-一种非常有效的工具，适合那些在文本技巧方面不太幸运的人，或者只是那些工作过度的人……但这绝不是一种责备或问责的方法。

一个工作环境，无论是哪种类型，或为何种目的服务，都是一个系统。一个由单独的组件组成的系统，如果正确地“协调”，则可以完全和谐地工作-或类似的外观。

建议老板读一读：高效人才的七个习惯

听起来他可能会有点谦虚，如果不是现实的话。他和其他所有人一样，都是团队的一员，他需要意识到这一点-否则，它将无济于事，最后，他将不惜一切代价。建议您阅读和/或研究以下内容：

调查5为什么分析，根本原因分析...使您能够更好地提供解决方案而不是问题的任何事物。您与老板的意见分歧只是一个问题，而不是解决方案。为他提供更好的东西，有意义的东西，甚至准备让他对这个想法表示赞赏。如果根本没有任何问题，就不能对失败有一个全面的了解-除了他的“我是老板”的心态。我希望您设法以一种所有人都可以接受的方式来解决这个问题，尤其是在这些时代。

编辑：就我个人而言，根据我自己的经验...“继续吧，怪我。因为肯定足够了，我会修复它，然后再解决，如果再次发生，谁会在那里度过难关呢？是的，你猜对了……我，咧着嘴笑。

#16 楼

对于问责制，我不需要person to blame字段，我想要Person who knows the code字段或person who can fix字段，这样我就知道将支持票发送到哪里。

这将加快修复问题的过程。错误本身并承担责任，有点像用一块石头杀死两只鸟。我个人会提出这个建议，让他决定这是否有助于提高士气和责任感，而又不会让人感到失败。极限测试不会捕获所有错误，否则就不会报告错误。

#17 楼

如果我的老板这样做，将会按照以下确切顺序进行操作：

1）我将立即开始寻找新工作。

2）每次出现错误时，有人责怪他，我老板的名字就会出现在这里，并说明为什么团队中的一个糟糕的过程对此负责。和CC交给他的老板（最好是分批）。你有单元测试吗？如果不是，则表示开发过程已中断，因此错误。您是否对所有外部系统进行持续的自动化集成测试？然后，开发过程将被破坏，从而导致bug。您是否有能力通过脚本使每个环境在生产中完全相同，从而避免人为错误？然后，开发过程将被破坏，从而导致bug。一个开发人员会很糟糕吗？那么招聘标准就很糟糕，因此就是老板的错。是否所有开发人员都因为每天工作12个小时而缺乏休息而犯下愚蠢的错误？然后，开发过程中断了。正如您所看到的，100％的错误是老板的错。

作为旁注：每个优秀的开发经理都知道我上面写的内容。敏捷策略旨在向老板或他/她的上司指出开发人员放慢速度的原因：看，我们花了50％的时间来修复错误。让我们看一下减少它们的策略，以便我们可以花费40％的时间来修复错误，然后重新研究该问题，将其提高到30％。等。

不幸的是，听起来您好像没有这个领域的好经理。因此，我建议您进行（1）的操作，而不要带给经理（退出面试时除外）

#18 楼

告诉他“怪”是负面的。将其更改为“要修复的人员”，然后至少以积极的方式进行构架，并且仍然可以完成相同的工作。人们被“责备”时该如何工作？

#19 楼

看来您的老板对软件没有深入的了解，也许他也不打算这样做。所以他有不同的语言，不同的文化。

放弃这样一个问题的工作，甚至在试图提出解决方案之前都只是放弃。戒烟就是戒烟。在他确保您永远不会相互理解之前，请不要退出。为确保这一点，您应该首先尝试。

由于他不懂我们的语言，而且他是老板，所以这里的第一步就是尝试用他的语言与他交谈。我的语言是什么意思？让我们一起思考：

我们是软件人，我们大多数人都喜欢我们所做的工作，我们与正在做的事情有着深厚的联系。否则，它将无法正常工作，并且一个人不能长期从事这项业务而不爱它或成为一个完整的公司...您填补了空白...

但是，他对事情的看法却大不相同。在收到每个错误报告时，虽然我们大多数人都为使事情变得更好而兴奋（不，即使有时确实非常压力，我们还是喜欢问题，只是承认！），但他认为这是失败，是一种存在的衡量标准不成功。他首先要了解的是错误是好的。 Bug使客户喜欢公司。 （现在这是他的语言）当客户报告错误或解决问题后，我们发现自己的错误时，它比从未发生过的情况好得多。错误会建立客户忠诚度（我是说真的！），错误会为用户与软件生产商之间的交流提供很好的借口。

要“增加错误的利润”，您应该提供错误报告更加开放。有了每一个错误报告及其快速，干净，良好的解决方案，客户就会感到“哇，这些家伙真棒！他们工作非常努力。看看他们正在解决的这些事情。我们甚至没有意识到软件是如此复杂。事情！”等等等等...

采取行动，用他的语言说话。对于软件公司而言，错误非常重要，这不是问题。它们使我们赖以生存。

对于团队道德，效率或您进行的任何谈话，可能会以与您预期相反的方式工作。如果您想退出，他会认为“啊哈，我的解决方案从第一天就开始起作用！不良链接在被暴露之前已经开始自行消失！”他相信在公司中找到坏男孩的想法，否则很难说服他。尤其是当您可能是那些坏孩子之一时。

所以，请专注于他真正的问题：错误。向他展示错误可能非常有用。没有任何问题，一段关系很无聊。所有不会杀死您的东西都会使您变得更坚强。每个错误都是增加客户满意度的绝佳机会。

这只是一件事。考虑一下他的担忧，您会发现许多其他项目要添加到您的列表中。金钥匙是提供另一种选择，而不是与他的想法作斗争！

#20 楼

如果您正在执行敏捷，那么听起来好像来自功能/故事注释。负责的人应该是允许错误通过的质量检查人员，或者接受功能/故事与错误一起完成的产品所有者/客户。

我确实在一天，这就是我要承担的事情。排字工人犯了错误的拼写，但校对员却错过了，所以
校对员要责怪印刷错误，而不是首先犯错的人。


在敏捷环境中，捕获错误（错误）是QA人员的责任，不接受不正确的内容是产品所有者的责任。这是两个级别的证明读者，它们应该使开发人员与发布的事物隔离开来，这是将任何事物归为敏捷环境中的错误的唯一方法。

#21 楼

我认为您的经理正在尝试使用错误的解决方案来解决问题。我认为可能存在一个问题，就是发布了太多的错误，您的经理希望开发人员对他们编写的代码拥有更多的所有权和责任感。

使用测试驱动的开发并建立持续的开发环境集成服务器（如Jenkins）将有助于解决此问题，而无需引入“怪罪游戏”。持续集成服务器对此非常重要，因为当某人提交“破坏构建”的代码时，会向团队发送一封电子邮件，向该人表明要归咎于此。由于该代码尚未发布到生产环境中，因此这种责备更加主动和令人鼓舞（而且很有趣！）。

结果是开发人员将拥有更多所有权，感到更加自信，而且生产代码中的错误也会更少。

#22 楼

指出如果一个人的错误导致错误最终在生产中出现，那么您的方法论或开发软件的整体方法就有问题。指出防止错误进入生产是整个团队的责任。

使用这两个参数中的任意一个，看看您是否可以说服老板，将“归咎于谁”字段作为单选字段会产生误导；因此，有必要确保“应归咎于”字段是多选字段。完成此操作后，请确保对于每个错误，每个人的名字都在该字段中。您的老板最终将看到该领域的任何报告都是徒劳的。

#23 楼

为了给老板一个荣誉，“责备分配”的概念已经被引入诸如SVN之类的工具中，并且适当地使用数据对于开发人员在调试时“确定与谁交谈”可能具有建设性，例如：http：/ /www.codinghorror.com/blog/2007/11/who-wrote-this-crap.html

虽然我同意gnat的回答，即根本原因字段是一件好事，但这是'如果获得相同的信息，并且对该字段进行“非规范化”以有时为受影响的源分配以前的开发人员名称，并且有时具有技术说明（例如“未扩展到10000个用户”）只会使人们感到困惑。我主张将“根本原因”字段保留为明确的技术说明（例如，即使出现明显的程序员错误，也要使其捕获诸如“ fooData = 999时的IndexOutOfRange Exception”之类的详细信息），当整体审核时，这可能会提供一些有用的反馈，并允许采取一些纠正措施来解决与体系结构或框架更改有关的整个问题类别（例如，改进自定义容器类，顶级异常处理）

也就是说，在Person to Blame字段中添加显然，这可能会向软件团队发送非常糟糕的信息和破坏性信息，而管理层则希望挑出并惩罚最经常破坏代码的单个开发人员。我怀疑经理认为，这种公开审查将使开发人员更加谨慎和自我调节，以免他们的名字出现在这种“耻辱之墙”上，并且不理解为什么开发人员会为此受到威胁，尤其是如果添加了这种威胁通常将其应用于每个错误报告。

将其添加为错误字段/潜在度量的问题很容易开始枚举：


错误的难度很大可以解决，并且错误计数/开发人员的简单统计信息不会反映出这一点。
开发人员在功能上的差异很大“”“”“”“”“”
许多软件系统具有需要重构的组件，但是重构遗留组件（尤其是在遗留基础没有/有限的单元测试工具的情况下）最初会引入错误。如果存在与产生新错误有关的污名/恐惧（即使这些琐事很难解决并且最终导致系统得到重大改进），则开发人员可能会因此而感到沮丧。提交与同一问题相关的错误数量很大的错误，导致错误计数/开发人员的偏度很高，除非进行了更详细的分析。

这只是冰山一角。将这些与谁期望哪些API行为，测试中的预期结果不正确以及要求不正确/缺失的“链中早期”问题的指责相结合，很明显，像这样的指标注定是无价值的（除非目的是损害士气并引起大规模的外逃。并为此做一些事情（希望是建设性的）。由于上面列出的原因，尝试通过在错误报告中添加字段来获取此信息将不会提供有意义的信息。以我的经验，可以通过与团队联系，参加大多数团队会议，整合（仔细地）与团队成员偶尔进行的一对一会议中学习的信息，以及熟悉其中的子系统来学习这些信息。代码（即使他们无法阅读代码。）

#24 楼

放手吧。您的老板会自己发现问题所在（如果存在）。

直言不讳，你有意见，他也是。他是您的经理，他的看法是制胜法宝。

是的，您可以就此问题进行战争，但这真的值得吗？我怀疑它要持续超过3个月才能失效。

但是积极破坏或尖叫它只会消耗政治资本，而这些资本本来可以用于请求额外的时间，下次加薪，晋升，或者将要做出真正关键的设计决定。

那时候，当你真的很重要时，npt希望老板记住你是积极破坏他的想法的人“要责怪的人”。

即使您不尊重决策，也要尊重办公室。

节省压力和麻烦，使决策将持续更长的时间。

#25 楼

告诉你的老板，团队发展需要社交技巧。他甚至可能点头。

但是问题是，这是开发人员极其讨厌的事情。添加暗示责备的工具比进行适当的问题分析更重要，这只会适得其反。例如，给硬币正面奖励：命名负责票务的人。

还从代码审查开始，以便彼此学习。后来免除了责任。

#26 楼

给他发电子邮件这样的问题。如果他愿意接受推理，则此处的评论将为他的推理提供健全性检查。如果他不合理，您就不可能用合理的理由说服他。此外，他将能够阅读对话之外的原因（由于在对话的热潮中消除了“正确”的动机，因此有时更令人信服）。

您可以也尝试将其转过来。该字段可以是“避免发生类似错误的可能步骤”，也可以是比该效果更短的内容。然后，您可以汇总解决方案并投票决定实施哪些解决方案，以改善您的工作场所。也许面向解决方案的方法更具生产力，并且可能会得到更好的接受（前提是在重新访问建议方面有实际的实践）。

#27 楼

我在这里看到两种可能性：他希望能够惩罚犯错的人，或者他只是没有想通。让他知道，每个人的看法都是他打算惩罚犯错的人。问他这是否是他要鼓励的文化。

我的老板决定在我们的错误跟踪模板中添加“ Person To Blame”字段会增加责任感。

经验中，当管理层想要“使人们承担更多责任”时，他们的意思是他们希望能够对失败进行精确的惩罚。无论是解雇绩效不佳的员工，还是只是让他们在年薪审查中被淘汰（“抱歉，鲍勃，您有17个错误被标记为您的错误，并且超过15个限制”），这都是惩罚。

他可能会说“哦，不，我们不想要那个，”然后问他如何使用这些数据。提醒他除非您要使用它，否则不要将数据点添加到数据库中。他是否想要根据给定的条件进行选择（“向我展示报告创建者子系统中的所有未解决的错误”），以便您可以从事工作，或者能够获取汇总数据（“哪个子系统拥有最多的错误”），以便您可以进行事后分析。他是否设想了某种失败的手提袋板，可以在公开场合羞辱人们？

他打算做什么？他是否想说“告诉我所有鲍勃的错？”为什么？还是他想说“大多数时间告诉我谁是过错”？为什么？第一个没有意义，第二个只是惩罚性的。或第三个选择是他没有真正的理由。

我承认他有可能在团队中寻找那些需要帮助以提高其技能的程序员。如果是这样，有更好的方法来捕获此信息，而这不会造成指责的文化。

#28 楼

我建议使用以下组合：

幽默
逻辑-最好是剃刀锋利的
正构图。例如，您可能会创建一个错误：负责人的字段无法捕获根本原因，也无法解决系统的过程问题。
在错误中：

“老板”原因背后的认识原因；
专业解释如果问题出在过程中，外部因素等，则该字段不起作用；
（可选）说明对士气的影响；
提出：

介绍“根本原因” ”字段或其他建议来改善捕获根本原因的方法，
引入“冠军以帮助避免将来发生”字段。这将是有权干的高级人员，他们可以进行有意义的更改来避免将来发生此类问题。每个人都知道那是谁的主意。

#29 楼

我相信这里要关注的关键方面是团队中对“老板”和其他方向的沟通开放程度。
指责永远都不是一件好事，但是，从管理的角度来看，如果您的一位开发人员多次陷入同一问题，那么也许是时候介入并尝试帮助他解决重复性问题了（例如，约翰没有正确测试代码：过去3个月中有3个生产错误，让我们给他一个清单，以便他记住他的代码应该是什么以及应该如何测试）。

来自开发从观点来看，“责备”已经被纳入诸如SVN之类的主流工具中，因此，我对使用“约翰，请解决您写的那句废话”并在其旁边加上名称没有任何害处。当您提交错误时，JIRA还会合并一个人的名字（但是，该字段并不真正对负责此事的人有意义，因此可以由某人进行修复）。

这就是问题但是，正如上面许多人所提到的，如果出现错误，这是一个共同的责任：从开发人员到测试人员，再到质量检查再到管理人员。如果您的老板在某个时候通过电话处理生气的客户，例如“我很抱歉，约翰没有正确地测试过”，那么我肯定会在寻找另一份工作。一个好的老板应该去“我们会照顾”的。没有名字，没有指责，只有解决方案。

再次，我相信一切都与沟通有关。也许老板唯一想做的就是看开发团队中谁遇到了麻烦，或者团队遇到了什么样的问题（也许参加培训课程？），但我认为您不会确切地了解他背后的原因决定（最好是我们的海报/阅读器），除非您与老板和整个团队进行交谈。