Этапы запуска бота в MAX: от идеи до релиза

Запуск бота в MAX — это не «сел и написал», а последовательность этапов с предсказуемыми артефактами на выходе. Хороший процесс снимает 80% сюрпризов на сдаче, удерживает бюджет в рамках сметы и оставляет команде запас на доработки. В этой статье — как мы ведём проекты от первой встречи с заказчиком до полного запуска и эксплуатации, с длительностями, ролями, артефактами, точками принятия решений и типовыми рисками. Подойдёт продактам, владельцам бизнеса и тех-лидам, которые планируют разработку и хотят понять, во что они ввязываются.

MAX как платформа моложе Telegram, но процесс разработки строится по тем же канонам корпоративной поставки. Отличия — в API (в стадии активного развития), Mini App SDK, интеграциях с экосистемой VK Tech и пока ещё небольшом сообществе разработчиков, что увеличивает время на исследовательские задачи. Учтём это в сроках и буферах.

Этап 1. Discovery — понять, что вообще строим

Длительность: 1–2 недели. Команда: PM, Tech Lead, иногда UX-исследователь. Нанимать всю команду сразу не нужно — на этом этапе обходимся двумя людьми.

Что происходит на discovery:

• 2–4 интервью с заказчиком и ключевыми стейкхолдерами по 60–90 минут.
• 5–10 интервью с предполагаемыми пользователями (если бот для b2c) или ключевыми сотрудниками (если b2b/внутренний).
• Сбор JTBD: какую работу пользователь нанимает бота делать. Часто формулировки заказчика и реальные потребности расходятся на 30–50%.
• Анализ конкурентов: какие боты в MAX и Telegram уже решают похожие задачи, что в них сильно и слабо.
• Карта пользовательских историй верхнего уровня: 8–15 сценариев с триггерами, шагами и результатами.
• Решение по стеку: язык backend (Go/Python/Node), нужен ли Mini App, какие интеграции критичны.
• Бизнес-гипотезы: что мы хотим проверить запуском, какие метрики будем смотреть.

На выходе — бриф проекта на 6–12 страниц, верхнеуровневая оценка по этапам в человеко-неделях и денежная вилка с разбегом ±30%. На этом этапе ещё рано фиксировать цену под ключ — слишком много неизвестных.

Артефакты этапа: бриф, карта JTBD, сравнительный анализ конкурентов, предварительная архитектурная схема, оценка.

Gate review: заказчик подтверждает, что цели и сценарии описаны корректно, и принимает решение, идём ли в ТЗ.

Этап 2. ТЗ и дизайн — фиксируем периметр

Длительность: 2–4 недели. Команда: PM, Designer (если есть Mini App), Tech Lead, иногда системный аналитик на корпоративных проектах.

Из чего состоит этап:

• Полное ТЗ на 30–80 страниц: цели, сценарии, технические требования, безопасность, нагрузка, приёмка.
• Карта FSM: состояния, переходы, условия, тексты сообщений, кнопки, обработка ошибок и таймаутов.
• Если в проекте Mini App — прототипы в Figma на 15–40 экранов, дизайн-система, состояния (loading, empty, error).
• Архитектурная схема: сервисы, БД, очереди, внешние API, потоки данных.
• ER-диаграмма БД с ключевыми сущностями и связями.
• Список интеграций с указанием API-методов, частоты вызовов, объёмов данных.
• Нефункциональные требования: SLA, RPO/RTO, целевая нагрузка, требования к логированию и мониторингу.
• План тестирования: что покрываем unit, что integration, что e2e, что проверяем нагрузкой.

Этап заканчивается подписанием ТЗ и предоплатой 30–50%. Любые изменения после — через формальный change request с пересчётом сроков и бюджета.

Артефакты: ТЗ, прототипы Figma, FSM-карта, схема архитектуры, ER-диаграмма, план тестирования.

Gate review: заказчик подписывает ТЗ; команда подтверждает технологическую осуществимость и итоговую оценку с разбегом не больше ±15%.

Чек-лист готовности к этапу 3:

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

Этап 3. Разработка backend — сердце бота

Длительность: 4–12 недель. Команда: 1–3 backend-разработчика, DevOps на четверть ставки. На крупных проектах — отдельный архитектор или тимлид.

Что делается:

