“尚春，你去写一份 Case Study 吧”。

当师父对我说出这句话的时候，我的第一反应是吃惊和委屈。根据我的了解，Case Study 一般是在发生较大的线上故障后才由当事人总结的。由于我们技术部门刚刚推行这个制度不久，当时只有很少的人写过。因此，我下意识地认为这更多是一种羞辱和惩罚，觉得本来一个不太大的问题会被所有人都知道，自己的面子都挂不住。

师父对我们一直都非常好，幽默风趣，善于授人以渔。他对技术和界面都有着极致的追求。虽然觉得写 Case Study 对这次线上故障有些小题大做，但我还是硬着头皮打开文档平台，开始着手写总结。首先，我简单了解了 Case Study 的文档结构，一般包含：

  • 关键事件时间线。主要记录线上故障的发生、发现、处理和解决过程；
  • 预估损失。不同的故障所造成的损失也不不尽相同。不过一般可以分为直接损失和间接损失。间接损失主要和 KPI 挂钩；
  • 原因分析。要求采用 5 Why 准则来层层递进地分析问题的本源；
  • 改进措施。根据之前的分析罗列出来具体的改进措施和负责人。

写完总结后，师父很满意，同时也给了一些建议，并嘱咐我一定要抓紧落实改进措施。这时我开始有些新的认识：他是想让更多人避免类似的问题，而不仅仅是惩罚我。

写 Case Study 最多的人

随着时间的推移，我们之前引入的一些代码检查等措施，提前发现了一些即将上线代码的问题。这让大家对之前的改进有了更多积极的评价。同时，其他业务线上的一些问题也引起老板的关注，他也提出了类似的要求。这些变化让我更深层次地理解了他的动机：让团队变得更强，系统更健壮。至于当事人的声誉，这是见仁见智的。但老板最终还是给我升职加薪了，说明至少在他看来，我的输出还可以，之前线上的问题并没有明显影响我的绩效。

有了这样的经验后，我对 Case Study 的看法逐渐有了转变，认为它不再是一种惩罚，而更多的是一种深入分析问题原因并加以改进的重要手段。这种自我批评、持续迭代的能力对于一个工程师或者一个技术团队来说至关重要。

后来我开始带人，再后来开始带团队，我除了自己也会主动去写 Case Study 以外，也会像我师父一样鼓励团队成员更多地去写。我本人甚至成为技术部门写 Case Study 最多的人之一。相应的，我们的代码质量、开发效率也在稳步提升，团队逐渐形成了一种学习进步的氛围。神奇的是，我们小组的声誉并没有因为写的 Case Study 多就备受诟病。

这里的 Post Mortem 居然连当事人名字都不写

在 Tubi 工作后，我发现这里大家也会去写类似 Cast Study 的文档，名字叫 Post Mortem，中文是“事后剖析”。总体形式和目的都很相像，只有两点不太一样：

  • 引入了 Time To Detect, Time To Aware, Time To Engage, Time To Fix 等故障生命周期指标，可以监控和逐步改进故障响应效率；
  • 不再提及任何具体的当事人名字。

第一点很容易理解。第二点一开始挺让我吃惊的，整个时间线都在描述具体的事实，没有任何一个公司同事的名字。即便有些地方非常有必要用一个人物作为主语或者宾语，也会用 A Engineer 或者其它方式来指代。后来通过和大家的接触我慢慢理解了这样的用意：避免指责具体的个人，把主要的焦点放在故障本身。联想到之前第一次写 Case Study 的情境，如果我只作为文档的书写者而不必在时间线和责任人里写上自己名字的话，大概也不会感到那么难堪吧。这的确是一个好办法！

公正文化 Just Culture

后来有美国同事跟我推荐了一篇 Just Culture 的文章，顿时有种相见恨晚的感觉，之前模糊的认知被这套已经在航空、医疗等高风险行业实施了很多年的经验一下子变得清晰和深刻起来。

