2021年初，在Snapcommerce，我们有25名工程师在班组工作。每个小组都有一个工程经理（EM）作为所有项目的负责人和技术负责人（TL），一个产品经理（PM），一个设计师，一个QA团队成员，以及最多七个个人贡献者（IC）工程师。对于工程师来说，从一个IC成长为TL可能是一条具有挑战性或不明确的道路。每个小组有一个TL，这并没有为IC创造一个自然的成长机会，以发展他们的技术领导和所有权技能。
我们的团队在结构上遇到的一些其他挑战包括。
- 缺少重点。我们的冲刺阶段更多的是将高优先级的任务混合在一起，而不是为明确的冲刺目标而努力。
- 在会议上花费太多时间。每个人都出席了所有的团队敏捷会议（站立、冲刺计划和积压工作），但只有一部分会议与他们的工作和专长相关。
- 共同的OKR所有权。团队的OKR交付责任是由团队共同承担的，这往往导致了责任感的缺失。
- 单一的失败点。没有一个有意识的努力来确保单一的失败点不会自然形成。
- 价值流被阻断。影响的结构越来越大，超出了EM或任何一个人能够掌握的范围；显然需要更多的分布式专业知识。
我们的解决方案是将我们的小队组织成一个基于领域的结构，我们将在下面讨论。这有助于团队和组织的整体成功，同时也构建和增加了我们的IC增长机会。
自从推出基于领域的结构以来，我们的团队规模增加了一倍，超过了50名工程师，我们在2022年第一季度的销售额突破了10亿美元。以下是我们如何使用基于领域的班组结构来扩大我们的软件工程团队。
领域的功能和结构
一个领域是一个小队的重点领域或专业。通过每个小队拥有多个领域，小队可以细分他们的工作，以专注于不同的业务、产品或技术重点领域。每个领域通常包含一个或多个OKRs或epics。
每个领域由以下角色组成。
1、领域领导（DL）
对该领域的成功负责的工程师。他们与PM一起工作，领导计划会议、仪式和实施。这是一个技术领导的机会，因为他们作为领域的TL发挥作用，帮助分配领域内的工作。这不是一个正式的导师或领导职位，它通常由团队中的中级或高级工程师担任。
2、领域贡献者（DC）
当涉及到计划会议、仪式和执行时，为领域做出贡献的工程师。每个领域至少会有一个，一个工程师可以同时是一个领域的DL和另一个领域的DC，或者是一个以上领域的DC。
我从第一原则出发，通过观察我们对传统团队的挫败感，看到了改进的机会，从而开发了领域。关于类似的结构，如团队拓扑结构，有一些文献正在出现。领域与流对齐的拓扑结构有关，也就是工作流与业务领域对齐。他们都在一个领域内推动简化的、快速流动的沟通。
领域结构的好处
将我们的小队分为领域，带来了以下好处。
- 多个IC可以增长他们的TL技能
与每个小队只有一个TL相比，有多少领域就有多少DL职位（通常每个小队有3-4个）。DL获得了领导敏捷仪式的机会，而工程师们也有了更大的主人翁意识，在这个结构中成长得更快。我们已经看到工程师成长为高级工程师，高级工程师成为经理。 - 减少会议时间
有了领域，我们不仅减少了会议（因为敏捷仪式是在领域层面上组织的），而且会议更加集中，与个人工作相关。每个工程师的会议时间减少到M/N，其中M是他们所在领域的数量，N是团队中领域的总数量。例如，如果团队有4个领域（N=4），每个工程师最多属于2个领域（M=2），那么与传统的团队模式相比，他们花在会议上的时间应该减少约50%。 - 减少单点故障
在我们以前的团队中，集成电路往往会发展成单点故障/知识孤岛，因为很多人最终会自己去做项目。在一个领域里有多个工程师，没有人应该单独工作。我们增加了协作和知识共享，也降低了总线系数。 - 避免单一经理人负担过重
期望一个单一的EM/TL知道整个团队的所有事情，可能会使他们不堪重负或导致疏忽。有了领域，团队中有多个DL，他们各自负责领导自己的领域并在其中分配工作。EM支持DL。 - 更大的所有权意识
作为团队，对团队OKRs有共同的所有权。领域创建了一个专门的工程师小组，为该领域提供最大的背景、所有权和连续性。在Snapcommerce，它为业务团队提供了明确的联系对象，许多团队很高兴有一个领域专注于他们的倡议。 - 平衡可持续性和生产力
知识共享有助于我们的可持续发展和避免孤岛，但端到端的所有权会推动生产力。通过领域，我们根据工程师所处的领域的多少来调整这种平衡。并非每个人都需要了解我们所监督的所有内容；相反，他们可以深入到监督的一个子集，但不是作为一个单一的故障点。 - 密切协作和目标导向的交付感
现在，我们有更小的工程师单位，有更强的共享所有权和协作意识，而不是一个大的团队，有些人最终会单独工作，以便将我们的努力分配到各个业务需求。我们对团队冲刺目标的最佳实践是，每个领域都有自己的高度集中的目标，并有明确的所有权。
领域结构的问题与挑战
我们对领域的第一次体验是在我们的数据和分析组织中成功地推出了它们。这让我们对建立领域的挑战有了一些经验，比如说。
1、定义好领域
领域往往是按照OKRs来组织的，然而，领域最好能超过季度的界限，以便有更多的技术领导的连续性和专业知识的积累。
无论是基于产品线、目标线，还是技术/架构线，都有必要对领域的定义进行批判性思考。一个以基础设施或架构为竞争优势的高度技术性组织，很可能需要在技术路线上定义领域，因为它需要在一个较窄的领域有深厚的专业知识。初创企业和业务交付组织更有可能在产品或目标线上定义领域。
2、团队结构文件的正规化
自然地，领域在团队层面上创造了一个稍微复杂的结构，这就需要对领域以及它们的DL和DC进行明确的记录。关键是要创建一个团队章程或类似的文件，清楚地说明什么是领域，谁是每个领域的一部分。幸运的是，所有的工程师仍然向EM报告，所以报告结构仍然简单。