在组织软件团队的上下文中，“两个披萨团队”范例已经变得非常流行。这个想法是让小型的、自力更生的团队独立工作来解决问题。“两个披萨”指的是保持团队足够小的指导，我们不需要订购超过两个披萨来喂养他们。
今天，这些团队就在我们身边，但我们没有看到我们预期的那种生产力或运输速度。大多数开发人员，特别是在较大的组织中，抱怨会议、沟通的负担、变化的缓慢速度等。初创公司经常通过吹嘘自己的敏捷性来向潜在候选人推销自己。但是，如果每个人都在使用相同的“授权团队”/“自主团队”模式来组织自己，那么大公司为什么会行动迟缓呢？
我认为我们已经失去了“两个披萨团队”(又名自治团队)的初衷。随着公司规模的扩大，我们组织和扩展团队的方式与想法的精神完全背道而驰，这使得保持团队积极性和敏捷性这一本已困难的问题变得更加困难。
“两个披萨”/“自主”团队的概念源于试图最小化多个团队之间的沟通，并授权单个团队完全控制交付客户价值。
在这个想法流行之前，最常见的团队组织方式是后端、UI、DBA、Ops等。构建任何功能都需要所有这些团队之间的大量沟通、协作和协调。
拥有解决单个特定问题所需的所有技能的小团队的概念就是为了解决这个问题。单个团队将获得完整的问题陈述和解决问题所需的工具。理想情况下，这将消除将多个团队围绕共享路线图和交付时间表进行调整的问题，并允许团队端到端地拥有问题解决流程。
两个披萨团队背后有两个核心概念-使命和独立。理想情况下，端到端意味着通向客户或企业。因此，每个自治团队都应该自己产生直接的业务价值，而不会与其他团队有太多重叠。此外，团队应该能够独立实现其目标(即不依赖或不受其他团队的干扰)，这减少了跨团队的沟通开销，因为其成员拥有解决问题所需的所有技能。
在这条线上的某个地方，我们忘记了“减少沟通”，只是开始专注于将独立的团队分配给本质上是微小的业务问题的问题陈述。随着问题空间被更精细地分割，希望在每一步都能达到规模，团队的数量也在增加。例如，原本负责向客户交付新数据的“数据交付团队”不幸变成了“数据摄取团队”、“数据处理团队”和“数据发布团队”(现实世界的例子)。
任务被冲淡了，因为大多数团队现在都在处理问题，这些问题是原始问题的子集，本身就没有价值。团队的成功不再能保证至少一个业务指标的改进。团队的工作不再与业务目标联系在一起，因此它与严格定义的执行范围联系在一起。“数据摄取团队”应该引入数据，仅此而已。虽然团队仍被允许随心所欲地执行此操作，但成功实现其目标并不意味着正在向客户交付新的数据。
作为直接后果，自治权被稀释了。单个团队本来可以聚集在一起解决数据交付问题，现在，拥有不同经理和不同路线图的多个团队必须聚集在一起，才能向客户交付任何东西。这正是创建这些小团队首先要解决的那种协调开销。
协调，也被称为调整、沟通、共享路线图、甘特图和许多其他听起来很积极的名字，是自治团队的大敌。
我们有很多独立的小团队，没有直接的影响，让每个人都指向一个方向已经成为一场噩梦。项目经理掩盖了协调优先级、努力和时间表所涉及的日益增加的复杂性，开发人员和经理越来越多地对与其他团队沟通的整个业务置之不理。
我们把一个好主意做得太过分了。现在的“小”团队当然很小，但是我们忘记了减少沟通的部分。取而代之的是，我们现在被提供给“小型的、高度协作的”团队，作为一种新的理想，就好像在执行过程中需要高度协作一样。
这对组织来说是一个巨大的盲点。小团队的隐性优点(没有任何原始背景)现在已经内在化到这样的程度，以至于小团队之间的深度协作在组织中被认为是一件好事。团队的生产力和动力在不断下降，即使他们的规模在增加。不知何故，我们仍然相信这种团队间组织工作的方式是有效的，一定是其他什么原因导致了生产率的下降。
在构思和集思广益的过程中，协作是一个很好的主意。它有助于从许多不同的人那里获得大量的信息，并可以帮助我们发现我们可能没有考虑到自己的新方面。它可以暴露解决问题的其他方法，甚至可以暴露已经由其他人解决的这个问题的一些版本。人与系统之间广泛的协作是我们如何构建比各部分之和更重要的东西的方式。
然而，一旦我们进入执行阶段，协作就非常昂贵。协作意味着两个人或团队不能只专注于自己的工作，他们还必须担心另一个人什么时候完成他们的工作，以及他们如何相互同步才能到达终点线。
我可以引用任何数量的工程原理来驳斥协作团队的神化，这似乎是当今的常态。
通常，假设多线程可以提高系统的性能。如果每个线程可以完全独立地在其自己的核心上执行，而无需与任何其他线程交谈或共享任何数据，则这是完全正确的。但是，当我们以某种共享状态结束或者线程数量超过CPU时，同步开销可能很快就会超过使用该技术所获得的所有性能收益。
阿姆达尔定律规定，当增加一名工人时，增加的产量有一个有限的上限。众所周知的问题是，每个额外的工作进程都会带来不可并行化的、呈指数级增加的通信开销。在某种程度上，增加另一名员工会让事情变得更糟，而不是更好。
“9个开发人员不可能在1个月内完成9个月的项目”是软件管理中的一个著名理念。然而，我们看到经理们试图孤立地发展和管理他们的团队。为什么会这样呢？
我的假设是，我们看到单个团队快速交付，我们将其解释为向这些团队添加更多成员将进一步扩大产出。在我们通过将团队从整个系统上下文中隔离出来来检查团队的世界中，很容易混淆独立和自治。
在高度协作的设置中，正确看待组织的方式类似于工厂车间。约束理论告诉我们，在这种情况下增加产量的唯一途径是拓宽瓶颈，拓宽从构思到最终交付到客户的整个“工作流程”。
但是，当我们单独看待每一步，并脱离“管道”其余部分的上下文时，“交付”具有非常不同的含义。意思就是“滚出我的门”。任何用这种观点来提高产出的尝试都只会产生局部最大值，这对最终的产出没有任何意义-它甚至可能是有害的。
这就是我们最终拥有太多小团队的地方，他们只关注自己的一小部分工作。这就是他们被激励去做的事情。如果我们团队的产出是按顺序安排的，那么无论他们在日常工作中多么独立，他们在交付方面都不是自主的。
任何管理过供应链的人都知道，以顺序方式组织的独立团队要求进行大量的沟通和反馈。沟通的渠道并没有被创建的小团队移除-它们已经被成倍增加了。更糟糕的是，通信发生在团队边界，那里实际上是最弱的(微服务中的通信开销很容易浮现在脑海中)。
如果我们根据问题陈述而不是功能来组织我们的独立团队，会发生什么？被授权使用其可支配的任何方法解决客户问题的团队本质上拥有需要完成的任务的整个“管道”。此团队不需要跨团队协作和沟通即可完成其工作。这个团队不仅独立运作，还独立为客户提供价值。
当团队独立地“向客户交付价值”时，它就是自主的。在他的小说“目标”中，Eliyahu M.Goldratt通过让他的主人公(他是工厂经理)将他的成功定义为销售增加，从而完美地强调了这一点。销售通常不是制造团队的问题，但这部小说强调了定义面向客户的“全球”目标是如何改变表现不佳的工厂的。
扩展此团队将直接增加更多业务价值，因为新资源将是(应该是？)。在团队的流水线内以最优的方式部署。这与之前任务所有者创建本地Maxima的情况没有什么不同，但因为团队拥有最终的客户问题，即使是本地最大值也是客户的胜利。
这就是最初的“两个披萨”团队要做的事情。不仅要独立执行，而且要独立交付客户价值。自治背后的核心思想不是安排团队来最大化价值链中步骤的输出，而是以这样一种方式定义价值链，即一个紧密联系的团队可以在上面释放出来。每个团队都必须根据客户成功来定义其产出，因为这就是组织边界的划分方式。
无论我们选择应用哪种范式，扩展团队的问题都是递归适用的。比方说，我们有自治的团队，现在我们如何扩大他们的产出，以实现更大的目标？
这是大型组织面临的中心问题。在公司的早期，领域专家涌现出来，并领导解决特定客户问题的小团队。由于公司规模较小，对客户产生直接影响通常并不困难。
然而，随着组织在范围、规模和抱负上变得越来越大，每个小团队现在都被期望提供越来越多的服务。这通常意味着通过增加更多成员来扩大团队规模。然后，每个团队开始在内部拆分成单独的子团队，我们又回到了独立团队，而不是自治团队。
我们如何扩展我们的团队，以实现越来越雄心勃勃的目标，同时保持他们的自主性？我将在下一篇文章中对此提出一些意见。