Согласно статистике Startup Genome, 9 из 10 стартапов закрываются, не добившись успеха. Причин много: деньги, команда, подход к реализации идеи. Если с деньгами и командой все более менее понятно — денег нужно больше, а команда должна быть профессиональной, то с подходом все немного сложнее. Он определяет, сколько нужно денег и какая потребуется команда. Говоря о подходах к разработке продукта, есть путаница в понятиях. Говоря о первой версии продукта, кто называет его MVP, кто-то — прототип, другие — вообще MVP прототип . Пришло время расставить все на свои места. В статье разберем, в чем принципиальная разница между MVP и прототипом, какие бывают прототипы и зачем нужна MVP разработка для стартапов.
Время чтения: 9 минут
Ищете слаженную команду разработки?
Поможем с дизайном и разработкой приложений для бизнеса и стартапов
Прототип — это интерактивная модель будущего продукта; драфт, в котором требуется доработка дизайна и функциональности. Это еще не готовый продукт, который используется для демонстрации возможностей проекта инвесторам или фокус-группе для тестирования.
Задачи, которые решает прототипирование:
В Purrweb мы делаем прототипы тогда, когда понимаем, что проект будет особенно сложен с технической стороны. То есть, когда надо проверить и точно понять, можно ли реализовать желаемую функциональность. Например, когда требуется сделать чат для приложения знакомств, который будет работать без интернета, или настроить механику стриминга. Недавно мы делали десктопное приложение, которое позволяет работать с 3D-моделью челюсти — здесь однозначно нужен был прототип, чтобы убедиться, что основная функция будет работать на нашем стеке без проблем.
Поскольку прототип не выводится на рынок, а служит скорее внутренним задачам проверки идеи, он не всегда может быть детально проработан с точки зрения визуала и функциональности. Рассмотрим виды прототипов и выделим их плюсы и минусы.
Графический прототип — набросок дизайна, визуализация без глубокой проработки. В дизайне даже есть отдельное понятие для такого визуала — вайрфрейм. Вайрфрейм нужен для фиксации идеи, первичного понимания продукта. Он не подойдет для демонстрации инвесторам, но поможет команде понять, что представляет собой продукт и в какую сторону нужно двигаться.
А еще вайрфреймы позволяют увидеть, как пользователи будут взаимодействовать с сайтом и насколько он будет для них удобен. Например, если вы хотите создать сервис, через который художники могут продавать свои картины, с помощью наброска дизайна можно сразу определить, где будет располагаться меню, где — галерея работ и т.д.
Интерактивный прототип — готовый дизайн с высокой детализацией. Он имитирует работу приложения и помогает получить более реалистичное представление о работе продукта. Формально интерактивный вариант может выглядеть как функционирующий продукт, но без кода. В дальнейшем результаты интерактивного прототипа могут использоваться для создания MVP.
Раньше мы использовали Marvel — удобную программу для интерактивного прототипирования, которая позволяет открывать доступ к проекту всей команде. Можно быстро получить обратную связь от коллег и внести в дизайн правки. Но потом мы выяснили, что Marvel сильно ухудшает качество изображения, поэтому перешли на не менее функциональный сервис Figma.
Технический прототип — продвинутая версия интерактивного. К продуманному дизайну здесь добавляется часть функциональности на уровне кода. Такой прототип нужен, когда или весь проект, или одна его функция обещает быть технически сложной. С помощью технического прототипа можно проверить, насколько реализуема идея и что нужно скорректировать на этапе до разработки MVP. Если нужную фичу удалось реализовать — можно представлять продукт инвесторам и переходить к созданию MVP.
Итак, мы поняли, что прототип и MVP — это не взаимозаменяемые подходы к разработке продукта. Они оба необходимы стартапу для успешного запуска. С прототипом и его целями и задачами мы разобрались, теперь перейдем к MVP.
Если интерактивный прототип помогает понять, как будет работать приложения, то MVP — это наиболее бюджетный и безопасный способ определить, насколько продукт будет востребован у реальных пользователей. И если все-таки промахнулись с функциональностью и визуалом, то скорректировать концепцию на начальных этапах разработки продукта. Данный метод широко используется на Западе — практически каждый стартап в Кремниевой долине начинается с создания минимально жизнеспособного продукта. В последнее время MVP разработка как тренд появляется и на рынках СНГ и России.
Подробнее о том, что такое MVP и как его создать, читайте в нашем гайде по созданию MVP.
Основная задача MVP — собрать обратную связь от пользователей и, если требуется, скорректировать бизнес-модель еще на этапе тестирования продукта.
Запуск минимально жизнеспособного продукта выгоден для стартаперов сразу по нескольким причинам:
Главное преимущество MVP перед прототипом — это мгновенный фидбек от целевой аудитории. Пользователи сразу могут ознакомиться и протестировать продукт, и составить предварительную оценку о проекте в целом. Минимально жизнеспособный продукт содержит минимум обязательных функций, что предполагает низкие расходы на разработку, однако помогает собрать максимум данных о рыночном спросе и поведении ЦА.
Есть два подхода к выбору ключевых фичей для MVP: User Story Mapping и MoSCoW метод. В деталях они немного отличаются, но задача у них одна и та же — выбрать фичи, без которых не получится запустить MVP. Мы подробно разбирали их особенности в другой статье ⬇️
MVP разработка обходится дешевле полноценной, так как позволяет своевременно отказаться от неэффективных решений, скорректировать стратегию и план проекта. Именно эта стадия разработки считается поворотным этапом для стартапов — реакции целевой аудитории помогают определить насколько продукт необходим на рынке, стоит ли дорабатывать концепцию и привлекать дополнительные ресурсы на разработку.
MVP — это первая боевая версия продукта, которая включает весь необходимый инструментарий для комфортного пользования продуктом; своеобразный плацдарм для тестирования реакции ЦА и дальнейшего развития проекта.
Конечно, MVP должен отвечать возможностям вашего стартапа и решать определенные задачи, поэтому и вариантов его создания существует несколько. Мы расскажем, какие типы MVP используются чаще всего и объясним нюансы их разработки на примерах наших кейсов.
1. Лендинг. Несмотря на то, что лендинг нельзя назвать продуктом, он может познакомить потенциальных клиентов со стартапом и заинтересовать в покупке. Лендинг поможет протестировать предполагаемую модель ценообразования, проверить покупательную способность пользователей, проанализировать их интерес в целом.
2. Concierge MVP. Тип тестирования гипотезы, когда вы проводите все операции вручную, чтобы собрать максимально полную обратную связь от пользователя. Этот вариант можно воплотить даже без разработки MVP-приложения: вы предлагаете клиенту услугу, и сами обеспечиваете ее выполнение. Таким образом, можно легко проверить спрос: если клиентам услуга интересна, проект автоматизируется.
3. Wizard of Oz (Волшебник страны ОЗ). Его механика похожа на Concierge MVP, то есть, тоже требует «ручного управления», но пользователь взаимодействует с интерфейсом сайта или приложения. Это помогает быстро проверить пользовательский интерес и проанализировать, насколько удобен будущий сервис для клиента. С таким MVP к нам обратились разработчики Cheflocal, проекта для поваров-фрилансеров. Перед тем как заказчик пришел к нам, все заказы обрабатывались вручную через WhatsApp.
4. Франкенштейн-MVP. Еще одна разновидность MVP с «имитацией» работы, но здесь работа вручную сводится к минимуму, а необходимые операции выполняются с помощью других сервисов. Такой способ тестирования мы выбрали для приложения Grecha.pro — единого чата для взаимодействия ресторанов с поставщиками. Половина бизнес-процессов реализуется с помощью других сервисов через сервис Integromat. Другая половина была написана разработчиками Purrweb.
5. Single Feature, или MVP одной функции. Суть этого типа раскрывается уже в названии: создается продукт с одной, самой интересной работающей функцией. Хороший способ заинтересовать в проекте и клиентов, и инвесторов.
Чтобы выбрать наиболее подходящий вашему стартапу вариант, нужно отталкиваться от нескольких факторов. Подробнее о том, какие типы MVP бывают и как подобрать нужный вам тип, мы говорим здесь.
На практике Purrweb чаще всего применялись три типа — MVP одной функции, Франкенштейн и Wizard of Oz. Эти виды лучше всего позволяют понять логику пользователя и отследить его взаимодействие с продуктом. Лендинг не дает такой возможности, поэтому используется не так часто.
Иногда при разработке к одному типу добавляются черты другого. Так при тестировании продукта можно добиться максимального результата. Как это работает, показываем на примере двух кейсов:
Платежная система Headcount
Headcount — система для перевода оплаты подрядчикам по всему миру. Заказчик обратился к нам тогда, когда сроки уже поджимали, поэтому нам нужно было запустить сервис за два месяца. Так как заказчик хотел представить сервис на событии Y Combinator, он должен был что-то уметь, в идеале — как можно больше. Поэтому мы сразу остановились на создании MVP без прототипа способом Single Feature, то есть одной функции. Приоритетной фичей в этом случае был механизм переводов. Но, так как перевести деньги нельзя без создания аккаунта и подключения банковского аккаунта, за основной фичей потянулось еще несколько. В результате работа над основными фичами помогла нам закончить проект в срок без переработок и других затрат.
Аренда пауэрбанков EnerGO
Цель проекта EnerGO — позволить пользователям арендовать пауэрбанки для зарядки смартфона на одной станции метро, а оставлять на другой. Это был наш первый IoT-проект, то есть, проект интернета вещей, когда устройства обмениваются данными через интернет. Тестирование приложения проходило с помощью станции из Китая у нас в офисе. В качестве работающего и самого подходящего варианта снова был выбран MVP одной функции.
После запуска мы добавили еще несколько функций, а через несколько месяцев разработали новую версию приложения. Стартап уже давно вышел на самоокупаемость, успешно работает и развивается.
Несмотря на разные функции MVP и прототипа, очень многие часто путают их. И планируют разработку только одного из этих подходов. Теперь, когда мы разобрались, что MVP и прототип — разные вещи, финализируем их отличия наглядно по 3 критериям: целям, задачам и возможностям монетизации.
Инсайты из мира разработки и экспертный взгляд на цифровые продукты в нашем Telegram-канале Стартап-пикап.
Минимально жизнеспособный продукт и боевой прототип — нетождественные понятия. Основные различия:
Для удобного сравнения этих двух подходов собрали их различия по категориям:
В некоторых случаях, когда компания обладает достаточными ресурсами и точно знает, в чем нуждается рынок и целевая аудитория, можно сразу переходить к MVP разработке стартапа без прототипирования. Purrweb рекомендует все таки не пропускать этот этап, так как прототипирование — хороший способ определить критические ошибки проекта еще на этапе планирования. Это исключит затраты на разработку и поможет создать минимально жизнеспособный продукт с конкурентоспособным рыночным предложением.
MVP и прототип — независимые этапы разработки одного продукта, преследующие разные цели. Обе сущности не могут взаимозаменяться на этапе разработки проекта, однако часто их функции совмещаются в стартапах с ограниченными бюджетом и сроками на разработку. В любом случае, решение по их «объединению» и существованию в целом принимается, исходя из возможностей, специфики и целей стартапа.
Если у вас возникли проблемы с минимально жизнеспособным продуктом, обращайтесь к специалистам Purrweb. Мы — команда полного продуктового цикла, которая специализируется на MVP-разработке с упором на удобство конечных пользователей. Если у вас остались вопросы по выбору типа MVP для вашего проекта, мы подскажем, какая модель будет наилучшим вариантом и успешно реализуем ее в короткие сроки.
Насколько публикация полезна?
Оцени эту статью!
21 оценок, среднее 4.8 out of 5.
Оценок пока нет. Поставьте оценку первым.
Так как вы нашли эту публикацию полезной...
Подписывайтесь на нас в соцсетях!
Читать
Ваша заявка уже у нас :)
Обычно ответ занимает от 12 до 24 рабочих часов.
Может, вы хотите запланировать онлайн встречу?
Извините, что-то пошло не так при отправке запроса.
Попробуйте позже.