kazminaviktoriya1
Перейти в профиль
Выйти из профиля
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="42" height="42"><rect fill-opacity="0"/></svg>)
Добавить аккаунт
Спринт 9/18: Agile-практики → Тема 4/7: Карта пользовательских историй → Урок 2/2
Минимально жизнеспособный продукт
В предыдущем уроке вы познакомились с картой пользовательских историй и узнали, что её можно поделить на итерации или релизы. В этом уроке вы узнаете, как выделить на карте MVP и для чего это нужно.
Что такое MVP?
MVP (Minimum Viable Product — минимально жизнеспособный продукт) — это продукт минимального размера, при выпуске которого успешно достигаются желаемые результаты.
В выявлении MVP так же, как в составлении карты пользовательских историй, принимает участие вся команда разработки. Иногда для этого привлекают и внешних экспертов: маркетологов или аналитиков рынка и других. Для выявления MVP команда разработки выдвигает одно из предположений (гипотез) о том, что необходимо самому пользователю или команде разработки для удовлетворения потребностей пользователя.
Гипотеза — это предположение, догадка или утверждение, которые требуют доказательства. В контексте разработки ПО гипотеза — это предположение о том, какие функции необходимы пользователю, какие функции могут хорошо повлиять на метрики бизнеса, например увеличить количество активных клиентов того или иного продукта.
В связи с этим ещё одно определение MVP:
MVP — это минимальный набор функций, который может реализовать команда, чтобы доказать или опровергнуть гипотезу.
Главная цель создания MVP — проверка гипотез. Благодаря MVP команда может быстро получать обратную связь от будущих пользователей продукта. MVP — это не просто набор функций, которые команда может сделать быстрее всего. Это жизнеспособный продукт, на котором можно проверить, удовлетворяются ли потребности пользователей. Главная цель при выделении MVP — как можно быстрее пройти цикл получения обратной связи (создание продукта → обратная связь от пользователей и стейкхолдеров → получение опыта командой разработки) и удовлетворить потребности пользователя, приложив минимум усилий команды разработки.
Проверка гипотез
Проверяя гипотезы, команда должна быть готова к двум результатам:
- Реакция пользователей или метрики продукта подтвердят гипотезу. В этом случае предположения окажутся верными и можно смело работать над продуктом дальше, то есть продолжать развивать его, основываясь на потребностях пользователя.
- Реакция пользователей или метрики продукта опровергнут гипотезу. В этом случае предположения не подтверждаются, но это не повод расстраиваться и бросать идею. Необходимо собрать обратную связь, поставить новые гипотезы и проверить их либо попробовать реализовать новую идею.
Важно понимать, что каждый релиз должен содержать минимально жизнеспособный продукт. Чтобы пользователи уже могли им пользоваться и удовлетворять свои потребности, а команда могла проверить свою гипотезу.
В начале этого спринта вы узнали, что в гибкой модели разработки учитывается неопределённость, связанная с продуктом, и неопределённость, связанная с проектом. Гипотезы тоже бывают двух видов: о продукте и о проекте.
Гипотезы о продукте
Исходя из неопределённостей, связанных с продуктом, команде разработки нужно выдвигать гипотезы о продукте для понимания потребностей пользователя. Желания пользователя могут постоянно меняться, а ещё функции, которые команда считает значимыми, могут оказаться совсем не нужными.
Функции, казавшиеся важными до начала разработки продукта, могут оказаться не стоящими вложений. В связи с этим необходимо разбивать процесс разработки на короткие итерации. Для команды важно выдвигать гипотезы о необходимой функциональности продукта и собирать обратную связь. Примером такой гипотезы может быть гипотеза о том, необходима ли та или иная функция для удовлетворения потребностей пользователей.
Например, гипотеза о продукте может быть сформулирована так: «Система лояльности увеличит количество клиентов, делающих повторный заказ, на 30%».
Гипотезы о проекте
Команде разработки также необходимо учитывать неопределённость, связанную с процессом создания продукта. Эта неопределённость заключается в том, что невозможно до начала реализации продукта спроектировать всю систему.
В связи с этим команда выдвигает гипотезы не только о продукте и его функциях, но и о проекте. Примером такой гипотезы может быть ожидаемый эффект от использования определённой технологии или инструмента.
Рассмотрим гипотезы о проекте на примере. Пользователи веб-сайта недовольны долгой загрузкой его страниц. Команда разработки предполагает, что сможет уменьшить время благодаря кэшированию — копированию на клиентском компьютере ранее загруженных с сервера данных. В результате время загрузки страниц сократится, поскольку веб-браузер будет использовать для отображения веб-страницы копии данных, не загружая их оригиналы с сервера.
Команда формулирует гипотезу о проекте: «Время загрузки веб-страниц будет занимать меньше одной секунды после реализации кэширования».
Перед вами несколько гипотез. Определите, какие из них относятся к продукту, какие — к проекту.
Для чего нужен MVP
MVP необходим для проверки гипотез. Ещё:
- Реализовать MVP быстрее и дешевле, чем разрабатывать продукт сразу с большим объёмом функций.
- MVP помогает снизить затраты и риски, так как позволяет быстро получить обратную связь от пользователей прежде, чем команда приступит к реализации полноценного решения.
- MVP даёт возможность избежать создания продукта, который не нужен пользователям. Проверяя гипотезы, команда понимает, какие функции действительно нужны пользователям.
- MVP позволяет протестировать фактический сценарий использования на реальных пользователях.
- Проверяя гипотезы, команда обучается новым практикам и технологиям.
Выделение MVP
Хенрик Книберг — разработчик и agile-тренер в своём блоге показал иллюстрацию выделения MVP, которая стала очень популярна в среде agile-команд (почитать об этом можно по ссылке). Представьте, что вашей команде необходимо реализовать продукт, главная цель которого — доставить пользователя из точки А в точку Б. И вы решили, что будете реализовывать продукт так, как показано на иллюстрации:
Реализуя продукт таким образом, каждую итерацию команда предоставляла пользователям функционал, пользоваться которым невозможно. Только по прошествии времени пользователь смог получить хоть какой-то продукт, который позволит ему доехать из точки А в точку Б. Команда приложила много усилий и потратила много времени, но не учла, что финальный продукт может не понравиться пользователю. Ещё она не учла, что для удовлетворения потребностей пользователя можно было сделать более простой продукт и улучшать его.
Правильной стратегией было бы каждый релиз представлять минимально жизнеспособный продукт, который удовлетворяет потребность пользователя добраться из пункта А в пункт Б. И при этом собирать обратную связь и вносить коррективы, чтобы в итоге найти тот продукт, который необходимо развивать для максимального удовлетворения потребностей пользователя.
Чтобы выделить MVP, необходимо выполнить несколько шагов:
- Определить проблему пользователя, которую необходимо решить.
- Определить гипотезу для решения этой проблемы.
- Определить минимальный набор функций для проверки гипотезы.
Разберём все три шага на том же примере продукта, главная цель которого — доставить пользователя из точки А в точку Б.
- Определить проблемы пользователя
Представим персону, для которой осуществляется разработка данного продукта. Миша — одинокий мужчина 29 лет, который не любит общественный транспорт и хочет быстро передвигаться по городу. Исходя из описания персоны, можно определить его основную проблему — он хочет быстро передвигаться по городу на индивидуальном транспорте.
- Определить гипотезы для решения проблемы
Какие гипотезы могла выдвинуть команда для выявления MVP:
Гипотеза: Скейтборд подойдёт Мише, чтобы добраться из точки А в точку Б, потому что он маленький и его удобно брать с собой.
В таком случае минимально жизнеспособный продукт — это обычный скейтборд на четырёх колёсах, ведь он позволяет добраться из одного места в другое, а на его разработку не нужно много времени. Но, получив обратную связь от пользователей, команда поняла, что не все пользователи умеют кататься на скейтборде, а значит, этот продукт их не удовлетворит.
Далее команда проверила ещё две гипотезы: о самокате и велосипеде как средствах передвижения по городу, — которые также не подошли пользователю. Но, проверяя эти гипотезы, команда выявила новые требования пользователей и пришла к четвёртой гипотезе.
Гипотеза: Мотоцикл подойдёт Мише, чтобы быстро и просто добраться из точки А в точку Б.
MVP станет мотоцикл на двух колёсах с минимальным функционалом. Он позволит быстро передвигаться не только по городу, но и на дальние расстояния. При этом не нужно стоять в пробках, их просто можно объехать. Получив обратную связь от пользователей, команда не выявила минусов.
Если бы персонами были семьи с детьми, такой MVP им бы не подошёл — команда должна была бы выдвинуть ещё одну гипотезу и предложить машину.
Таким образом, в MVP будет входить самый простой мотоцикл, который команда смогла создать за короткий срок. Он позволяет передвигаться из одной точки в другую с комфортом. Когда команда выяснила, что этот продукт подходит пользователям, она может приступать к улучшениям продукта.
При выделении MVP необходимо соблюдать простое правило: устраните любые опции, процессы или задачи, которые не помогут проверить гипотезу. Если функция усложняет задачу, но не проверяет гипотезу, от неё нужно отказаться.
Многие известные компании начинались именно с проверки гипотезы посредством MVP. Первой гипотезой стартапа Airbnb было предположение, что во время командировок на конференции в другие города люди не хотят платить за номер в гостинице, так как цена на них во время таких мероприятий слишком высока. А всё, что нужно человеку во время командировки, — это кровать и завтрак. Спустя десять лет Airbnb проверял уже совсем другую гипотезу: во время путешествий люди хотят бронировать уникальное жильё и получать впечатления.
Если вам интересно, можете ещё почитать истории создания таких компаний, как Uber, Dropbox или Spotify.
Связь MVP и карты пользовательских историй
В прошлом уроке вы узнали о карте пользовательских историй и разобрали её на примере приложения с интерактивной картой метро. Главная задача приложения — помочь пользователям не тратить много времени на поездку. Давайте вспомним получившуюся карту пользовательских историй.
Помимо деления пользовательских историй на итерации и релизы, на карте можно выделить MVP. Разберём, как это сделать, на примере одной группы персон (Ангелина и Виталий).
Определим их основную проблему
Пользователи хотят понимать, сколько времени им необходимо заложить на дорогу в метро, чтобы приехать вовремя и не опаздывать.
Выделим гипотезу о продукте
«Пользователи будут строить свой маршрут в приложении для понимания того, сколько времени им необходимо затратить на дорогу».
Определим минимальный набор функций для проверки гипотезы
Для определения минимального функционала проанализируем карту и выберем пользовательские истории, которые войдут в MVP. Анализировать будем слева направо, переходя от одной задачи к другой.
Первая задача «Открыть карту». В рамках этой задачи была выделена только одна история: «Как пользователь, я хочу сразу увидеть карту своего города, чтобы не терять время». Она отлично подходит под выделенную нами гипотезу, ведь без карты пользователи не смогут построить маршрут. Поэтому данную историю необходимо включить в MVP.
На карте пользовательских историй MVP выделяется как ещё один слой, на который необходимо «перетащить» подходящие истории. Остальные же истории остаются на уровне, который называют на карте бэклогом продукта.
Следующая задача «Найти нужную станцию». В этой задаче было выделено пять историй.
Для проверки гипотезы, сформулированной выше, и реализации минимального функционала ни одна из этих историй не подходит. Эти истории останутся в бэклоге, к ним команда сможет вернуться после реализации MVP, если их гипотеза подтвердится.
В рамках задачи «Построить маршрут» было выделено три истории.
Для реализации минимального функционала, проверяющего выделенную гипотезу, подойдёт одна история: «Как пользователь, я хочу ввести названия станций начала и конца маршрута, чтобы узнать его детали». С помощью неё пользователь сможет построить необходимый ему маршрут. Добавим её в MVP.
Последняя задача на карте, относящаяся к Ангелине и Виталию, — «Посмотреть альтернативный маршрут». Возможность составить альтернативный маршрут не относится к минимальному функционалу. К этой истории можно вернуться после проверки гипотезы, поэтому она пока тоже останется в бэклоге.
Истории из пользовательских задач «Выбрать избранный маршрут», «Посмотреть детали избранного маршрута» относятся уже к другой группе персон (Костя и Виталий), а значит, и проблемы у них будут другие. Для их решения необходимо выдвинуть другую гипотезу и выявить другой MVP.
Итак, MVP для проверки гипотезы «Пользователи будут строить свой маршрут в приложении, чтобы понять, сколько времени им необходимо затратить на дорогу» будет состоять из трёх историй. Достаточно реализовать их, чтобы проверить эту гипотезу.
Давайте посмотрим на получившуюся карту пользовательских историй:
Заключение
MVP (Minimum Viable Product — минимально жизнеспособный продукт) — это продукт минимального объёма, при выпуске которого успешно достигаются желаемые результаты.
В выявлении MVP так же, как в составлении карты пользовательских историй, принимает участие вся команда разработки.
Главная цель создания MVP — проверка гипотез. Проверяя гипотезы, можно столкнуться с двумя результатами:
- Реакция пользователей или метрики продукта подтверждают гипотезу.
- Реакция пользователей или метрики продукта опровергают гипотезу.
В гибких моделях разработки команда может выделить гипотезы двух видов:
- Гипотезы о продукте.
- Гипотезы о проекте.
MVP необходим для снижения затрат и рисков за счёт получения обратной связи от пользователей перед реализацией полноценного решения.
Выявить MVP можно с помощью трёх шагов:
- Определить проблему пользователя, которую необходимо решить.
- Определить гипотезу для решения этой проблемы.
- Определить минимальный набор функций для проверки гипотезы.
Используя вместе MVP и карту пользовательских историй, команда может определить состав бэклога продукта.
Чат поддержки