Почему известная методология Spotify Model не работает

Статья Джереми Ли о том, как он тот ушел с позиции менеджера продукта в Spotify, и почему Spotify Model не работает.

Своему успеху Spotify обязан системе управления, так называемой Spotify Model, которая подразумевает автономию команд при сохранении коммуникации, подотчетности и качества. Это гибкая система, которая позволяет структурировать организацию производства, оставаясь при этом в рамках гибкой системы Agile.

У Spotify есть своя матричная структура (Pod structure по Agile), которая отличается от привычной свой линейной структурой. В матрице Spotify люди делятся на отряды (squads), в которых взаимодействуют сотрудники с разными навыками (full-stack) для поставки фичи.

Вертикальное измерение – для поставки продукта, а есть горизонтальное – для обмена знаниями, инструментами и кодом. Вертикальное измерение – это «что создать», горизонтальное – «как сделать это хорошо».

Итак, работники делятся на отряды; каждый отряд – это мини-стартап, который выносит определенную фичу. В отряде есть менеджер по продукту, выступающий в роли младшего CEO функционала. Группа команд – это клан. В командах работают дизайнеры и инженеры разных специальностей. Идея состоит в том, что команда должна обладать всеми необходимыми навыками без необходимости обращаться к другой команде за помощью. У менеджеров по продукту традиционная структура. Менеджер по продукту подчиняется директору по продукту своего отдела («лидеру клана»). Однако разработчики не входят в командную структуру.

Вот тут подробнее.

Во-первых, ответственность технических менеджеров по продукту была маленькой (горизонтальное измерение). Даже их задача – помогать в развитии навыков работы с людьми – была ограничена, потому что невозможно независимо оценивать конфликт внутри команды будучи сильно вовлеченным в ее повседневную жизнь.

Во-вторых, менеджеру по продукту не хватало равноправного партнера, технического менеджера с аналогичным уровнем ответственности, который бы отвечал за сроками работ или мог бы согласовать приоритеты.

В-третьих, когда возникали разногласия внутри команды разработки, менеджеру по продукту самому приходилось вести переговоры со всеми разработчиками вместе. Если не получалось договориться, приходилось обращаться к техническим менеджерам (вне структуры), чье количество должно было совпадать с количеством разработчиков в команде. Если и они не смогли прийти к консенсусу, то проблема переходила на рассмотрение к техническому директору.

У продакта должен быть равный ему технический специалист. Ответственность продактов – приоритезация. Технические менеджеры должны нести ответственность за работу разработчиков, будучи в контакте с менеджером по продукту.

Если компания небольшая (каковой Spotify был в первые годы), команды выполняет широкий круг задач, а внутри них часто меняются инициативы. По мере масштабирования компании, чтобы сократить дублирование функций в команде, создаются новые команды, призванные повысить эффективность работы. Чем больше команд, тем меньше потребность в смене инициатив. Это позволяет сфокусироваться на реальных проблемах. Но каждая ответственность, которую передает одна команда другой, – это основа для зарождения кросс-командной работы

У Spotify нигде не прописан процесс кросс-командной работы, поэтому пострадала общая производительность.

Автономия не означает, что командам нужно решать все проблемы самостоятельно.

Многие работники Spotify попросту не имели представления о базовых методах Agile. Людям не хватало общего языка для обсуждения проблем, компетенций – для их решения и опыта – для их оценки.

И даже попытки предоставить Agile-коучей заканчивались не совсем удачно: их всегда не хватало; их работа была не достаточно продолжительна, чтобы помочь команде оценить производительность; более того, они ни за что не отвечали.

Сотрудничество – это навык, требующий определенных знаний и практики. Не нужно полагать, что у всех по дефолту есть представление об Agile-методах.

Agile Scrum наделил некоторые слова – «сжигание» или «спринт» – новыми значениями, потому что предоставил новые концепции, которым нужно было дать имена.

Spotify же предоставил целый словарь слов для описания своего образа работы. И это создавало иллюзию чего-то, что требовало изучения.

Если удалить эти синонимы, модель Spotify будет описывать лишь совокупность кросс-функциональных команд, обладающих слишком большой автономией и плохой структурой управления.