• Каркас приложения: структура проекта, конфиги, логирование, обработка ошибок, healthcheck.
• Реализация handlers всех команд и callback-ов из FSM.
• Подключение к API MAX: получение апдейтов (long-polling или webhook), отправка сообщений, работа с inline-клавиатурами и Mini App-кнопками.
• Машина состояний: хранение, переходы, восстановление после рестартов.
• Слой работы с БД: миграции, репозитории, транзакции.
• Сервисный слой: бизнес-логика отдельно от транспорта.
• Очереди для долгих задач (рассылки, генерация отчётов, синхронизация).
• Unit-тесты на критичную логику, integration-тесты на handlers.
• DevOps: Docker, CI/CD, dev/staging/prod окружения, секреты в Vault или аналоге.

Работаем спринтами по 1–2 недели. В конце каждого — демо заказчику с показом работающих кусков. Раз в неделю — апдейт по часам, оставшимся задачам, рискам.

Артефакты: работающий бот на staging, покрытие тестами от 60%, документация API, runbook для DevOps.

Параллельные потоки: дизайн Mini App (этап 4), подготовка интеграций со стороны заказчика (тестовые контуры CRM, 1С).

Типовые риски этапа:

• Изменения API MAX по ходу проекта (платформа молодая) — закладывайте буфер 10–15%.
• Недоступность тестовых контуров заказчика — блокирует половину работы по интеграциям.
• Расширение скоупа «по мелочи» — каждая мелочь добавляет 0.5–2 дня.

Этап 4. Mini App — если бот не только текстовый

Длительность: 2–6 недель, в параллель с этапом 3 или после него. Команда: 1–2 frontend-разработчика, дизайнер на полставки.

Этап нужен не всегда. Если функциональность укладывается в кнопки и формы — Mini App избыточен. Когда без него не обойтись:

• Каталог товаров с фильтрами и поиском.
• Личный кабинет с историей операций.
• Сложные формы на 10+ полей с валидацией.
• Интерактивные дашборды и отчёты.
• Платежи через встроенный SDK MAX.

Что делается:

• Дизайн-система: компоненты, токены, состояния.
• Frontend на React/Vue/Svelte (наш стек по умолчанию — React + TypeScript + Vite).
• Интеграция с MAX WebApp API: получение initData, валидация подписи на backend, тема и цветовая схема.
• API-слой к собственному backend (этап 3).
• E2E-тесты на ключевые сценарии.
• Адаптивная вёрстка под мобильный (основной кейс) и десктоп.

Артефакты: Mini App на staging-домене, документация фронта, e2e-тесты.

Подводные камни: валидация initData от MAX обязательна на каждом запросе — без неё уязвимость на подмену пользователя. Тестировать Mini App нужно в реальном приложении MAX, а не в браузере, потому что разница в поведении.

Этап 5. Интеграции — где утекает бюджет

Длительность: 2–8 недель. Команда: backend-разработчики этапа 3, иногда отдельный интегратор на 1С.

Самый непредсказуемый этап. На каждую интеграцию закладываем буфер:

• CRM (Битрикс24, AmoCRM): документация хорошая, риск +20%. Типичные задачи — создание лидов, обновление сделок, синхронизация контактов.
• 1С: документация плохая, инфраструктура у каждого заказчика своя, риск +50%. Часто требуется доработка обмена со стороны 1С-щика заказчика.
• Платежи (ЮKassa, Tinkoff, СБП): документация хорошая, но нужны юридические согласования и фискализация по 54-ФЗ. Риск +30%.
• Аналитика (Яндекс.Метрика, AppMetrica): относительно простая, риск +10%.
• SMS, email, push: провайдер на выбор, риск +15%.
• Внутренние API заказчика: риск зависит от качества документации, в среднем +40%.

Что делаем на этапе:

• Подключаем продакшн-эндпоинты вместо моков из этапа 3.
• Реализуем retry, idempotency, circuit breaker для внешних вызовов.
• Логируем каждый запрос-ответ к внешним системам — без этого расследовать инциденты невозможно.
• Согласовываем форматы данных с владельцами систем-партнёров.
• Тестируем edge cases: что происходит при таймауте 1С, при отказе платёжки, при отзыве согласия на ПДн.

Артефакты: работающие интеграции на staging, схемы потоков данных, runbook на каждую интеграцию (как поступать при сбоях).

Этап 6. QA и нагрузочное тестирование

Длительность: 1–3 недели. Команда: 1–2 QA-инженера, DevOps для нагрузочного, разработчики на исправлении багов.

Что прогоняем:

