这篇文章主要讨论了在公司中知识流失的问题，特别是从工程师的角度出发。作者提出了“生物数据存储”这个术语，强调了每位员工在保存和传递知识方面的关键作用。
文章指出，知识流失可能会对组织的沟通结构和系统设计产生重大影响，因此需要采取措施来避免这种“黑洞”效应。
作者提出了一些解决方案，包括使用文档、事件模拟和BPMN等工具来捕获、保存和共享关键知识。
此外，文章还强调了公司文化的重要性，鼓励员工积极参与知识分享和开放沟通。
最后，作者建议工程师可以通过积极参与沟通、导师制度和内部文档等方式，发挥关键作用，以在组织内部保留和传递重要知识。
总之：
- 失去员工知识可能导致沟通不畅、系统设计不完善，工程师可以通过衡量问题解决时间和知识转移率来评估组织效率。
- 公司失去的知识对业务流程、创新和效率有影响，但可通过文档、ADR和EventStorming等工具来加速知识传承。
- 公司文化的改变和领导的积极推动对于知识共享至关重要，工程师可以通过开放沟通、导师制度和参与内部知识共享项目来促进知识传递。
为了撰写这篇文章，我特别创造了 "生物数据存储"（Biological Data Storage）一词，简称 BDS。这个术语几乎涵盖了公司的所有员工。我明白，没有人愿意被视为只是一种资源，当然也不会被视为 "生物数据存储 "的一部分。但是，在公司资源的背景下，员工可以被比作技术数据存储库，只不过多了一个有价值的背景。我想从工程师的角度更广泛地审视这个问题。我们经常听说康威定律：
任何组织在设计一个系统（广义上的系统）时，其设计结构都是该组织传播结构的复制品。
而我认为，知识的流失就是交流的枯竭，最终会导致所创建系统的不完善。
工程方法的特点是，我们致力于衡量各种事件的影响，并通过具体的指标来评估其实际意义。在应对员工离职的挑战时，可以考虑使用这些指标来评估组织的有效性：
- 解决问题的时间：
- 衡量解决问题或挑战的速度，并帮助确定问题解决过程的效率。
- 知识转移率：
- 衡量新员工实现自给自足所需的时间，并表明知识转移和入职的有效性。
我认为这些指标为组织效率及其无缝整合新团队成员的能力提供了宝贵的见解。在康威定律的背景下，知识的流失成为不仅影响沟通而且影响公司内部系统设计的关键因素。
考虑一下：当一个拥有丰富知识和专业知识的团队成员离开时，他们带走的不仅是事实和数据，还有他们独特的见解、解决问题的方法以及对组织复杂性的理解。缺乏此类知识可能会扰乱团队内部和跨部门的信息流动。结果，沟通结构可能会动摇，从而阻碍组织有效应对挑战的能力。
此外，系统的设计也会受到深远的影响。掌握宝贵知识的工程师和开发人员可能会根据他们的专业知识做出设计选择。这些决定可能没有被其他人记录或清楚地理解，当它们的作者离开时，可能会变得不透明。这可能会导致维护和开发这些系统的困难，可能导致效率低下和漏洞。
现在，当我们将知识转移率指标引入这种背景时，很明显，衡量新员工实现自给自足所需的时间至关重要。这个持续时间越长，知识差距就越明显，影响通信和系统设计。组织必须认识到知识不仅仅涉及数据，还涉及数据。它关系到理解和背景，它的丧失会严重阻碍团队的顺利运作和系统的发展。
组织没有记忆
你可能会问："失去这些知识会给公司带来什么影响？是业务流程像纸牌搭的房子一样开始倒塌？创新失去了翅膀？公司的效率会像秋风中的落叶一样一落千丈吗？在 98% 的情况下，上述问题的答案当然是否定的，因为我们可以管理这些风险。公司有应对这些风险的方法，但他们真的有吗？
《组织没有记忆》是特雷弗-克莱兹（Trevor Kletz）在《灾难的教训》（Lessons from Disaster）一书中的一句话，该书强调了组织记忆的概念，以及由于组织内部缺乏对过去错误的有效学习，事件和事故是如何反复发生的。克莱兹教授强调，组织无法从事故中吸取教训，即使是发生在公司内部的事故。我有时觉得，当知识离开我们的公司时，也会出现类似的模式。也许因为它不能轻易用金钱来衡量，所以常常被淡化。
虽然 克莱的书与化学工程有关，但我认为有几条普遍真理适用于任何情况和行业。例如，另一句话 "你没有的，不会泄露 "与 "你没有的代码是不可维护的，也不会有错误 "的观点非常相似。在我们的领域也可能存在类似的原则。
不过，即使在现阶段，也可以加快知识获取的过程。有几种方法可以做到这一点，例如创建程序、图表和文档。
文档就像商业世界中的藏宝图。创建文档是一回事，但在组织内部（无论组织规模大小）保持文档更新却是一项挑战。鼓励团队定期更新文档也是一项挑战。即使是准备最充分的文档，也往往缺乏许多细节，比如具体业务决策背后的理由，为什么选择特定的数据库或框架，或者为什么我们使用 Y 技术而不是在整个公司更普遍的 X 技术。
因此，文档就像公司的藏宝图，而记录、组织和结构化的公司内部流程、系统和实践信息则类似于架构决策记录（ADR）。
这就好比架构决策记录（ADR）。
ADR 就像我们企业的飞行记录仪。它们记录了系统设计或重大技术选择过程中做出的关键决策。
为什么这很重要？在创造新事物时，我们会做出许多决定，如果没有正确的背景，这些决定日后可能会显得不合理。ADR 就像打开了一个盒子，解释了做出这些决定的原因。这是了解公司历史和演变的关键。在我们的 BDS 中，ADR 就像是专家在做出关键决策时的思想记录。当这些专家离开后，这些录音就会成为知识宝库，帮助我们避免重蹈覆辙。
一种常见的情况是：负责解决问题的团队必须投入宝贵的时间，重新寻找解决方案，尝试可能的修复方法，甚至进行试错。这不仅会延长解决问题的过程，还会导致次优解决方案、挫败感增加，并对整体工作效率产生负面影响。有了文档和 ADR，我们可以大大缩短这段时间。
事件风暴
既然我们现在知道了自己的思维局限性，与其强迫人们去筛选成堆的文档，不如使用事件风暴法。这种技术有助于理解业务流程、识别事件和活动，并以易于理解的方式整合知识。我们关注行为，关注变化的内容和原因。
我们一起开发解决方案，了解流程，因为我们从头到尾都看到了。通过 EventStorming 理解流程比阅读文档更快、更简单。在 EventStorming 会议期间，大多数问题都能找到答案，知识可以同时传达给许多人，无论他们是否是技术人员。
这种会议最重要的成果是，你可以讨论为什么流程看起来是这样的，为什么选择了一个特定的序列，而不是另一个--本质上，这是一个文档、ADR 和对话的超级混合体。
我再次强调，这种对流程的理解是集体形成的--每个人都觉得自己是解决方案的一部分。就我们的 BDS 而言，EventStorming 就像是在做出关键决策时捕捉专家们的想法。
真实案例
在 Allegro，我们最近遇到了这样一种情况：负责一项关键服务的整个开发团队被调往另一个项目。新团队继承了这项服务，有机会与离职团队合作一段时间。不过，在这种情况下，我们也进行了 EventStorming 会议。
为了提供更多细节，这些会议持续了整整两天，每次持续 8 个小时。
过去五年积累的知识不仅仅局限于两张绘图纸大小、每张长达 6 米的纸上，而是主要以一种无缝的方式融入了参与者的头脑中。我相信，这有助于新团队在接管该领域时增强信心。
有趣的是，你并不需要在 EventStorming 上花费大量时间，就能挖掘出足够的业务知识。在前面提到的案例中，会议持续了两天，但涉及的是整个团队。对于个人而言，两小时的研讨会足以让我们了解流程的全貌。尽管 EventStorming 可以让我们相对轻松地吸收大量知识，了解流程中发生了哪些变化以及变化的原因，但细节决定成败。要真正了解流程是如何变化的，最好先在有经验的人的指导下做一些小任务。
寻找类似 UML 的替代方案？
遗憾的是，EventStorming 并不能解决所有与知识流失相关的问题。虽然我并不怀疑这个工具有多么神奇，但通过它获得的知识只会留在参与者的脑海中。如果不以文档或 ADR 的形式加以保存，它可能会像离职员工一样转瞬即逝。对此有什么办法呢？我们最初的想法可能会导致我们创建某种形式的描述或文件，正如我们所知，这伴随着准备工作的挑战和试图吸收新知识的人的认知超载。
看来，在处理知识流失及其有效转移的问题时，BPMN（即业务流程模型和符号）等工具值得一提。
BPMN 提供了标准化的业务流程图形表示法。
通过使用 BPMN 图，我们可以直观地绘制工作流程和程序。这种方法不仅简化了对复杂流程的理解，还有助于全面记录。当与其他知识共享技术（如 EventStorming）相结合时，BPMN 可以成为保存和传递关键业务知识的强大资产。
然而，BPMN 有一套复杂的符号和符号规则，这可能会使某些人创建和解释图表变得复杂。创建
创建高级 BPMN 图表并充分利用该符号的潜力需要专业知识和经验。
不熟悉 BPMN 的人可能很难有效地使用它。尽管有这些不便之处，BPMN仍然是许多组织建模和记录业务流程的重要工具。我认为它是对前面提到的技术的完美补充。
只要记住在你的工具库里有合适的工具，更重要的是，要根据实际情况选择合适的工具，同时考虑到它的优缺点。