如何通俗易懂地分享复杂的工作知识？

多年来，我们都学到了很多“知识或技能”，其中一些比其他更复杂。对于工作中许多日常事务，最好将它们自动化，或者通过找到更好的解决方法来简化。然而，有时有一些复杂的流程不容易自动化，或者自动化不划算。

同时，我们都知道，当某些单一知识瓶颈控制甚至囤积关键知识时，这不仅对个人，也对企业的安全构成威胁，无论是有意还是无意。

在这些情况下，我们如何确保不只是拥有复杂流程知识的人（不仅知道“做什么”，还知道“为什么”）能处理这项任务，而不是唯一能够处理这个任务的人？

这其实更像是一个讨论话题，不过我会在下面试着给出一个不完整的答案。

这句话可能有点俗套，但我觉得标题很好地概括了我想要传达的意思，感觉挺贴切的。

据我所知，作为知识持有者，有时候放手很难，特别是当你觉得别人可能不会“正确地”完成工作时。但最好的做法是相信他们能够胜任并放权。通常情况下，人们会超出你的预期。

我曾经有过这样的经历，自己掌控某些流程的时间过长，结果当我放手让别人接手时，他们实际上做得比我更好，而且他们常常能从不同角度思考问题，最终优化了整体工作流程。

例如，我最近有一个任务，分析过去24小时内指标的变化图表，以确保系统健康处于正常水平，并确保没有遗漏任何警报。当我查看它时，我在心里将其与之前的基线做了个比较，感觉上大致符合预期。

新来的人第二天也做了同样的任务，注意到有一个指标显示的是“平均值”而不是“最大值”，这意味着我们没有得到所需上下文中该指标的真实数据（我想是指CPU使用率）。他们的新视角揭示了一个非常重要的见解，就像代码审查一样，可以在看似无误的代码中发现错误或缺陷。

不要等待，马上行动起来

从另一个角度来看，即“那个没有所需知识但本应具备的团队成员”，我发现他们似乎太乐意分担他们的工作负担，特别是对于那些没人愿意做的繁琐工作。

在知识持有者不想分享这些知识的情况下，他们通常会认识到他们应该分享这些知识，并且通常可以被说服去做，即使他们有些勉强。这种情况通常也是企业领导者乐于支持的，所以如有必要，可以向上级汇报（不过显然需要谨慎处理，因为处理不当可能损害团队关系）。

在领导职位上，经常需要确保团队没有单一故障点，或者至少通过某种备份策略来最小化这些问题。现代敏捷团队的一个原则是T形开发者的结构，以及跨职能团队的一般概念。这并不意味着每个人都必须完全掌握并接受过每项工作的培训；这样的结构很快就会变得难以管理和事倍功半。T形开发者，即如图示这种技能结构，这样的团队并不意味着每个人都必须具备并接受过每项工作的训练。

然而，这确实意味着团队的所有不同方面都应该有一个基本的了解，例如，大多数或所有团队成员都能做基本支持任务，一两个团队成员可以在这方面带头，推动改进，比如实现自动化，或者简化流程。

这就是为什么知识共享对于高效团队来说如此重要，因为没有它，信息壁垒很快就会形成，并导致团队内部及整个公司会遇到各种麻烦，最终会影响到所有客户。

知识共享面临的最大挑战是确保方法的一致性，这不仅包括实际采取的步骤，还包括应用的质量和细节程度。

作为领导者，鼓励和确保这样的标准可能很困难，但这种一致对团队保持健康和高效至关重要，因此，无论什么层级都应该非常重视。

之前我在一些团队里待过，当成员A完成任务时，基本上肯定要返工，构建失败（通常是因为他们“忘记”在本地运行QA），部署时也会有兼容性问题，同样的任务交给成员B，测试覆盖率高，运行得非常顺畅，并且向前和向后兼容，甚至还有关于它如何工作的说明（当然，成员A就说是没时间做这些）。

团队成员自己应当成为他们标准的执行者，无论是通过代码审查，将工单返回给那些“忘记运行质量检查”的人，还是其他任何情况。通常，相关的人为了避免社交压力和重复工作，会开始改善自己的行为。

这变成了一点杂乱无章，下面就是简短版本。

• 作为一名知识持有者，要保持开放和诚实，并愿意分享你的知识，这不仅帮助团队，也对你自己非常有利！
• 作为一名团队成员或知识'求知者'，提供帮助，大家都会抢着要！
• 作为一名团队领导，在鼓励知识分享时，确保一致性和持续性是关键，并尽量让团队成员自己推动；如果只是自上而下的推动，效果不如同伴间互相推动来得好。

你是一名开发者、技术领导，还是其他相关技术岗位的人员？你对这个话题有什么看法？我很想听听大家关于知识分享的好建议，从分享者的角度、接受者的角度，以及管理层的角度。