建立共享所有权的文化

在2020年，当疫情来袭时，我失去了我的第一份技术工作。那天正好是我从学校接孩子回家，准备开始为期三周的假期。但那一年他们再也没有回去过。不知怎的，我竟然开始面试一份DevOps职位——当时我甚至都不知道DevOps是什么。经过第一次面试后，面试官让我阅读《凤凰项目》(The Phoenix Project)，然后她会给我第二次面试的机会。

在书中，布伦特是大家遇到问题时第一个想到的运维工程师，他总是能给出所有答案，解决各种问题，拯救一天。问题在于，布伦特是一个瓶颈，而不是一个放大器。

当知识被孤立时，我们就会让团队处于风险之中。当有人去度假、需要休息一段时间，甚至更糟糕的是离开公司时，你的团队会怎样？这种影响可能是令人窒息甚至是瘫痪的。孤立的知识所带来的隐性成本会导致一种被称为“知识囤积”的现象，团队成员无论是有意还是无意，都会对自己的专长变得保护起来，不会与他人分享。孤立知识的更多成本包括：

• 单点故障：关键专业知识掌握在少数人手中，造成依赖性。
• 重复努力：由于缺乏共享知识，团队可能不知不觉地重复工作。
• 缓慢入职：新团队成员难以拼凑分散的信息。

如果专业知识在整个团队中分布，并且你不依赖任何一个人，你就能提高团队的稳定性并取得成功。我们没有意识到，孤岛知识的成本要高得多。

孤立的知识导致局部优化，但整体上却变得低效。这意味着团队开始在自己的小圈子里变得极其高效，但整个组织却开始受到影响。你会看到顶尖的工程师在公司的不同角落重新发明轮子，独自进行重复性工作。当你引入新成员时，没有明确的知识共享路径，新人入职缓慢，因为他们需要拼凑零散的知识。这不仅仅是小麻烦，你为此付出了时间、士气和错失机会的代价。

在开发文化背景下，这个问题尤其具有破坏性，会导致团队间实践不一致，并阻碍统一工程文化的形成。开发人员在信息自由流通、协作受到重视、每个人都能获得所需知识的环境中会表现得更好。即使是在像亚马逊推广的“两披萨团队”这样的小型敏捷团队中（团队规模足够小，可以用两披萨来喂饱所有人），如果未采取措施鼓励知识共享，知识孤岛仍然会形成。

我知道有些人一谈到共享所有权就开始紧张起来。你可能会认为这意味着当事情出错时在互相推卸责任。但这并不是重点。这并不是在指责别人。而是要拥抱团队责任，共同贡献、学习和成长。这关乎于创造一个环境，在这个环境中每个人都感到对项目的成功负责，而不仅仅是他们自己的任务。

当我们拥抱共同所有权时，我们承认每个人的观点和想法都很重要，并且他们有能力对项目产生影响。

在两披萨团队结构中，共享所有权不仅有益，而且是必要的。小团队被设计成自主、快速行动且高度协作的。当团队中的每个人都对项目有全面的了解时，每个人都能做出更好的决策，避免重复劳动，并在整个开发过程中保持高标准。这种协作需要一种文化，在这种文化中，专业知识被公开分享，团队的成功被优先于个人的成功。

这就是一个CODEOWNERS文件可以帮助团队开始的地方。如果你知道什么是CODEOWNERS文件，你可能会认为它是一种在GitHub上为特定代码库分配审查责任的方法。但我认为更好的理解方式是将其视为一种专长地图——一个文件，列出了代码库不同部分的主要负责人。

我想花一点时间来改变这样一个观点，即限制访问或创建守门人。相反，我希望你将其视为突出专长和鼓励协作的一种方式。当拉取请求进来时，相关的人会自动收到通知。这也意味着当有人有问题时，他们知道该联系谁。

作为其中的一部分，重要的是要记住，CODEOWNERS 文件并不是一个静态文档。随着团队的成长以及人们开发新的专长领域，它应该随之变化。可以将其视为一个动态文档，代表了团队的集体知识。

别误会：CODEOWNERS 文件并不能解决你所有的问题。它只是一种工具，和其他工具一样，它的有效性取决于你如何使用它。真正的目标应该是建立一个共享知识和持续学习的文化。

让我们从拥有文化的思维转变为专家文化的思维。

所有权意味着排他性。“这是我的代码，我的项目，我的责任。”这种心态可能会制造障碍并阻碍合作。

另一方面，专业知识是值得分享和庆祝的。专注于专业知识会培养一种拥有深厚知识并愿意帮助他人理解这种知识的心态。

当我们建立一种专家文化时，我们也会改变价值的衡量标准，不是看你是否不可或缺，而是看你如何提升整个团队。你不是一个代码“守护者”，而是一个倍增器。我们都希望在团队和组织中拥有倍增器。

那么今天你可以做什么呢？在开源酱（OpenSauced）中，我们为pizza-cli开发了一个codeowners命令，用于分析你的git历史记录，生成一个CODEOWNERS文件，并自动保持其更新。这意味着你不必猜测如果有关于某个特定文件的问题该联系谁。（我在技术中的知识债务问题这篇文章中对此进行了更多讨论。）

对于代码库中的每个文件，pizza-cli + GitHub Action 会分配最多三个“负责人”。为什么是三个？三个负责人可以在明确责任和共享知识之间取得平衡，既不会限制到只有一个负责人，也不会将责任分散给太多人。

记住，这并不是关于建立界限或“专属”领域。而是关于在团队内部展示专业知识，开始对话，并相互学习。

前往pizza-cli试试看。你可以从小规模开始，用一个项目或团队进行测试，并开始讨论代码所有权和专长。

像 pizza-cli 这样的工具只是开始。目标是建立一个知识丰富的开发者文化，在这种文化中，每个人都能茁壮成长。

像 pizza-cli 这样的工具可以帮助确保没有人成为瓶颈。

创建一个共享知识和持续学习的开发者文化是一个持续的过程，但这样的投资是值得的。让我们建立团队，互相提升，拥抱专长，并共同成长。