[附精彩评论与答复]既不指责人，也不指责事

要指责过程，而非指责人。——威廉·爱德华兹·戴明

太长不读版

除了在工作中不指责人之外，还要小心不要通过没有建设性地指责事，而变相和隐性地指责人。应该把关注点放到指责不适应变化的过程、知识和工具上。

正文

如果指责和羞辱个人或团队所做出的“错事”，成为组织的文化，那么人们就会因担心受到惩罚，而不敢把问题摆出来。从而让后人重蹈覆辙，给组织和个人带来更多损失。

毕竟，企业中的那些“错事”，根因都出自机制和过程，而不是出自个人和团队。
针对这一点，在做敏捷回顾的时候，我们经常提倡“对事不对人”。

但要小心，这会让人一不小心落入另一个“深坑”：虽不指责人，但却指责事，从而隐含着要有人出面对此事负责，这样又回到指责人去了。

比如，在《SRE Google运维解密》书中第15章就举了一个指责事情的例子：

“我们需要完全重写那个复杂的后端系统！ 在过去的3个季度里，它每周都会掉链子。我相信所有人都烦透了一点一点地去改代码。 说真的，要是再收到一个让我做技术支持的短信，我就自己去重写了……”

这句话只指责了事情，没有指责人，看似不错。但它有着不言而喻的下文：“有人需要为后端系统掉链子负责”，这种隐性指责人的方式，杀伤力也很大。

那么面对这种场景，什么样的回顾态度是有建设性的呢？那就是不去指责人和事，而是强调改善过程、知识和工具及其好处，从而吸引人们去做改进。

这里的“不去指责”，除了大家熟悉的“不去指责人”，还有大家不熟悉的“不去指责事”。

看看书中接下来给出的另一个例子是如何体现这种态度的吧。

“重写整个后端系统这个行动项，实际上可以消灭那些没完没了的烦人技术支持短信。而且这个版本的维护手册很长，很难啃下来，所以一旦重写，我相信未来带着技术支持手机的工程师会感谢我们！”

从中能看出，这段同样没有指责人的话，虽然包含了对“烦人技术支持短信”和“维护手册很长”的抱怨，但是这些都是为了强调“消灭支持短信”和“后人感谢我们”所带来的好处的。这样就没有“要有人出面对‘错事’负责”的意味，反而会激发人们对“重写后端系统”的责任。

该书译者把blameless译作“对事不对人”，体现了人不是问题的根因这一点。但却容易让忿忿不平的人去指责事，从而隐形地把人与事对上号，回到指责人的老路。

所以在做敏捷回顾的时候，与其提倡“对事不对人”，不如提倡“对人和事菩萨低眉，对过程、知识和工具金刚怒目，同时又让人们看到怒目的好处，从而吸引人们担起改进的责任”。

---

---

精彩的评论和回复

“‘毕竟，企业中的那些“错事”，根因都出自机制和过程，而不是出自个人和团队。 ’，不敢苟同。”

假如从事软件开发的企业中的错事责任在个人和团队，那么出于趋利避害的人性，大家就会为避免自己担责而去推卸责任或指责他人，最终没人想干必须要试错的创新的事情。而软件开发本身就是创新，所有被开发的软件都是独一无二的，而错事的责任在人只会让创新失败，是开发软件的企业的毒药。假如在丰田公司这样首先实践包含持续改进在内的精益的企业中，错事责任在个人和团队，那么就无法进行改进。因为改进是针对失误的，同样是出于趋利避害的人性，大家就会为避免自己担责而将失误的“黑锅”推卸给他人或指责他人，最终无法实施改进而每况愈下。所以，“错事责任在个人和团队”，是杀死创新型和持续改进型企业的元凶。

“责任不清楚才会有推卸。团队不齐心才会有指责”。

分清责任，就会回到“部门墙”的老路，走向敏捷和DevOps 的反面，会增加半成品交接的时间，降低团队交付的速度，万万使不得。把失误归咎于人，才会让团队不齐心，让人去指责。

“你只需要做，不需要付任何责任”。

也不是这样。交付产品的责任在团队，而不是个人。失误归咎于欠佳的过程，而每个人尤其是管理者都有持续改进过程的责任。

