К основному контенту

Как Spotify создает продукты

Автор: Хенрик Книберг (Henrik Kniberg)
Перевод с английского проектом Agile Translations.


Разработать продукт непросто. Большинство попыток разработки терпят неудачу, и самой распространенной причиной этого считается создание неправильного продукта.

Spotify - шведский низкобюджетный стартап с замечательными показателями выпуска продуктов. Их продукты любимы пользователями и артистами, они распространяются со скоростью вирусов - у них более 20 миллионов активных пользователей, 5 миллионов платных подписчиков, и быстрый рост продолжается. К примеру, чтобы в США начать с нуля и дорасти до 1 миллиона платных подписчиков, им потребовался приблизительно год, а ведь это иностранный рынок, где присутствует множество крепких игроков.

Главная идея Spotify – предоставить вам музыку для каждого момента. Это неограниченный доступ к любой музыке мира и возможность быстро ею поделиться. Чем больше музыки «расшарено» и проиграно, тем больше денег поступает артистам. Начавшись c музыкального проигрывателя несколько лет назад, их продукты сегодня превратились в повсеместно присутствующую и всем знакомую платформу для открытия новой музыки и установления непосредственной связи между артистами и поклонниками.

Их продукты просты, персональны и забавны. Даже музыканты «Металлики», долгое время выступавшие непримиримыми оппонентами любых сервисов для трансляции музыки, теперь считают Spotify "наилучшим транслирующим сервисом" и "поражены его простотой и удобством".


Однако здесь есть парадокс: успешные компании, такие как Spotify, просто хотят выпускать продукты, которые будут нравиться людям. Но им неизвестно, что именно нравится людям, пока этот продукт ими не выпущен.
Как же они узнают об этом?
Цель этой статьи - создать общее представление о том, как Spotify подходит к разработке продукта.

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

Благодарности. 
Эта модель изобретена не мной. Материал этой статьи базируется на дискуссиях с Gustav Söderström, Oskar Stål, Olof Carlson, их внутренних документах и моделях, таких как “Think It, Build It, Ship It, Tweak It”. Также я многое узнал их разговоров с дизайнерами, разработчиками и тренерами гибкой разработки. Спасибо всем вам!

Обзор 

Сущность нашей философии такова:

  • Мы создаем инновационные продукты и управляем риском, первым делом дешево создавая прототип.
  • Мы запускаем продукт не к определенной дате, а лишь достигнув нужного качества.
  • Мы непрерывно ведем тонкую настройку продукта после запуска - так мы убеждаемся в том, что наши продукты движутся от удобства при запуске к восхищению. 
Все основные направления деятельности по созданию продукта проходят 4 стадии:

  1. Think It (обдумай)
  2. Build It (построй)
  3. Ship It (доставь)
  4. Tweak It (подстрой)
Перед вами схема, на которой вы можете проследить весь поток от идеи до продукта и все события на каждой стадии этого движения:

Четыре фаза разработки продукта Spotify
Более подробную версию этой схемы вы увидите в конце статьи.

Think It = выясни, какой тип продукта мы разрабатываем и для чего.

Build It = создай минимально работоспособный продукт, готовый для реальных пользователей.

Ship It = постепенно предоставь 100% пользователей доступ к нему, измеряя параметры и улучшая продукт.

Tweak it = Постоянно совершенствуй продукт. Это действительно окончательное состояние; продукт находится здесь, пока не будет закрыт или пересмотрен (= вернуться к Think It).

