团队交互模式
§1摘要与结论
显式定义团队之间的交互方式——限时高带宽协作、清晰边界的服务消费、以及教练式促进——以消除含糊的协调要求，使团队边界的成本与收益可被管理。
别名：interaction modes、三种交互模式、协作模式、X-as-a-Service | 英文：Three Team Interaction Modes | 类型：方法 / pattern
§2局部关系图
§3原理 · 为什么
团队间关系不清是协调成本的主要来源。含糊的「加强沟通」「密切配合」既无法执行也无法评估。团队交互模式把跨团队关系收敛为若干种有明确成本、时长与边界的形态，让协作从默认的、无限制的高成本模式，转为按需选择、可预期的关系。其核心洞见是：并非所有协作都值得高带宽；多数跨团队关系应追求低交互、清晰边界，只在探索新事物时短期使用高带宽协作。显式定义交互方式，也使团队边界成为可管理的对象。把关系显式化还有一个附带收益：团队可以就「我们是否需要如此紧密」展开讨论，从而把隐性协调成本变成可管理的选择。
§4机制 · 如何运作
三种模式对应不同目的与成本。协作模式是高带宽、双向的，适合共同探索新接口、新技术或新实践，成本高且应限时，探索完成后应退出。服务消费模式是一种一方提供、一方按约定使用的关系，交互低、边界清晰，是成熟关系的默认形态。促进模式是一方帮助并指导另一方，目标是让对方获得能力后不再依赖，通常是临时、聚焦的。选择哪种模式取决于任务状态：不确定、需共创时用协作，稳定、可标准化时用服务消费，能力缺口明确时用促进。三者可随成熟度演化。三种模式并非互斥，同一对团队可在不同任务上采用不同模式，关键是让模式与任务的不确定程度相匹配。三种模式的成本结构差异明显。协作模式带宽最高、代价最大，适合双方共同解决尚不确定的问题，因此必须限时并设退出条件，否则会长期占用双方的核心资源；服务消费模式把关系固化为一方提供、一方按约定使用，交互频率低、边界清晰，是稳定关系的默认形态；促进模式以能力转移为目标，通常临时而聚焦，一旦对方可以自持就应结束。三种模式可以随成熟度演化：新接口先在协作中探索，稳定后转为服务消费；能力缺口先用促进补齐，再交回原团队。
§5工程 · 怎么落地
实践中应把团队交互方式显式登记并公开，让每个跨团队关系都能回答「我们处于哪种模式、期望持续多久、退出条件是什么」。对处于协作模式的团队，设置明确的结束时间与产出目标，避免高成本协作长期化。对适合标准化的交互，优先把它转化为清晰边界的服务，减少双向依赖。对促进关系，应约定能力转移的验收标准，防止教练关系变成长期代劳。定期复核交互方式是否与当前任务状态匹配，当团队能力或系统边界变化时及时切换模式。登记与复核不必沉重，关键是让模式变化有明确触发条件，避免关系在无人注意时长期停留在高成本状态。落地时要做的是把交互方式显式化并公开，让每对团队都能说明当前处于哪种模式、预期持续多久、什么条件下切换或退出。对标注为协作的关系，应设置明确的结束时间与共同产出，避免高成本协作被默认长期化。对适合标准化的关系，应优先转成边界清晰的服务，减少双向依赖。对促进关系，应约定能力转移的验收标准，防止教练关系退化为长期代劳。团队关系是时点快照，因此模式需要随目标与探索结果定期复核。
§6权衡卡
风险出现在模式与任务状态不匹配时。
反例之一是把协作当成默认关系，导致所有团队都疲于协调；反例之二是把服务消费当成唯一目标，在需要共创的阶段过早划清边界。
- 交互模式是简化模型，无法覆盖所有真实关系。
- 长期维持协作模式会耗尽团队带宽，但过早切换到服务消费模式又可能在边界尚未稳定时制造错误抽象。
- 服务消费要求接口稳定，若需求本身仍在剧烈变化，强推服务化会锁定错误设计。
- 促进模式若缺乏退出机制，会演变为依赖而非赋能。
- 因此交互模式应随任务的不确定程度动态选择，并以团队带宽与边界稳定性作为切换依据，而非追求某种模式上的统一；也应接受边界在一定时期内是模糊的。
- 过早把仍在剧烈变化的关系固化为服务，会在边界尚未稳定时锁定错误的抽象；长期停留在协作模式，则会让双方团队被协调耗尽带宽。
- 促进模式若没有退出机制，会把赋能变成依赖。
- 此外，模式无法覆盖所有真实关系，处于过渡期或需要多方共同探索的场景，边界本就模糊，强行归类反而失真。
- 因此应按任务的不确定程度选择模式，并接受一定程度的模糊与动态切换。
权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7冲突 / 对比表
| 对照维度 | 团队交互模式 | 平台团队与最薄可行平台 |
|---|---|---|
| 定位 / 依据层 | 团队交互模式 · Three Team Interaction Modes | 平台团队与最薄可行平台 · Platform Team and Thinnest Viable Platform |
| 核心定义（原文） | 显式定义团队之间的交互方式——限时高带宽协作、清晰边界的服务消费、以及教练式促进——以消除含糊的协调要求，使团队边界的成本与收益可被管理。 | 以产品方式建设平台团队，把通用能力封装为可自助使用的内部产品，以降低流对齐团队的认知负荷、加速交付；并以最薄可行平台约束平台规模，避免臃肿平台制造新依赖。 |
| 首条机制断言（原文） | 团队间关系不清是协调成本的主要来源。 | 流对齐团队若被迫自建一切通用能力，认知负荷将迅速超载，交付速度随之下降。 |
| 张力冲突关系 | 平台服务化与高带宽协作需求的张力（张力冲突） | 同一条 张力冲突 边的另一端 |
| 典型反例（原文） | 反例之一是把协作当成默认关系，导致所有团队都疲于协调；反例之二是把服务消费当成唯一目标，在需要共创的阶段过早划清边界。 | 反例之一是平台越做越厚，提供的抽象超出必要，使用方反而需要理解更多；反例之二是以标准化为名集中审批权，使平台从赋能工具变成管控关卡。 |
| 处置要点（原文） | 实践中应把团队交互方式显式登记并公开，让每个跨团队关系都能回答「我们处于哪种模式、期望持续多久、退出条件是什么」。 | 实践中应先把平台当作产品经营：识别真实使用方与其核心痛点，按优先级交付能显著提速的能力，而不是罗列应建设的功能清单。 |
§8信源与核验
核验结论：高带宽协作成本高且应限时，多数成熟关系应转为低交互、清晰边界的服务消费，并按任务状态选择模式 [WEB-045]
§9原始关系清单
展开：本节点的全部原始关系边（4 条，含边 ID 与方向）
| 关系 | 方向 | 对端节点 | 说明 |
|---|---|---|---|
| 张力冲突 | ← MTH-N-04 | 平台团队与最薄可行平台 E-659 | 平台服务化与高带宽协作需求的张力 |
| 依赖关联 | ← MTH-N-02 | 团队拓扑四类型 E-653 | 团队类型须以交互模式定义协作 |
| 依赖关联 | ← MTH-N-04 | 平台团队与最薄可行平台 E-655 | 平台团队主要采用服务消费交互 |
| 依据推导 | → ESS-N-03 | 团队边界与架构边界耦合 E-648 | 交互模式设计依据团队边界耦合 |