MVP на low-code платформе: как собрать за неделю и что делать, когда он выстрелит

Про сборку MVP на платформе пишут все. Разбираем вторую половину вопроса — что происходит с таким MVP, когда гипотеза подтвердилась.

Коротко

MVP — не урезанная версия продукта, а способ получить ответ на один вопрос за минимальные деньги.
Внутреннему сервису MVP нужен не меньше, чем стартапу: проверить процесс на одном отделе дешевле, чем разворачивать его на всю компанию.
На low-code за неделю собирается заявочный сервис, реестр, кабинет и маршрут согласования. Не собирается нагрузка, свой алгоритм и уникальный интерфейс.
Даже в MVP обязательны роли, обработка отказов и место для данных — без них проверяется не гипотеза, а терпение сотрудников.
Сценариев после успешного MVP три, и выбирать между ними надо до сборки, а не после.

Что такое MVP и чем он отличается от прототипа и POC

MVP — минимальная версия продукта, которой уже можно пользоваться. Смысл не в том, чтобы сделать «то же, но поменьше», а в том, чтобы получить ответ на один конкретный вопрос, затратив минимум. Вопрос формулируется до сборки и звучит проверяемо. Станут ли дилеры оформлять заказы сами. Сократится ли срок согласования, если убрать двух согласующих. Будут ли монтажники отмечать выполнение с телефона.

Рядом живут два похожих понятия, и путаница между ними стоит денег.

Прототип отвечает на вопрос «как это будет выглядеть». Он может быть нерабочим — достаточно, чтобы по нему можно было провести разговор. Прототип не собирают из настоящих данных и не отдают пользователям.

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

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

Проверка на понимание. Если результат нельзя дать человеку в работу, это прототип. Если можно, но никто не собирается смотреть на метрику, это просто маленькая система.

Зачем MVP внутреннему сервису, а не только стартапу

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

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

MVP внутреннего сервиса устроен просто. Берём один отдел, один процесс и одну метрику. Собираем минимальный контур, отдаём людям, смотрим три недели. За это время становится видно то, чего не покажет ни один опрос — какие поля не заполняют, какие шаги пропускают, где возвращаются к почте.

Экономика тоже понятная. Ошибка в требованиях, найденная на одном отделе, стоит переделки одного контура. Та же ошибка, найденная после внедрения на всю компанию, стоит переделки и потерянного доверия к системе.

Четыре пути собрать MVP

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

Путь	Срок до работающего контура	Что нужно от вас	Что остаётся после MVP
Своя команда разработки	Месяцы, если команда занята — не начнётся вовсе	Постановка задачи и приоритет выше текущих продуктов	Код, который надо развивать и поддерживать
Подрядчик или фрилансер	Недели и месяцы	ТЗ, приёмка, бюджет на итерации	Код и договорённости о доработках
Конструктор своими руками	Недели	Сотрудник, который освоит платформу	Приложение в платформе и один обученный человек
Сборка ассистентом на платформе	Дни и недели	Описание процесса словами или ЧТЗ	Приложение в платформе, готовое к развитию

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

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

ЧЕТВЁРТЫЙ ПУТЬ

Приложение из описания процесса

Nolan — ИИ-ассистент, который собирает приложение на low-code платформе. Он не заменяет платформу, а работает поверх неё.

Вы описываете процесс словами или загружаете ЧТЗ. Ассистент переводит описание на объектный язык платформы — сущности, поля, роли, экраны, маршруты — и собирает приложение из компонентов, которые в платформе уже есть и уже работают. Дальше правки вносятся в чате.

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

заявочные сервисы, реестры, кабинеты и маршруты согласований
правки в чате без нового релиза
заявленный эффект — в 10–50 раз меньше трудозатрат на типовое решение

Что собирается на low-code за неделю

Реалистичный список того, что укладывается в короткий срок. «Неделя» здесь означает срок до момента, когда приложением можно пользоваться, без учёта согласований внутри компании.

