Главное Свежее Вакансии Образование
Выбор редакции:
1 099 6 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Почему надо начинать разработку с MVP

Уже много статей написано про MVP, но люди все равно наступают на грабли «идеального продукта» при создании проектов. Я не хочу писать очередную учебную статью, а хочу поделиться полученным опытом на примере реального кейса, а также рассказать, как мы изменили свой подход к разработке проектов.

Раньше у нас подход к разработке был такой: «клиент всегда прав, раз платит значит мы будем делать», и мы не сильно отговаривали или останавливали клиентов в их хотелках. Относились к проекту не как к продукту, которым будут пользоваться люди, а как к списку задач, которые надо реализовать, и чем их больше, тем лучше, чем сложнее, тем круче, чем дольше, тем богаче. В итоге многие стартапы закрывались, потому что количество хотелок разрасталось с геометрической прогрессией, и среди них терялись по-настоящему важные вещи, разработка выходила очень дорогой, а продукт не оправдывал ожидания. Это НЕПРАВИЛЬНЫЙ подход, и мы больше так не делаем.

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

Всю техническую документацию по проекту разрабатывал сам и в процессе разработки постоянно вносил новые правки. Хотел сразу выпустить «идеальный продукт», который бы полностью соответствовал его ожиданиям.

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

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

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

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

Я думаю, у многих были похожие случаи, когда клиент приходит с какой-нибудь безумной идей и говорит: «Мне нужен супер сайт, чтобы он сразу держал как минимум 1 миллион запросов в секунду, я собираюсь презентовать его на ближайшей IT конференции и планирую, что после презентации, будет 5 миллионов пользователей, потому что все захотят его использовать». И разрабочики начинают придумывать highload-архитектуру, настраивают шарды, реплики, покупают мощные сервера, а после конференции у чувака в базе оказывается всего 100 человек, и нагрузка 20 запросов в секунду в пике. Итог: потрачена куча времени и денег, а проект через месяц закрывается, так как оказался никому не нужным.

Итак, что же такое MVP?

MVP (minimum viable product, иногда ошибочно расшифровывается как minimum valuable product или minimal valuable product) — это минимально жизнеспособный продукт, который позволяет получить осмысленную обратную связь от пользователей, понять, что им нужно, и не создавать то, что им неинтересно и за что они не готовы платить и не будут использовать.

Смысл данной концепции в том, что идея проекта — это гипотеза. Вы предполагаете, что данный товар, сервис или услуга будут востребованы, и вам необходимо это проверить. Для этого необходимо следовать алгоритму:

b_5ad5ab425e082.jpg

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

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

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

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

b_5ad5ab67ce05c.jpg

Вывод

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

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

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

Антон Репьев, технический директор Lodoss Team

+6
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Pavel Baly
спасибо за статью
Ответить
Бидюков Денис
Так это надо ещё ведь постараться доказать свою точку зрения. Проблема-то в том, что кругом полно дебилов, которые пишут всякую хрень. Я помню как мне в качестве аргумента против SEO привели видео какого-то хрена, который утверждает что SEO - это прошлый век. И бесполезно что-то доказывать.
Ответить
Lodoss Team
Мы создаем мобильные и веб-приложения для высоконагруженных систем
rootlodoss 91305
Денис, аргументировано доказывать свою точку зрения - один из главных скилов при общении с клиентом )
Ответить
Бидюков Денис
Да кто ж спорит-то... Только мне попадались и попадаются такие кадры, которым важны не аргументы, а тупо «пузомерки». Недавно общался с мадам одной. Спрашивает мол а какое у вас образование, отвечаю мол 9 классов. На что получаю что-то типа: нам нужен исполнитель с высшим образованием... Вот сейчас мы ждем человека, с Франции должен вернуться, он для БМ делал сайт, знаете такого? Нет, не знаю, я изучаю в большей степени новости индустрии, а не то, кто кому делает сайты. Занавес. Какие на... аргументы?

Конечно я могу сказать что работал с Ростехом, РАНХиГС, участвовал в организации авиашоу МАКС, МАТФ 2018 и многое другое. Ну это же не правда, хотя косвенно я имею отношение ко всем этим организациям и ивентам. Вот и задумаешься над тем, что бы бросить к черту эту бесполезную честность, от неё все равно никакого проку. Честным вообще быть невыгодно..
Ответить
Бидюков Денис
На резонный вопрос типа кто этот хрен, ты получаешь резонный вопрос а кто ты такой. Вот и встает вопрос реализации своих проектов, а когда проект становится успешным, то уже и клиентура не сильно-то нужна )))
Ответить
EasyGuide
Платформа для путешественников и гидов
Easy_Guide 89081
Хорошая статья! Поэтому мы и начали с MVP
Ответить
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.