团队拓扑

• 我们是否有合适的团队？
• 我们是否在某些没有任何团队处理的领域缺乏能力？
• 团队在自主权和其他团队的支持之间是否已实现必要的平衡？

开发和运营主管可以通过团队拓扑的视角审视他们的组织，从而更好地了解是否已有合适的团队。我们建议将团队变化的数量减少到四大基本团队拓扑，这些拓扑对于高层管理层和实际团队成员自己来说都很容易理解：

• 流对齐团队
• 平台团队
• 复杂子系统团队
• 助力团队

请注意，这些团队类型会根据公司的规模和成熟度采取不同的形式。实际上，组合多种类型的团队，或者将一个团队转变为另一个团队，通常是最好的方法。

流对齐团队专注于单一、有影响力的工作流。它可以是单个产品或服务、单个功能集、单个用户过程或单个用户角色。该团队有能力尽可能快速、安全和独立地为客户或用户创造和交付价值，而无需将部分工作交给其他团队来完成。

由于流对齐团队的工作涉及全方位交付，因此他们必须更接近客户，而且通常已经实现敏捷。该团队会将客户反馈纳入开发周期，同时维护生产环节的软件。

虽然流对齐团队在很多软件公司中十分常见，但其他组织可能更熟悉按职能组织的团队结构（即独立的工程、设计、QA 团队），而不是交付流。

由于流对齐团队是组织中最常见的团队类型，因此其他团队的角色均是相对于流对齐团队来定义的。流对齐团队应定期联系以下支持团队（复杂子系统、助力和平台团队），以不断提高产品和服务的交付速度和质量。

平台团队使流对齐团队能够高度自主地交付工作。虽然流对齐团队仍对生产环节的构建、运行和修复应用具有完全所有权，但平台团队会提供流对齐团队可以使用的内部服务。

平台团队负责创建可供众多流对齐团队使用的功能，而且开销很小。通过优化产品，平台团队可以最大限度地减少流对齐团队的资源和认知负担。这也使最终用户受益，因为平台团队可以创建跨越不同用户体验或产品的一致体验。

在 Atlassian，平台团队负责构建我们所有产品（例如身份管理）使用的服务，并为流对齐团队提供相关文档、支持和咨询。

复杂子系统团队会根据特定技能和知识负责构建和维护系统的一部分。大多数团队成员必须是特定知识领域的专家才能理解和更改子系统。

该团队的目标是为那些在包含或使用子系统的系统中工作的流对齐团队减少负担。借助复杂子系统团队的专业知识和能力，流对齐团队不必在对于其日常工作来说过于复杂的领域培养能力。该团队的团队成员可能具有某些微服务（例如开票服务）、算法甚至人工智能方面的专业知识。

一个易犯的错误是在每个使用子系统的流对齐团队中安插专家。虽然这可能看起来很有效，但最终并不具有成本效益，而且也超出了流对齐团队范围。

流对齐团队不断承受着快速交付和响应更改的压力，因此很难有时间研究、学习和磨炼新技能。

由既定技术（或产品）领域的专家组成的助力团队可帮助弥合这一能力差距。这些团队专注于研究和实验，就影响工具堆栈的工具、框架和生态系统选择提出明智的建议。

此举可让流对齐团队有时间获取能力并就此提升，而无需将时间浪费在偏离其主要目标的事务上。助力团队主要致力于通过专注于问题而非解决方案来提升流对齐团队的能力，从而提高其自主性。

如果助力团队的工作完成出色，那么它所协助的团队应在大约几周后便不再需要其帮助。助力团队不必处理长久依赖性。