Just culture is a concept related to systems thinking which emphasizes that mistakes are generally a product of faulty organizational cultures, rather than solely brought about by the person or persons directly involved. In a just culture, after an incident, the question asked is, “What went wrong?” rather than “Who caused the problem?”.

Just Culture 是一种组织文化的理念，其核心思想是鼓励组织在处理错误和事故时采取一种公正和合理的态度，而不是简单地追究责任。和 Blame Culture 相对立，这一理念认为事故通常是由多个因素的复杂互动引起的，而不仅仅是个别人员的责任。因此，对于无意的错误和系统性问题，应该以学习和改进为导向，而不是惩罚个别员工。

具体来说，这种文化包含如下要素：

  • 采用共享责任的模型：鼓励建立一种共享责任的模型，使整个组织都参与到错误和事故的处理中。这意味着不仅仅是个别人员负责，而是整个团队和组织共同分享责任；
  • 从错误中学习而不是责怪个体：强调将错误视为学习的机会，而不是简单地追究责任。通过分析错误的根本原因，组织可以制定改进措施，以防止将来类似的错误发生；
  • 管理行为选择：关注并区分人为错误、有风险的行为和鲁莽行为。鼓励组织采取不同的方法来处理这些不同类型的行为，以确保适当的反应和学习；
  • 将安全设计纳入系统和流程：强调将安全性集成到组织的所有系统和流程中，而不是仅仅依赖于个体的注意力和警觉。通过设计安全性，可以减少系统性的错误和事故；
  • 组织、领导层对共同目标的承诺：这种承诺在组织层面上奠定了文化基石，使得处理错误和事故成为一个合作和学习的过程，而不是惩罚的手段。

总体而言，在 Just Culture 下，团队成员能够更好地理解和接受自己的责任。他们知道他们的行动和决策对整个团队和项目的结果产生影响。这种责任感激励着他们更加谨慎和专注地工作，以减少错误和失误的发生。团队成员之间建立了更强的信任和合作关系，因为他们知道即使犯错，他们也会得到支持和帮助。

对于管理者的挑战

从 Blame Culture 转变到 Just Culture 绝非易事。一方面，人的本性是趋利避害的，大多数人不会轻易地去提出各种潜在的问题。另一方面，准确地区分系统问题、人为失误、鲁莽行为等不同类型的错误极具挑战，团队不同人的认识层次也较难统一。这些挑战都是现实存在的，需要管理者认真思考和应对。

结合我自身的经验，在这里分享几个给管理者的建议：

  • 以身作则。作为管理者，是团队成员的标杆。如果能够更多地去认真剖析自己的过失，在系统和流程层面做出改进，就会向大家传达一个强烈的信号：领导也是人，也会犯错，而且愿意和大家分享他当时的经历，并从中汲取教训。领导如果只说不做，大家会有些踌躇、将信将疑。只有领导这样做了，大家才会更加信服，认为这是一种真真切切的鼓励；
  • 建立透明的沟通机制：建立一个开放、透明、安全的沟通环境对于 Just Culture 来说至关重要，只有让大家畅所欲言才能把事实越辩越明、挖到足够多足够深入的细节，也让大家参与到团队文化的构建中来。事实上，这对于一个团队的成长来说几乎是最为重要的，需要每个管理者足够重视；
  • 平衡责任与学习：在处理错误时，要确保适当的责任被追究，同时也要强调学习和改进。区分人为错误、有风险的行为和鲁莽行为非常有难度，管理者需要制定清晰的标准和流程，以便在面临不同类型的行为时能够做出一致的决策。培训团队成员以更好地理解和评估这些行为也是关键的一步。

总之，Just Culture 在团队建设方面具有重要的益处。它为团队成员提供了一个安全的环境，鼓励他们积极报告错误和失误，并从中学习和改进。同时，实施 Just Culture 也面临不少挑战，需要确保公正和平衡，并培养团队成员的自我反思和学习能力。通过领导者的支持和示范，Just Culture 可以在技术团队中发挥其潜力，促进构建一个持续学习、表现卓越的优秀团队。

参考文献