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

在最新的“ WTF”举措之一中，我的老板决定在我们的错误跟踪模板中添加“ Person To Blame”字段将增加责任感（尽管我们已经可以将错误与功能/故事联系起来）。我认为这会降低士气，增加手指指向性并且不能解释报告为Bug的缺失/误解功能的说法是闻所未闻的。

我还可以使用其他一些反对这种做法的有力论据吗？有什么我可以与团队和老板分享的文章吗？

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

搜索类似的网络软件缺陷的根本原因分析，有丰富的资源，以证明这种推理^{1，2，3，4，...}。

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

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

告诉你的老板当是单一的开发者指责，根源场肯定会涵盖（“由Bob制作编码错误在提交1234，吉姆在回顾567错过”）。使用根本原因一词的目的是涵盖类似的案例，以及超出开发团队范围的案例。

^{例如，如果该错误是由硬件故障引起的（应归咎于该人是购买并测试过该产品的团队之外的人），则根本原因字段可以解决这一问题，而“应归咎于单个开发人员”将被打破该问题跟踪流程。}

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

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

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

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

让人们向后咬手指并指尖，试图避免设置后不会消失的黑斑，这是不好的。它什么也解决不了。很少有人恶意疏忽。您需要进行适当的回顾，查看出了什么问题以及可以做些什么来确保它不再出错。

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

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

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

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

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

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

另一个软件指标失败。

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

错误：

鲍勃忘了检查输入，程序除以零崩溃了。

对：

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

将“要怪的人”更改为“要称赞的人”

修复错误的主要人员会在上面加上他们的名字。

简单的答案。

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

更重要的是，是因为诚实的错误而使某人受害，还是要尽快解决该问题？

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

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

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

Gandhian公民抗命：在每个字段上都输入您的名字（除非其他开发人员加紧为错误提供名称），并为每个错误归咎于您，无论是否属于您。没有什么比这更使该领域或怪罪某人的想法了。如果您的老板问为什么在每个领域都叫您名字，那么您可以解释“因为我不认为发展是一种责备游戏，如果您真的需要人们责备和钉十字架，那就把我钉在十字架上，然后让我的团队和平共处。”

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

她所做的不是在我们的文书工作中添加“责怪人”字段，而是为每个设计师提供了一组彩色贴纸。每个设计师都得到了一个不同的彩色贴纸，并被告知必须将任何经过甚至触摸的设计都添加到该设计的文书工作中。

老板所说的“贴纸计划”的目标是确定我们部门所有错误的来源（文书工作中的错误，错档，不良副本，实质上是与错误等效的印刷错误）

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

不要只在[Blame]框中输入您的名字，而是将每个人的名字放在团队/项目中，并确保整个团队都这样做。

我们共同努力反对她的奥威尔式的chi子气，结果我们实际上最终发现了彼此的错误并互相谈论，最终大大减少了错误。她虽然是位经理，但并没有意识到自己的主动性最终使我们团结起来并提高了生产力，而是束手无策，解散了不干胶标签系统，并宣布它是失败的，并正式谴责了我们所有人。

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

说明该系统使编写最多代码的人看起来是最糟糕的程序员，而编写最少代码的人看起来是最好的程序员。

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

Dilbert连环画，1995年11月13日来自官方Dilbert连环画档案。

我回想起曾经有一次Snow Snowing有人指出“不跌倒”并不是高手滑雪的标志；而是常常是不做任何尝试（或根本不滑雪）的标志。

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

听起来您的老板可能对缺陷数量感到沮丧。团队中的人对质量充满热情吗？为原因创建一个“ what”字段而不是一个“ who”字段可能会更有效率。例如：需求变更，设计缺陷，实施缺陷等。即使没有小组合作来改善产品质量，即使这样做也将失败。

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

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

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

奇怪的是，以前没有人提到过：向bug跟踪器添加这种功能会激发员工尝试玩系统的行为。

对于类似问题所提出的方法来说，这是一个常见问题，在其他类似想法中（按代码行数支付，按错误数支付）。这将鼓励许多人专注于获得良好的成绩，而不是解决与他们正在使用的软件有关的问题。

例如，尝试提交带有文字的错误报告以减轻自己的责任，并将其推卸给其他人，可能会导致开发人员误解了问题的原因（或将工作交给了不了解该部分内容的另一位开发人员与最努力的代码一样，这也是导致该错误的主要原因），这导致花费更多的时间和精力来解决问题。

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

这是一个很高的要求。除了改变主意后节省面子的问题外，还有一个基本问题是，主要考虑个人责任的人通常都在那种思维方式中考虑解决方案。

您要求撰写有关此主题的文章，然后想到了Peopleware。它是备受推崇的主题，并在一般意义上谈论了如何管理难以衡量产出的从事创造性工作的人员。问题在于您阅读本书并不会有多大帮助，您的老板必须阅读它，并至少相信其中一些。

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

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

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

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

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

至少，指派负责负责和“解决”问题的“负责方”，或者提出跟踪和/或防止发生类似事件的计划，将是很好的。有时解决方案不过是额外的培训。我曾在许多公司中工作过（这是您的职位描述的一部分），以获得“公司薪水/公司时间”教育。有一个地方甚至建立了一个完整的“培训中心”，当地的大学有时会借用它们的工业技术课程。

