Автор: Хенрик Книберг (Henrik Kniberg)
Перевод с английского проектом Agile Translations.
Разработать продукт непросто. Большинство попыток разработки терпят неудачу, и самой распространенной причиной этого считается создание неправильного продукта.
Spotify - шведский низкобюджетный стартап с замечательными показателями выпуска продуктов. Их продукты любимы пользователями и артистами, они распространяются со скоростью вирусов - у них более 20 миллионов активных пользователей, 5 миллионов платных подписчиков, и быстрый рост продолжается. К примеру, чтобы в США начать с нуля и дорасти до 1 миллиона платных подписчиков, им потребовался приблизительно год, а ведь это иностранный рынок, где присутствует множество крепких игроков.
Главная идея Spotify – предоставить вам музыку для каждого момента. Это неограниченный доступ к любой музыке мира и возможность быстро ею поделиться. Чем больше музыки «расшарено» и проиграно, тем больше денег поступает артистам. Начавшись c музыкального проигрывателя несколько лет назад, их продукты сегодня превратились в повсеместно присутствующую и всем знакомую платформу для открытия новой музыки и установления непосредственной связи между артистами и поклонниками.
Их продукты просты, персональны и забавны. Даже музыканты «Металлики», долгое время выступавшие непримиримыми оппонентами любых сервисов для трансляции музыки, теперь считают Spotify "наилучшим транслирующим сервисом" и "поражены его простотой и удобством".
Однако здесь есть парадокс: успешные компании, такие как Spotify, просто хотят выпускать продукты, которые будут нравиться людям. Но им неизвестно, что именно нравится людям, пока этот продукт ими не выпущен.
Примечание.
Как и все модели, это упрощение действительности. Они далеко не всегда буквально следуют описанному здесь процессу, существует множество локальных вариаций. Эта статья должна создать у вас общее представление.
Благодарности.
Эта модель изобретена не мной. Материал этой статьи базируется на дискуссиях с Gustav Söderström, Oskar Stål, Olof Carlson, их внутренних документах и моделях, таких как “Think It, Build It, Ship It, Tweak It”. Также я многое узнал их разговоров с дизайнерами, разработчиками и тренерами гибкой разработки. Спасибо всем вам!
Обзор
Сущность нашей философии такова:
Более подробную версию этой схемы вы увидите в конце статьи.
Think It = выясни, какой тип продукта мы разрабатываем и для чего.
Build It = создай минимально работоспособный продукт, готовый для реальных пользователей.
Ship It = постепенно предоставь 100% пользователей доступ к нему, измеряя параметры и улучшая продукт.
Tweak it = Постоянно совершенствуй продукт. Это действительно окончательное состояние; продукт находится здесь, пока не будет закрыт или пересмотрен (= вернуться к Think It).
В Spotify более 30 команд (это маленькие, кроссфункциональные самоорганизующиеся команды, больше описано в статье: "Scaling Agile @ Spotifywith Tribes, Squads, Chapters, and Guilds”) и множество разных продуктов, поэтому для того, чтобы следить за происходящим в остальной компании и представлять это зрительно, мы используем таблицу состояния продукта, показывающую на какой из стадий находится данный продукт. Приблизительно она выглядит так:
Кроме того, мы испытываем прогностические инструменты, а команды отвечают за регулярное обновление таблицы сроков (дата А-дата Б), показывающие, когда они предполагают достичь следующей стадии.
Зачем 4 стадии?
Самый большой риск – построить неправильный продукт: ведь он не приносит радости нашим пользователям, не улучшает показатели успеха, такие как привлечение пользователя, удержание пользователя, т.д. Мы называем это "риск продукта".
Эта модель из четырех стадий помогает нам снизить риск и быстро выпустить продукт. График, приведенный ниже, показывает, как снижается риск на каждой стадии, насколько затратной является каждая из стадий:
Как можно заметить, стадия «Обдумай» снижает риск до малых показателей. Постепенно снизившиеся издержки производства на стадии «Настрой» показывают, что со временем продукт не нуждается в таком количестве обновлений и команды могут переключиться на другие проекты.
Продолжительность каждой фазы сильно варьирует, приведенные выше соотношения - просто пример. Общее время тоже варьирует: некоторые продукты выходят из разработки за несколько месяцев, другие - за полгода или больше того. Тем не менее, внутри каждой фазы достаточно постоянно происходят релизы (пусть даже и внутренние).
Итак, давайте теперь присмотримся к каждой из стадий.
Think It
Идеи продукта могут возникать все время и происходить от любого из сотрудников компании. Большинство идей - это усовершенствования существующих продуктов ("настройки"), а команды будут применять их, и выпускать свои собственные.
Стадия «Обдумай» означает появление у кого-либо совершенно новой идеи продукта или желания переделать уже существующий продукт.
Если менеджмент соглашается, что идея стоит исследования, формируется маленькая кроссфункциональная команда "Обдумай". Обычно она состоит из разработчика, дизайнера и владельца продукта. Задача их в том, чтобы составить определение продукта и разработать внушающий доверие прототип.
Определение продукта - это короткий документ, отвечающий на следующие вопросы:
Наиболее важная часть определения продукта - это его история или нарратив. Что он расскажет миру? Как будет выглядеть его пресс-релиз?
Вот, например, недавний продукт Spotify - таблица «Discover». Приведем выдержку из двухминутного видео, представляющего данный нарратив:
Самое важное здесь, чтобы нарратив был написан еще до того, как построен продукт! Таким образом, мы обеспечиваем убедительный вид продукта, даже еще не разработав его.
Кроме того, команда «Обдумай это» разрабатывает множество разных прототипов, чтобы поэкспериментировать с оформлением приложения - как с низкокачественными бумажными прототипами, так и с высококачественными работоспособными прототипами (однако с ложными источниками данных и так далее). Внутренние фокус-группы задействуются, чтобы установить, какие прототипы наилучшим образом передают нарратив, до тех пор, пока число их не сузится до нескольких выигрышных кандидатов.
Этот процесс носит циклический характер, жестких сроков здесь нет.
Продукт просто не стоит разработки до тех пор, пока мы не сможем показать впечатляющий нарратив и работоспособный прототип, который полностью его выполняет, а мы не можем сказать наперед, сколько займет разработка правильного продукта.
Как показывает кривая риск/издержки, приведенная выше, стадия «Обдумай» позволяет нам снизить риск продукта весьма рентабельным путем - мы просто разрабатываем прототип и экспериментируем. Это позволяет нам дешево и безопасно ошибаться, так что мы можем вести испытания, пока не выясним, каков тот самый правильный продукт, который мы собираемся разрабатывать.
Критерий завершения:
Стадия «Обдумай» заканчивается, когда команда и менеджмент приходят к общему пониманию того, что данный продукт стоит разработки (или же данный продукт никогда не станет достоин разработки и должен быть отбракован). Это субъективное решение, которое не поддерживается никакими вещественными данными. Эти вещественные данные задействуются на стадии «Доставь», поэтому мы хотим добраться до нее как можно скорее.
Build It
Команда «Обдумай» сейчас расширяется до более постоянной команды (иногда множества команд) со всеми необходимыми навыками для разработки, тестирования и доставки реального продукта. Эта команда будет причастна к данному продукту на протяжении длительного срока, а не просто в фазе «Построй».
Цель стадии «Построй» - разработать MVP (минимально работоспособный продукт), который достаточно хорош, чтобы выпустить его для внешних пользователей, и также достаточно хорош, чтобы улучшить кое-что в самом продукте. MVP разрабатывается повторно при помощи методов гибкой разработки, таких как Скрам, Канбан, экстремальное программирование.
Здесь важно найти баланс, и это иллюстрируется шкалой "от бесполезного к совершенному".
С одной стороны, мы не хотим разрабатывать продукт целиком до тех пор, пока не доставим его, поскольку это могло бы задержать наше изучение. Мы не можем быть уверены, что стоим на правильном пути, пока не предоставили реальное программное обеспечение реальным пользователям, так что мы хотим добраться туда как можно быстрее.
С другой стороны, мы не хотим выпускать бесполезный и постыдный продукт. Даже если мы скажем людям, что это альфа- или бета-версия, люди ждут от Spotify прекрасных программ и будут оценивать нас по тому, что мы выпускаем.
Итак, команде нужно определить малейший из возможных продукт, который они могут разработать, чтобы соответствовать базовому нарративу и доставлять удовольствие пользователям. Нам нужно, чтобы этот продукт соответствовал нарративу, а не обладал всеми возможностями. Возможно, подходящим термином будет Минимально Любимый Продукт.
Велосипед - любимый и полезный продукт для того, у кого нет лучших средств транспорта, но он остается весьма далек от мотоцикла, в который он превратится. Нам нужно следовать базовому нарративу, иначе наши измерения могут сбить нас с толку. "Вот мы выпустили колесо, и никто им не пользуется, поэтому этот продукт неудачен. Значит и велосипед достраивать нет нужды".
Ключевая разница между «Обдумай» или «Построй», в том, что мы используем все возможные обходные пути и не переживаем по поводу технического качества. В фазе «Построй», мы пишем код на уровне продукции и встраиваем в него качество.
Критерий Завершения:
Стадия «Построй» заканчивается, когда менеджмент и команда приходят к общему пониманию, что этот продукт выполняет базовый нарратив и достаточно хорош, чтобы начать его выпуск для реальных пользователей.
Мы готовы к Моменту Истины!
Ship Ip
Цель данной стадии заключается в том, чтобы постепенно выдать продукт для 100% пользователей, при этом измеряя степень исполнения продуктом своего обещания в "диком пользовании" и обеспечивать это исполнение.
Команда начинает с релиза для небольшого процента пользователей (обычно от 1-5%) для сбора данных. Как поведут себя эти пользователи в сравнении с остальными 95-99%?
Помните, мы на стадии «Think It» определили для продукта несколько гипотез. Сейчас мы сможем наконец-то проверить, насколько они правильны, при необходимости повторно улучшив продукт. Очень редко можно получить правильный продукт с первой попытки, и сила данной модели отчасти и в том, что нам не приходится этого делать.
Когда отряд и менеджмент приходит к общему пониманию того, что продукт производит ожидаемое воздействие на малую группу пользователей, мы постепенно предоставляем его все большему количеству пользователей, проводя при этом измерения и улучшая его. Это дает нам время для работы с операционными аспектами, такими как мощность техники, мониторинг, график развертывания, расширяемость, т.д.
Критерий Завершения:
Стадия «Ship It» завершается, когда продукт доступен всем пользователям. Помните, что этот продукт еще не "завершенное приложение". Завершения фазы «Ship It» означает, что продукт (MVP + необходимые усовершенствования) был выпущен на 100%. Такой вещи как "законченное приложение" не существует, поскольку продукт постоянно совершенствуется даже после этой стадии.
Tweak It
Это самая важная стадия, поскольку именно сюда попадают все продукты (если не отправляются в мусорную корзину по пути), именно в этом месте продукты проводят наибольшее время.
Сейчас продукт находится в производстве и доступен всем пользователям.
Хотя в определенной степени он уже проверил себя на стадии «Ship It», всегда остается довольно много пространства для улучшений. Отряд продолжает экспериментировать, проводить A/B тестирование и улучшать продукт, в то же время наблюдая за его показателями. Это может включать в себя важные новые приложения или же тонкие настройки.
Однажды в будущем отряд может достичь момента уменьшения обращений к продукту. Продукт великолепен, наиболее важные улучшения внесены, но соотношение цена/польза выглядит менее привлекательно. Если же взглянуть на показатели, окажется, что новые усовершенствования не приводят к большим переменам. Это означает, что продукт достиг "локального максимума".
В такой момент менеджмент и отряд обсуждают, довольны ли они этой горой, или стоит поискать вершину повыше? Если первое верно, команда может постепенно переключиться на новые продукты. Иначе, команда может вернуться к "Think It", чтобы переделать этот продукт и совершить прыжок к локальному максимуму (или более высокому пику).
Одним из примеров может служить сайт www.spotify.com. Этот сайт настраивался 4 года, пока летом 2012 мы не решили переделать его. Этот сайт передает главную идею Spotify совершенно иначе и куда более эффективным образом.
Обзор всего процесса
Заключение
Надеюсь, эта статья понравилась вам!
Если некоторые части этой модели вызвали у вас мысль: "Да я уже знал об этом, мы десятилетиями этим занимались", вы наверняка правы.
Эта модель вовсе не что-то новое и удивительное, это работающая штука, а новая она или старая, неважно.
Я считаю такую комбинацию практик очень вдохновляющей и мощной. Надеюсь, что вы тоже найдете здесь что-то полезное для вашего контекста.
Если у вас возникли какие-либо отзывы, пишите мне или оставляйте комментарии в блоге. Возможно, нам не хватит времени на подробные ответы, но сможем добавить к данной статье FAQ, опираясь на наиболее распространенные вопросы.
Хенрик Книберг: henrik.kniberg@spotify.com
http://www.crisp.se/henrik.kniberg
Переведено с английского проектом Agile Translations.
Оригинальная статья: How Spotify Builds Products.
Перевод с английского проектом 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”. Также я многое узнал их разговоров с дизайнерами, разработчиками и тренерами гибкой разработки. Спасибо всем вам!
Обзор
Сущность нашей философии такова:
- Мы создаем инновационные продукты и управляем риском, первым делом дешево создавая прототип.
- Мы запускаем продукт не к определенной дате, а лишь достигнув нужного качества.
- Мы непрерывно ведем тонкую настройку продукта после запуска - так мы убеждаемся в том, что наши продукты движутся от удобства при запуске к восхищению.
- Think It (обдумай)
- Build It (построй)
- Ship It (доставь)
- 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.