Веб-приложение, мобильное приложение или бот: что выбрать для первой версии

Сначала опишите действие, а не экран

Фраза «нам нужно приложение» не является требованием. За ней могут скрываться регистрация на мероприятие, согласование заявки, учёт выездов, доставка уведомления или регулярная работа с каталогом. Запишите одну проверяемую формулировку: «пользователь из такого-то контекста должен выполнить действие за такое-то время и вернуться с такой-то частотой». Затем отделите обязательные свойства от желательных. Камера, работа без сети, системное уведомление и геопозиция — не украшения; если без них задача не выполняется, они влияют на форму клиента. Если же человек приходит из поиска, читает сложную информацию и делится ссылкой, мобильная установка может быть лишней преградой.

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

Матрица выбора по сценарию и бюджету

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

Как не превратить таблицу в голосование

Сначала заполните строку «обязательное доказательство». Например: человек должен приложить фотографию при отсутствии стабильной сети; менеджер должен открыть заявку на рабочем компьютере; клиент должен перейти из рекламного объявления без установки. Потом назначьте владельца проверки и дату. Формат «мне кажется, мобильное привычнее» не засчитывается. Формат «семь из десяти участников полевого теста не смогли завершить web-сценарий при пропадании связи» был бы доказательством, но такие числа можно использовать только после реального теста. До него строка остаётся гипотезой.

Три типовых сценария и разные ответы

Сценарий первый: небольшая B2B-служба согласует заявки, работает с длинными формами и пересылает ссылки коллегам. Первый контакт происходит по почте, большинство действий выполняется с ноутбука. Здесь web-клиент позволяет проверить процесс без установки и даёт общий адрес конкретной заявки. Мобильный клиент может появиться позже для уведомлений и быстрого подтверждения, но в первой версии он увеличит число поверхностей. До релиза полезно задать бюджет производительности, потому что тяжёлая форма на слабом устройстве способна разрушить преимущество web.

Сценарий второй: мастер фиксирует состояние оборудования в помещении без уверенного интернета, делает несколько фотографий и возвращается к черновику через час. Если полевой тест подтверждает эту среду, локальное хранение, синхронизация, обработка lifecycle и доступ к камере становятся частью основной ценности. Нативный мобильный клиент получает вес не потому, что «все пользуются телефоном», а потому, что обязательный сценарий зависит от поведения устройства. При этом backend, модель данных и правила конфликта синхронизации всё равно нужно проектировать отдельно от экрана.

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

Бюджет первой версии — это не только разработка

Сравнивайте варианты на одном горизонте: например, до решения «закрыть, продолжить или добавить второй канал». Для каждого варианта отдельно оцените исследование, дизайн, клиентскую разработку, backend, тестирование, аналитику, выпуск, поддержку пользователей, наблюдаемость, безопасность и удаление или перенос данных. Не подставляйте среднюю ставку из статьи: используйте доступность своей команды и подтверждённые предложения. Если значение неизвестно, оставьте диапазон и укажите событие, после которого он уточняется.

• Разовые затраты: прототип, архитектурный каркас, настройки публикации, миграция начальных данных и доступность.

• Повторяющиеся затраты: инфраструктура, обновления зависимостей, проверка новых версий OS или API, поддержка и мониторинг.

• Цена задержки: время до первого реального пользователя и ожидание review, если оно применимо.

• Цена второго канала: повторный UI, тесты, авторизация, аналитика и согласованность поведения.

• Цена выхода: экспорт данных, отключение интеграции, уведомление аудитории и перенос идентичности.

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

Добавьте к расчёту стоимость продуктовой обратной связи. Если bot-сценарий можно проверить вручную за несколько дней, а мобильный клиент потребует доступной сборки до первой сессии, разница во времени является частью эксперимента. Но быстрый канал полезен только тогда, когда проверяет то же поведение. Ручной оператор, который незаметно исправляет ошибки prototype, может создать ложное впечатление качества. Записывайте, какие действия выполняет система, какие — сотрудник за сценой и какие ограничения видит участник. После теста решите, выдержит ли выбранная форма следующий объём без скрытой ручной работы.

Как сохранить путь ко второй форме

Отделите доменные правила от первого клиента. Статусы заявки, права доступа, расчёты и журнал действий должны иметь единый серверный контракт. Web, мобильный экран или бот преобразуют ввод и показывают результат, но не хранят разные версии бизнес-правил. Это не призыв строить универсальную платформу заранее. Достаточно явно назвать границу, сохранить API-контракт и не привязывать пользовательский идентификатор только к одному мессенджеру. Так команда избегает двойной логики, не создавая абстракции для гипотетических каналов.

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

Семидневная проверка до полноценной разработки

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

2. День 2: заполните матрицу и пометьте каждое неизвестное как гипотезу, а не как факт.

3. День 3: соберите кликабельный или ручной прототип самого короткого сценария в двух оставшихся вариантах.

4. Дни 4–5: наблюдайте выполнение задачи представителями нужного сегмента; фиксируйте препятствия и контекст, не подсказывая маршрут.

5. День 6: оцените бюджет проверки, поддержки и выхода на одном горизонте.

6. День 7: выберите форму, запишите исключённые варианты, доказательства и дату пересмотра решения.

Ограничения и практический следующий шаг

Web-стандарты развиваются, магазины меняют правила, а API мессенджера добавляет и удаляет возможности. Перед релизом перепроверьте конкретные браузеры, версии OS, регион распространения и политику платформы. Матрица не подтверждает спрос, не оценивает юридические обязанности и не гарантирует одинаковое качество реализации. Она делает выбор проверяемым: команда видит, какой факт изменит решение и какую зависимость принимает.

Практический следующий шаг: сегодня напишите одно основное действие пользователя и заполните только три строки матрицы — первый вход, обязательная возможность устройства и цена выхода. Если хотя бы одна строка основана на мнении, назначьте короткий тест. Не начинайте отдельные web, iOS, Android и bot-проекты одновременно: выберите самый дешёвый канал, который способен честно проверить задачу, и зафиксируйте условие перехода к следующему.

Что читать дальше

• задать бюджет производительности

• проверить доступность интерфейса

• сравнить полную стоимость владения