Что собираем	Что входит в MVP	Что оставляем на потом
Заявочный сервис	Форма, один маршрут согласования, статусы, уведомления	Пороги сумм, эскалация, отчётность
Реестр или справочник	Структура, фильтры, права на просмотр, выгрузка	Версионирование записей, история изменений
Кабинет контрагента	Вход, свои документы и статусы, обращение	Данные из учётной системы в реальном времени
Маршрут согласования	Прямой путь с двумя-тремя участниками	Ветвление по данным, замещение на время отпуска
Внутренний портал	Единая точка входа, новости, ссылки на сервисы	Персонализация, интеграция с каталогом пользователей

Общий принцип отбора. В MVP входит то, без чего процесс не пройдёт ни разу. Всё, что делает процесс удобнее или закрывает редкий случай, ждёт подтверждения гипотезы.

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

Чего на low-code не собрать

Границу полезно знать до старта, иначе неделя превратится в месяц выяснения, почему не получается.

Нагрузку. Если в требованиях появилось число — столько-то запросов в секунду, столько-то миллионов записей — разговор про платформы можно не начинать.
Свой алгоритм. Расчёт, который и есть ценность продукта, платформа не воспроизведёт без кода. В low-code его дописывают, в no-code он невозможен.
Уникальный интерфейс. Всё, за что пользователь платит вниманием, — анимации, сложные визуализации, нестандартная навигация.
Публичный продукт с обязательствами. Требования к отклику и доступности, записанные в договоре с клиентами.
Мобильное приложение в магазинах. Возможность собрать и опубликовать приложение для стора определяется платформой, и это стоит уточнять до старта, а не в середине недели.

Если задача попадает хотя бы в один пункт, MVP всё равно можно сделать — но проверять на нём надо процессную часть — техническую он не закроет.

Где именно проходит потолок платформы — в разборе low-code и no-code.

Как описать MVP, чтобы его можно было собрать

Описание — единственная работа, которую нельзя ни делегировать, ни ускорить. Хорошее задание на MVP короткое и состоит из пяти частей.

Вопрос гипотезы. Одно предложение о том, что мы хотим узнать. Без него MVP превращается в маленькую систему без критерия успеха.
Сущности и связи. Что за объекты живут в процессе и как они друг с другом соотносятся. Заявка принадлежит сотруднику, сотрудник относится к подразделению, у подразделения есть руководитель.
Роли и что каждая видит. Три роли для MVP обычно достаточно. Важно не забыть про того, кто видит всё, — иначе некому будет разбирать спорные случаи.
Маршрут по шагам, включая отказ. Отказ и возврат на доработку пропускают чаще всего, а происходят они с первого дня.
Что считаем успехом. Метрика и её текущее значение. Если текущего значения нет, первым делом замеряем его, иначе сравнивать будет не с чем.

Полезное упражнение перед сборкой — пересказать это описание вслух человеку, который процессом не занимается. Места, где приходится добавлять «ну, там ещё бывает, что», и есть пропущенные ветви сценария.

Что обязательно должно быть даже в MVP

Соблазн выбросить всё, что не относится к главному пути, велик, и на трёх вещах экономить нельзя. Иначе вы проверите не гипотезу, а терпение сотрудников.

Роли и права. Даже в контуре на один отдел кто-то не должен видеть чужие данные. Без прав MVP невозможно отдать людям, а значит, невозможно и проверить гипотезу.

Обработка отказов. Что увидит пользователь, если обязательное поле пустое, если файл не загрузился, если смежная система не ответила. Приложение, которое падает молча, люди бросают за два дня и обратно уже не возвращаются.

Место для данных. Хотя бы понимание, где данные лежат, кто имеет к ним доступ и что будет, если MVP решат закрыть. Забрать данные из закрытого приложения потом — отдельная работа, о которой лучше подумать сразу.

