我的领导离职了，公司损失了一个“知识库”？

写这篇文章的想法是在一次会议上冒出来的，那次会议上我们知道了我们的主管要离开公司去寻找新机会了。一位同事对此感叹，我们最怀念的就是随着这位领导一同离去的那些知识。

不幸的是，事情就是这样：我们不仅失去了一位同事，而且还失去了很多宝贵的知识和经验。然而，这样的故事并不只是发生在我的主管身上，也发生在了我的导师身上。

所有在各自领域中成为专家的人们都在重复这样的故事。他们熟谙通向成功的路径，也知道如何避开那些通向灾难性失败的方向。当他们离开我们的身边，会带走很多我们在任何书籍、笔记或 Jira 票证中都找不到的知识。

这就引出了一个根本性的问题：如何才能避免这种知识“黑洞”？我们如何确保知识不会随着它们的拥有者一起消失？这篇文章讨论的就是这样一个主题。

有些人作出了业务决策……但并没有告诉我们理由

我专门为本文创建了一个术语，名为“生物数据存储（Biological Data Storage）”或简称“BDS”。公司中的几乎每一位员工都适用于这条术语。我知道没有人希望自己被视为一种单纯的资源，当然也不想被视为“生物数据存储”的一部分。然而，从公司资源的视角来看，员工可以比作某种技术数据的存储库，但除了技术数据外还有着价值很高的上下文。

我想从工程师的角度从更大的层面上来研究这个问题。我们经常听到有人提到康威定律：

任何组织在设计一个系统（广义定义）时所做出来的设计结构，都是组织内部沟通结构的副本。

我认为知识的流失其实是沟通不畅的结果，这最终会导致组织所创建的系统出现缺陷。

工程方法的特点就是我们致力于衡量各种事件的影响，并使用特定指标评估事件的真正意义。在应对员工离职的挑战时，请考虑以下指标来评估组织的有效性：

1. 解决问题的时间：

• 衡量解决问题或挑战的速度，并帮助确定问题解决过程的效率。

1. 知识转移率：

• 衡量新员工开始独立产生价值所需的时间，并表明知识转移和新人培训的效果。

我认为这些指标为组织效率及其无缝整合新的团队成员的能力提供了宝贵的见解。在康威定律的背景下，知识的流失成为了不仅影响组织内部沟通效率，而且影响公司内部系统设计的关键因素。

考虑一下：当拥有丰富知识和专业知识的团队成员离开时，他们带走的不仅是事实和数据，还有他们独特的见解、解决问题的方法以及对组织复杂性的理解。缺乏此类知识可能会扰乱团队内部和跨部门的信息流动管道。结果，组织的沟通结构可能会因此动摇，影响组织有效应对挑战的能力。

此外，系统的设计也会受到深远的影响。掌握宝贵知识的工程师和开发人员可能会基于他们的专业知识做出设计选择。这些决策可能没有被其他人记录下来或清楚地理解到位，当它们的作者离开时，决策本身就可能会变得不透明。这可能会导致维护和开发这些系统出现困难，可能导致效率低下和漏洞丛生。

现在，当我们将知识转移率指标引入这种背景时，很明显，衡量新员工开始独立产生价值所需的时间是至关重要的。这个时间越长，知识漏洞就会越明显，进而影响组织沟通和系统设计。组织必须认识到知识不仅仅涉及数据，还关系到对数据的理解和数据的上下文，它的流失会严重阻碍团队的顺利运作和系统的发展。

组织没有记忆

你可能会问，“失去这些知识对公司又能有什么影响？”业务流程是不是会因为流失的知识而像沙土堆一样崩溃呢？创新也会失去翅膀？公司的运转效率会像秋风冷雨中的落叶一样直线下降？在 98% 的情况下，上述问题的答案当然是否定的，因为我们可以管理此类风险。公司有很多应对这些问题的方法，但他们真的成竹在胸吗？

Trevor Kletz 的著作《灾难的教训》中引用了《组织没有记忆》中的一句话，该书强调了组织记忆这一概念，以及由于组织内缺乏从过去的错误中有效学习的能力，而导致事件和事故再次发生。Kletz 教授强调，组织无法从事故中吸取教训，即使是在公司内部发生的事故也是如此。有时我觉得当知识离开我们的公司时也会出现类似的模式。也许是因为它不能轻易地用金钱来衡量，所以它常常被低估。

