Почему надо начинать разработку с MVP
Раньше у нас подход к разработке был такой: «клиент всегда прав, раз платит значит мы будем делать», и мы не сильно отговаривали или останавливали клиентов в их хотелках. Относились к проекту не как к продукту, которым будут пользоваться люди, а как к списку задач, которые надо реализовать, и чем их больше, тем лучше, чем сложнее, тем круче, чем дольше, тем богаче. В итоге многие стартапы закрывались, потому что количество хотелок разрасталось с геометрической прогрессией, и среди них терялись по-настоящему важные вещи, разработка выходила очень дорогой, а продукт не оправдывал ожидания. Это НЕПРАВИЛЬНЫЙ подход, и мы больше так не делаем.
Несколько лет назад пришел к нам клиент и хотел сделать новую социальную сеть, у него был бюджет, на который он планировал разработать проект и запустить его. Человек горел проектом, у него было много идей, и каждую неделю он генерировал дюжину новых.
Всю техническую документацию по проекту разрабатывал сам и в процессе разработки постоянно вносил новые правки. Хотел сразу выпустить «идеальный продукт», который бы полностью соответствовал его ожиданиям.
Из-за всех изменений разработка проекта затянулась на полтора года, у клиента закончились деньги, и проект пришлось заморозить. Через 6 месяцев он вернулся с новой порцией идей и денег. Мы еще полгода разрабатывали мобильное приложение и добавляли новый функционал, который был нужен разве только самому заказчику и его друзьям, так как никакой аналитики он не проводил, бета-версию не запускал, гипотезы не проверял.
В итоге он потратил все деньги, проект так и не увидел свет, а клиент получил большие проблемы с инвесторами, потому что потратил их деньги, но так и не запустил проект. А мы не получили хороший проект в наше портфолио.
Если бы заказчик следовал концепции «бережливого стартапа», создавал бы MVP и тестировал гипотезы, а не старался сделать «идеальный продукт», то скорее всего этот проект бы жил и имел свою аудиторию.
Сегодня на этапе согласования проекта и сроков мы объясняем клиенту главный принцип MVP, помогаем с выбором гипотез, формируем список задач, которые необходимо реализовать в первую очередь, и объясняем, почему мы ограничиваем хотелки, тем самым помогая клиенту сделать качественный и нужный продукт, которым будут пользоваться люди.
Я думаю, у многих были похожие случаи, когда клиент приходит с какой-нибудь безумной идей и говорит: «Мне нужен супер сайт, чтобы он сразу держал как минимум 1 миллион запросов в секунду, я собираюсь презентовать его на ближайшей IT конференции и планирую, что после презентации, будет 5 миллионов пользователей, потому что все захотят его использовать». И разрабочики начинают придумывать highload-архитектуру, настраивают шарды, реплики, покупают мощные сервера, а после конференции у чувака в базе оказывается всего 100 человек, и нагрузка 20 запросов в секунду в пике. Итог: потрачена куча времени и денег, а проект через месяц закрывается, так как оказался никому не нужным.
Итак, что же такое MVP?
MVP (minimum viable product, иногда ошибочно расшифровывается как minimum valuable product или minimal valuable product) — это минимально жизнеспособный продукт, который позволяет получить осмысленную обратную связь от пользователей, понять, что им нужно, и не создавать то, что им неинтересно и за что они не готовы платить и не будут использовать.
Смысл данной концепции в том, что идея проекта — это гипотеза. Вы предполагаете, что данный товар, сервис или услуга будут востребованы, и вам необходимо это проверить. Для этого необходимо следовать алгоритму:
Надо понимать, что MVP — это не сырой продукт, сделанный в спешке, или продукт, который недоделан, а это продукт или даже процесс, содержащий только основные функции, которые необходимо проверить на реальных пользователях.
Когда вы собираетесь делать продукт или сервис, у вас изначально много предположений. Вы думаете, что вы знаете, чего хотят пользователи, что они ищут, каким должен быть дизайн, какую маркетинговую стратегию использовать, какая архитектура будет наиболее эффективной, как монетизировать продукт. Но это не так! Неважно, насколько вы хорошо все продумали, всё равно некоторые гипотезы окажутся ошибочными, а без анализа не будете знать, какие именно.
Поэтому не нужно пытаться делать в первом релизе все фичи, которые приходят в вашу голову. Может оказаться, что большая часть из них будет не востребована, а вы потратили время и деньги на реализацию.
Концепция MVP позволяет сократить время запуска проекта за счет создания только необходимых функций и начать получать реальный фидбек по своему продукту.
Вывод
Если вы делаете стартап или создаете приложение, обязательно тестируйте свои гипотезы, умеряйте свой пыл в добавлении новых фич.
Если вам делают проект на заказ и команда бездумно соглашается на все ваши хотелки (даже на самые идиотские), увольняйте их сразу, не ждите, пока они потратят все ваши деньги.
Если вы делаете проекты на заказ, помогайте клиенту выбирать нужные гипотезы, относитесь к проекту как к продукту, которым будут пользоваться реальные люди, постарайтесь помочь ему создать хорошее приложение, которое не умрет в течение полугода, а если и умрет (не все идеи хорошие), то вы сэкономите кучу времени и денег клиенту. Поверьте, люди это оценят.
Антон Репьев, технический директор Lodoss Team
