4 причины, почему вашему проекту нужен MVP

4 причины, почему вашему проекту нужен MVP

Авторы статьи
Ляна Колпакова
Елена Руденец

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

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

  1. Что такое MVP
  2. Зачем IT-проекту нужен MVP
  3. Процесс разработки: от идеи до MVP
  4. Сколько стоит разработка MVP

1. Что такое MVP

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

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

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

2. Зачем IT-проекту нужен MVP

Многие воспринимают MVP как незаконченный продукт, из-за чего возникает вопрос: зачем тратить деньги на его создание? Однако это представление неверно. Минимальный – не значит “недоделанный”. Минимально жизнеспособный продукт – это уже готовое решение, которое закрывает одну главную потребность клиента.

Разработка MVP решает ряд важных задач, стоящих перед владельцами бизнеса.

2.1. Проверка идеи на практике

У вас есть идея, нацеленная на решение проблемы, с которой не справляются уже имеющиеся на рынке предложения. Но не каждая идея, которая выглядит обреченной на успех, находит отклик у аудитории. Даже если вы уверены в своем решении на 100%, оно может не выстрелить. В этом легко убедиться, пролистав популярные категории в App Store или Play Market: они переполнены однообразными приложениями для онлайн-тренировок, скидочными сервисами и социальными сетями. Но лишь некоторые из них проходят “рыночный отбор” и становятся хитами.

Фокусировка на собственных представлениях о том, что нужно клиенту – прямой путь к тому, что проект не взлетит. В такой ситуации оказались создатели приложения Adkeeper. Идея была проста: с помощью приложения пользователи могут сохранить себе понравившиеся рекламные объявления. С одной стороны, это давало бы клиентам возможность воспользоваться понравившимся предложением позже. С другой – служило бы качественным показателем для рекламодателей. По задумке создателей, такая практика помогла бы повернуть время вспять и наполнить интернет по-настоящему красивой рекламой в стиле 70-х, вытеснив безвкусные баннеры. Идея привлекла инвестиции, и приложение заработало. Однако вложения размером в $43 млн не помогли сделать сервис привлекательным для клиентов: создатели обнаружили, что никто не хочет взаимодействовать с рекламой таким способом.

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

2.2. Сбор информации для полноценного продукта

Вы изначально знаете, что будущий продукт будет многофункциональным и сложным. Но на начальном этапе, перед стартом разработки такого масштабного продукта, нужно уточнить некоторые детали:

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

В таком случае создание MVP – это надежный способ протестировать свою гипотезу прежде чем финансировать разработку полноценного продукта.

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

Dropbox сегодня. Источник

2.3. Привлечение внимания инвесторов

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

Идея веб-сайта Product Hunt пришла к Райану Гуверу в 2013 году, когда он почувствовал необходимость оперативно узнавать о запуске новых продуктов и обсуждать их с единомышленниками. Чтобы убедиться, что такая потребность существует у широкого круга аудитории, Райан начал с создания группы для обмена ссылками при помощи приложения Linkydink. Первоначальная версия ProductHunt представляла e-mail рассылку со списком новых продуктов, которые понравились Райану Гуверу. Уже в таком виде идея стала популярной и оправдала дальнейшие затраты на разработку полноценного веб-сайта и приложения. Меньше чем через год проект привлек инвестиции в размере $6,1 млн.

Источник

2.4. Рост количества прибыльных проектов внутри компании

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

Twitter начинался как небольшой второстепенный проект компании Odeo – подкаст-платформы. В 2005 году, на фоне анонса Apple о платформе для подкастов на iTunes, компания Odeo остро нуждалась в новых идеях. Одной из них стал сервис коротких сообщений-статусов, которые отправлялись не одному человеку, а сразу группе друзей или коллег. Прототип Twitter (или Twttr, как он назывался тогда) появился в марте 2006 г. Идея не показалась инвесторам привлекательной, однако быстро завоевала популярность пользователей: уже через год через Twitter ежедневно публиковалось 60 000 твитов. В конце 2019 года ежедневная монетизируемая аудитория социальной сети составляет 152 миллиона.

Источник

3. Процесс разработки: от идеи до MVP

В Umbrella IT мы разделяем разработку MVP на 5 этапов.

3.1. Начало работ

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

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

3.2. Подготовка прототипов

Согласовав объем и сроки работ, команда готовит и утверждает вайрфреймы – черно-белые прототипы интерфейса приложения. Это “скелет” вашего будущего продукта, и уже на этапе MVP стоит спроектировать его максимально удобно для пользователя. В противном случае, когда функциональность станет шире, придется объяснять аудитории, как пользоваться вашим продуктом – а это требует времени и усилий. Непонятный интерфейс способен убить энтузиазм пользователей и опустить рейтинг даже самого инновационного продукта до низких значений.

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

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

3.3. Поиск IT-решений

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

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

3.4. Разработка

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

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

В конце каждого майлстоуна (1-2 недели) итог демонстрируется заказчику.

3.5. Релиз продукта

Когда все майлстоуны в MVP закрыты, проект выносится на стенд для beta-тестирования клиентами или презентации продукта инвесторам.

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

4. Сколько стоит разработка MVP

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

  • Сложность идеи приложения
    Сделать новостной агрегатор с базовым функционалом проще и дешевле, чем e-commerce сайт с большим количеством интеграций и сложной системой ролей с разным уровнем доступа к объектам. Кроме этого, стоимость проекта возрастает, если вашему сервису требуется:
    • мультиязычность;
    • интеграция с социальными сетями;
    • онлайн-чаты с возможностью создавать группы, делиться файлами, использовать эмодзи;
    • сложный UI/UX c многоступенчатыми формами, наполненными логикой страничками;
    • сложные операции с файлами: преобразование, записи в файлы.

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

  • Поддержка разных устройств
    Стоимость проекта напрямую зависит от количества устройств, на которых планируется использовать приложение, так как это увеличивает объем работы по адаптации элементов интерфейса и контента под разные размеры экранов. Для MVP рекомендуется начать с одной версии – веб-платформы для B2B проектов или мобильного приложения для B2C.

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

  • Стек технологий
    От технологий, используемых на проекте, зависит стоимость специалистов, работающих над ним, а также доступность готовых решений и возможность интеграции с другими сервисами, что сказывается на скорости разработки.
  • Состав команды
    Как правило, в команду по разработке MVP входят 2 разработчика (Senior и Middle) и QA-инженера. Мы также подключаем PM (Project Manager), который регулирует рабочий процесс.

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

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

  • 60 часов работы PM;
  • по 250 часов работы на каждого разработчика;
  • 200 часов работы QA-инженера.

Так как в основе оценки стоимости MVP – почасовая ставка специалистов, которые задействованы на проекте, то данные цифры актуальны для MVP с простой бизнес-логикой и базовой функциональностью.

Нужна помощь в разработке MVP?

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