3 ошибки при создании MVP
Итак, ваша блестящая идея полностью изменит представления клиентов и компаний. Прекрасно! Однако время, когда инвесторы были готовы выписывать чеки за голую идею, минуло безвозвратно.
Сегодня инвесторы предпочитают вкладывать средства в уже опробованные решения, а не спонсировать маркетинговые исследования. Поэтому наиболее оптимальным решением для стартапа программного продукта, как для рядовых пользователей, так и для корпоративных клиентов, будет создание продукта с минимальным функционалом (MVP - Minimal Viable Product).
Как показали исследования, проведенные агентством CB Insights, нехватка средств не является наиболее распространенной (хоть и существенной) причиной неудач новых проектов. Невостребованность на рынке – главная причина провалов. Данный факт еще раз подчеркивает важность проведения полноценного маркетингового исследования в рамках любого проекта.
О целях, выборе правильного времени и ценности создания MVP сказано достаточно. Автор статьи убежден, что, прежде всего, создание MVP направлено на генерирование идей, проверку предположений и минимизацию рисков.
Безусловно, вопрос о том, как подходить к созданию MVP, открывает широкий простор для дебатов, но после того, как вы определились с главным направлением, следует уяснить для себя основные факторы, которые окажут самое существенное влияние на конечный успех.
Приведем три самых распространенных ошибки, которые следует избегать:
1. Неукомплектованная команда
Как правило, если авторами проекта являются программисты и разработчики, они сбалансировано подходят к вопросу своей компетенции и ценности предложения, на которых основан MVP. Однако молодым талантливым программистам следует помнить, что нежелательно делать ставку на непроверенную идею, которая, к тому же, может быть не их собственной.
Практика показывает, что количество предпринимателей, не обладающих достаточными познаниями в предметной области и ищущих знающих партнеров, преобладает.
Если у вас нет опыта в программировании и дизайне, и нет команды для создания MVP, вопрос нахождения партнера, готового предоставить техническую поддержку, является первостепенным.
Хорошая команда, способная решать поставленные задачи, не только увеличивает шансы на успех, но и позволяет вам сфокусироваться на других аспектах бизнеса.
Представление о том, что для создания успешного MVP требуется только программист и дизайнер графики, является заблуждением. MVP ничем не отличается от разработки любого программного продукта – для этого требуются специалисты в области пользовательского интерфейса, верстальщики веб-страниц, специалисты в области серверных приложений, системные администраторы, специалисты по контролю качества и менеджеры проекта.
Рекомендуем: MVPM: менеджер по минимальному жизнеспособному продукту
Специалистов широкого профиля, в должной степени обладающих всем набором данных навыков, практически, не существует.
В идеале время на разработку MVP составляет несколько месяцев (некоторые говорят, что не более 90 дней), и на всех стадиях разработки существует много отправных точек, которые потребуют слаженной работы всей команды.
Независимо от того, являетесь ли вы прозорливым бизнесменом, в состоянии самостоятельно собрать слаженную команду, или вам необходим для этого партнер, ключевым элементом успеха в создании MVP является наличие грамотных специалистов, способных решать любые задачи на всех стадиях разработки.
Рекомендуем: Почему вам нужен MVP? Или как не потратить месяцы и годы решая надуманную проблему
2.Промашки на стадии создания прототипа
Создание прототипа является важнейшим этапом всего процесса разработки программного продукта, способным дать очень многое, и которым не следует пренебрегать. Вдумчивое планирование и создание реалистичных моделей поможет вдохнуть жизнь в ваш проект, снизить риски и избавиться от неопределенности.
Основные направления для создания прототипов MVP:
Архитектура интерфейса – построение основной структуры, а также описание принципов обмена данными в вашем приложении.
Примерный прототип – грубый макет, включающий в себя некоторые интерактивные элементы и описывающий информационную архитектуру приложения.
Точный прототип – включает высококачественные изображения и большое количество интерактивных элементов, позволяющих осуществлять навигацию по приложению.
Создание дизайна – к этому моменту собраны и учтены все замечания и пожелания. Чтобы упростить переход к стадии разработки, уже на стадии построения прототипа можно продумать, какие графические элементы вы будете использовать.
Рекомендуем: 9 принципов lean-подхода для разработки UX
Выбирая различные элементы для включения в прототип вашего продукта – это почти как выбирать леденцы в кондитерской.
Однако следует помнить, что прототип создается совсем не для того, чтобы уже сейчас сделать из вашего продукта картинку; основная задача – это увязать все планируемые функции и опции с предпочтениями конечного пользователя.
Задумайтесь, каким образом каждая деталь влияет на удовлетворенность пользователя от использования программного продукта. Решение должно быть основано на анализе впечатлений и отзывов первых клиентов, а также маркетинговых исследованиях, с учетом поставленных целей. Самый верный способом провалить стадию создания прототипа – это снабдить его не тем функционалом.
Вот, чего следует избегать на стадии построения прототипа MVP:
Дополнительные эффекты и опции – речь идет о незначительных вещах, которые добавляют привлекательности, но не имеют реальной значимости для MVP, например, интеграция с социальными сетями.
«Хочу, как у всех» – несомненно, анализ конкурентов важен, однако не стоит добавлять к своему продукту какую-то функцию, только потому, что это сделал кто-то еще. Когда речь идет об MVP, действовать с оглядкой на «того парня» - не самый лучший подход. Это может обернуться потерей времени и сил, поэтому необходимо, прежде всего, сконцентрироваться на поставленных целях.
По запросу – не смотря на то, что основной смысл MVP – это учет мнения пользователей, добавление каждой детали или функции, которые пожелали видеть первые пользователи, может стать ошибкой. В данном вопросе следует опираться на вдумчивый анализ, а не на мгновенный порыв.
3.Неправильный выбор метода разработки
Как и любое другое программное обеспечение, MVP может разрабатываться двумя способами – гибкий и каскадный. О преимуществах и недостатках каждого из этих методов сказано много.
Исследования консалтинговой фирмы Ambysoft, проведенные в 2013 году показали, что гибкий метод разработки приводит к успеху в 64% случаев, тогда как каскадный метод – только в 49% случаев. Что касается MVP, автор статьи убежден, что гибкий метод значительно превосходит каскадный метод, как по качеству, так и по срокам исполнения.
В случае если для разработки программного продукта вы привлекли партнера, еще стоит задуматься о способе оплаты его услуг – будет ли это почасовая оплата, либо фиксированная сумма.
Как правило, водопадный метод подразумевает фиксированную стоимость разработки, тогда как при использовании гибкого метода применяется почасовая оплата.
На первый взгляд влияние способа оплаты на MVP кажется неочевидным, но, так же как и в случае подрядчика-строителя, это может сильно повлиять на отношения в команде, и на итоговый результат.
Перечислим основные преимущества гибкого метода разработки и почасовой оплаты, применительно к MVP:
Прозрачность: данный метод позволяет лучше понимать, насколько быстро продвигаются дела, сколько времени потрачено, и каковы результаты.
Гибкость: программисты могут использовать прогрессивный подход в своей работе. Гибкость является непременным условием при разработке программного обеспечения, а возможность быстро поменять направление работы в случае необходимости, очень важна для общего успеха MVP.
Скорость: разработчикам не приходится тратить много времени на планирование, чтобы избежать рисков, поэтому они могут быстро приступать к работе над проектом. Сдача продукта происходит частями, как правило, каждые две недели, поэтому процесс проверки и тестирования результатов упрощен. Это позволяет быстро проверить все рабочие функции и собрать необходимые отзывы, ускоряя процесс сдачи готового проекта.
Сегодня совет начать с разработки MVP можно дать многим стартапам. Это позволяет провести тщательное планирование и выявить подводные камни, значительно повысив шансы на успех не только пилотного проекта, но и всей идеи конкретного продукты и бизнеса в целом.
Последний совет: не отказывайтесь быстро от своей идеи. Целью создания MVP и построения прототипа является тестирование, сбор отзывов, анализ, усовершенствование и повторное тестирование. Данный цикл может занять какое-то время, прежде чем вы получите желаемый результат.