“这更像是一种政治正确的追求，并不适合在一个需要高效运转的公司中。如果这样追求，效率高不起来的，如果还认为一定能搞，有些乌托邦。比如说，长春生物制药造假，既不指责人、也不指责事，期待他们能自我纠错和改进？人人都有这种思想觉悟，天下早就大同、共产了。再说试错这件事，你评论中包含着一种“企业不允许试错”的前提，我想你把“试错”与“犯错”混为一谈了。你去问任何互联网企业的管理层人员是否允许员工或团队试错？我想答案都是肯定的。又问是否允许犯错？我想答案也很明显：尽量避免，可再一再二不可再三。你的讨论里更激进，把创新和犯错强绑定，这样的逻辑有待商榷。那么，试错和犯错区别是什么？我觉得前者是指聪明人目标明确、用科学的方法在做一件无前车之鉴的事，可能对可能错，传说中的爱迪生发明电灯泡的过程就属此类。而犯错是指蠢人可能没弄清楚目标、用不科学的方法，甚至在做的是有最佳实践经验借鉴的事情，还把事情搞砸了。犯了错，一定得担责，管理者有义务清理出害群之马，犯错者有义务完成自我救赎。”

不指责人和事，但要指责欠佳的过程。世界每时每刻都在变化，当初制定的有效的过程，过一阵就失效了。所以必须要改。犯错的原因在于欠佳的过程，而不是人。因为每个人都是经过面试进入公司的，面试的同事已经验证他们的初衷都是努力为公司工作的。任何初衷好的人，在遵循有瑕疵的过程时，都会失误。再考虑前面说到的失效的过程，把失误的责任丢给这些人，明显不合理。应该要改进失效的过程。反之，如果不改进过程，而是惩罚人，势必激起人的反对，反而把良好初衷的人，变成存心报复的人。

“过程是大自然形成的吗？如果要改进过程，是否等于说，某单位（人）制定实施的某过程有问题么？如果不去追究这个不良过程的制定与实施者，如果不让他认识到自己的不良性，他凭什么要改进？”

世界每时每刻都在变。当初制定的有效过程，会不适应后面的变化。所以必须要改进。

“过于一刀切，任何环境必须有边界，比如职业道德，跨过边界的事情就是错误，不论是个人还是团队，谁跨越谁就要负责，并应该被惩罚，才能保证整个环境的健康。创新依然如此，不可能创新就可以不遵循基本约束，事后还免责。”

我相信那个经过了4个月最后越界的人，最初加入团队的时候也是经过面试同事的认可的，其本人也不是以越界为目的而来的。是团队欠佳的过程，迫使他越界。我相信好的团队过程，能把来“讨债”的人，变为“报恩”的人。而欠佳的团队过程，能把“报恩”的人，转变为“讨债”的人。

“If the context of a failure is about a spike or a story which is within the timeframe of a sprint or two, then the system of scrum can give everyone an opportunity to learn from the mistake through the sprint review and retro. You fail early and fail cheap, you also need to embrace failure. Of course, the team is responsible to it since it’s in the spring backlog. But the product owner also need to understand the risk of a spike as well as the capabilities of the development team. E.g. if the dev team doesn’t have capability x and you are asking them to develop x, it will face a lot more hurdles and failure compare to someone who had done it before. The way to embrace failure and encourage innovation is provide a safe environment. We also need to learn from the context of each failure through retrospective for continuous improvement.”

Agree. I think improving the quality of the context identification is the part of improving the processes.

“举个例子哈。假如新来的同事不熟悉缓存的用法，团队内部也没有相关的文档，纯粹靠个人发挥，那么，责任应该让测试承担。毕竟，缓存不是单元测试能搞明白的。问题是，开发也需要了解如何测试缓存。终究是要找人背锅的。否则，谁来推动呢？”

这种情况就要找团队来背锅，而不是“测试人员”。“假如新来的同事不熟悉缓存的用法，团队内部也没有相关的文档，纯粹靠个人发挥。”这种情况一般是：1）新的缓存技术团队无人熟悉；2）熟悉缓存技术的人离职，没有留下文档。对于第1种，团队可以设定一个时间盒，比如1周，找两个感兴趣的同事，学习和研究这个新技术，然后分享给包括开发和测试在内的同事。对于第2种，可以参考第1种的做法先找人熟悉这个技术，然后吸取分工明确的教训，让大家轮换地结对工作，使得开发和测试都熟悉这个技术。