Spotify 以开发一种吸引大量关注的工程文化而闻名：一切都围绕着创建“小队squads”；许多产品团队试图效仿它，但很少有人能成功。尽管 Spotify 不再使用产品小队，但该方法可以为其他敏捷产品团队带来好处。在本文结束时，您将对 Spotify Squad 框架有一个清晰的了解，以及哪些部分可以帮助您的产品团队文化蓬勃发展。
Spotify Squad 框架的简史
Spotify 于 2008 年推出，为其开发方法使用了一个 Scrum 团队框架。然而，他们的快速增长突显了传统的 Scrum 实践并不总是 Spotify 最敏捷的选择。团队决定替换 Scrum方法和术语。
Spotify Squads 是由八人或更少人组成的跨职能、自力更生的团队。他们对任何产品构建负有端到端的责任。这包括：
- 构思
- 设计
- 测试
- 部署
- 优化
每个小队都有一个独特的使命、短期目标和一些长期目标——所有这些都有助于实现更大的公司使命。
就Spotify 而言，公司的使命是：释放人类创造力的潜力。
工程小组做出本地决策，这意味着他们拥有推进项目或启动项目的自主权，而无需依赖高层的批准。
Spotify 建立团队是出于信任——依靠雇佣聪明的人来做出明智的决定，并以建立一支自主的劳动力为目标。
什么是 Spotify 小队Squads、部落tribes和行会guilds？
Spotify 将工程文化提升到了新的高度——以及新的名称。您需要了解一些术语才能处理整个产品团队结构。
- 小队Squads：由八名或更少的产品人员组成的任务驱动型小组。一个产品生态系统可以有任意数量的小队，只要他们能在更大的产品使命上保持一致。 Spotify 模型小队合作寻找解决方案。特定的小队将拥有特定的系统或流程——他们的目标是让彼此能够使用这些系统或流程，以便其他小队可以完成他们的任务。 小队往往专注于产品交付和质量。
- 部落Tribes：小队的组。部落可以包括任意数量的小队，并且通常会出于某种目的将它们组合在一起。这可以是位置、产品区域、问题的整体概览或更多。
- 章Chapters：整个小队的能力领域，在Spotify 小队部落内。
例如，四个小队中可能有一个专门从事应用程序开发的人。这四个人将组成四个小队的一章。
每个guilds都有一名负责人担任正式的直线经理。这种结构使人们能够从一个小队跳到另一个小队，并在不失去他们的经理和领导者的情况下开展不同的计划。 - 行会guild：一个由不同小队和部落具有共同兴趣的人组成的轻量级社区。
公会可以有来自同一个小队的多个人。它们对于建立超越其角色的文化和员工敬业度至关重要。
人们可以随心所欲地来来去去，公会可以围绕 Python 或 Google Analytics 等专业开发领域展开。或者，他们可以专注于个人兴趣，例如读书俱乐部、瑜伽或权力的游戏。
Spotify 强调社区胜过等级制度，并相信一个足够强大的社区可以做出正确的决定，而无需得到高度重视一致性的领导者的批准。
Spotify 相信，通过小队、部落、分会和公会建立一个自治社区，他们正在建立一个有潜力“创造更好的东西”的产品团队。
Spotify产品开发方法
自主的 Spotify 产品小组使产品发布顺利进行。产品团队希望轻松且频繁地发布，他们鼓励“可管理”和频繁发布。
“我们的目标是比任何人都更快地犯错。” - Spotify 的创始人
Spotify 更改了其产品的架构以实现解耦发布。这意味着，某些小队负责应用程序的某些功能或特定区域，而不是所有小队都负责整个应用程序。
小队分为三个核心区域：
- 客户端功能组
- 基础设施队
- 客户端应用程序小队
解耦发布会产生“有限的爆炸半径”，这意味着如果产品部署失败，则它仅限于其直接半径，并且不会使整个产品失败。
- 首先构建原型或MVP
想想；建造了它；交付它；调整一下！
Spotify Squads 的产品开发方法基于精益创业原则。他们通过研究确定问题，定义描述来总结解决方案，并就该新产品更新或功能的目标和效果建立一个假设（或多个假设）。
一旦上述所有内容都到位，Spotify Squads 就会构建原型来运行用户测试。将此方法整合到您的产品开发团队中的一个绝妙方法是使用 Chameleon 运行 fake door测试。
- 如何运行 Chameleon fake door测试以获取用户反馈
- 在您的产品中上传样机图像- 低保真原型。
- 当该样机通过点击触发或悬停，启动应用程序内Microsurvey。
- 向用户解释这是一个 WIP。询问他们是否有兴趣试用新功能并提供反馈。
- 您还可以询问用户在看到样机后他们希望、想要或期望从新功能中看到什么。
- 收集您的反馈并就产品构建做出数据驱动的决策。
接下来，Spotify（你可以）构建一个最小可行产品（MVP）。Spotify 也将其称为最小可爱产品（MLP）——非常可爱。
这个初始产品足以满足我们上面提到的叙述，但远非完美。
- 测试影响并分析数据
接下来，MVP 会发布给一小部分用户。该小组运行 A/B 测试和其他用户测试方法，以帮助做出优化调整的决策。
- 如何使用 Chameleon 分析 UX 和 UI
这是尝试客户反馈调查以获取有关新产品的一些定性数据的最佳时机。如果您使用 Chameleon 分析进行应用内定量评估，您还可以轻松获得大量集成，包括：
- Mixpanel
- Amplitude
- FullStory
- Heap
- Kissmetrics
然后，负责的发布小组将继续调整并将产品发布给同一个用户测试组，直到他们对自己的工作感到满意并可以开始向 Spotify 的整个用户群推出。
当然，它不止于此。有一个持续的反馈循环和对新功能或产品的持续测试。
嘘。像Microsurveys这样的变色龙工具可以成为收集连续定量 和定性数据以用于未来产品调整并突出显示需要注意的 UI 错误的好方法。
从 Spotify Squads 失败中学习
以上似乎是敏捷产品开发彩虹和雏菊的集合。然而，情况并非总是如此。多年来，Spotify Squads 框架受到了相当多的批评，其中很多来自前雇员。它被批评为：
- 从未真正存在过
- 解决错误的问题
- 过于自主
- 假设人的情商能力
- 取代产出问责制
今天，Spotify 不再使用——或渴望使用——这个看似辉煌的框架。这就引出了一个问题：为什么？
- 缺乏工程经理阻碍了与 PM 的沟通
从 Spotify Squads 框架中学到的一个重要知识是需要某种层次的层次结构——管理者的存在是有原因的。该框架让产品所有者在没有工程经理的情况下管理设计和工程团队——或者至少是供不应求时。
“当工程团队内部出现分歧时，产品经理需要与团队中的所有工程师协商。如果工程师无法达成共识，则产品经理需要升级为与团队内有工程专业的人数一样多的工程经理。”
这些角色对工作成果几乎没有责任；相反，他们对某人的职业发展和专业技能发展负责。
这让产品经理与成群结队的工程师进行沟通，而不是与工程师的一位领导进行沟通，从而导致时间浪费、来回频繁，或许还有一点自主权。
- 跨团队协作和自主性难以平衡
Spotify 追求高度自治和高度一致性。
例如，业务领导提出问题，解释问题的原因，并要求小队寻找、构建和发布解决方案。然而，其中许多问题需要跨小队协作。
这并不总是一种选择，因为拥有急需的流程或工具的其他小队无法及时获得响应。
这导致小队为自己找出解决方案的工具，尽管同行评审代码流程到位，但仍有大量时间浪费和未共享的知识 - 没有他们希望的那么敏捷。
- 协作需要技巧和实践
当然，Spotify 聘请了聪明人；产品负责人、工程师、数据负责人。他们的目标是成为一家具有成长心态、敏捷原则和匹配人员的敏捷公司。
然而，聪明的人不一定是熟练的人。Spotify 工程团队框架需要某些人才并不总是具备的技能，协作就是其中之一。
“人们缺乏有效讨论流程问题的通用语言、解决问题的教育以及评估绩效的经验。它不是真的敏捷。只是不是瀑布而已。”
- 听起来很酷的名字会造成额外的障碍
最后，尽管我们这么说很痛苦，但听起来很酷的名字并不总能带来很酷的解决方案。
如果您的命名结构不是以员工为中心编写的，那么人们可能很难理解什么是什么。你正在教授一种新语言，以及一个新框架；有很多问题要问。
小队、公会、分会、部落，听起来更像是《权力的游戏》的情节，而不是建立的产品文化，工作场所经济因此而受到影响。