Но есть подход, который снижает стартовый бюджет для любой задачи, — разработка через MVP. Вместо того чтобы сразу проектировать систему с полным набором функций, мы выделяем ключевые из них — те, что закрывают основную потребность пользователей, — и запускаем именно их. Это не «дешёвая версия ради экономии», а осознанное сужение задачи на первом этапе с чётким планом, что и когда добавится позже.
Такой подход снижает риски и для заказчика, и для бюджета: вы вкладываете меньше на старте и проверяете, действительно ли продукт нужен пользователям в том виде, как задуман, прежде чем инвестировать в полную версию.
Мы в MEN IN DEV разрабатываем такие продукты с 2016 года — 65+ проектов и 20 млн+ пользователей приложений и систем. Специалисты в штате — аналитики, дизайнеры, разработчики, тестировщики — работают над каждым проектом от брифинга до запуска, поэтому решение о том, что войдёт в MVP, а что можно отложить, принимается совместно с командой, которая видит всю картину проекта, а не только свой узкий участок задачи.
MVP как способ снизить стартовый бюджет
MVP работает как фильтр между идеей и полноценной разработкой, отсекая функции, которые кажутся важными на бумаге, но без которых продукт вполне может обойтись на старте. Мы вместе с заказчиком детально разбираем задачу и выделяем функции, без которых продукт не может работать вообще, — остальное откладывается до следующих релизов. Это заметно сокращает объём работ на старте и, соответственно, стоимость первого этапа проекта.
Хороший пример — приложение оператора Lovit: переработанный интерфейс и чат-бот увеличили конверсию в покупку в 2 раза, а нагрузку на телефонную поддержку снизили в 3 раза. Такой результат получился не из огромного набора функций с самого начала, а из точного попадания в несколько ключевых изменений, напрямую влияющих на конверсию, — остальные доработки пришли позже, уже на основе данных о реальном поведении пользователей приложения.
MVP не означает урезанное качество или недоделанный продукт — это полноценно спроектированная, продуманная и протестированная система, просто с осознанно меньшим набором функций на старте. Мы закладываем архитектуру так, чтобы после проверки гипотезы систему можно было расширять, а не переписывать заново, — иначе экономия на старте обернётся двойными расходами на этапе роста.
Для METRO C&C такой подход сработал буквально: первый релиз приложения вышел через месяц после старта работ, а за первый месяц его скачали более 270 000 раз. Быстрый и недорогой первый релиз позволил собрать данные о поведении пользователей и уже на этих данных развивать программу лояльности «Метрополия», в которой сегодня больше 100 000 участников.
Когда MVP не подходит, а когда экономит больше всего
MVP особенно выгоден, когда вы не до конца уверены в востребованности продукта в целом или отдельной его функции у вашей аудитории. Для клиники МЕДИ мы разработали решения, которые увеличили число обращений в 1,5 раза, а повторных обращений — в 2 раза, включая видеоконсультации — функцию, которую сначала имело смысл проверить на ограниченной аудитории, прежде чем встраивать в основной продукт как обязательную часть сервиса и тратить бюджет на её масштабирование сразу на всех клиентов.
Подход становится менее выгодным, когда задача изначально небольшая, понятная и не содержит спорных гипотез — тогда выделять MVP из уже простого проекта не имеет смысла, это только добавит этапов согласования без реальной экономии — небольшой проект и так по сути является минимально необходимой версией. Также MVP не заменяет полноценную аналитику: даже минимальную версию нужно спроектировать осознанно, иначе на доработку уйдёт больше времени, чем если бы систему сразу продумали чуть более полно. Мы честно предупреждаем об этом на брифинге, если видим, что заказчик рассчитывает через MVP просто сэкономить, не понимая, что часть работы по анализу задачи и проектированию всё равно придётся сделать заранее, ещё до старта программирования.
Обычно MVP делаем по модели Fixed Price — с зафиксированным набором функций и сроком, — а дальнейшее развитие продукта ведём по Time & Materials или Retainer, когда список доработок формируется уже по фактическим данным использования, а не по предположениям, которые были на старте проекта.
Стоимость MVP: из чего складывается
Бюджет MVP складывается из тех же составляющих, что и бюджет полной системы, — только в существенно меньшем объёме: часы аналитика, UX/UI-дизайнера, разработчиков и тестировщика, необходимые для реализации выбранного, тщательно продуманного минимального набора функций. Разница в том, что на входе мы сознательно ограничиваем количество экранов, ролей пользователей и интеграций, оставляя только критичные для проверки гипотезы, а не пытаемся заранее предугадать все возможные сценарии использования продукта.
Иногда дополнительная экономия достигается ещё и выбором технологии: кроссплатформенная разработка на Flutter позволяет выпустить MVP сразу на iOS и Android из одной кодовой базы — это дешевле, чем вести две отдельные нативные команды на этапе, когда продукт ещё не подтвердил свою востребованность и лишние расходы неоправданны. Если гипотеза подтвердится и потребуется максимальная скорость работы или доступ к специфическим функциям устройства, часть модулей позже можно перевести на нативную разработку — Swift для iOS и Kotlin для Android.
Для программного продукта MVP экономит бюджет не за счёт урезания качества, а за счёт того, что часть функций откладывается до момента, когда станет понятно, что они действительно нужны. Прайса на сайте нет и не будет: стоимость MVP и дальнейшего развития системы считаем под задачу. Заполните форму заявки на сайте — в ней есть поле для описания задачи и вложение файла до 50 Мб, — либо пришлите бриф или техническое задание на info@mendev.ru, если оно уже готово. На брифинге поможем определить состав MVP под вашу задачу и дадим оценку сроков и стоимости разработки ПО. Расскажите на брифинге, какую гипотезу должен проверить продукт, — это поможет точнее определить состав первой версии и не закладывать в бюджет функции, которые понадобятся позже.
