需要设计或重组工程团队、对齐服务边界、减少跨团队依赖时，用…

在设计或重组工程组织、团队边界、服务所有权、平台团队和跨团队交互时，用 Team Topologies 让团队拓扑支撑快速流动。

适用场景

解决思路

1. 把团队作为交付单元：按团队而不是个人来分配交付责任和所有权。
2. 把团队边界与交互当作系统架构设计：依据 Conway's law，组织沟通结构会塑造系统结构。
3. 决定目标架构后，先塑造团队及其沟通路径，让目标架构自然出现（inverse Conway maneuver）。
4. 让大多数团队对齐业务变化流；只有能减轻 stream-aligned team 认知负荷时才设其他类型团队。
5. 为每一对需要交互的团队明确声明交互模式：collaboration、X-as-a-Service 或 facilitating。
6. 把团队拓扑当作活的架构决策：随着系统、技术和市场变化持续演进，而不是一次性 reorg。
7. 用 0-10 分评估组织/团队设计，报告当前得分，并列出达到 10/10 所需的具体改动。
8. 按评分标准校准：9-10 分为 stream-aligned teams 拥有按认知负荷定尺寸的端到端切片，platform/enabling/complicated-subsystem teams 只在降低负荷时存在，交互模式明确且刻意演进。
9. 7-8 分：大多为 stream-aligned 且有真实平台，但存在共享所有权、未声明交互模式或一个过载团队。
10. 5-6 分：团队类型有名称但按技术层切边界，协作无边界，平台采用被强制。
11. 3-4 分：到处是 component teams，共享服务由工单驱动，每次变更跨多个团队。
12. 0-2 分：组织忽视 Conway's law，按项目配人导致流动，所有人对所有人沟通，无认知负荷概念。
13. 观察实际沟通结构（聊天、代码评审、会议邀请），而不是只看组织架构图；实际沟通驱动架构。
14. 避免“所有人跟所有人沟通”；用有边界的沟通限制耦合，健康组织需要更少而非更多跨团队沟通。
15. 任何人塑造团队、汇报线或招聘时都在做架构决策；架构师要共同设计组织，reorg 要经过架构评审。
16. 当目标架构与团队结构冲突时，按团队结构调整：要么改目标架构，要么改团队结构，不要假设可以强行违反 Conway's law。
17. 想要解耦服务时，先建立小而解耦、能独立部署的团队，让架构跟随。
18. 团队合并等 reorg 提案要作为架构变更评审，由技术负责人/架构师签核，而不仅由 HR 决定。
19. 系统混乱时，映射实际沟通（聊天和评审图）以发现“独立”团队之间的隐藏耦合。
20. 把每个团队强制归入四类之一：stream-aligned、enabling、complicated-subsystem、platform。
21. 默认使用 stream-aligned；其他三类只有在能减少 stream-aligned team 负荷时才保留。
22. 对模糊团队章程强制选择类型，例如把 “Core services team” 转为有内部客户和 SLA 的 platform。
23. 对深度专业能力建立 complicated-subsystem team，并藏在简单接口后，例如推荐引擎团队向 streams 暴露 scoring API。
24. complicated-subsystem team 仅由真实专业能力证明合理，不因管理方便设立；多数组织需要零个或一个。
25. 用 enabling team 推广新实践并限时，例如测试自动化专家用 8 周教练每个 stream，然后退出。
26. 按能力转移而非关闭工单衡量 enabling team；若从不退出，它已变成依赖。
27. platform 的存在是为了减少 stream 的负荷；如果采用平台比自建更难，它就是负债而非平台。
28. 避免反模式：shared-services team 变成工单队列瓶颈；dev 与 ops 之间的 “DevOps team” 增加第三个筒仓；到处 component teams 导致每个特性跨多个团队。
29. 对每一对交互团队只选择并声明一种模式：collaboration、X-as-a-Service 或 facilitating。
30. 把 collaboration 用于发现，并限时；它会模糊边界并提高双方认知负荷，每个团队同时最多一个 collaboration。
31. 已建立接口用 X-as-a-Service；边界仍未知时不要用，因为它用发现速度换可预测性。
32. 让交互模式刻意演进：先 collaboration 发现接口，接口稳定后转 X-as-a-Service。
33. 把持续摩擦当作组织感知数据：别扭的 collaboration 暗示边界错误；笨拙的服务暗示平台需要产品工作。
34. 引入重大新平台能力时，临时声明切回 collaboration，之后再转 X-as-a-Service。
35. 新平台能力：stream 和 platform 先结对 6 周开发 logging API，然后 stream 消费该 API。
36. 两个团队陷入无尽会议时，声明目标模式；若确定为服务关系，就取消常设同步会并发布 API。
37. 能力缺口用 facilitating engagement：enabling team 就 observability 实践结对，在一个季度内退出。
38. 按认知负荷匹配职责：最小化 extraneous load，考虑 intrinsic load，保护 germane load 的容量。
39. 按域而非人数衡量负载；每个团队最多一个 complicated domain，绝不两个；可以持有两到三个 simple domains；绝不把一个 complicated domain 拆给多个团队。
40. 团队过载时减少域，而不是扩大团队；如果软件超出团队规模，拆分软件。
41. 发布 Team API 使团队可被消费：代码、文档、on-call、聊天频道和工作协议，让他人无需会议即可交互。
42. 保持团队长期稳定，优先于项目制配人；解散已磨合团队会丢弃数月信任并再次支付磨合成本。
43. 团队规模约 5-9 人；团队分组注意 Dunbar 自然上限约 15、50、150。
44. 优先移除外在负荷：paved roads、模板和平台服务能买回 germane 容量，无需 reorg。
45. 团队 thrash 时，盘点并分类其域，例如 1 个 complicated + 3 个 simple，则减掉两个 simple 域。
46. 跨团队 onboarding 慢时，发布 team API；每个团队列出 owners、docs、on-call、channels、request path。
47. 项目结束时保留团队并移动工作；把已磨合团队重新指向下一 stream，不要默认解散。
48. 拆分软件时优先沿自然断裂面；默认是业务域（DDD bounded context）。
49. 仅在具体强制理由下使用其他断裂面：监管合规、变更节奏、团队地点/时区、风险、性能隔离、技术、用户画像。
50. 通常避免按技术层拆分；frontend/backend/DBA 拆分会让每个特性都需要三个团队。
51. 对任何拆分做试金石：该部分能否作为独立服务或 SaaS 提供？不能，则边界会泄漏。
52. 把 “monolith” 视为超过代码：单库、耦合发布火车和强制全组织标准化都会阻碍团队独立。
53. 每个工件只有一个所有者；若三个团队共有，提取到 platform，或以 inner source + steward 方式运行。
54. 同一系统不同部分可用不同断裂面；不必一个断裂面统治整个系统。
55. 拆 monolith 先映射 bounded contexts；例如 Orders、Payments、Catalog 变成三个团队拥有的服务。
56. 合规负担无处不在时，按监管范围拆分；把 PCI flows 隔离到一个受审计的服务和团队。
57. 变更速率混合时，按节奏拆分；例如 weekly-changing pricing 与 yearly-changing ledger 分开。
58. 把平台作为内部产品运营，客户是 stream-aligned teams。
59. 从 Thinnest Viable Platform 开始：能加速 streams 的最小事物，甚至可先是一个策展 vetted services 的 wiki 页。
60. 从策展和文档开始（“use these services, this way”）；仅在策展不够时才构建软件。
61. 把内部开发者当客户：做用户研究，发布 roadmap 和 SLA，像产品指标一样跟踪 adoption 和 developer experience。
62. 保持平台采用可选；如果 streams 能离开，平台必须凭价值竞争；强制采用会隐藏平台失败直到灾难发生。
63. 用 shadow platforms、等待时间增长、重复跨团队摩擦和 on-call 痛苦作为拓扑需演进的感知信号。
64. 没有最终拓扑；每几个季度基于信号重新审视团队边界和交互模式，而不是仪式化。
65. 组建平台团队时采用产品实践：roadmap、内部用户研究、office hours、版本化 API 和 SLA。
66. 平台蔓延时回到 TVP：砍到 streams 真正使用的六个服务，其余策展。
67. 组织再次感觉“不对劲”时，运行 sensing review；用 friction log 和等待时间数据驱动一次有意的边界变更。
68. 不要创建位于 dev 和 ops 之间的 “DevOps team”；改为 platform team 提供自助工具，或用 enabling team 培养能力。
69. 不要让 enabling team 永久存在；设置时限和明确退出标准。
70. 不要强制平台采用；保持可选并让平台凭价值竞争。
71. 不要按技术层拆团队；沿业务域断裂面拆分并采用 stream-aligned ownership。
72. 项目结束时不要解散团队；保持长期团队，把工作流向团队而非把人流向项目。
73. 不要把 shared-services team 当工单队列；转为 platform-as-product（自助）或 enabling team。
74. 不要按人数而非认知负荷定团队规模；盘点并分类域，每团队最多一个 complicated domain。
75. 不要留下隐式交互模式；为每对团队声明模式并定期评审演进。
76. 若每个 stream-aligned team 不能无 handoff 交付典型变更，则把团队重新对齐到业务变化的端到端切片。
77. 若每个团队不能归入四类之一，则分类每个团队，转换或解散不合适者。
78. 若每对依赖团队未声明交互模式，则按对声明 collaboration、X-as-a-Service 或 facilitating。
79. 若每个团队的域数量超出认知负荷启发式，则重新分配域；每团队最多一个 complicated domain。
80. 若服务和 repo 边界不与团队边界匹配，则沿断裂面重新拆分；每个工件一个所有者。
81. 若平台采用不自愿或未按移除负荷衡量，则把平台当产品运营，跟踪自愿采用和 DevEx。
82. 若 enabling engagement 未设时限和退出标准，则预先设定结束日期和能力转移目标。
83. 若没有 recurring 机制感知和演进拓扑，则每季度评审 friction、等待时间和 on-call 信号。

适用边界 · 注意事项

• 当问题聚焦于 DDD bounded contexts 的具体建模时，改用 domain-driven-design。
• 当问题聚焦于代码依赖方向时，改用 clean-architecture。
• 当没有权限调整团队边界、汇报线、招聘或交互模式时，只用本技能做诊断和提议，不要直接落地 reorg。