Подготовка к Mini App начинается не с макетов и не с выбора технологии. Сначала компания должна определить бизнес-задачу, путь пользователя, источник данных и процесс после целевого действия. Иначе разработка автоматизирует неопределённость и перенесёт внутренние проблемы в новый интерфейс.
Этот чек-лист поможет подготовить вводные для пилота и сократить количество изменений уже во время разработки.
1. Сформулируйте бизнес-задачу
Формулировка «нам нужно мини-приложение в MAX» описывает канал, но не результат. Рабочая задача должна отвечать на три вопроса:
- какое действие выполняет пользователь;
- что меняется в процессе компании;
- по какой метрике оценивается запуск.
Пример слабой постановки: «сделать приложение для клиентов».
Пример рабочей постановки: «дать клиенту возможность выбрать услугу и желаемое время, передавать заявку администратору со всеми параметрами и сократить количество уточняющих звонков».
Для первого запуска лучше выбрать один приоритет: заявка, запись, заказ, поддержка, подбор или личный кабинет.
2. Опишите текущий процесс
До проектирования зафиксируйте, как задача решается сейчас:
- Откуда приходит клиент?
- Какие вопросы ему задаёт сотрудник?
- Где проверяются цены, расписание или наличие?
- В какую систему заносятся данные?
- Кто принимает решение и отвечает клиенту?
- Какие исключения возникают?
- Где чаще всего теряются обращения?
Полезно пройти реальный сценарий вместе с сотрудником, а не ограничиваться регламентом. Фактический процесс часто отличается от описанного: данные дублируются в таблицах, статусы передаются в чатах, а часть решений держится на знаниях одного человека.
3. Спроектируйте целевой путь пользователя
Целевой путь должен быть короче текущего и заканчиваться понятным результатом. Для каждого шага укажите:
- что видит пользователь;
- какое действие выполняет;
- какие данные вводит;
- что проверяет backend;
- какое состояние считается успешным;
- что происходит при ошибке.
Не копируйте структуру сайта. В Mini App пользователь приходит с более конкретным намерением, поэтому первый экран должен сразу предлагать целевое действие.
4. Определите состав первой версии
Разделите функции на три группы:
Обязательно для пилота
Без этих функций невозможно проверить ключевую гипотезу. Например, выбор услуги, отправка контакта и передача заявки менеджеру.
Полезно после подтверждения
Функции улучшают процесс, но не обязательны для первого запуска: личный кабинет, бонусы, сложные фильтры, история действий.
Не входит в текущий сценарий
Идеи, которые не связаны с основной задачей. Их нужно сохранить в backlog, а не включать в разработку автоматически.
Такой приоритет защищает пилот от бесконечного расширения.
5. Подготовьте данные
Интерфейс зависит от качества данных. Определите источник для каждого объекта:
- каталог и категории;
- цены и тарифы;
- расписание;
- сотрудники и филиалы;
- остатки;
- статусы заявок и заказов;
- клиентские данные;
- документы и материалы.
Для каждого источника укажите владельца, частоту обновления и способ доступа. Если данные ведутся в нескольких системах, выберите основную до интеграции.
6. Проверьте доступность интеграций
Составьте карту систем, с которыми должен взаимодействовать MAX:
| Система | Что передаём из MAX | Что получаем обратно |
|---|---|---|
| CRM | Контакт, лид, источник, комментарий | Ответственный и статус |
| 1С или ERP | Заказ, клиент, состав | Цены, остатки, номер и статус |
| Расписание | Услуга, специалист, запрос слота | Свободное время и подтверждение |
| Helpdesk | Тема и описание обращения | Номер, приоритет и статус |
Проверьте API, права, тестовый контур, лимиты и владельца системы. Фраза «интеграция с 1С» недостаточна: важны конфигурация, версия, доработки и доступный механизм обмена.
7. Назначьте владельцев процесса
Минимально нужны три роли:
- бизнес-владелец, принимающий решения о сценарии;
- операционный ответственный, знающий реальный процесс;
- технический контакт по системам и доступам.
Также определите, кто обрабатывает обращения после запуска, кто следит за контентом и кто принимает инциденты. Без этой ответственности Mini App может корректно собирать заявки, но не создавать ценность.
8. Подготовьте контент и состояния
Понадобятся:
- название и описание бота;
- логотип;
- тексты кнопок и подсказок;
- карточки товаров или услуг;
- уведомления об успехе;
- сообщения об ошибке;
- пустые состояния;
- контакты поддержки;
- правила отмены, оплаты или возврата.
Отдельно подготовьте тексты для нестандартных ситуаций: нет свободного времени, товар закончился, внешняя система недоступна, заявка уже создана.
9. Проверьте юридические требования
Компания отвечает за содержание приложения и законность обработки пользовательских данных. Нужно определить:
- какие персональные данные собираются;
- на каком основании они обрабатываются;
- где и сколько хранятся;
- кому передаются;
- как пользователь может отозвать согласие или запросить удаление;
- нужны ли пользовательское соглашение, политика конфиденциальности и оферта;
- кто является оператором данных.
Правила MAX требуют соблюдения законодательства и возлагают ответственность за приложение на разработчика или владельца сервиса: правила размещения приложений.
Юридические тексты следует готовить под фактический сценарий, а не копировать без проверки из другого проекта.
10. Задайте аналитику до разработки
Для каждого этапа определите событие:
- источник перехода;
- запуск бота;
- открытие Mini App;
- начало сценария;
- выбор ключевого параметра;
- отправка формы;
- успешная запись в CRM или другую систему;
- ошибка;
- ответ сотрудника;
- повторное использование.
Целевая метрика должна отражать бизнес-результат. Например, «подтверждённая запись», а не только «нажатие кнопки».
11. Определите требования к поддержке
Ещё до запуска договоритесь:
- кто принимает сообщения об ошибках;
- какое время реакции допустимо;
- как обновляются данные и контент;
- кто следит за внешними API;
- где хранятся логи;
- как выполняется резервное копирование;
- кто продлевает инфраструктуру и домены;
- как выпускаются обновления.
Mini App зависит от MAX, хостинга и внешних систем, поэтому отсутствие владельца поддержки создаёт операционный риск.
12. Подготовьте тестовый план
Тестировать нужно не только интерфейс, но и полный процесс:
- новый пользователь;
- повторный пользователь;
- неверные данные;
- отсутствие вариантов;
- двойная отправка;
- закрытие приложения на середине;
- медленное соединение;
- недоступная CRM или 1С;
- повторное событие от MAX;
- действия сотрудника после заявки.
Перед открытием широкой аудитории проведите закрытый пилот на сотрудниках и небольшой группе клиентов.
Что передать разработчику
Качественный стартовый пакет включает:
- Описание задачи и метрики.
- Схему текущего и целевого процесса.
- Состав первой версии.
- Список экранов и состояний.
- Источники данных.
- Перечень интеграций и документацию API.
- Роли и ответственных.
- Юридические тексты.
- Контент и бренд-материалы.
- План аналитики и приёмки.
Не обязательно превращать это в формальное техническое задание на сотни страниц. Важнее, чтобы решения были согласованы и не противоречили реальному процессу.
Частые вопросы
Нужно ли полностью описывать продукт до старта?
Нет. Для пилота достаточно подробно описать основной сценарий, данные, интеграции и критерии приёмки. Остальные функции можно развивать итерационно.
Кто должен быть владельцем проекта со стороны бизнеса?
Человек, который может принимать решения о процессе и доступен команде разработки. Если все вопросы проходят через нескольких посредников, сроки и качество согласований ухудшаются.
Можно ли начать без CRM?
Да, если поток небольшой и назначен ответственный за ручную обработку. Но способ передачи заявок и контроль статусов всё равно нужно определить заранее.
Нужен ли отдельный дизайн?
Да, если сценарий выходит за рамки готового шаблона. Интерфейс должен учитывать MAX UI, мобильные состояния и конкретный путь клиента.
Когда подключать аналитику?
До разработки основных экранов. События и идентификаторы источников являются частью архитектуры, а не дополнением после запуска.