Из Spotify начали увольняться технические специалисты, и компания поменяла весь подход к разработке: вот что произошло
Когда-то команда приложения Spotify состояла из двух человек, которые «сидели дома и кодили». Когда она начала расти, фаундеры пригласили Agile-эксперта на консультацию. Он посмотрел на все это безобразие и порекомендовал использовать нашумевшую Spotify Model — как Agile, только улучшенный.
В 2021 году Spotify Model, хотя о ней по-прежнему много пишут, канула в лету, а ей на смену пришел Spotify Rhythm. В подкасте студии «Либо Либо» Engineering Manager (что это за должность — объясняется далее в тексте) Spotify Юлия Куропатенкова рассказала, почему так вышло и как работает компания сейчас.
Highload публикует основные тезисы рассказа.
Общая структура работы Spotify
Основная фишка системы — множество автономных команд или squads (англ. «отряд»). Можно сказать, что каждый такой squad — это мини-стартап. В нем есть до десяти человек (но обычно пять-семь). Это дает сотрудникам больше мотивации и вовлечения, но и больше ответственности.
Так, в Spotify почти каждый разработчик также является Site Reliability Engineer (SRE). То есть каждый программист может поднять ту часть системы, в которой он работает, если она упадет уже на продакшене. Для сравнения, в Google SRE — это только пятая часть инженеров и они считаются «штучным товаром».
В Spotify около тысячи таких команд, которые отвечают только за одну функцию в приложении. Например, мой squad занимается бэкендом авторизации и аутентификации. Еще есть команды, которые отвечают за функцию лайков или интеграцию с Chrome.
Squads объединены в департаменты — или tribes (англ. «племя»). Tribes занимаются какой-нибудь большой частью приложения. Например, squads, которые обособленно работают над интеграцией Spotify с Chrome, Tesla и другими партнерами, объединены в общий tribe интеграций.
Сейчас в Spotify около 50 tribes. Они сгруппированы в около десятка missions (англ. «миссия»). Missions преследуют очень большие глобальные цели, которые определяются исходя из направлений работы, который каждый год устанавливают фаундеры.
То есть формируется такая схема:
Структура команд Spotify
Что пошло не так в Spotify Model
Spotify Model был направлен на то, чтобы дать большой рост и мотивацию для всех разработчиков. С этой целью ни на одном из уровней не было технических лидов. Были просто технические эксперты, которые не принадлежали ни к одной команде, а определяли направление в общем.
В squads же были назначены product owners и agile-коучи. Первые занимались самим продуктом, вторые — следили, как используются agile-практики.
Но в какой-то момент мы поняли, что у нас слишком много коучей, а product owners слишком уходят в техническую экспертизу. Технические эксперты же, наоборот, не занимаются ничем техническим и потому либо увольняются, либо уходят в разработку.
Так и произошел переход от Model к Rhythm. Структура не изменилась, но изменились некоторые роли.
Как работает Spotify Rhythm
Product owners убрали из ряда команд. Agile-коучей на уровне squads также перестали назначать. Вместо технических экспертов придумали инженерных менеджеров (Engineering Managers) — они стали как раз «лидами» в squads.
Хотя, задачи на этой роли шире, чем у техлида. Если возвращаться к аналогии «squad — это мини-стартап», то инженерный менеджер — это CTO. Ты и разрабатываешь продукт, и доставляешь его.
Обычно в работе я балансирую и стараюсь закрывать ту потребность, которая «горит». Например, на пару месяцев делаю упор именно на технической части и плотно работаю с девелоперами.
Сейчас в моей команде есть:
- шесть бэкенд-разработчиков;
- один веб-инженер;
- дизайнер;
- product owner;
- и я 🙂 — инженерный менеджер.
Чтобы каждому разработчику было понятно, куда и зачем мы движемся, мы используем метрики — не только на уровне tribe и mission, но и squad.
Метрики могут быть:
- технические — например, время ожидания;
- продуктовые — например, реакция пользователей на новую экспериментальную фичу;
- KPI — например, количество пришедших пользователей.
Data scientists и data engineers (в каждом tribe есть хотя бы один такой специалист) обрабатывают метрики и показывают их на дашбордах. Так мы смотрим, насколько мы достигаем поставленных целей и где нужно «поднажать».
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: