Из 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. Ты и разрабатываешь продукт, и доставляешь его.

Обычно в работе я балансирую и стараюсь закрывать ту потребность, которая «горит». Например, на пару месяцев делаю упор именно на технической части и плотно работаю с девелоперами.

Сейчас в моей команде есть:

• шесть бэкенд-разработчиков;
• один веб-инженер;
• дизайнер;
Курс Java developer від Mate academy.
Вивчайте Java та отримайте можливість працювати майже в будь-якій галузі: її використовують від фінансової сфери до аграрної. Працевлаштування гарантуємо!
Отримати знижку на курс
• product owner;
• и я 🙂 — инженерный менеджер.

Чтобы каждому разработчику было понятно, куда и зачем мы движемся, мы используем метрики — не только на уровне tribe и mission, но и squad.

Метрики могут быть:

1. технические — например, время ожидания;
2. продуктовые — например, реакция пользователей на новую экспериментальную фичу;
3. KPI — например, количество пришедших пользователей.

Data scientists и data engineers (в каждом tribe есть хотя бы один такой специалист) обрабатывают метрики и показывают их на дашбордах. Так мы смотрим, насколько мы достигаем поставленных целей и где нужно «поднажать».