• Unit-тесты: покрытие критичной логики не ниже 70%, для бизнес-правил — 90%.
• Integration-тесты: взаимодействие компонентов, контракты с моками внешних API.
• E2E-тесты: ключевые сценарии целиком, в идеале — на отдельном MAX-боте.
• Smoke-тесты: короткий список критичных проверок для запуска после каждого деплоя.
• Регресс: тест-кейсы из ТЗ, прогоняются вручную или через автотесты.
• Нагрузочное: k6, Locust или Artillery. Целевая нагрузка из ТЗ × 2 как запас, проверка деградации.
• Security-аудит: SQL-инъекции, XSS в Mini App, валидация подписи MAX, защита от брутфорса.
• Тестирование на реальных пользователях: 5–10 человек проходят сценарии, мы записываем их сессии и собираем фидбек.

Все найденные баги категоризируются:

• P1 (блокеры): чинятся до релиза.
• P2 (важно): чинятся до конца этапа 8 или в первой неделе поддержки.
• P3 (косметика): уходят в бэклог, фиксятся по приоритету.

Артефакты: отчёт о тестировании, протокол нагрузочного, реестр известных дефектов с планом устранения.

Gate review: все P1 закрыты, P2 не больше согласованного лимита (обычно 5–10), нагрузочное прошло целевой профиль.

Этап 7. Pre-launch — юридическая и операционная готовность

Длительность: 1 неделя, в параллель с этапом 6. Команда: PM, юрист (внешний или внутренний), бухгалтер заказчика.

Что нужно подготовить до публичного запуска:

• Политика обработки персональных данных по 152-ФЗ. Если бот обрабатывает ПДн (а почти любой обрабатывает: имя, телефон, e-mail), политика обязательна.
• Согласие на обработку ПДн в первом сценарии — пользователь должен дать его до сбора данных.
• Уведомление в РКН об обработке ПДн — подаётся через сайт регулятора, рассмотрение до 30 дней.
• Уведомление о трансграничной передаче — если используете внешние сервисы (например, аналитика за пределами РФ).
• Оферта на услуги, если бот продаёт. Без неё вы не имеете права принимать оплату.
• Фискализация по 54-ФЗ: подключение онлайн-кассы для платежей. ЮKassa и Tinkoff умеют выписывать чеки автоматически.
• Реестр операций с ПДн внутри компании заказчика — формальный документ, нужен при проверке РКН.
• Регламент инцидентов: что делать при утечке, кому сообщать, в какие сроки уведомить РКН (72 часа по новой редакции 152-ФЗ).

Артефакты: все юридические документы выложены на лендинг и доступны из бота, поданы уведомления в РКН.

Чек-лист готовности к soft-launch:

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

Этап 8. Soft launch — канарейки и постепенный rollout

Длительность: 1–2 недели. Команда: вся команда на дежурстве + представители заказчика.

Логика канареечного запуска:

1. 5% аудитории в первый день. Обычно — внутренние пользователи компании заказчика и узкая фокус-группа.
2. Мониторинг 48–72 часа. Метрики: процент успешных сценариев, время отклика, ошибки backend, нагрузка на БД, обратная связь от пользователей.
3. Расширение до 25–50%, если P1-инцидентов нет, P2 — не более согласованного количества.
4. Ещё 48 часов мониторинга, проверка масштабирования.
5. 100% аудитории. Объявление о запуске в маркетинговых каналах.

На каждом шаге — короткий retro: что работает, где затыки, нужно ли откатывать. План отката должен быть готов до старта soft-launch: какой коммит, какая версия БД, как уведомить пользователей.

Что мониторим:

• Технические метрики: RPS, p50/p95/p99 latency, error rate, использование CPU/RAM/диска.
• Продуктовые метрики: завершённость воронок, время прохождения сценариев, доля переходов в поддержку.
• Бизнес-метрики: лиды, оплаты, конверсия из подписки в покупку.
• Юзер-фидбек: тикеты в поддержку, упоминания в социальных сетях, прямые сообщения.

Артефакты: отчёт о soft-launch, реестр инцидентов с реакцией, обновлённый бэклог P2/P3.

Этап 9. Полный запуск и поддержка

Длительность: постоянно. Команда: support-инженер на дежурстве, разработчики на минор-фичах и hotfix, PM на роадмапе.

Что входит в стандартный SLA поддержки:

• Мониторинг 24/7 с алертами в MAX/Telegram/PagerDuty.
• Реакция на инциденты по приоритетам: P1 — 30 минут, P2 — 4 часа, P3 — 1 рабочий день.
• Hotfix-цикл: обнаружение → диагностика → фикс → ревью → деплой. Целевое время на P1 — 2–4 часа.
• Ежемесячный апдейт зависимостей, патчи безопасности.
• Бэкапы и проверка восстановления — ежемесячно полный прогон recovery-сценария.
• Минор-фичи и улучшения через ежемесячные спринты или почасовку.
• Аналитика и продуктовые гипотезы: раз в квартал — ретроспектива и роадмап на следующий квартал.

