改善交付时间应该是每个组织的目标。阻碍交付流程加速的一个主要减速器是组织中的不同团队传统上一直在孤岛中工作。为了解决这个问题，在大多数情况下会出现一个简单的解决方案：增加不同团队之间的沟通。
但是，这个解决方案就足够了吗？当公司成长时，“增量沟通解决方案”如何扩展？我们将在本文中解释其中的一些内容，但作为剧透：适当的团队互动是一个复杂的问题，而复杂的问题很少有简单的解决方案。
跨团队沟通如何扩展
《团队拓扑》一书解决了这个沟通问题，定义了四种基本的团队拓扑和三种团队交互模式：
团队拓扑如下：
- 流对齐的团队：与来自（通常）业务领域的一部分的工作流对齐。
- 赋能团队：帮助与流对齐的团队克服障碍。还检测缺失的功能。
- 复杂的子系统团队：需要大量数学/计算/技术专长的地方。
- 平台团队：一组其他团队类型，提供引人注目的内部产品以加速流对齐团队的交付。
关于交互，他们介绍了以下三种交互模式：
- 协作：团队在规定的时间内一起工作以发现某些东西。
- X-as-a-Service：一个团队提供，一个团队“作为服务”消费。
- 促进：一个团队帮助和指导另一个团队。
根据团队拓扑，他们建议尝试交互模式或其他模式。
当您想应用这些概念时，如果不了解具体的团队背景，就没有正确或错误的答案。但是检查您当前的团队互动并对其进行评估是一个很好的起点。一些例子：
- 在我目前的公司Audiense 中，流对齐团队每次想要创建一些基础架构组件（例如新队列、事件主题等）时都需要与系统团队进行“协作交互”。流对齐团队没有在他们的开发过程中没有这个基础设施创建部分，所以协作总是在功能开发的最后，导致一些块。几个月前，平台团队创建了一项服务，不同的流对齐团队能够在其中创建编写一些代码的基础架构组件，并且这些组件是在 CI 过程中自动创建的。这种交互现在是X-as-a-Service，并且我们已经删除了该依赖项。我们现在有其他部分正在做同样的事情，但这种依赖导致了许多块。
对于类似的情况：在您负担得起 X-as-a-Service 的部分，长期采用协作交互模式是否有意义？ - 如果你通常需要等待一些人做出一些决定：这样做有意义吗？您能否通过在特定时间使用促进交互模式来消除这种依赖性？
这些是你应该问自己的问题类型。
与往常一样，将问题作为一个持续的过程来处理，采取小步骤来改善您当前的情况：
- 评估您当前的团队依赖关系及其交互模式。
- 首先处理阻塞依赖项，这样功能就不会闲置了，这些依赖项是您当前的瓶颈。
- 更新该交互模式并删除该依赖项。
- 找到下一个瓶颈。
- 重新开始。