Модель Spotify: что это, сквады, трайбы, чаптеры и гильдии

Автор

Хенрик Книберг и Андерс Иварссон (описание); инженеры Spotify (практика), 2012

Уровень

301 · Продвинутый

Подходит

растущая компания, корпорация

Время на внедрение

две-четыре недели на карту зависимостей и пилот одной кросс-функциональной команды

Что понадобится

список продуктов или сервисов, которые делают ваши команды, и схема того, какая команда от какой зависит · руководитель, который может дать одной команде долгосрочную миссию и право выпускать результат · менеджеры, готовые отдать часть контроля над тем, как выполняется работа

Модель Spotify — описание того, как Spotify организовал команды разработки около 2012 года. Её изложили Хенрик Книберг (Henrik Kniberg) и Андерс Иварссон (Anders Ivarsson), на тот момент сотрудники Spotify, в статье Scaling Agile @ Spotify (октябрь 2012 года). В начале авторы оговаривают: они не изобретали модель, а статья фиксирует способ работы, который продолжал меняться. Позже Йоаким Сундён (Joakim Sundén) говорил, что название «модель Spotify» компания не вводила. Книберг писал в 2015 году, что модель никогда не задумывалась как универсальный фреймворк. Это только пример того, как работала одна компания.

Что такое сквады, трайбы, чаптеры и гильдии

Сквады (squads) — команды, которые выпускают продукт. Трайбы (tribes) объединяют родственные сквады. Чаптеры (chapters) связывают внутри трайба людей с одним навыком. Гильдии (guilds) — открытые сообщества по всей компании. Все четыре термина взяты из статьи 2012 года. Она описывала компанию с более чем 30 командами в трёх городах, в которой за три года техническая часть выросла с 30 до 250 человек.

У сквада есть владелец продукта, который задаёт приоритеты, но формального лидера нет. Метод работы сквад выбирает сам. Размер сквада в статье не указан. Scrum Guide называет типичный размер скрам-команды — 10 человек или меньше. По статье, одни сквады использовали спринты скрама, другие работали по канбану, третьи смешивали подходы. Авторы назвали получившуюся структуру матрицей. Сквады образуют вертикальное измерение («что делать»), чаптеры — горизонтальное («как делать хорошо»). Авторы писали, что матрица смещена в сторону поставки.

Почему её копировали многие компании

Модель копировали по двум причинам. Она давала конкретную картину автономии в масштабе, когда таких картин было мало. И Spotify опубликовал о ней много материалов. В марте и сентябре 2014 года вышли два анимированных ролика о культуре разработки. Книберг описывал их как рассказ о пути, который продолжается. По его словам, рассказ в основном верен для большинства сквадов большую часть времени.

Хорошо документированный случай — ING Нидерланды. В интервью McKinsey от января 2017 года сказано: ING начал переход в июне 2015 года. Итог — примерно 350 сквадов по девять человек в 13 трайбах. Spotify назван одним из источников идей. Руководители ING говорят о росте скорости и вовлечённости. Независимых измерений в этом источнике мы не нашли. ING также адаптировал идею. Книберг писал в 2015 году, что компании, копировавшие модель, адаптировали её под свой контекст.

Что говорили о ней люди, работавшие в Spotify

Несколько сотрудников сказали, что модель описывала цель, а не фактическое положение дел. Йоаким Сундён, agile-коуч Spotify в 2011–2017 годах, выступил на Agile2017 с докладом You can do better than the Spotify model. В интервью InfoQ 2017 года он сказал, что Spotify этот термин не вводил и был далёк от «agile-нирваны». Он назвал пробелы. Инженерные практики вроде разработки через тестирование встречались редко. Часть сквадов не проверяла свои планы. Канбан-команды редко ставили лимиты незавершённой работы.

Андерс Иварссон, соавтор статьи, сказал в подкасте 2016 года, что модель нельзя считать шаблоном (так сказано в описании выпуска). В описании также отмечено: чем крупнее организация, тем труднее согласовывать работу команд. Джейсон Йип (Jason Yip), коуч Spotify, перечислил собственные проблемы. Среди них — крупные инициативы на несколько трайбов, которые выполнялись плохо.