在过去的20年中，我一直在制造环境中工作，在编程环境中，编程错误不仅会导致错误，还会物理地破坏事物，并且/或者更糟的是，它们会使人受伤。但是，在每个制造领域中表现出色的一个恒定因素是，在任何情况下都不会有人应责。因为这是系统的缺陷，简单明了，而不是人员的缺陷。以这种方式看待-拼写检查器是一种非常有效的工具，适用于那些文本技巧欠佳的人，或者只是那些工作过度的人...但绝不是一种责备或问责的方法。

一个工作环境，无论是哪种类型，或服务于什么目的，都是一个系统。由各个组件组成的系统，如果正确地“协调”，则可以完全和谐地工作-或类似地表现出来。

建议您上司阅读：高效人的七个习惯

听起来他可能会有点谦虚，如果不是现实的话。与其他所有人一样，他也是团队的一员，他需要意识到这一点-否则它将不起作用，最后，他将不惜一切代价。

建议您阅读和/或研究：

调查5为什么进行分析，根本原因分析...使您能够更好地提供解决方案而不是问题的任何方法。您与老板的意见分歧只是一个问题，而不是解决方案。给他提供更好的东西，有意义的东西，甚至准备让他为这个想法而赞扬。

现在看来他似乎还没有准备好解决任何问题，因为他根本不了解损坏的东西（如果有什么损坏的话），除了他的“我是老板”的心态之外。

祝好运！我希望您能够以一种所有人都可以接受的方式来解决这个问题，尤其是在当前时代。

编辑：就我个人而言，根据我自己的经验...“继续，怪我。因为果然，我会修复它，然后再解决，当它再次发生时，谁来拯救这一天呢？猜到了……我，咧嘴笑了。”

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

这样可以加快修复错误本身的速度并提供责任感，就像用一块石头杀死两只鸟。我亲自提出这个问题，让他决定这是否有助于提高士气和责任感，而又不会让人感到失败。极限测试无法捕获所有错误，否则就不会报告错误。

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

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

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

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

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

不幸的是，听起来好像您因为这个领域没有好的经理。因此，我建议您做（1），不要将其带给经理（退出面试除外）

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

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

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

我们是软件人，我们大多数人都喜欢我们所做的工作，我们与所做的事情有着深厚的联系。否则，它将无法正常工作，并且长时间无法从事这项业务，而不会爱上它或成为一个完整的人。

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

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

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

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

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

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

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

那天我确实进行过排版，这是我的看法。

这就像责怪排字工人拼写错误以及校对员应该找到但错过的其他事情一样。打字员打错了拼写，但校对员却打错了，因此归咎于校对是印刷错误，而不是首先犯错的人。

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

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

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

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

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

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

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

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

就是说，明显地将Person To Blame字段添加到软件团队可能会向管理团队想要挑出并惩罚最经常破坏代码的单个开发人员发送非常不好的消息和破坏性消息。我怀疑经理认为，这种公开审查将使开发人员更加谨慎和自律，以免他们的名字出现在这种“耻辱之墙”上，并且不理解为什么开发人员会为此受到威胁，特别是如果添加了它通常用于每个错误报告。

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

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

那只是冰山一角。将这些与谁期望哪些API行为，测试中的预期结果不正确以及要求不正确/缺失的“链中较早”问题的指责相结合，很明显，像这样的指标注定是无价值的（除非目的是损害士气并引起大规模外流。）

回到老板的观点，可以确定是否有开发人员反复破坏代码，并尝试对此做一些事情（希望是富有建设性的）。由于上面列出的原因，尝试通过在错误报告中添加字段来获取此信息将不会提供有意义的信息。根据我的经验，可以通过与团队联系，参加大多数团队会议，整合（仔细地）与团队成员偶尔进行的一对一会议中学习的信息，以及熟悉其中的子系统来学习这些信息。代码（即使他们看不懂代码）。

放手吧。您的老板会自己发现问题所在，如果确实如此。

坦白地说，您有意见，他也有意见。他是您的经理，他的意见是制胜法宝。

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

但是，积极地破坏这一点或大声疾呼只会浪费政治资本，而这些资本可以更好地用于请求额外的休假，下次加薪，晋升，或者何时将要做出真正关键的设计决定。

在那一刻，您确实不希望老板记住您是积极破坏他的“应归咎于人”的想法的人。

即使您不遵守决定，也要尊重办公室。

节省压力，避免麻烦的决定会持续更长的时间。

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

但是问题是，这是开发人员极其不满意的。添加暗示责备的工具比进行适当的问题分析更重要，这只会适得其反。

取而代之的是，您需要激励措施来提高社交技能，而您拥有的沟通基础设施应对此提供支持。例如，积极投币：命名负责票务的人。

还从代码审查开始，以便您可以互相学习。后来免除了责任。

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

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

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

我的老板决定在我们的错误跟踪模板中添加一个“ Person To Blame”字段，以提高责任心

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

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

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

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

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

从开发的角度来看，“责备”已经被纳入诸如SVN之类的主流工具中，因此，我对使用“约翰，请修正您编写的废话”并在名称旁边添加一个名称并没有什么害处。它。当您提交错误时，JIRA还会合并一个人的名字（但是，对于负责此事的人而言，它并不是真正意义上的意思，它实际上是由某人修复的）。

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

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