名称: 交互模式 描述: 团队交互模式及其随时间演变 允许工具: 读取, 全局搜索, 查找, 写入, 编辑
团队交互模式技能
何时使用此技能
在以下情况下使用此技能：
- 交互模式任务 - 处理团队交互模式及其随时间演变
- 规划或设计 - 需要交互模式方法的指导
- 最佳实践 - 希望遵循既定模式和标准
概述
使用Team Topologies交互模式定义和演变团队交互模式。
强制要求：文档优先方法
在定义交互模式之前：
- 调用
文档管理技能获取交互模式指导 - 通过MCP服务器验证Team Topologies概念（使用困惑度）
- 基于Skelton和Pais的交互模式提供基础指导
三种核心交互模式
Team Topologies 交互模式：
┌─────────────────────────────────────────────────────────────────┐
│ 交互模式 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ 协作 │ │
│ │ │ │
│ │ ┌───────┐ ┌───────┐ │ │
│ │ │ 团队 │◄──────────►│ 团队 │ │ │
│ │ │ A │ 共同工作 │ B │ │ │
│ │ └───────┘ └───────┘ │ │
│ │ │ │
│ │ 高带宽 • 共享目标 • 时间限制 │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ X-即服务 │ │
│ │ │
│ │ ┌───────┐ ┌───────┐ │
│ │ │ 团队 │───────────►│ 团队 │ │
│ │ │ A │ 消费 │ B │ │
│ │ └───────┘ API └───────┘ │
│ │ │
│ │ 清晰API • 低耦合 • 可持续长期 │
│ └──────────────────────────────────────────────────────────┘
│ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ 促成 │ │
│ │ │
│ │ ┌───────┐ ┌───────┐ │
│ │ │促成团队│──────────►│ 团队 │ │
│ │ │ │ 帮助改进 │ A │ │
│ │ └───────┘ └───────┘ │
│ │ │
│ │ 知识转移 • 时间限制 • 退出计划 │
│ └──────────────────────────────────────────────────────────┘
│ │
└─────────────────────────────────────────────────────────────────┘
协作模式
协作：密切合作以实现共享目标
特征：
• 高带宽沟通
• 共享结果责任
• 团队边界模糊（暂时）
• 频繁同步
• 联合决策
何时使用：
• 新产品/服务开发
• 复杂集成工作
• 创新或发现阶段
• 重大架构变更
• 快速问题解决
持续时间：
• 时间限制（数周至数月）
• 不可长期持续
• 应演变为X-即服务
工作迹象：
✓ 联合拥有结果
✓ 频繁非正式沟通
✓ 共享理解发展
✓ 共同解决问题
✓ 双向知识转移
反模式：
✗ 协作无结束日期
✗ 一个团队完成所有工作
✗ 无知识转移发生
✗ 依赖性增加
✗ 以“协作”为借口模糊边界
示例：
┌─────────────────────────────────────────┐
│ 支付团队 + 安全团队 │
│ │
│ 目标：实现PCI合规 │
│ 持续时间：3个月 │
│ 退出：安全变为X-即服务 │
│ │
│ 活动： │
│ • 联合设计会议 │
│ • 共享Slack频道 │
│ • 配对实施 │
│ • 知识转移会议 │
└─────────────────────────────────────────┘
X-即服务模式
X-即服务：通过API消费另一团队的能力
特征：
• 清晰、版本化API
• 最小协调需求
• 团队独立运作
• 提供者-消费者关系
• 尽可能自服务
何时使用：
• 稳定、定义明确的能力
• 平台团队提供
• 标准基础设施需求
• 商品化服务
• 协作建立模式后
持续时间：
• 长期可持续
• 默认交互模式
• 可从协作演变而来
工作迹象：
✓ 消费者成功自服务
✓ 提供者很少被联系
✓ 存在清晰文档
✓ 版本化允许演变
✓ 两团队独立运作
反模式：
✗ 持续后门请求
✗ 文档总是过时
✗ 无警告的破坏性变更
✗ 提供者成为瓶颈
✗ 服务不符合需求
示例：
┌─────────────────────────────────────────┐
│ 流对齐团队 → 平台团队 │
│ │
│ 服务：容器部署 │
│ 接口：CLI + Terraform模块 │
│ 文档：自服务指南 │
│ 支持：办公时间 + Slack │
│ │
│ 消费者： │
│ • 阅读文档 │
│ • 使用CLI部署 │
│ • 如有阻塞提交问题 │
│ • 参加办公时间提问 │
└─────────────────────────────────────────┘
促成模式
促成：帮助另一团队改进其能力
特征：
• 促成团队领导
• 知识转移重点
• 教学而非执行
• 时间限制参与
• 清晰退出标准
何时使用：
• 识别能力差距
• 新技术采用
• 流程改进需求
• 团队在模式上挣扎
• 技能发展需求
持续时间：
• 时间限制（数周至数月）
• 能力转移时退出
• 非永久性
工作迹象：
✓ 接收团队获得技能
✓ 随时间帮助减少
✓ 促成团队可退出
✓ 接收团队拥有能力
✓ 知识文档化
反模式：
✗ 促成团队完成工作
✗ 无技能转移发生
✗ 创建依赖性
✗ 参与无限期拖延
✗ 接收团队被动
示例：
┌─────────────────────────────────────────┐
│ DevOps促成 → 结账团队 │
│ │
│ 目标：提高CI/CD成熟度 │
│ 持续时间：6周 │
│ 退出：团队拥有其流水线 │
│ │
│ 活动： │
│ 周1-2：评估与规划 │
│ 周3-4：配对改进 │
│ 周5：团队领导实施 │
│ 周6：文档与移交 │
└─────────────────────────────────────────┘
交互模式选择
模式选择矩阵：
┌────────────────────┬─────────────────┬─────────────────┬─────────────────┐
│ 情况 │ 协作 │ X-即服务 │ 促成 │
├────────────────────┼─────────────────┼─────────────────┼─────────────────┤
│ 新产品开发 │ ✓ 从此开始 │ → 演变为 │ │
│ 发现工作 │ ✓ │ │ │
│ 复杂集成 │ ✓ │ │ │
├────────────────────┼─────────────────┼─────────────────┼─────────────────┤
│ 稳定能力 │ │ ✓ 默认 │ │
│ 平台服务 │ │ ✓ │ │
│ 基础设施 │ │ ✓ │ │
├────────────────────┼─────────────────┼─────────────────┼─────────────────┤
│ 技能差距 │ │ │ ✓ │
│ 流程改进 │ │ │ ✓ │
│ 采用帮助 │ │ │ ✓ │
└────────────────────┴─────────────────┴─────────────────┴─────────────────┘
交互演变
典型演变模式：
模式1：协作 → X-即服务
开始 中 结束
┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐
│ A │◄──►│ B │ → │ A │◄──►│ B │ → │ A │───►│ B │
└─────┘ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘
协作 模式出现 API定义
模式2：促成 → 独立
开始 中 结束
┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐
│ 促成 │───►│ A │ → │ 促成 │───►│ A │ → │ 促成 │ │ A │
└─────┘ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘
重帮助 轻触 团队独立
模式3：X-即服务 → 协作 → X-即服务
开始 中 结束
┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐
│ A │───►│ B │ → │ A │◄──►│ B │ → │ A │───►│ B │
└─────┘ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘
使用服务 重大变更共同 新API版本
团队类型与交互兼容性
交互兼容性矩阵：
│ 流对齐 │平台 │促成 │复杂子系统 │
│ │ │ │ │
────────────────────┼────────┼────────┼────────┼───────────┤
流对齐 │ 协作 │ XaaS │促成 │ XaaS │
────────────────────┼────────┼────────┼────────┼───────────┤
平台 │ XaaS │ 协作 │促成 │ XaaS │
────────────────────┼────────┼────────┼────────┼───────────┤
促成 │促成 │促成 │ 协作 │ 促成 │
────────────────────┼────────┼────────┼────────┼───────────┤
复杂子系统 │ XaaS │ XaaS │促成 │ 协作 │
│ │ │ │ │
────────────────────┴────────┴────────┴────────┴───────────┘
XaaS = X-即服务（默认，可持续）
协作 = 协作（时间限制）
促成 = 促成（时间限制，知识转移）
交互反模式
应避免的反模式：
1. 永久协作
问题：两团队总在协作模式
影响：两团队均不完全独立
修复：定义API，演变为X-即服务
2. 促成无退出
问题：促成团队永不离开
影响：创建依赖性，非能力
修复：时间限制参与，定义退出标准
3. X-即服务无服务
问题：声称API但非实际自服务
影响：隐藏协作，提供者超载
修复：投资文档，自动化
4. 协作剧场
问题：称为协作但一团队完成工作
影响：无知识转移，怨恨
修复：定义联合结果，共享工作
5. 太多交互模式
问题：团队与10+团队密集交互
影响：认知过载，上下文切换
修复：减少依赖性，整合交互
6. 无演变计划
问题：交互从不审查或演变
影响：次优模式持续
修复：季度交互审查
交互映射模板
# 团队交互地图：[团队名称]
## 当前交互
### 协作模式
| 合作团队 | 目的 | 开始时间 | 计划结束 | 退出标准 |
|-------------|---------|---------|-------------|---------------|
| [团队] | [为何协作] | [日期] | [日期] | [标准] |
### X-即服务（我们提供）
| 消费者团队 | 服务 | API/接口 | SLE |
|--------------|---------|---------------|-----|
| [团队] | [我们提供什么] | [接口] | [SLE] |
### X-即服务（我们消费）
| 提供者团队 | 服务 | API/接口 | 我们使用 |
|--------------|---------|---------------|-----------|
| [团队] | [我们消费什么] | [接口] | [我们如何使用] |
### 促成（我们接收）
| 促成团队 | 能力 | 持续时间 | 退出标准 |
|--------------|------------|----------|---------------|
| [团队] | [他们帮助什么] | [日期] | [标准] |
### 促成（我们提供）
| 接收团队 | 能力 | 持续时间 | 退出标准 |
|----------------|------------|----------|---------------|
| [团队] | [我们帮助什么] | [日期] | [标准] |
## 交互健康
### 工作良好
- [工作良好的交互]
- [另一个正面交互]
### 需要关注
| 交互 | 问题 | 提议变更 |
|-------------|-------|-----------------|
| [团队] | [问题] | [解决方案] |
## 计划演变
### Q1变更
| 当前 | 目标 | 原因 |
|---------|--------|--------|
| 与团队X协作 | XaaS | API现在稳定 |
### 减少的依赖性
| 依赖性 | 当前影响 | 减少计划 |
|------------|----------------|----------------|
| [团队] | [影响] | [计划] |
## 审查计划
- **上次审查：** [日期]
- **下次审查：** [日期]
- **审查者：** [姓名]
交互审查过程
季度交互审查：
1. 映射当前状态
□ 列出所有团队交互
□ 按模式分类
□ 记录每个持续时间
2. 评估健康
□ 哪些交互工作良好？
□ 哪些在挣扎？
□ 有“永远协作”吗？
3. 计划演变
□ 什么应变更模式？
□ 什么可减少？
□ 什么需要更多投资？
4. 采取行动
□ 更新交互协议
□ 为时间限制设置退出标准
□ 沟通变更
工作流
定义交互模式时：
- 映射当前交互： 今天存在什么？
- 分类模式： 协作、X-即服务，或促成？
- 评估适合： 每种模式是否适合情况？
- 识别反模式： 任何有问题模式？
- 计划演变： 什么应变更以及何时？
- 文档协议： 使交互明确
- 定期审查： 季度评估
参考
详细指导：
最后更新： 2025-12-26