Spotify 模型是什么
Spotify 模型源自该公司公开分享的工程组织实践：小队（Squad）像自组织的小型团队，部落（Tribe）是多支小队的集合，分会（Chapter）横向连接同职能成员，行会（Guild）是跨部落的兴趣社区。Spotify 官方多次说明自身仍在演化，并不建议其他公司直接复制。
结构名词
| 小队 Squad | 类似自组织特性团队，端到端负责一块领域 |
|---|---|
| 部落 Tribe | 若干小队的集合，共享优先级与物理或虚拟空间 |
| 分会 Chapter | 跨小队同职能成员的横向连接，关注技能与标准 |
| 行会 Guild | 跨部落的兴趣社区，自组织的知识分享网络 |
典型使用场景
- 讨论组织敏捷时，用它的结构名词解释小队自治与横向连接
- 设计横向社区：分会承担技能标准，行会承担知识分享
- 判断自身是否具备前提：是否有平台支撑与授权文化
- 避免照搬：把它作为参考案例而非实施模板
- 向管理层说明组织调整的取舍与代价
借鉴要点示例
借鉴要点示例
可借鉴：小队自主权、跨小队横向社群、平台支撑前置
需谨慎：组织结构名词本身（容易只改名字不改权责）
真正关键：授权边界、平台能力、管理者角色转变
判断前提：是否有足够规模支撑分会与行会运转
# 名称好抄，授权与文化难抄可借鉴与需谨慎
| 要素 | 可借鉴之处 | 风险 |
|---|---|---|
| 小队自治 | 端到端负责、减少交接 | 缺少平台支撑时变为重复建设 |
| 部落结构 | 优先级对齐与共享空间 | 规模不足时层级徒增 |
| 分会 | 同职能技能标准统一 | 与直线管理职责冲突 |
| 行会 | 低成本知识分享 | 全靠自愿时很快停摆 |
把结构名词当作转型成果是常见误区：改名之后权责、协作方式与管理考核不变，协调成本反而增加。