Назад

Гайд по разработке MVP для крупного бизнеса

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

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

Время чтения: 9 минут

Содержание

Главное

  • Во время работы над MVP крупным компаниям стоит избегать «перенасыщения» MVP функциями, сохранять общий дух и стиль бренда и следить за тем, чтобы новый продукт не вредил существующим процессам.
  • Оптимальный вариант разработки MVP — сотрудничество с аутсорс-компанией. Выбирайте подрядчиков с надежным портфолио, подходящей тактикой коммуникации, достаточным количеством ресурсов и бережливым подходом.
  • Процесс разработки MVP состоит из UI/UX дизайна, веб-разработки и тестирования. После запуска продукта анализируйте отзывы и на их основе дорабатывайте продукт.

MVP для крупного бизнеса: как это вообще возможно

Термин «минимально жизнеспособный продукт» обычно используют применительно к стартапам. Концепция MVP действительно оказалась в центре внимания после публикации книги Эрика Риса «Бизнес с нуля. Метод Lean Startup». Это своего рода библия бережливого управления проектами и продуктами.

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

Минимально жизнеспособный продукт — это версия продукта с набором базовых функций, которую выпускают для привлечения аудитории.  Он может быть простым, но обязательно должен приносить пользу.
UBER then and now

Uber — хрестоматийный пример MVP. Когда-то он был выпущен только для заказа такси в Сан-Франциско через iPhone. Теперь это крупный агрегатор для частных перевозок и доставке

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

Допустим, сотрудник в вашей логистической компании разработал план по «прокачке» корпоративной CRM. Идея звучит интересно, но проверить ее востребованность хочется без особых затрат. Желательно быстро и наверняка. Именно в этом и помогает MVP.

Проблемы при создании MVP для крупных компаний

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

Проблема № 1. Страх новизны 

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

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

Начните с малого, например, с проверки концепции (Proof of concept). Это один из способов наглядно продемонстрировать гипотезу стейкхолдерам. Читайте подробнее о том, что такое PoC

Проблема № 2. Привычка делать все и сразу  

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

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

ЧИТАЙТЕ ТАКЖЕ  User Story Mapping и не только: методы отбора функций для MVP

Проблема № 3. Опасения за имидж бренда

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

Google Glass

К счастью, Google Glass запустили как MVP и провал стоил компании не так дорого, как могло быть в случае с полноценным продуктом

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

Проблема № 4. Совмещение с основным продуктом

Любая разработка продукта, даже если речь о проверке концепции, требует внимания и сил как минимум одного человека. При этом менеджерам нужно уследить за существующим продуктом и сделать так, чтобы его качество не пострадало.

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

Примеры успешных MVP

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

Twitter

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

Twitter тогда и сейчас

Изначально Twitter разработали, чтобы сотрудникам Odeo было проще общаться друг с другом

Через некоторого время Odeo канула в Лету, а вот Twitter набрал обороты. Если верить сервису Statista, к 2022 году ежемесячное число активных пользователей мессенджера перевалило за 368 миллионов.

Twitter тогда и сейчас

Теперь интерфейс Twitter выглядит вот так

Slack

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

Приложение Слак

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

В 2020 году общая стоимость приложения оценивалась в $27 млрд.

iZumator

Чтобы вы не подумали, что MVP — вариант для мастодонтов бизнеса, приведем пример из своей практики. Несколько лет назад мы сотрудничали с сетью магазинов мобильных телефонов iZum. Они обратились к нам за разработкой обучающей платформы для сотрудников. Для них мы создали iZumator.

iZumator работает так: студенты регистрируются или авторизуются, составляют расписание занятий, проходят курсы и могут даже разработать авторский тренинг

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

Как бизнесу выбрать партнера для разработки MVP 

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

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

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

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

✅Проведите исследование рынка и познакомьтесь с его главными игроками. Можете попросить рекомендации у знакомых предпринимателей, у которых есть опыт сотрудничества с подрядчиками.

✅«Погуглите» имя потенциального партнера, соберите досье в блогах и соцсетях. Обязательно изучите отзывы о работе, например, на  Clutch. Так вы убережете себя от работы с неоднозначными личностями и заранее узнаете, какие идеи, подходы и методы транслирует команда.

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

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

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

✅Не принимайте решения, потому что вам обещают сделать очень быстро или дешево. Хорошую работу не делают за три копейки в течение 3 дней. Соотношение цены и качества должно быть разумным.

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

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

Как крупному бизнесу запустить MVP

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

Шаг 1: Сформулируйте идею и проведите исследование

🎯 Основная цель: разработать концепцию, подходящую для рынка

Перед тем как непосредственно начать разработку, надо точно очертить концепцию продукта. Это подготовительный этап, когда вы формулируете свое предложение для пользователя. Здесь важно сделать 4 вещи.

