Чего не хватает в вашем MVP

Каждый, кто участвовал в разработке программного обеспечения за последние пять лет, вероятно, слышал термин MVP (Минимальный жизнеспособный продукт). И если вы несёте ответственность за взаимодействие с пользователем, скорее всего, вы часто бываете разочарованы этими тремя буквами.

Возможно, потому что вы обычно сталкиваетесь с ними ближе к концу проекта, когда звучат предложения подобных этому: «Это отличная идея, но мы просто не можем внедрить ее прямо сейчас. Давайте запустим MVP и добавим это позже».

Наиболее распространенное определение минимального жизнеспособного продукта( MVP) — это продукт, обладающий достаточным количеством функций, чтобы удовлетворить пользователей и обеспечить обратную связь для будущего развития.

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

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

Приведенная ниже модель, первоначально предложенная Юсси Пасаненом (впоследствии она стала обязательным артефактом любого поста в блоге на эту тему), объясняет, как не разочаровать своих пользователей, предоставляя им продукт как можно быстрее. Он предлагает вместо последовательного создания слоя за слоем, создать хотя бы минимальный кусочек на каждом слое.

Любой MVP должен иметь набор функций, который дает пользователям:

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

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

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

Если мы хотим уменьшить масштаб, самое разумное место для начала — это основа этой пирамиды — функциональность. Какие функции мы хотим включить? Знаю, вы сейчас напряглись. Я тоже, пока не понял, что «функциональный слой» является ложным дном этой пирамиды.

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

Предположим, мы хотим продукт, который решает проблему X для наших пользователей. Для каких сегментов наших пользователей мы должны построить MVP для проверки нашего подхода? Этот вопрос должен быть драйвером в планировании скоупов проекта.

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

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

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

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

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

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

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

Например, если вам обычно требуется полчаса, чтобы добраться до работы, вы ожидаете, что завтра у вас уйдет примерно столько же времени. Хотели бы вы, чтобы ваша поездка была короче? Конечно, но вы знаете, что не всегда получаете то, что хотите. Однако, если ваш трамвай завтра опаздывает на 15 минут, а ваша поездка превращается в 45 минут, вы можете потерять контроль над собой.

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

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

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

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

Часто ли она использует подчеркивание? Технически да, но практика двойных подчеркиваний для окончательных итогов предшествует компьютерам и электронным таблицам. Ваша попытка ограничить область действия MVP просто не является достаточной причиной, чтобы игнорировать это.

Создание MVP — это не сокращение возможностей, а поиск минимального функционала, который вы должны создать для определенной вами аудитории.

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

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

Перевод статьи The thing that’s missing from your MVP. Доступно по ссылке