虽然 Kletz 的著作讲的是化学工程的领域，但我从中看到了一些适用于任何情况和行业的普遍真理。例如，另一句话“你没有的东西，是不能泄漏的”与“你没有的代码是免维护的，并且不会有错误”的想法非常相似。我们的领域可能存在类似的原则。

然而，即使在这个阶段，知识获取的过程也可以加速。有多种方法可以做到这一点，例如创建过程、图示、表格和文档。

文档就像是业务世界中的藏宝图。创建文档是一回事，但在组织内（无论其规模如何）保持文档内容不落伍则是一项挑战。鼓励团队定期更新文档也是一个挑战。即使准备得最好的文档也常常缺乏许多细节，例如特定业务决策背后的基本原理、为什么选择特定数据库或框架，或者为什么我们使用技术 Y 而不是在整个公司内更流行的 X 技术。

因此，虽然文档就像公司的藏宝图，但有关公司内部流程、系统和实践的记录、组织和结构化信息更多属于架构决策记录（ADR）的范畴。ADR 就像我们业务的飞行黑匣子。它们包含了系统设计期间做出的关键决策或重大技术选择的记录。

为什么这很重要？在创造新事物时，我们会做出许多决定，如果日后没有正确的背景信息供查阅，这些决定可能会显得很不合理。ADR 就像打开了一个盒子，解释了为什么当时我们要做出这些决定。这是了解公司历史和演变的关键。在我们的 BDS 背景下，ADR 就像是专家在做出关键决策时的想法记录。当这些专家离开后，这些记录就成为了知识的宝库，帮助我们避免重蹈覆辙。

一个常见的情况是：负责解决问题的团队必须投入宝贵的时间来重新发现那些本来被探索过的解决方案、尝试潜在的修复方法，甚至进行反复试验。这不仅会延长解决问题的过程，还会导致解决方案不够理想、增加挫败感并对整体生产力产生负面影响。借助文档和 ADR，我们可以显著缩短这一过程。

冗长文档的替代方案？

没有人读文档。如果有人读了，他也看不懂。如果他理解了，也立刻就会忘记。

不幸的是，正如上面引用的 Stanisław Lem 的描述一样，文档、程序和 ADR 的问题在于人们需要熟悉它们。我想即使在 SpaceX 中，这些内容是否会被认为是最激动人心的阅读材料也要打一个大大的问号，或者也许我只是不了解他们。无论如何，即使有人设法阅读文档，他们也只会保留他们理解的那些内容。我们从文档中看到了其他人的工作，以及他们强加的思维和决策方式。经常出现的情况是，当下出现的问题没有人知道答案，而知道答案的人也不再在公司工作了。

由于我们现在很清楚自己的心理存在局限，因此我们可以使用事件风暴（EventStorming）方法，而不是强迫人们筛选成堆的文档。这种方法有助于我们理解业务流程、识别事件和活动，并以可理解的方式将知识归纳总结在一起。我们关注行为、变化的内容以及原因。我们一起开发解决方案并了解各种流程，因为我们是从头到尾走过这些流程的。通过事件风暴方法理解流程比阅读文档更快、更容易。在事件风暴会议期间，大多数问题都能找到答案，而且知识可以同时传达给许多人，无论他们是否是技术人员。此类会议最重要的成果是，你可以讨论为什么流程看起来是这样的，为什么要选择特定的顺序，而不是另一个——这本质上是文档、ADR 和对话交流的合体。我再次强调，对流程的理解是集体层面的——每个人都感觉自己是解决方案的一部分。就我们的 BDS 而言，事件风暴可以让我们在做出关键决策时捕捉到那些专家的想法。

现实生活中的例子

在 Allegro，我们最近遇到了一种情况，负责某项关键服务的整个开发团队被转移到了另一个项目。继承该服务的新团队有机会与调职的团队合作一段时间。然而，在这种背景下，我们也进行了事件风暴会议。为了提供更多细节，这些会议持续了整整两天，每次持续 8 小时。之前团队过去五年来积累的知识并不只是浓缩在了两张绘图纸大小、每张 6 米长的纸上，更是基本无缝地融入了每一位会议参与者的头脑中。我相信这一过程有助于新团队在接管该领域时获得更大的信心。