Самый резкий отзыв — эссе Джеремайи Ли 2020 года, написанное после работы в Spotify. Он утверждает три вещи. Модель была целью и не была внедрена полностью. Автономия без общих приоритетов и подотчётности создавала трение. У руководителей чаптеров было мало ответственности за поставку. Это мнение одного человека. Большую часть утверждений он подкрепляет публичными высказываниями сотрудников Spotify. Майкл Манкинс и Эрик Гартон из Bain высказали близкую общую мысль в Harvard Business Review. Автономия может повышать вовлечённость, но без контроля даёт неопределённость и неэффективность.

Что говорят рецензируемые исследования

Имеющиеся исследования написали в основном Дарья Смите (Darja Smite), Нильс Бреде Мое (Nils Brede Moe) и коллеги. Сотрудник Spotify Марцин Флорьян (Marcin Floryan) — соавтор нескольких работ, и это нужно учитывать при чтении. Исследования подтверждают часть модели и показывают, что другая часть изменилась.

По гильдиям есть исследование четырёх гильдий Spotify: 11 интервью и опрос 125 участников. Гильдии давали людям больше точек зрения на проблемы, координацию между подразделениями и чувство принадлежности. Исследование также фиксирует, что число инженеров выросло с нескольких сотен в одной локации до нескольких тысяч в шести. Это создало нагрузку на гильдии. Доля участников на регулярных встречах гильдий в среднем составляла около 20%. Смите и Мое представили предварительные результаты руководителям гильдий Spotify в феврале 2018 года. Эта работа впервые вышла в IEEE Software в 2019 году.

По автономии есть статья 2023 года в Journal of Systems and Software. Авторы изучили шесть сквадов в 2019 году. Они сообщают, что весной 2020 года было около 500 сквадов в шести миссиях и около 50 трайбов. Часть структур отменили (в статье названы чаптеры). Часть потеряла популярность (названы гильдии). Часть появилась заново, например миссии. Сквады сами решают, как делать продукт, но их ограничивают общие технологические решения и зависимости от других сквадов. В 2019 году каждый сквад в среднем взаимодействовал с 26 другими в запросах на слияние кода. Вывод авторов: автономия в масштабе не означает анархию и требует нескольких ограничений, которые её обеспечивают. Доля менеджеров в разработке оставалась низкой по мере роста компании. Это связано с нормой управляемости.

Исследователи вне Spotify нашли похожее противоречие. В исследовании двух телекоммуникационных компаний автономия команд ограничивалась потребностью в согласованности. Согласованность шла и сверху вниз, и через сообщества. К 2018 году другие исследователи уже занимались вопросом, как согласовывать сквады в организациях, скопировавших метод.

Что из неё взять

Рассматривайте модель как кейс одной компании. Модель отвечала на реальный вопрос: как сохранить скорость команд и не отказаться от координации. Источники подтверждают немного. Давайте командам миссии, позволяющие выпускать результат от начала до конца. Измеряйте зависимости и состояние команд, как это делал Spotify в опросах сквадов и в проверке здоровья сквада. Делайте сообщества добровольными, но обеспечивайте их ресурсами. Ожидайте, что структура изменится: статья 2023 года показывает, что так и произошло. Сама статья 2012 года говорила, что модель дала Spotify то, во что можно расти. В резюме сессии 2022 года Книберг цитируется так: модель создали раньше, чем она стала нужна. Другие способы построить команды вокруг работы — структура growth-команды и проектирование операционной модели. План Growth Lab начинается с работы и её зависимостей, до любых названий команд. Подробности — в разделе Growth Lab.

Как применять: Модель Spotify: что это, сквады, трайбы, чаптеры и гильдии по шагам

