Прототип приложения или MVP: что лучше сделать сначала

Четыре формата отвечают на четыре вопроса

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

Кликабельный прототип проверяет логику экранов

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

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

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

Технический эксперимент проверяет риск, который может остановить проект

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

До разработки запишите условие успеха. Фраза «попробовать ИИ» не помогает принять решение. Гораздо полезнее проверить, сможет ли система расшифровать две минуты речи на трех поддерживаемых телефонах за заданное время и без передачи медицинских данных в непроверенный сервис. Сохраните модели устройств, тестовые данные, скорость, стоимость и ошибки.

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

Ручной пилот показывает спрос и настоящую операционную работу

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

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

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

MVP — уже рабочий продукт, а не подробный макет

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

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

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

Что можно проверить с помощью ИИ за две недели

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

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

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

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

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

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

Не обещайте заранее, что ни одна строка не пропадет. Ценность прототипа — в знаниях. Отказаться от хрупкого кода, но сохранить правильный сценарий вполне нормально.

Как выбрать формат по шагам

1. Назовите предположение, из-за которого весь проект может потерять смысл.
2. Если люди не понимают сценарий, проверьте кликабельный прототип.
3. Если под вопросом технология, проведите ограниченный измеримый эксперимент.
4. Если неизвестны спрос, цена или процессы, окажите услугу вручную небольшой группе.
5. Когда сценарий, технология и операция понятны, опишите минимальный рабочий MVP.
6. Заранее решите, какой результат означает продолжение, изменение или остановку.

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

Что подготовить для оценки разработки

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

В Appfyl мы предлагаем начать с прототипа, когда сценарий еще постоянно меняется. Технический эксперимент нужен, если проект зависит от сомнительной интеграции. Когда ядро уже понятно, можно планировать MVP на рабочей архитектуре. В статье о сроках разработки мобильного приложения мы отдельно рассматриваем быстрый прототип с ИИ, первую low-code-версию и более крупную индивидуальную разработку.

Заполнить основные данные можно в брифе Appfyl для оценки приложения. Перечислять все возможные функции не нужно. Гораздо полезнее честно описать, что пока остается непонятным.

Частые вопросы