Разработка MVP
Разработка MVP это работающая версия продукта малым объёмом, собранная ради одного: проверить спрос на живых людях, а не в презентации. Дешевле выяснить за несколько недель, что гипотеза не работает, чем через год полноценной разработки.
MVP это не урезанный продукт и не дешёвая версия хорошего. Это самая короткая работающая цепочка, которая отвечает на один главный вопрос. Обычно вопрос звучит так: станут ли люди этим пользоваться и заплатят ли. Всё, что не помогает получить ответ, из первой версии убирается, даже если оно очевидно понадобится позже.
Отсечение лишнего и есть основная работа. Заказчик обычно приходит со списком из тридцати функций, и каждая кажется обязательной. Мы разбираем, какая из них проверяет гипотезу, а какая просто откладывает момент истины. Обычно из тридцати остаётся пять, и это самая полезная часть проекта.
Ответ, который приносит MVP, бывает и отрицательным, и такой ответ мы тоже отдаём. Он неприятный, но стоит одну небольшую версию продукта, а не год разработки и запуск, которого никто не ждал. Иногда результат оказывается третьим: гипотеза не подтвердилась, зато на разговорах с людьми нашлась другая. Так появился SignItNow. Мы вели техническую часть рекламной кампании вместе с директором по маркетингу заказчика, разговаривали с предпринимателями, и из этих разговоров выяснилось, что заверить документ и подписать документ это разные потребности, а вторую никто не закрывает. Продукт вырос отсюда, а не из чужой гипотезы.
И отдельно про качество. Слово «минимальный» относится к объёму, а не к тому, как написан код. Мы не делаем MVP, который придётся выбросить целиком: архитектура закладывается так, чтобы удачную версию можно было развивать дальше. Если какую-то часть мы сознательно пишем на выброс ради скорости, мы говорим об этом заранее и объясняем, чем это обернётся при развитии.
Перед MVP разумно собрать прототип: он дешевле и снимает часть вопросов до разработки. Дальше в дело идут дизайн, веб-разработка или мобильное приложение и бэкенд, а когда первая версия подтвердит спрос, продукт превращается в полноценный онлайн-сервис. Если вопрос ещё шире и звучит как «стоит ли вообще этим заниматься», начните с бизнес-консалтинга.
Что входит в услугу
Можно взять любой набор из перечисленного.
Что именно мы проверяем, на ком и по каким признакам поймём, что ответ получен. Без этого MVP превращается в просто маленький продукт.
Какие сценарии входят в первую версию, а какие нет. Спорные функции откладываем письменно, чтобы к ним можно было вернуться.
Ключевые экраны кликабельно, потом оформление. На этом этапе часто отваливается ещё пара функций.
Фронтенд, серверная часть, интеграции и всё, без чего сценарий не работает целиком.
Выкатываем на реальных пользователей, смотрим поведение, собираем обратную связь и метрики.
Разбор результата и честный ответ: развивать, переделывать или закрывать. Плюс оценка следующего шага.
Как мы работаем
Что проверяем, на ком, какими цифрами меряем успех.
Состав первой версии, что откладываем, оценка по этапам.
Кликабельная версия и оформление ключевых экранов.
Двухнедельные итерации с демонстрацией, каждую можно открыть и пройти сценарием.
Реальные пользователи, наблюдение, метрики, решение о следующем шаге.
Стек и инструменты
Кейсы по услуге
Частые вопросы
За прототипом нет кода, это связанные экраны для проверки логики и удобства. MVP это работающий продукт с серверной частью и реальными данными, на котором проверяют спрос и деньги.
Дешёвая версия делает всё то же самое, только хуже. MVP делает мало, но полностью, и отвечает на конкретный вопрос. Это разные вещи, и путать их дорого.
Зависит от того, сколько сценариев входит в первую версию и нужна ли своя серверная часть. Оценку даём по этапам после разбора гипотезы, и там же видно, за что именно вы платите.
Тогда вы узнаете об этом за недели и за небольшие деньги. Это и есть цель. Мы отдаём отрицательный ответ прямо, а не предлагаем доработать ещё немного.
Не целиком. Архитектуру закладываем так, чтобы удачную версию можно было развивать. Если часть кода пишется на выброс ради скорости, мы называем это до начала работ.
Всё определяет договор, и прописываем мы это на этапе технического задания, до начала работ. По ходу проекта команда работает либо на нашей инфраструктуре, либо на вашей: выбор зависит от сложности проекта и от того, есть ли у вас готовая инфраструктура. Каждый утверждённый этап переносится на ваши серверы и в ваш репозиторий, то есть работа накапливается у вас, а не у нас. После закрытия проекта весь код, наработки и документация передаются вам вместе с правами на них.
Да, отдельной договорённостью: дежурство, доработки и переход от первой версии к полноценному продукту.
Смежные услуги
Обсудим вашу задачу?
Расскажите, что нужно сделать - вернёмся с оценкой сроков, составом команды и планом первых двух недель.