1. Сначала составьте карту зависимостей. Выпишите все команды и отметьте, какие другие команды блокируют их или замедляют. Spotify регулярно задавал этот вопрос своим сквадам. Результат: карта зависимостей, на которой видно, где автономия уже невозможна.
2. Дайте каждой команде долгосрочную миссию. Сформулируйте для каждой команды одну миссию, например платежи или мобильное приложение. Миссия рассчитана на годы, а не на один проект. Результат: каждая команда знает, чем владеет и чем не владеет.
3. Разделите приоритеты и ремесло. Определите, кто задаёт приоритеты команды (в Spotify — владелец продукта в скваде), а кто отвечает за навыки и карьеру (в Spotify — руководитель чаптера). Результат: две названные роли с разными вопросами. Люди знают, к кому идти с вопросом «что делать» и к кому — с вопросом «как делать хорошо».
4. Ограничьте размер группы. Держите команды с общей миссией в группе, где люди знают друг друга. Книберг и Иварссон закладывали для трайбов размер менее 100 человек. Результат: граница группы, основанная на том, сколько отношений человек способен поддерживать.
5. Добавьте сообщества с защищённым временем. Создайте добровольные группы для людей с похожей работой и выделите им часы в неделе. Исследование гильдий Spotify назвало нехватку выделенного времени одним из главных препятствий. Результат: сообщества, которые встречаются, а не только нарисованы на схеме.
6. Проверяйте и убирайте то, что не работает. Раз в квартал проводите короткий опрос команд о зависимостях и трудностях с релизами, как делал Spotify. Убирайте структуры, которые результаты не подтверждают. Результат: короткий список изменений, которые нужно оставить или отменить.

Примеры

ING Нидерланды, 2015–2017 годы

ING начал переход в июне 2015 года. В интервью McKinsey, опубликованном в январе 2017 года, говорится о примерно 350 сквадах по девять человек в 13 трайбах. Руководитель ING назвал Spotify одним из источников вдохновения. Руководители сообщают о более быстром выходе на рынок и росте вовлечённости и удовлетворённости клиентов. Это их собственные утверждения в интервью. Независимых замеров в источнике нет.

Платёжная компания с 60 инженерами

Иллюстративный пример, реальная компания не подразумевается. Шестьдесят инженеров в командах по шесть человек образуют десять команд. Это меньше 100 человек, поэтому хватит одного трайба, без промежуточных уровней между командами и руководителем разработки. Каждая команда получает миссию: выплаты, выпуск карт или проверка мошенничества. Цифры здесь — арифметика, а не измеренный результат.

Цифровая команда сети клиник

Иллюстративный пример, реальная клиника не подразумевается. Команда из 25 человек делает приложение для записи, кабинет пациента и интеграцию с биллингом. Три кросс-функциональные команды владеют по одному из этих продуктов, у каждой свой тестировщик. Общая группа по тестированию собирается раз в месяц, чтобы тестировщики не решали одну задачу трижды. Первая проверка показывает, что команды кабинета и биллинга блокируют друг друга. Их объединяют.

Когда применять

Используйте модель как источник идей, если несколько команд выпускают один продукт, передачи между функциями замедляют работу и команды теряют время в ожидании друг друга. Она подходит растущим организациям разработки и продукта примерно от 30 до нескольких сотен человек, где руководители могут дать командам реальные права на решения.

Когда не применять

Не копируйте структуру и терминологию целиком. Авторы называли описание снимком одной компании, а исследование Spotify 2023 года сообщает, что чаптеры отменили, а гильдии потеряли популярность. Откажитесь от модели, если у команд мало общих зависимостей, если руководители не готовы делегировать решения или если мало людей знакомы с гибкими практиками.

Частые ошибки

• Копировать названия и оргсхему без карты зависимостей, владения продуктом и квартальных проверок, на которых они держались.
• Давать командам автономию без общих приоритетов и показателей результата. Бывший сотрудник Spotify Джеремайя Ли (Jeremiah Lee) утверждал, что из-за этого между командами возникало трение.
• Считать руководителей чаптеров начальниками людей, не влияющих на поставку. Тогда за результат на уровне нескольких команд никто не отвечает.
• Предполагать, что каждый сквад следует хорошим гибким практикам. Йоаким Сундён (Joakim Sundén), бывший agile-коуч Spotify, говорил, что многие сквады общепринятых практик не соблюдали.
• Запускать гильдии и чаптеры без времени и спонсора. Они держатся на добровольцах, и посещаемость падает.

Вопросы и ответы

Что такое модель Spotify?