Модели поддержки:

Параллельные потоки на протяжении проекта

Помимо технических этапов идут постоянные потоки, без которых запуск не состоится:

• Маркетинг: позиционирование, лендинг, описание бота, каталог в MAX, первые рекламные кампании. Стартует с этапа 5–6, активируется к этапу 8.
• Юридическое: документы, согласования с банком, фискализация. Идёт с этапа 2, кульминация — этап 7.
• Контент: тексты сообщений, FAQ, база знаний для поддержки, шаблоны рассылок. С этапа 3.
• Обучение поддержки заказчика: скрипты, передача знаний, доступ к админке. С этапа 7.
• Документация для разработчиков: README, runbooks, ADR. На протяжении всех этапов.

Стоимость по этапам — что закладывать в бюджет

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

Гибридная модель — Agile внутри waterfall

Этапы выглядят как классический waterfall, но внутри каждого этапа мы работаем спринтами. Это даёт предсказуемость крупных блоков и гибкость в рамках:

• На discovery — итеративные интервью с уточнением гипотез после каждой пары.
• На разработке — спринты по 1–2 недели с демо.
• На soft-launch — короткие циклы наблюдения и реакции.

Что не делается итеративно: ТЗ (нужна цельная картина), архитектура (нужна согласованность), юридическое (нужен законченный пакет).

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

Сроки срывают почти все проекты — вопрос на сколько и что с этим делать. Алгоритм действий:

1. Не скрывать. Чем раньше команда подняла руку, тем меньше ущерб. Запретить «дотянем как-нибудь».
2. Зафиксировать причину. Расширение скоупа? Технический долг? Внешние блокеры? Ошибка в оценке? Без диагностики не починить.
3. Пересчитать оставшийся объём. Реалистичная оценка того, что осталось, без героизма.
4. Предложить варианты заказчику: перенос даты, сокращение скоупа, добавление людей (помогает редко), компромиссы по качеству (опасно).
5. Зафиксировать решение письменно, обновить план, продолжать.

Типовые причины срывов в проектах MAX-ботов: непредсказуемые интеграции с 1С, изменения API платформы, медленные согласования со стороны заказчика, недооценка времени на тестирование Mini App.

Чек-лист готовности к каждому этапу

К этапу 3 (разработка):

• ТЗ подписано, прототипы согласованы.
• Доступы к репозиторию и серверам выданы.
• Контуры тестовых интеграций доступны.
• Команда подобрана и доступна в датах.

К этапу 5 (интеграции):

• Backend-ядро работает на staging.
• Документация на API партнёров получена.
• Тестовые аккаунты CRM, ЮKassa, 1С выданы.
• Контактные лица на стороне заказчика для каждой интеграции назначены.

К этапу 8 (soft-launch):

• Все P1 закрыты, P2 в согласованном лимите.
• Юридические документы опубликованы.
• Каналы поддержки настроены.
• План отката описан и согласован.

Что нужно от заказчика на каждом этапе

Если что-то из этого появляется в середине этапа, а не на старте — сроки сдвигаются.

Итого

Полный путь от идеи до бота в MAX в продакшене с поддержкой — девять этапов суммарно от 14 до 40 недель в зависимости от сложности. Для типового MVP без Mini App и сложных интеграций — 8–12 недель. Для корпоративного сервиса с 1С, Mini App и аналитикой — 24–40 недель. Главные условия предсказуемого срока: ответственный владелец продукта на стороне заказчика, заранее предоставленные доступы, реалистичный бюджет с резервом 10–15%, и команда, которая поднимает руку при первых признаках срыва, а не дотягивает в последний момент.

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

Сколько всего этапов в запуске бота MAX и сколько это занимает?+

Девять этапов. 1) Discovery 1–2 недели. 2) ТЗ и дизайн 2–4 недели. 3) Backend 4–12 недель. 4) Mini App 2–6 недель (если нужен). 5) Интеграции 2–8 недель. 6) QA и нагрузочное 1–3 недели. 7) Pre-launch 1 неделя. 8) Soft launch 1–2 недели. 9) Полный запуск и поддержка — постоянно. Общий срок зависит от сложности: типовой MVP без Mini App — 8–12 недель, корпоративный сервис с 1С и аналитикой — 24–40 недель. Часть этапов идёт в параллель, поэтому суммарная длительность меньше арифметической суммы.

Какая команда нужна на каждом этапе разработки бота MAX?+