Три вещи, которые в MVP не нужны и почти всегда туда попадают. Красивый дизайн, потому что на этапе гипотезы важна работоспособность. Отчёты, потому что отчитываться пока нечем. Интеграция со всем сразу — достаточно одной, самой критичной.

Кто ведёт MVP внутри компании

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

Владелец гипотезы. Человек из бизнеса, которому нужен ответ. Он формулирует вопрос, принимает результат и объясняет сотрудникам, зачем это. Если владельца нет и MVP ведёт ИТ, эксперимент превращается в демонстрацию технологии — люди попробуют из вежливости и вернутся к прежнему способу.

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

Пилотный отдел. Люди, которые будут пользоваться. Их выбирают не по лояльности, а по типичности процесса — эксперимент на самом продвинутом отделе даёт красивую картинку и бесполезный вывод.

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

Практика, которая ускоряет всё это. Договоритесь о рамке эксперимента одной страницей — вопрос, отдел, срок, метрика, что делаем при положительном и отрицательном ответе. Такая страница снимает половину будущих споров, потому что решение о судьбе MVP принято заранее.

Как проверять гипотезу: какие метрики снимать

MVP без замера — это просто маленькая система. Замер устроен из двух частей, и первая часть делается до сборки.

Метрика	Как замерить до MVP	Что смотреть после
Доля работы через новый контур	Сколько случаев сейчас идёт через почту и мессенджеры	Сколько ушло в приложение за три недели
Время цикла	Календарный срок от начала до результата, по десяти последним случаям	Тот же срок на случаях в приложении
Возвраты и переделки	Сколько случаев из ста уходит на доработку	Изменилась ли доля
Отказ от инструмента	—	Сколько людей перестали заходить после первой недели
Обходные пути	Какие обходные пути есть сейчас	Появились ли новые вокруг приложения

Две последние строки важнее первых трёх и почти никогда не замеряются. Люди, тихо вернувшиеся к прежнему способу работы, и новые обходные пути — самый честный сигнал о том, что гипотеза не подтвердилась, даже если формальные цифры выглядят прилично.

Про срок наблюдения. Три недели — разумный минимум. Первая уходит на привыкание, и судить по ней нельзя; со второй начинается реальная картина.

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

MVP выстрелил: три сценария развития

Ядро вопроса, и решать его надо до сборки. От выбранного сценария зависит, на чём собирать MVP.

Сценарий	Когда выбирают	Что делают	Чем платят
Развивать на платформе	Процессная задача, нагрузка предсказуема, требования будут меняться	Достраивают контур модулями, оставляют в той же среде	Потолком платформы
Переписать под задачу	Появились требования к нагрузке, свой алгоритм или уникальный интерфейс	Пишут систему заново, MVP работает как подробное ТЗ	Сроком и бюджетом полноценной разработки
Оставить как есть	Гипотеза подтвердилась, но объём работы небольшой	Ничего не меняют, приложение просто живёт	Ограничениями, которые уже известны

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

Третий сценарий выбирают чаще, чем ожидают, и это нормальный итог. Значительная часть внутренних задач закрывается контуром, который собрали за неделю, и наращивать его незачем.

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

ЧТО ОСТАЁТСЯ У ВАС

MVP не запирается в конструкторе

Главный страх при сборке MVP на платформе звучит так — гипотеза подтвердится, а результат окажется в тупике. У Nolan цикл сборки не односторонний: по собранному приложению формируется итоговое ТЗ и документация на его функциональность, и дальше разработку ведут по этому описанию. Поэтому все три сценария развития остаются открытыми.

Отдельно про то, что MVP редко остаётся собой. Требования меняются с первой недели использования, и правка формы, роли или шага маршрута вносится в чате, без нового релиза. Для этапа проверки гипотезы это главное — успеть изменить контур, пока интерес к вопросу не остыл.