Так Spotify описал свою организацию разработки в 2012 году. Небольшие кросс-функциональные сквады объединены в трайбы. Их связывают чаптеры (люди с похожими навыками) и открытые гильдии. Хенрик Книберг и Андерс Иварссон изложили это в октябре 2012 года и назвали описание снимком компании, которая продолжала меняться.

Использует ли Spotify модель Spotify сейчас?

Отчасти. В статье 2023 года исследователей, среди которых есть соавтор из Spotify, сказано: весной 2020 года в компании было около 500 сквадов и около 50 трайбов. Там же указано, что от чаптеров отказались, гильдии потеряли популярность, а добавился новый уровень — миссии.

Сквад — то же, что скрам-команда?

Близко, но не одно и то же. В статье 2012 года сквад назван похожим на скрам-команду. Сквады сами выбирали способ работы: спринты скрама, канбан или смесь. Сам скрам предписывает роли и события, которые сквад мог принять или отклонить.

Кто придумал модель Spotify?

Конкретного автора нет. Книберг писал в 2015 году, что не изобретал модель, а только рассказал о ней, и что она выросла из экспериментов многих сотрудников Spotify. Статья 2012 года начинается с заявления, что её авторы модель не изобретали. Йоаким Сундён, agile-коуч Spotify, говорил, что Spotify сам этот термин не вводил.

Какого размера трайб?

В статье 2012 года трайбы проектировались менее чем на 100 человек со ссылкой на число Данбара. Это была цель проектирования на тот момент. Весной 2020 года, по данным исследования 2023 года, в компании было около 500 сквадов в примерно 50 трайбах. В среднем на трайб приходилось около десяти сквадов.

Источники

1. Henrik Kniberg and Anders Ivarsson, Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds, October 2012
2. Spotify Engineering, Spotify engineering culture, part 1, 2014
3. Spotify Engineering, Spotify engineering culture, part 2, 2014
4. Henrik Kniberg, Spotify engineering culture (part 1), Crisp blog, 2014
5. Henrik Kniberg, Squad health check model, Spotify Engineering, 2014
6. Henrik Kniberg, No, I didn't invent the Spotify model, Crisp blog, 2015
7. Leading Complexity, Summary of Henrik Kniberg's session on the Spotify model, Crisp blog, 2023
8. The Agile Revolution, Episode 112: Inside Spotify with Anders Ivarsson, 2016
9. InfoQ, Spotify: The Agile Nirvana? Interview with Joakim Sundén, 2017
10. Agile2017, You can do better than the Spotify Model, Joakim Sundén and Catherine Peck-Phillips, 2017
11. Jason Yip, How things still don't quite work at Spotify, and how we're trying to solve it, slides
12. Jeremiah Lee, Spotify's Failed #SquadGoals, 2020
13. Mankins and Garton, How Spotify balances employee autonomy and accountability, Harvard Business Review, 2017
14. Smite, Moe, Levinta and Floryan, Spotify guilds: how to succeed with knowledge sharing in large-scale agile organizations, IEEE Software, 2019
15. Smite, Moe, Floryan, Levinta and Chatzipetrou, Spotify guilds, Communications of the ACM, 2020
16. SINTEF, Smite and Moe, Results from guild study in Spotify, preliminary results, lecture, 2018
17. Smite, Moe, Floryan, Gonzalez-Huerta, Dorner and Sablis, Decentralized decision-making and scaled autonomy at Spotify, Journal of Systems and Software, 2023
18. Moe, Smite, Paasivaara and Lassenius, Finding the sweet spot for organizational control and team autonomy in large-scale agile software development, Empirical Software Engineering, 2021
19. Salameh and Bass, Influential factors of aligning Spotify squads in mission-critical and offshore projects, PROFES 2018
20. McKinsey, ING's agile transformation, interview with Peter Jacobs and Bart Schlatmann, 2017
21. Ken Schwaber and Jeff Sutherland, The Scrum Guide, 2020

Обновлено 30 октября 2026

Илья ПушинОснователь PUSHERS & COO Fintech ServiceИлья строит операционные системы для растущих компаний в медицине и финтехе. С 2021 года руководит трансграничными платежами в ARBI Exchange, лицензированном обменнике в Таиланде, включая KYC, AML и выход в новые юрисдикции.Об автореLinkedIn