有趣的是，你不需要在事件风暴上花费大量时间来发现足够的业务知识。在前面提到的案例中，会议持续了两天，但这是整个团队层面的。对于个人来说，两个小时的研讨会足以了解我们流程的整体情况。尽管事件风暴使我们能够相对轻松地吸收一些知识，以了解流程中发生了什么事情，以及为什么发生种种变化，但细节决定成败。要真正了解这个过程是如何变化的，最好的入门方法是在有经验的人的指导下完成一些小的任务。

正在寻找类似 UML 的替代方案？

不幸的是，事件风暴并不能解决所有与知识流失相关的问题。虽然我不怀疑这个工具的出色效果，但通过它获得的知识只会留在参与者的脑海中。如果不以某种方式以文档或 ADR 的形式保存下来，这些知识依旧可能会像离职员工一样转瞬即逝。关于这一问题我们还能做些什么？我们最初的想法可能会推动我们创建某种形式的描述或文档，正如我们所知，这一过程中会遇到很多关于文档准备的挑战，还会让试图吸收新知识的人们出现认知超载。

看来，在处理知识流失及其有效转移问题时，值得一提的是像 BPMN（业务流程模型和表示法）这样的工具。BPMN 提供业务流程的标准化图形表示。通过使用 BPMN 图，我们可以直观地映射工作流程和过程。这种方法不仅简化了对复杂流程的理解，而且有助于全面记录。当与其他知识共享技术（例如事件风暴）结合使用时，BPMN 可以成为保存和传输关键业务知识的强大资产。

然而，BPMN 有一套复杂的符号和符号规则，这可能会让某些人创建和解释图表的过程变得颇为复杂。创建高级 BPMN 图并充分利用符号的潜力需要专业的知识和经验。不熟悉 BPMN 的人们可能很难有效地使用它。尽管存在这些不便，BPMN 仍然是许多组织中建模和记录业务流程的宝贵工具。我相信它是对前文提到的技术的完美补充。

只需记住，你应该在你的武器库中准备正确的工具，更重要的是根据具体情况选择合适的工具，同时充分衡量其优点和缺点。

还有一件事……

解决问题的时间指标是组织应对挑战时的效率的一项明确指标。解决问题的时间较短意味着问题得到迅速解决，最大限度地减少干扰并确保组织平稳运行。知识转移率指标是一种量化和解决知识损失的方法，揭示了其对组织内沟通结构和系统设计的影响。

这两个指标都直接受到文档、ADR、事件风暴或 BPMN 等工具的合理使用的影响。我也在前文尝试揭示了它们在知识转移方面的优点和缺点。

然而还有另一项挑战——改变公司文化。员工必须知道他们拥有哪些工具，并认可分享知识是成功关键这一观念。领导力在这里起着至关重要的作用，因为领导者需要积极促进和参与知识共享和开放沟通过程。如果公司领导积极认可并参与知识共享，其他员工就更有可能效仿他们。然而，改变组织文化是一个耗时的过程。在新的行为和信念战胜旧的行为和信念之前，耐心和毅力至关重要。

世上无难事

作为组织中的工程师，无论规模大小，你都可以采取一些积极主动的步骤来促进知识转移。首先也是最重要的，我们应该积极与同事进行开放的沟通。我们应该鼓励讨论和信息共享，尤其是在你的专业领域内，以确保大家共享的是有价值的见解。其次，指导可以是一个强大的工具。我们可以主动指导初级团队成员或向更有经验的同事寻求指导。此外，我们可以参与公司内部的知识共享活动，例如棕包会议、研讨会或跨职能项目。最后，我们应当考虑创建内部文档和存储库或对其作出贡献。这些资源可以作为你的同事和未来团队成员的宝贵参考，确保知识保留在组织内。通过积极参与这些实践，你可以在组织内保存和传播关键知识方面发挥关键作用。

小结

在本文中，我讨论了从工程师的角度来看，公司中的知识流失是如何出现的，以及为什么它会构成威胁。生物数据存储这个术语可能听起来很不传统，但它强调了每个团队成员在保存和转移知识方面所发挥的关键作用。重点在于，我们要记住员工不仅仅是资源，更是宝贵的信息、经验和专业知识的活宝库。在 BDS 的世界中，每个成员都为集体知识体系做出贡献，塑造组织的沟通结构。当我们告别离职的同事时，让我们也一同告别知识应该局限于个人头脑的观念。相反，让我们采用开放沟通、积极知识共享和正确工具（例如事件风暴和 BPMN）的文化，在整个组织内捕获、保存和共享关键知识。

原文链接：https://blog.allegro.tech/2023/10/battle-against-knowledge-loss.html