{"id":14262,"url":"\/distributions\/14262\/click?bit=1&hash=8ff33b918bfe3f5206b0198c93dd25bdafcdc76b2eaa61d9664863bd76247e56","title":"\u041f\u0440\u0435\u0434\u043b\u043e\u0436\u0438\u0442\u0435 \u041c\u043e\u0441\u043a\u0432\u0435 \u0438\u043d\u043d\u043e\u0432\u0430\u0446\u0438\u044e \u0438 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u0435 \u0434\u043e 1,5 \u043c\u043b\u043d \u0440\u0443\u0431\u043b\u0435\u0439","buttonText":"\u041f\u043e\u0434\u0440\u043e\u0431\u043d\u0435\u0435","imageUuid":"726c984a-5b07-5c75-81f7-6664571134e6"}

Минимально жизнеспособный продукт

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

Как построить автомобиль, начав со скейтборда?

Итак, давайте всё-таки начнём с банальностей, чтобы прийти к общему знаменателю. MVP – это минимально жизнеспособный продукт, запускающийся в начале стартапа. Часто к нам за разработкой приложения обращаются клиенты, которые хотят сделать сразу крупное приложение с кучей функционала, уверенные в своей идее. Уверенность - это круто, но, чтобы не было потом мучительно больно, стараемся убеждать, что начинать нужно с MVP. Пусть он будет страшным, с бедным функционалом, но MVP должен хорошо воспроизводить ключевой бизнес-процесс, чтобы проверить есть ли на него спрос. Если есть, то, уже после первого теста спроса, можно обвешивать проект улучшениями.

В интернете легко гуглится вот такая зарисовка пути развития стартапа. Давайте её и возьмём за пример.

Доска на колесах

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

Ключевая особенность MVP состоит в том, что вы не можете сразу сделать автомобиль, а начинаете с чего-то малого, потому что ограничены в ресурсах. Представляете, если Вы построите автомобильный завод, наймёте несколько десятков тысяч работников, а клиенты захотят ездить на лошадях? По мере подтверждения идеи, мы улучшаем продукт, чтобы в конечном итоге получился «удобный и сверхскоростной автомобиль».

Проверка идеи

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

Так, например, и с приложениями стартапов. Вместо того, чтобы сделать дешёвый "тест идеи", люди вкладываются в дизайн, кучу вторичных функций, делают версии под Windows Mobile и ещё более редкие платформы, убеждая себя, что чем скрупулёзнее подойти к вопросу на старте, тем больше шансов на успех. Забывая при этом, что, по сути, играют в угадайку - получится угадать что нужно пользователям или нет. А вместо того, чтобы угадывать нужно сделать минимальный продукт и идти тестировать деньгами.

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

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

Автомобиль – это средство передвижения?

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

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

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

Ну, а если, Вы придёте к мнению, что автомобиль - это всё-таки роскошь, то придёте к производству кареты обшитой золотом :)

0
27 комментариев
Написать комментарий...
Тёма Томилин

Всё же, скейтборд, мне кажется, не может являться MVP автомобиля. Суть MVP скорее в этой картинке:

Ответить
Развернуть ветку
Mike Espoo

Проблема в том, что примеры с автомобилями вообще не подходят для описания MVP, но именно их пытаются приводит в качестве примера потому что наглядно.

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Почему? Мне кажется всё как раз очень показательно.

Ответить
Развернуть ветку
Тёма Томилин

Мне кажется, проблема кроется в неописанных пользовательских сценариях и бизнес-требованиях. "Я хочу передвигаться быстрее, чем пешком" - этого недостаточно. Если мы пойдем по такому пути и сделаем скейт, то на выходе с большой вероятностью получим такой ответ заказчика: "Это - ̶г̶о̶в̶н̶о̶ не то, что я хотел".

Ответить
Развернуть ветку
Денис Гордиенко
Автор

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

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Тёма Томилин

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

Ответить
Развернуть ветку
Vasily Afanasyev

Скромная статья про такой серьезный вопрос.

Ответить
Развернуть ветку
Mihail

Для совсем новичка самое то, я примерно так же клиентам и стажерам объясняю, а для остальных она вообще не нужна, тк количество нюансов зашкаливает

Ответить
Развернуть ветку
Денис Гордиенко
Автор

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

Ответить
Развернуть ветку
Alexander Bazarkin

Роль MVP относительно полного продукта наглядно объясняет сравнение с прототипом. Принципиальная разница между ним - одна: MVP можно продавать, а прототип - нет.

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Хорошо сказано

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Денис Гордиенко
Автор

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

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Denis Kiselev

Не уверен в термине «жизнеспособный» для MVP. Ценный? Минимально возможный продукт?)

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Жизнеспособный имеется ввиду тот, который полностью обеспечивает единственный бизнес-процесс.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Daniil Khanin

MVP это не продукт, и даже не часть будущего продукта. Задача MVP проверить гипотезы спроса, потом его надо уничтожать и делать уже нормальный продукт. Аля apple 2 и Macintosh. Но это очень грубый пример.

Ответить
Развернуть ветку
Вася Бездомный

"Программисты занимаются вечным улучшением кода"- очень смелое заявление, проверять его я, конечно, не буду

Ответить
Развернуть ветку
Денис Гордиенко
Автор

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

Ответить
Развернуть ветку
Igor Kowalski

Вот так и рождается халтура и всякое говно с низким качеством.

Ответить
Развернуть ветку
Mike Espoo

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

Когда делается MVP то куча плюсов
а) Опыт многих компаний показывает, что у таких проектов в ~5+ раз больше шансов по сравнению с not MVP.
б) Гораздо меньший чек входа на рынок.
в) Есть возможность начать получать фин отдачу раньше.
г) Есть возможности для маневра, чтобы исправить архитектуру и возможно сменить направление развития, фокус продукта и т.д.

Одним существенным минусом является, что конкуренты узнав о Вашем продукте, могут начать копать в этом направлении.

Ответить
Развернуть ветку
Денис Гордиенко
Автор

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

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Вам, конечно же, виднее

Ответить
Развернуть ветку
Igor Kowalski

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

Ответить
Развернуть ветку
Sergey K

Но эта статья не для потребителей, а для "производителей". Согласен, с точки зрения потребителя - это дикость, но потребительский подход совершенно не совместим с реализацией каких-либо проектов и с бизнесом вообще.

Вообще даже с точки зрения потребителя я думаю не всё так плохо, т.к. редкий проект оказывается на рынке на стадии mvp.

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Дебилы есть во всех отраслях. Вы просто написали ультимативно про подход, мол MVP - это говно с низким качеством. Я с этим не согласен.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Dmitry Bushkov

Возможно, если в аббревиатуре MVP заменить Product на Prototype, в мире будет меньше бессмысленных споров.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Денис Гордиенко
Автор

Если представить, что в мире есть только бензопилы, то создание ручной пилы - это возможность дать человеку распилить бревно заплатив 500р, а не 10 000р. Если я пилю брёвна пару раз в год, то это экономия затрат.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Dmitry Bushkov

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

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку
24 комментария
Раскрывать всегда