Rose debug info
---------------

Subscribe to this blog

Spotify MVP

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

Верхний пример

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

«Вот, сэр, наша первая итерация, переднее колесо. Как вам?»

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

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

Нижний пример

Давайте рассмотрим нижний пример.

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

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

Клиент вряд ли будет доволен этим. Это и рядом не стоит с машиной, которую он заказал. Но это нормально! Мы не пытаемся сделать клиента счастливым на данный момент. Наша главная цель на данный момент — обучаться и проверять. В идеале команда заранее четко объясняет это клиенту, поэтому он не слишком разочарован.

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

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

Поэтому на следующей итерации мы пытаемся решить эту проблему или хотя бы пытаемся узнать о ней чуть больше.

Скейтборд с ручкой! Теперь клиент не должен падать и сильно напрягаться.

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

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

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

Ну что теперь? Опять же, возможно, клиент доволен мотоциклом. Мы могли бы закончить проект раньше, чем планировалось. Большинство продуктов пронизано сложностью и функциями, которые никто не использует. Итеративный подход — это действительно способ найти самый простой и дешевый способ решения проблемы клиента.

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

Клиент очень доволен! Почему? Поскольку мы узнали по пути, что он ценит свежий воздух. В конце концов, он получил машину, но лучше, чем планировалось изначально!

Пример: музыкальный плеер Spotify

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

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

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

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

Получив что-то приличное, они начали проверять себя, свою семью и друзей.

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

Но они бесстыдно передали скейтборд в руки реальных пользователей — друзей и родственников — и быстро получили ответы, которые им нужны. Да, это было технически возможно. И да, людям абсолютно понравился продукт. Гипотезы были подтверждены. Этот прототип помог убедить музыкальных лейблов и инвесторов.

Пример: Minecraft

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

Это был их скейтборд. Вся связь пользователей и разработчика строилась в Твиттере.

Пример: Lego

Совершенно обратный пример был у Lego. Это продукт Lego Universe, многопользовательский онлайн-мир Lego. Звучит весело, да? Проблема в том, что они были чрезмерно амбициозными и в итоге попытались довести все до совершенства, прежде чем выпустить в мир.

Около 250 человек работали в течение 4-5 лет, и когда релиз, наконец, пришел, прием был очень теплым. Готовая игра была красивой, но не такой веселой, как ожидалось, поэтому продукт был закрыт через 2 года. Скейтборда не было! Почему нет? Потому что скейтборды не удивительны, по крайней мере, если вы ожидаете машину, а культура Lego заключается в том, чтобы доставлять удивительные впечатления!

Погоня за совершенством задержала жизненно важную обратную связь, что означало ошибочные предположения о том, что нравится пользователям, а что нет. Точная противоположность Minecraft.

Интересно, что команды Lego Universe фактически использовали Scrum и многократно выпускались — как это делали парни из Minecraft. Но релизы были только внутренними. Так что, скорее всего, были скейтборд, велосипед и так далее, но эти продукты никогда не доходили до реальных пользователей.

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

Выводы

  1. Избегайте доставки больших и сложных продуктов одним пуском. Делайте это итеративно и постепенно. Проверяйте каждую итерацию.
  2. Начните с определения вашего скейтборда — самого раннего тестируемого продукта. Стремитесь к облакам, но проглотите свою гордость и начните с доставки скейтборда.

Источник Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable


Чтобы не пропустить новую заметку — подпишитесь на мой канал в Телеграме или RSS.

Next
Do you want to discuss something? Just write to me! telegram or email