Исследование аудитории. Если вы уже давно развиваете бизнес, то должны хорошо знать, на кого ориентируетесь. Однако перед запуском стоит провести более глубокий анализ актуальности продукта, опросить аудиторию и понаблюдать за ее поведением. Еще полезно изучить Google Trends — там можно увидеть, какие запросы интересуют пользователей.

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

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

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

Шаг 2: Расставьте приоритеты

🎯Основная цель: четкий список функций, которые расставлены в порядке важности

Цель разработки MVP — запустить базовую версию продукта. У зрелого бизнеса с этим бывает сложно из-за привычки работать с полнофункциональными решениями.

Советуем начать проект с составления матрицы приоритетов. Она учитывает следующие параметры:

  • усилия — сколько времени/денег/внимания понадобится для добавления функции?
  • значимость — какую пользу получит бизнес/целевая аудитория от функции?
  • риск — насколько сложно внедрить функцию?

Сначала вы отвечаете на вопросы, а затем рисуете график. В зависимости от ответов функции попадают в области «Обязательно», «Желательно», «Возможно», «Бессмысленно».

Пример матрицы

  • Усилий мало, риск высокий, значимость высокая — Обязательно
  • Усилий мало, риск низкий, значимость низкая — Возможно
  • Усилий много, риск высокий, значимость высокая — Желательно
  • Усилий много, риск высокий, значимость низкая — Бессмысленно

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

Шаг 3: Проектирование UI/UX

🎯Основная цель: разработка дизайн-макетов

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

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

Дизайн не заканчивается на выборе цветовых схем и красивых деталек. Еще одна важная задача на этом этапе — продумать качественную архитектуру и UX (опыт пользователя). Пользовательский путь должен быть естественным, без барьеров и сложностей, чтобы не отпугивать аудиторию. Его удобно визуализировать с помощью майндмэпа, который охватывает все стадии взаимодействия с продуктом. От онбординга до выполнения ключевого действия.

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

Майндмэп — полезная вещь, потому что четко показывает возможные сценарии, которые проходят пользователи в вашем приложении или на сайте. На основе этих знаний дизайнер создает прототипы. Это предварительная версия, где дается общее представление о композиции элементов и их положении в интерфейсе. После утверждения прототипов можно переходить к макетам. Сначала команда создает один макет с визуальной концепцией и отправляет его на согласование. Затем отрисовывает остальные: для каждого экрана и состояния.

Шаг 4: Разработка и тестирование

🎯 Главная цель: готовый продукт

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

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

Наш личный выбор — JavaScript. Этот язык используют миллионы разработчиков в мире, они дорабатывают, развивают и улучшают его технологии. JS-фреймворки можно использовать как для создания мобильных, так и десктопных сайтов и приложений. Для мобильной разработки  мы используем React Native, который позволяет выпускать продукт сразу на iOS и Android. Это удобно в контексте MVP.

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

ЧИТАЙТЕ ТАКЖЕ  Как выбрать стек технологий для MVP

Шаг 5: Релиз и анализ отзывов

🎯Основная цель: релиз и анализ отзывов

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

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

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

Вот несколько советов о том, что вы можете предпринять после релиза:

  • заново изучить целевую аудиторию, выяснить, удалось ли охватить нужных пользователей и стоит ли изменить стратегию;
  • выбрать то, что необходимо улучшить в первую очередь, а какие аспекты могут подождать до следующей итерации;
  • ответить на главный вопрос разработки продукта: «Могу ли я монетизировать это? Принесет ли это деньги?». Ведь ради этого все и затевалось.
ЧИТАЙТЕ ТАКЖЕ  Маркетинг для MVP: что делать, если MVP готов?

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

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

Этап Время Примерная стоимость
Оценка проекта 8 часов 0 ₽
Анализ проекта, включая приоритезацию функций 1 неделя 61 000 ₽
UI/UX дизайн 4 недели 330 000 ₽
Разработка 9 – 10 недель 2 300 000 ₽
QA Параллельно с разработкой 330 000 – 360 000 ₽
Менеджмент проекта На протяжении всего проекта 240 000 ₽
Всего 3 – 4 месяца Примерно 3 400 000 ₽

Заключение

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

Если у вас есть идея, мы можем создать уникальный MVP. Purrweb — это 190 специалистов и 8-летний опыт разработки более 300 проектов. Свяжитесь с нами, чтобы получить бесплатную оценку вашего проекта.

Насколько публикация полезна?

Оцени эту статью!

1 оценок, среднее 5 из 5.

Оценок пока нет. Поставьте оценку первым.

Так как вы нашли эту публикацию полезной...

Подписывайтесь на нас в соцсетях!

Share