工程领导者面临的主要挑战之一是识别知识孤岛。如果不加以识别和解决，这些孤岛会逐渐演变为对个别员工的依赖，这些员工可能（无意中，甚至可能是无意识地）开始拖慢团队的进展。在我职业生涯的某个阶段，我记得我被指派去更改我们 iOS 应用在 Apple Store 中的配置细节。通常情况下，我们优秀的创始 iOS 工程师会负责这个任务，但这次他正在休产假，所以这个任务落到了我身上。
当我开始时，我很快意识到我无法完成这个任务 —— 无论是一个小时、一天还是一周。为什么？因为负责的工程师在离开之前没有将凭据上传到密码管理系统。毕竟，为什么要费心呢，他是处理所有与 iOS 相关事务的专家，做得又快又好。然而，在这种情况下，工作是紧急的，因为我们意识到我们一直在做一些非法的事情（因为我们最近才开始有法律团队），所以必须迅速完成 —— 但我们做不到。
你看到了发生了什么吗？一个知识孤岛让我们陷入了困境！所以现在的问题是：你如何避免这样的知识孤岛和随之而来的个人依赖？我有一些想法可以分享给你。
但首先，知识孤岛为什么会出现？#
在公司早期，只有一个人知道如何做某些事情或只有一个人拥有正确的权限是很正常的。理想情况下，这些情况是有限的，并且不是关键任务。例如，只有一个 CSS 专家能够快速将动画 “调整到完美” 是可以的。然而，只有一个人知道如何回滚部署就不行。
同样，在团队中，有些情况下没有讨论或流程来决定谁将负责某项任务。相反，角色是隐性的 —— 使用内部名称，如 “DevOps 专家” 或 “后端女孩”。还有一些情况，当工程经理或产品合作伙伴需要紧急完成某项工作时，直接找特定的工程师。这样做时，他们往往会绕过团队流程和仪式。
这些情况往往表明：如果不加以注意，它们有可能打开潜在的知识孤岛。
如何识别知识孤岛？#
关键在于寻找，或者说倾听个人依赖。为此，留意以下短语，这些短语表明你有单人依赖：
👉 “我不想做那个任务，因为_非常资深的工程师 X_正在度假”
👉 “我需要问_创始工程师 Y_进行部署，因为他们是唯一有权限的人”
👉 “我在等待_DevOps 专家 Z_的审核后再合并，因为他们是基础设施即代码的专家”
简单来说，任何事情没有按预期进行因为某个人无法使用，表明你可能有问题。
避免知识孤岛的 3 个有效方法#
现在你知道知识孤岛很容易导致单人依赖，并且慢慢地变成一个麻烦，以下是 3 个想法，帮助你从一开始就避免它们：
1. 设计时考虑知识孤岛#
避免只由功能专家组成的团队。至少要有一些全栈工程师或多个人能够处理团队可能会做的任何类型的任务。这将帮助你创造一个文化，让所有团队成员都能舒适地尝试任何类型的任务。
为此，在低层次的团队设计中，始终明确问以下问题：是否有超过一个人能够处理该团队所做的每种工作？
2. 组织团队轮换#
另一个最佳实践是组织团队轮换或团队 “狩猎”，让成员永久（或暂时）加入组织内的其他团队。这有助于鼓励跨团队的知识共享，让人们有机会向之前没有合作过的其他人学习。
从积极的一面来看，团队轮换不仅帮助员工学习新知识，还鼓励个人对他人的工作方式产生同理心 —— 在整个组织中创造对彼此工作的尊重感。由于只有一两个特定团队的成员在这些狩猎中与其他团队合作，每个团队仍然可以正常运作。
3. 确保所有关键任务由两个人完成#
最后，确保至少有 2 个人能够完成将软件投入生产所需的所有关键任务。即使只有其中 1 个人能够很好地完成工作，让两个人了解任务的细节可以避免知识仅限于一个人。
同时，确保这些关键任务的 “如何做” 有文档支持，所有人都可以访问。这样，所有人都能获取知识 —— 帮助你减少对单个人的依赖。
知识共享实践#
优秀的团队将知识共享作为一种实践。这可以通过多种方式实现：
投资于文档#
创建关于如何正确记录的指南，包括在哪里托管所有文档以及以什么格式打包信息（例如，简短的屏幕录制解释视频或清单）。但请记住，文档需要时间。此外，文档可能会迅速变得过时、重复或令人困惑。
为文档设定指南并安排时间创建知识共享文档将有所帮助。定期更新这些文档也很重要，否则所有的工作都可能迅速白费。
组织知识咖啡会#
这些是 “展示与分享” 会议，团队成员分享他们如何完成某项任务。在这些知识共享会议中包括问答时间，可以在组织中创造一个富有成效的同伴学习环境。
这些会议唯一的缺点是，有时对内向的人来说可能会让人感到畏惧，对喜欢通过实践学习的人来说价值不大。通过邀请愿意进行展示和分享的人员来克服这一点。至于团队中的内向者，询问他们是否希望锻炼公共演讲的能力，以激励他们主持这样的会议。
以小组形式工作#
这是我最喜欢的知识共享方式 —— 以小组形式工作（集体编程或成对编程）。在这样的知识共享会议中，所有员工都有机会通过实践学习。这使其成为创造学习文化和防止知识囤积的最有价值的方式之一。
不过，关于这一点的一个常见抱怨是？它会减慢团队的速度。在某些情况下，是的，可能确实如此，但仅在短期内。例如，如果 Java 高手必须与前端新手配对，那么深入研究 JVM 垃圾回收的后端任务可能会完成得更慢。
然而，这仅仅是在短时间内对特定任务的最大速度造成了降低，因为在接下来的一周，你会发现同样的前端新手参与后端任务 —— 避免了为他们专门创造低价值的工作。同样，Java 高手可能会离开去其他公司工作，而在你雇佣新高手之前，前端新手将继续推动产品向前发展。
简而言之，忍受小幅度的减速将会在未来为你节省大量时间 —— 使这一切都是值得的。
结束语#
没有人会在一年中的每一天都工作，而且很少有人会想永远留在你的公司。这使得防止知识孤岛和拯救组织免受单人依赖变得重要。你需要投资于文档，举办知识共享会议，并组织团队轮换。最重要的是，设计团队时要考虑知识共享。
如果你仍然发现自己在降低知识共享的优先级，我建议你假设在你最大的生产紧急情况或最关键的客户紧急功能请求的那一天，你的 MVP 工程师将会高兴地庆祝孩子的出生或结婚。
有了这样的假设，你将走上防止知识孤岛的道路。