На discovery — PM и Tech Lead, 2 человека. На ТЗ и дизайне — добавляется дизайнер (если есть Mini App) и иногда системный аналитик, 3–4 человека. На разработке backend — 1–3 backend-разработчика и DevOps на четверть ставки. На Mini App — 1–2 frontend-разработчика и дизайнер на полставки. На интеграциях — те же backend плюс интегратор на 1С при необходимости. На QA — 1–2 тестировщика. На pre-launch — PM и юрист. На soft-launch — вся команда на дежурстве. На поддержке — support-инженер и разработчики на минор-фичах. Пиковая численность команды на крупных проектах — 6–8 человек.

Что входит в этап pre-launch и зачем он нужен?+

Pre-launch — это юридическая и операционная подготовка к публичному запуску, обычно 1 неделя в параллель с финальным QA. Что готовится: политика обработки персональных данных по 152-ФЗ, согласие пользователя на обработку ПДн в первом сценарии бота, уведомление в РКН (рассматривается до 30 дней), уведомление о трансграничной передаче если используете внешние сервисы, оферта на услуги если бот продаёт, подключение онлайн-кассы по 54-ФЗ через ЮKassa или Tinkoff, реестр операций с ПДн, регламент реакции на инциденты с уведомлением РКН в 72 часа при утечке. Без этого этапа запускать бота с реальными пользователями нельзя — штрафы по 152-ФЗ доходят до 18 млн ₽ за повторное нарушение.

Что такое soft launch и зачем нужен канареечный rollout?+

Soft launch — это поэтапный запуск бота на ограниченную аудиторию с мониторингом перед открытием для всех. Логика: открываем 5% пользователей в первый день, обычно внутренние сотрудники компании-заказчика и узкая фокус-группа. Мониторим 48–72 часа: процент успешных сценариев, время отклика, ошибки, фидбек. Если P1-инцидентов нет, расширяем до 25–50%. Ещё 48 часов наблюдения с проверкой масштабирования. Если всё хорошо — открываем на 100%. План отката должен быть готов до старта. Канареечный rollout снижает радиус поражения от непойманных багов с 100% аудитории до 5% — критично для платных и корпоративных сервисов.

Какие интеграции дольше всего разрабатываются и почему?+

Самая непредсказуемая интеграция — 1С: документация плохая, инфраструктура у каждого заказчика своя, часто нужна доработка обмена со стороны 1С-программиста заказчика. Закладывайте буфер +50% к базовой оценке (типовая интеграция 10–20 дней превращается в 15–30). Вторая по сложности — внутренние API заказчика: качество сильно зависит от документации и зрелости IT, средний буфер +40%. Платежи (ЮKassa, Tinkoff, СБП) сами по себе быстрые (3–5 дней), но требуют юридических согласований и фискализации по 54-ФЗ — общий буфер +30%. CRM (AmoCRM, Битрикс24) и аналитика (Метрика, AppMetrica) предсказуемы — буфер 10–25%. SMS, email, push — самые быстрые, +15%.

Как мы работаем со срывами сроков и что делать заказчику?+

Сроки срывают почти все проекты — вопрос на сколько и как реагировать. Наш алгоритм: 1) Команда обязана поднять руку при первых признаках срыва, без скрытия. Чем раньше — тем меньше ущерб. 2) Фиксируем причину: расширение скоупа, технический долг, внешние блокеры, ошибка в оценке. Без диагностики не починить. 3) Пересчитываем оставшийся объём реалистично, без героизма. 4) Предлагаем заказчику варианты: перенос даты (самое здоровое), сокращение скоупа (тоже нормально), добавление людей (помогает редко), компромиссы по качеству (опасно, не рекомендуем). 5) Решение фиксируем письменно, обновляем план. От заказчика — оперативные согласования и отказ от давления «всё равно сделайте к дате».

Какой резерв закладывать в бюджет проекта бота MAX?+

Минимум 10–15% от общей сметы — это не подушка для команды, а защита заказчика от двух сценариев. Первый: расширение скоупа в ходе работы (всегда возникают «очевидно нужные» доработки, которых не было в ТЗ). Второй: непредсказуемые блокеры на интеграциях, особенно с 1С и внутренними системами. Без резерва проект попадает в одну из двух ловушек — либо постоянные дополнительные платежи (что портит отношения и плывёт по срокам), либо команда режет качество чтобы уложиться (что портит продукт). Распределение по этапам: discovery 5–8%, ТЗ и дизайн 10–20%, backend 30–45%, Mini App 10–25%, интеграции 10–20%, QA 8–12%, pre-launch 2–5%, soft launch 3–5%, резерв 10–15%.