Spotify — это сервис стриминга музыки онлайн. Они известны тем, что «перенесли радио в интернет» и тем, что их модель разработки ПО стала примером для подражания многих компаний. Из стартапа в 30 человек Spotify превратилась в организацию, в которой работают 1600 сотрудников из 30 стран. Компании стало сложно применять классический Scrum, не отклоняясь от Scrum Guide.
Тогда Spotify создали собственный фреймворк: они оставили принципы и ценности Agile в основе, но изменили некоторые артефакты, роли и ритуалы. В процессе получилась экосистема, удобная для работы большой компании, филиалы которой находятся в разных городах.
Рассказываем, какую модель создали Spotify, какие ценные техники у них можно перенять и почему компанию называют «лицом с плаката» мира Agile.
Правила хороши для начала, затем их можно сломать
Команда Spotify решила для себя, что принципы Agile в основе работы дают больше, чем конкретная практика. Тогда началась адаптация Scrum и перестройка компании по собственной модели.
Spotify переименовали scrum-мастера в agile-тренера. Вместе с названием изменилась роль: тренер стал отвечать за гибкость в целом, а не за исполнение scrum-процесса.
Компания также заменила scrum-команду, основную единицу Scrum, на отряд. Это была попытка уйти от стереотипа, который вызывает название «команда разработки». В команде разработки присутствовали не только программисты, её ролевой состав был гораздо шире.
Что такое Отряд?
Отряд, в оригинале Squard, — это небольшая кросс-функциональная, самоорганизованная команда. Обычно, в ней не больше восьми участников. У каждого в отряде есть свои обязанности. Команда работает в соответствии с собственной миссией, которая детализирует миссию компании.
Отряд Spotify автономен. Это достигается тем, что он полностью получает свободу в выборе: сотрудники решают, что разрабатывать и как для этого организовать собственную работу. Какому-то отряду удобнее работать по Scrum, кому-то — по Kanban, кто-то обходится самописными правилами.
Главное, чтобы в работе команда следовала своей миссии, стратегии продукта и краткосрочным целям. Это позволяет добиться автономности, а не локальной переоптимизации.
Spotify считает доверие более важным, чем контроль. Отряд работает быстрее, если рабочие решения принимаются внутри, а не ждут согласования от менеджеров из других отделов.
Как построен Spotify
В Spotify мало стандартов. Любой стандартизации они предпочитают совместное владение системой и обмен опытом. Например, когда большинство отрядов начинают использовать одинаковый инструмент, он может стать стандартом по умолчанию. Это происходит, потому что многие уже знают, как с ним работать и делятся знаниями с другими.
Для взаимодействия внутри компании Spotify сотрудники предложили свою матрицу. Они впервые представили термины Tribe (Клан, или Племя), Chapter (Отделение, ~общественное собрание), Guild (Гильдия).
Три этих термина описывают внутреннюю структуру компании: это и есть масштабирование по модели Spotify.
Вся компания разделена на отряды. Они полностью владеют определенной частью функционала: разрабатывают её стратегию, лучше всех знают свою часть кода. Например, отряд отвечает за раздел «Поиск» или «Рекомендованные артисты».
У отряда есть владелец продукта. Он так же, как в Scrum, отвечает за бэклог и оценивает пользовательские истории. Отряд работает вместе, в одном кабинете, к которому прикреплена своя зона отдыха. Squad похож на мини-стартап: у него есть всё, чтобы правильно развивать свою часть функционала.
Отряд в масштабе компании — очень маленькое деление, поэтому близкие по направлению отряды объединяются в кланы до 100 человек. Например, клан мобильной разработки или плеера.
Отряды одного клана находятся территориально близко друг к другу. Spotify предоставляет им общие залы для совещания, поощряет взаимодействия и любые неофициальные собрания. Есть роль лидера клана. Этот сотрудник — рядовой разработчик в отряде, но он также выделяет время, чтобы создавать продуктивную среду для своего клана.
Отряды и кланы — вертикальная структура Spotify. Но компания также объединяется по горизонтали через отделы и гильдии.
Отдел объединяет специальности внутри клана. Это могут быть fronend- и backend-разработчики, agile-тренеры, тестировщики, дизайнеры и др. Внутри отдела носители стека технологий обмениваются профессиональными знаниями и идеями. Коллеги могут помочь с задачей, например, научить использовать новый инструмент или сделать ревью. Так инновации и общий стек распространяются между отрядами.
В отделе также есть лидер. В организации без иерархии и бюрократии позиция лидера отдела в корне отличается от привычного менеджера и тимлида. У него нет формальной власти. Он рядовой член отряда, просто некоторый процент времени решает задачи отдела: может проводить обучение, сессии ответов на вопросы или личный тренинг. Он также отвечает за профессиональное развитие своего отдела, поэтому может нести ответственность за повышение уровня дохода своих коллег.
Наконец, есть концепция Гильдий. Это неформальное сообщество по интересам, которое может выходить за рамки профессионального объединения. Например, сотрудники могут собраться в гильдию любителей фотографии. У гильдий также есть координатор, который организует встречи.
Общая структура Spotify выглядит так:
Поставка ценности
Главная цель подобной организации — создать инфраструктуру для непрерывных выпусков обновлений.
В Spotify упростили процесс выпуска релизов. Для этого изменили архитектуру, так что каждый отряд может независимо обновлять свой сервис. Чтобы синхронизировать обновления разных команд, ввели роль System Owner— владелец системы. Это тоже должность по совместительству. Он поддерживает систему рабочей и координирует отряды в процессе обновлений.
Интересно обратить внимание на то, как Spotify выпускает обновления. У отрядов есть график релизов. В обновление попадают как законченные функции, так и незавершенные. На момент релиза незаконченные функции скрыты и доделываются следующем спринте. Когда работа над функцией завершается, ее открывают для пользователей. Такой ранний выпуск решает проблемы интеграции и меньше разветвляет код.
Чтобы люди внутри компании могли генерировать новые идеи и поставлять эту самую ценность, Spotify создает дополнительные условия.
У каждой команды есть hack-day, когда раз за спринт целый день можно заниматься собственными идеями, самообразовываться или общаться с коллегами. Некоторые отряды собирают все hack-days в одну неделю и реализую свои идеи.
Также Spotify продвигает культуру эксперимента. В компании нет ответственного за решения. Вместо этого реализовывают обе идеи, А и Б, а затем выбирают ту, что работает лучше.
Как применить модель
Модель, предложенная Spotify, полностью отвечает духу Agile. Компания стала «лицом с плаката», красноречивым примером из мира гибкой разработки. Но есть расхожая фраза: «Модель Spotify работает только в Spotify», потому что модель очень сложно внедрить. Причину ищут в культурных различиях, шведском фундаменте и прочем. Отчасти это так. Успешно следовать примеру Spotify могут те организации, где уже есть сформированные scrum-команды, а манифест Agile записан на подкорке.
Возможно, полностью всё перенести не удастся и не всем это нужно. Можно перенять отдельные практики:
- Переименовать команды. Кроме отряда, другие компании называли продуктовые команды юнитами, фракциями, группами и другими, трудно переводимыми на русский синонимами слова «команда». Это помогает отдалиться от старого подхода к работе.
- Создать профессиональные объединения и «клубы по интересам».
- Разделить проекты на систему кланов. Например, сайт/приложение/настольная версия или клиентская/бизнес-/внутренняя части.
- Проводить хак-дни или контесты для гильдий. Они помогут расслабить команду, но при этом рабочее время будет расходоваться также эффективно.
Существует много способов реорганизации. Правда, формальная перетасовка обычно не решает проблемы. Практики эффективны, когда сама идеология внедрена, но могут быть провальными и обременительными, если принципы Agile не прижились в вашей компании.
Главный коуч Spotify, Joakim Sundén, говорит, что Spotify далеки от «аджайл-нирваны». Не все команды равномерно используют практики из гибких подходов. Такие вещи, как TDD или парное программирование, еще недостаточно распространены.
Сами Spotify считают свою модель временной и рассчитывают, что будут меняться дальше.