три сценария развития открыты после проверки гипотезы
итоговое ТЗ и документация на собранное приложение

MVP не выстрелил: как закрыть правильно

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

Что стоит сделать при закрытии.

Записать, что именно не сработало. Люди не пользовались, процесс не ускорился, выяснилось, что узкое место в другом месте. Через полгода этот вывод спасёт от повторного захода на ту же задачу.
Забрать данные. Даже в неудачном контуре осталась картина того, как процесс идёт на самом деле.
Сохранить описание. Постановка задачи, сделанная для MVP, годится для следующей попытки и для разговора с подрядчиком.
Сказать людям, что эксперимент закрыт. Сотрудники, которых попросили попробовать и не сообщили результат, в следующий раз не придут.

Отдельный сюжет — когда гипотеза не подтвердилась из-за инструмента, при том что идея верная. Это видно по обратной связи. Люди говорят «идея правильная, но неудобно» и называют конкретные места. Тогда закрывать надо не задачу, а способ.

Можно ли забрать собранное: что проверить у платформы

Вопрос стоит задавать до выбора платформы, потому что стоимость выхода определяется в момент входа. Четыре вещи, которые надо выяснить.

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

Ни один ответ сам по себе не дисквалифицирует платформу. Отказ отвечать — дисквалифицирует.

Сроки и из чего складывается стоимость

Срок MVP на платформе измеряется днями и неделями, и главный риск для срока лежит не в сборке. Он в согласованиях внутри компании — доступ к тестовым данным, разрешение подключить один отдел, договорённость с ИТ о размещении. Эту часть стоит начинать одновременно со сборкой.

Стоимость складывается из четырёх составляющих, и сравнивать пути имеет смысл по всем четырём.

Лицензия платформы. Модель важнее суммы, потому что она определяет расходы при росте числа пользователей.
Сборка. Своими силами, силами вендора или ассистентом — разница в разы.
Время своих людей. Описание процесса, приёмка, объяснение сотрудникам. Эта часть не исчезает ни на одном пути.
Развитие после MVP. Стоимость типовой правки, умноженная на то, сколько раз в год у вас меняются процессы.

Ошибка сравнения, которая встречается чаще всего, — считать только вторую строку. Дешёвая сборка, после которой каждое изменение требует внешнего специалиста, обходится дороже, чем сборка подороже с правками внутри компании.

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

Типичные ошибки MVP

MVP без вопроса. Собрали «минимальную версию системы», критерия успеха нет, решение о развитии принимается на ощущениях.
MVP на всю компанию. Взяли пять отделов сразу, чтобы «сразу увидеть картину». Получили проект, а не эксперимент, и потеряли право на ошибку.
MVP без пользователей. Собрали и показали руководству. Гипотеза о том, будут ли люди этим пользоваться, осталась непроверенной.
Отчёты в первой версии. Половина срока ушла на аналитику процесса, который ещё ни разу не прошёл.
Идеальный дизайн. Неделя на согласование внешнего вида контура, который может быть закрыт через месяц.
Забыли замерить «до». Самая обидная ошибка. Гипотеза подтвердилась, а доказать это нечем, потому что исходных значений никто не зафиксировал.

Читайте также

Покажем Nolan на вашем процессе

Свяжемся в течение одного рабочего дня. Без спама.

Опишите задачу — мы разберём ваш процесс и подготовим демо-приложение на его основе

Вы оставляете заявку и кратко описываете задачу

Мы разбираем процесс или ЧТЗ

Показываем демо работающего приложения

Наши продукты:

Программа для ЭВМ «Nolan»

Программа для ЭВМ «CDP.Light»

Программа для ЭВМ «Корпоративный портал»

Компания «Технологии возврата»

3 года занимается разработкой и развитием ИИ

Из описания — в готовое приложение

Войти в Nolan

Политика конфиденциальности

Наш корпоративный блог

Согласие на обработку пепрсональных данных