Что такое MVP мобильного приложения

Разработка продукта — это сложный многоэтапный процесс, который требует вложения сил и средств. Поэтому еще в самом начале необходимо найти ответы на основные вопросы: нужен ли продукт пользователю, будут ли его покупать, стоит ли финансировать его создание? Меня зовут Владислава Ларкина, я операционный директор студии мобильной разработки CleverPumpkin. Рассказываю в статье, как найти ответы на эти вопросы и прояснить ситуацию с помощью запуска MVP.

Зачем нужен MVP

Термин MVP (Minimum Viable Product), «минимально жизнеспособный продукт» появился примерно 20 лет назад и означал версию нового продукта, используемую для получения с минимальными усилиями обратной связи от клиентов. Очень быстро этот инструмент стал незаменимым в разработке приложений, сайтов, сервисов.

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

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

Какими преимуществами обладает MVP

За счет реализации минимума функциональности вы экономите время и выпускаете продукт на рынок как можно раньше. Грамотно разработанный MVP позволяет своевременно занять нишу. 

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

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

Мифы и рифы MVP

Казалось бы, узнали об MVP — используйте и создавайте проекты. Однако простота этого инструмента обманчива. Заблуждения о том, что такое MVP, что он должен выполнять, а что нет, часто приводят к потере бюджета, нарушению дедлайнов и, как следствие, к разочарованию пользователей. Вот почему стоит разобраться, чем минимальная жизнеспособная версия точно не является — и все встанет на свои места.

1. MVP — это готовый продукт

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

2. MVP — это основа продукта

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

3. MVP — это продукт с недоработанной функциональностью

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

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

К тому же функциональность — это лишь один компонент, который есть в продукте — не стоит забывать про остальные. Даже на уровне MVP приложение должно быть: надежным, удобным в использовании, вызывать приятные эмоции у пользователей.

Время или функциональность: выбираем модель оплаты

Разобравшись, что такое MVP, давайте поговорим о том, столько будет стоить его разработка. Конечно, мы не назовем вам даже приблизительную цену — ведь мы не знаем подробностей задания — однако можем описать способы расчетов. 

В среде разработчиков (и не только) существуют три модели оплаты труда. 

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

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

Модель «Time&Materials»: при таком подходе заказчик оплачивает не фиксированную стоимость услуг согласно ТЗ, а время, по факту потраченное командой на разработку. Отличие этого подхода — гибкость и возможность по необходимости менять условия. 

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

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

Не MVP единым

Рынок постоянно растет, требования пользователей к продукции меняются, а вместе с ними меняется и MVP. Это понятие постепенно расширяется, сменяясь на более продвинутый MAP — Minimum Awesome Product, то есть «минимально привлекательный продукт».

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

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