В Spotify более 30 команд (это маленькие, кроссфункциональные самоорганизующиеся команды,  больше описано в статье: "Scaling Agile @ Spotifywith Tribes, Squads, Chapters, and Guilds) и множество разных продуктов, поэтому для того, чтобы следить за происходящим в остальной компании и представлять это зрительно, мы используем таблицу состояния продукта, показывающую на какой из стадий находится данный продукт. Приблизительно она выглядит так:

Таблица состояния продуктов Spotify

Кроме того, мы испытываем прогностические инструменты, а команды отвечают за регулярное обновление таблицы сроков (дата А-дата Б), показывающие, когда они предполагают достичь следующей стадии.

Зачем 4 стадии? 

Самый большой риск – построить неправильный продукт: ведь он не приносит радости нашим пользователям, не улучшает показатели успеха, такие как привлечение пользователя, удержание пользователя, т.д. Мы называем это "риск продукта".

Эта модель из четырех стадий помогает нам снизить риск и быстро выпустить продукт. График, приведенный ниже, показывает, как снижается риск на каждой стадии, насколько затратной является каждая из стадий:

График снижения рисков продукта

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

Продолжительность каждой фазы сильно варьирует, приведенные выше соотношения - просто пример. Общее время тоже варьирует: некоторые продукты выходят из разработки за несколько месяцев, другие - за полгода или больше того. Тем не менее, внутри каждой фазы достаточно постоянно происходят релизы (пусть даже и внутренние).

Итак, давайте теперь присмотримся к каждой из стадий.

Think It 

Идеи продукта могут возникать все время и происходить от любого из сотрудников компании. Большинство идей - это усовершенствования существующих продуктов ("настройки"), а команды будут применять их, и выпускать свои собственные.

Стадия «Обдумай» означает появление у кого-либо совершенно новой идеи продукта или желания переделать уже существующий продукт.

Фаза "Think It"

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

Определение продукта - это короткий документ, отвечающий на следующие вопросы:

  • Зачем нам это разрабатывать? 
  • Кому и какая от этого польза?
  • Какие ключевые показатели призван улучшить данный продукт?
  • Это может быть определено как количество транслируемой музыки, количество загрузок, число подписчиков.
  • Каковы гипотезы?
  • Как мы узнаем, что продукт удался?
  • Будет ли это "качественным скачком" (таковым считается продукт, позволяющий, по крайней мере, двукратно улучшить избранный для оценки критерий)? Если ожидается лишь незначительное улучшение показателей, возможны другие причины для его разработки, например, соображения стратегии. 
Определение продукта - это не документ с перечнем требований или план проекта. В нем нет списка приложений, бюджетов, планирования ресурсов и тому подобного. Это скорее описание цели проекта на основании данных.

Наиболее важная часть определения продукта - это его история или нарратив. Что он расскажет миру? Как будет выглядеть его пресс-релиз?

Вот, например, недавний продукт Spotify - таблица «Discover». Приведем выдержку из двухминутного видео, представляющего данный нарратив:
Мы предлагаем вам новый способ совершить музыкальное открытие.   
Смотрите! Любимый артист делится с вами песней. Мы как никогда сближаем артистов с фанатами. Нравится артист? Просто фолловьте их и делитесь своими открытиями с друзьями. 
Другой пример - это Mobile Free Radio, с нарративом "Radio you can save". В данном случае мы использовали Google Adwords, чтобы испробовать разные нарративы вживую и выяснить, какой из них был наиболее убедителен.

Самое важное здесь, чтобы нарратив был написан еще до того, как построен продукт! Таким образом, мы обеспечиваем убедительный вид продукта, даже еще не разработав его.

Кроме того, команда «Обдумай это» разрабатывает множество разных прототипов, чтобы поэкспериментировать с оформлением приложения - как с низкокачественными бумажными прототипами, так и с высококачественными работоспособными прототипами (однако с ложными источниками данных и так далее). Внутренние фокус-группы задействуются, чтобы установить, какие прототипы наилучшим образом передают нарратив, до тех пор, пока число их не сузится до нескольких выигрышных кандидатов.

Выбор и отбраковка продуктов

Этот процесс носит циклический характер, жестких сроков здесь нет.

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

Как показывает кривая риск/издержки, приведенная выше, стадия «Обдумай» позволяет нам снизить риск продукта весьма рентабельным путем - мы просто разрабатываем прототип и экспериментируем. Это позволяет нам дешево и безопасно ошибаться, так что мы можем вести испытания, пока не выясним, каков тот самый правильный продукт, который мы собираемся разрабатывать.

Критерий завершения: 

Стадия «Обдумай» заканчивается, когда команда и менеджмент приходят к общему пониманию того, что данный продукт стоит разработки (или же данный продукт никогда не станет достоин разработки и должен быть отбракован). Это субъективное решение, которое не поддерживается никакими вещественными данными. Эти вещественные данные задействуются на стадии  «Доставь», поэтому мы хотим добраться до нее как можно скорее.

Build It 

Команда «Обдумай» сейчас расширяется до более постоянной команды (иногда множества команд) со всеми необходимыми навыками для разработки, тестирования и доставки реального продукта. Эта команда будет причастна к данному продукту на протяжении длительного срока, а не просто в фазе «Построй».

Цель стадии «Построй» - разработать MVP (минимально работоспособный продукт), который достаточно хорош, чтобы выпустить его для внешних пользователей, и также достаточно хорош, чтобы улучшить кое-что в самом продукте. MVP разрабатывается повторно при помощи методов гибкой разработки, таких как Скрам, Канбан, экстремальное программирование.

Фаза "Build It"

Здесь важно найти баланс, и это иллюстрируется шкалой "от бесполезного к совершенному".


С одной стороны, мы не хотим разрабатывать продукт целиком до тех пор, пока не доставим его, поскольку это могло бы задержать наше изучение. Мы не можем быть уверены, что стоим на правильном пути, пока не предоставили реальное программное обеспечение реальным пользователям, так что мы хотим добраться туда как можно быстрее.

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

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

Велосипед - любимый и полезный продукт для того, у кого нет лучших средств транспорта, но он остается весьма далек от мотоцикла, в который он превратится. Нам нужно следовать базовому нарративу, иначе наши измерения могут сбить нас с толку. "Вот мы выпустили колесо, и никто им не пользуется, поэтому этот продукт неудачен. Значит и велосипед достраивать нет нужды".

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

Критерий Завершения: 

Стадия «Построй» заканчивается, когда менеджмент и команда приходят к общему пониманию, что этот продукт выполняет базовый нарратив и достаточно хорош, чтобы начать его выпуск для реальных пользователей.

Мы готовы к Моменту Истины!

Ship Ip

Цель данной стадии заключается в том, чтобы постепенно выдать продукт для 100% пользователей, при этом измеряя степень исполнения продуктом своего обещания в "диком пользовании" и обеспечивать это исполнение.
Фаза "Ship It"

Команда начинает с релиза для небольшого процента пользователей (обычно от 1-5%) для сбора данных. Как поведут себя эти пользователи в сравнении с остальными 95-99%?

Помните, мы на стадии «Think It» определили для продукта несколько гипотез. Сейчас мы сможем наконец-то проверить, насколько они правильны, при необходимости повторно улучшив продукт. Очень редко можно получить правильный продукт с первой попытки, и сила данной модели отчасти и в том, что нам не приходится этого делать.

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

Критерий Завершения: 

Стадия «Ship It» завершается, когда продукт доступен всем пользователям. Помните, что этот продукт еще не "завершенное приложение". Завершения фазы «Ship It» означает, что продукт (MVP + необходимые усовершенствования) был выпущен на 100%. Такой вещи как "законченное приложение" не существует, поскольку продукт постоянно совершенствуется даже после этой стадии.

Tweak It

Это самая важная стадия, поскольку именно сюда попадают все продукты (если не отправляются в мусорную корзину по пути), именно в этом месте продукты проводят наибольшее время.

Фаза "Tweak It"

Сейчас продукт находится в производстве и доступен всем пользователям.

Хотя в определенной степени он уже проверил себя на стадии «Ship It», всегда остается довольно много пространства для улучшений. Отряд продолжает экспериментировать, проводить A/B тестирование и улучшать продукт, в то же время наблюдая за его показателями. Это может включать в себя важные новые приложения или же тонкие настройки.

Однажды в будущем отряд может достичь момента уменьшения обращений к продукту. Продукт великолепен, наиболее важные улучшения внесены, но соотношение цена/польза выглядит менее привлекательно. Если же взглянуть на показатели, окажется, что новые усовершенствования не приводят к большим переменам. Это означает, что продукт достиг "локального максимума".

Подстройка и локальный максимум продукта

В такой момент менеджмент и отряд обсуждают, довольны ли они этой горой, или стоит поискать вершину повыше? Если первое верно, команда может постепенно переключиться на новые продукты. Иначе, команда может вернуться к "Think It", чтобы переделать этот продукт и совершить прыжок к локальному максимуму (или более высокому пику).

Подстройка и переосмысление

Одним из примеров может служить сайт www.spotify.com. Этот сайт настраивался 4 года, пока летом 2012 мы не решили переделать его. Этот сайт передает главную идею Spotify совершенно иначе и куда более эффективным образом.

Обзор всего процесса
Весь процесс разработки продуктов Spotify

Заключение 

Надеюсь, эта статья понравилась вам!

Если некоторые части этой модели вызвали у вас мысль: "Да я уже знал об этом, мы десятилетиями этим занимались", вы наверняка правы.

Эта модель вовсе не что-то новое и удивительное, это работающая штука, а новая она или старая, неважно.

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

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

Хенрик Книберг: henrik.kniberg@spotify.com
http://www.crisp.se/henrik.kniberg

Переведено с английского проектом Agile Translations.
Оригинальная статья: How Spotify Builds Products.

ПОПУЛЯРНОЕ

Шаблоны декомпозиции Пользовательских Историй (User Stories)

Автор: Richard Lawrence Переведено с английского проектом Agile Translations   Хорошие Пользовательские Истории следуют INVEST модели , предложенной Биллом Вейком (Bill Wake). Они независимые ( I ndependent), обсуждаемые ( N egotiable), ценные ( V aluable), поддающиеся оценке ( E stimable), небольшие ( S mall) и тестируемые ( T estable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели. Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая” , однако, не сможет похвастаться тем же в случае с “независимая” и “ценная” . За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Все о Скрам от Майка Кона

На сегодняшний день многие уже знают основы Scrum. Однако я часто сталкиваюсь с разночтениями, и даже спорами по некоторым моментам. Поэтому считаю, что нужно обратиться к истокам. Как, наверняка, многие знают Майк Кон – один из наиболее популярных Scrum-тренеров, он работает с этой методологией более 10 лет, написал 2 концептуальные книги по практикам Agile, а также множество интересных и ценных статей, является одним из основателей Scrum-альянса и Agile-альянса. По праву его можно считать тем специалистом, определениям которого можно доверять. Читать дальше...

Скрамбан - собираем лучшее

Автор: Илья Павличенко . Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности. Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь ): « Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы

Планирование релиза: уходим от термина, но не от практики

Автор: Майк Кон (Mike Cohn) Перевод с английского. Я хочу обратить внимание на термин, используемый в Скраме (точнее, даже Аджайл термин), который во многом пережил себя: планирование релиза. Общепринятое использование "релизного планирование" заключалось в том(я так тоже делал), что мы смотрели в будущее на несколько спринтов вперед и пытались предсказать, что бы мы могли выпустить. Было бы хорошо в идеале эти предположения выражать в виде диапазона значений, возможно даже с использованием интервалов вероятности. В течение многих лет я учил команды делать именно так. Скажем, мы могли сказать, что “Мы уверены на 90%, что через шесть месяцев сможем выпустить продукт с функционалом в диапазоне между 150 и 200 стори поинтов.” Я до сих пор считаю эту практику полезной и каждый Скрам-мастер должен знать как это делается. Что на самом деле потеряло смысл, так это сам термин “планирование релизов”.

Диаграммы Ганта и Agile проекты. Так уж они несовместимы?

Автор: Алексей Кривицкий. "Планы бесполезны, планирование необходимо". Ейзенхауэр Диаграммы Ганта – это традиционный механизм визуального планирования, который получил свою популярность благодаря артефакту традиционных проектов, который назывался Work Breakdown Structure (WBS), и продуктам Microsoft Project и Microsoft Project Server, которые позволяли конструировать и хранить WBS. Пропоненты Agile принципов много внимания уделяют визуализации и открытости планирования. Так почему же так часто в контексте Agile мы слышим критику в адрес диаграмм Ганта? Давайте разберёмся. Пару слов о терминологии. В данной статье " традиционными подходами " к управлению проектами (или просто традиционными проектами) называются те подходы или проекты, которые противопоставляются Agile проектам. Я не использовал термин «водопадных проектов», так как во-первых на практике настоящих водопадных проектов не так много, а во-вторых по мимо водопадных и Agile проектов есть ещё мн