Перейти к основному контенту

Методология проектной работы Metabot

Основная логика ведения проектов и создания ботов “Метабот-стайл”

Ключевая идея процесса

Создание бота или цифрового ассистента в Metabot — это не “построить кнопки” и “написать пару текстов”.
Это полноценный инженерно-производственный процесс, который соединяет:

  • аналитику,

  • проектирование,

  • разработку,

  • тестирование,

  • запуск,

  • поддержку и развитие.

Мы работаем как команда, создающая цифровой продукт, который должен:

  • решать реальную задачу бизнеса,

  • иметь понятную архитектуру,

  • быть устойчивым под нагрузкой,

  • легко развиваться,

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

  • обладать предсказуемым жизненным циклом.

Чтобы это обеспечить, мы используем шестиступенчатую методологию Metabot Project Delivery.

Схема процесса (общая логика)

Ниже — чистая, визуально читаемая схема процесса в стиле “одно окно понимания”. 


                   ┌──────────────────────────────┐
                   │   Этап 1. Оценка проекта     │
                   │  (запрос → стоимость → КП)   │
                   └──────────────▲───────────────┘
                                  │
                                  │ согласование
                                  │
                   ┌──────────────┴───────────────┐
                   │ Этап 2. Проектирование       │
                   │   и планирование             │
                   │ (аналитика → схема → ТЗ →    │
                   │ дорожная карта)              │
                   └──────────────▲───────────────┘
                                  │
                                  │ готовая архитектура
                                  │
                   ┌──────────────┴────────────────┐
                   │  Этап 3. Разработка и сборка  │
                   │  (каркас → логика → интеграции│
                   │   → AI → черновой прототип)   │
                   └──────────────▲────────────────┘
                                  │
                                  │ собранное рабочее решение (pre-release версия)
                                  │
                   ┌──────────────┴────────────────┐
                   │  Этап 4. Тестирование         │
                   │   и отладка                   │
                   │ (проход всех сценариев →      │
                   │ фиксы → подготовка к приёмке) │
                   └──────────────▲────────────────┘
                                  │
                                  │ готовый продукт
                                  │
                   ┌──────────────┴────────────────┐
                   │  Этап 5. Сдача и запуск       │
                   │  в эксплуатацию               │
                   │ (релиз → мониторинг → обучение│
                   │   → первичная аналитика)      │
                   └──────────────▲────────────────┘
                                  │
                                  │ переход в жизнь
                                  │
                   ┌──────────────┴────────────────┐
                   │  Этап 6. Поддержка и развитие │
                   │ (SLA → улучшения → BT → мини- │
                   │  проекты → масштабирование)   │
                   └───────────────────────────────┘

Ниже подробное описание каждого этапа.

Этап 1 — Оценка проекта 

Этот этап отвечает на базовый вопрос: «Что именно делаем, сколько это стоит и в каком формате работаем?»

1. Цели этапа

  • Зафиксировать исходный запрос клиента и перевести его с «хочу бота» на язык задач и ограничений.

  • Прикинуть трудозатраты и стоимость проекта с разумной точностью.

  • Определиться с моделью работы: фиксированная цена или time & material.

  • Подготовить для клиента коммерческое предложение (КП) и при необходимости — концепцию решения.

2. Входы этапа

Что нам нужно собрать, прежде чем считать деньги:

  • Описание задачи от клиента (часто — «как есть», голосом/текстом).

  • Базовая информация:

    • какие каналы нужны (Telegram, VK, WhatsApp, сайт, виджет и т.п.);

    • есть ли уже CRM, 1С, телефония, склад и т.д.;

    • какие процессы хотят трогать (лиды, поддержка, продажи, склад, сервис).

  • Ограничения:

    • сроки («к вчерашнему дню» / к мероприятию / «спокойно за 2 месяца»);

    • бюджетные рамки, если клиент ими делится;

    • инфраструктурные ограничения (облако/он-прем, безопасность, политика ИБ).

  • Примеры и референсы (если есть):

    • существующие скрипты операторов, регламенты;

    • примеры чужих ботов, которые нравятся;

    • уже написанные ТЗ/идеи, даже сырые.

3. Аналитика на этапе оценки

Важно: аналитика — это уже работа. Но на этапе оценки мы делаем её в гибком режиме:

  • Минимальная аналитика (для типовых решений):

    • уточняем целевую аудиторию и ключевые сценарии (1–3 основные воронки);

    • фиксируем базовую структуру бота и данных;

    • проверяем, нет ли «красных флажков» по интеграциям.

  • Расширенная аналитика (если проект нестандартный или большой):

    • короткие интервью с заказчиком/ключевыми пользователями;

    • разбор текущего процесса «как есть»;

    • набросок целевой схемы «как должно быть»;

    • первичный перечень рисков и допущений.

Часть этой аналитики мы часто делаем “в подарок”, чтобы клиенту было легче принять решение. Но честно понимаем, что глубокая аналитика — это уже отдельный оплачиваемый этап/спринт.

4. Концептуальное описание проекта

На этом же этапе мы часто готовим концепцию — человеческий текст + упрощённую структуру решения:

  • Формулируем цель проекта с нашей, профессиональной точки зрения.

  • Переводим запрос клиента в структурированное описание:

    • роли пользователей (клиент, оператор, менеджер, монтажник, и т.п.);

    • основные сценарии и ветки (воронки, сервисные цепочки);

    • ключевые точки интеграции (CRM, склад, телефония, 1С и т.д.).

  • Подсвечиваем то, что клиент не учёл, но критично:

    • где нужны доп. статусы, справочники, таблицы;

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

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

Такую концепцию мы иногда делаем как бонус к КП, иногда — как отдельный документ (особенно в сложных проектах и тендерах).

5. Модели ценообразования

На этом этапе мы выбираем одну из двух моделей работы:

  1. Фиксированная цена (fixed price)

    • Подходит для:

      • более-менее типовых проектов;

      • понятного объёма работ;

      • клиентов, которые хотят «конечную сумму» и понятный набор результатов.

    • Что делаем:

      • оцениваем трудозатраты с запасом по рискам;

      • включаем в цену возможные изменения в разумных пределах;

      • фиксируем границы проекта: что входит, а что явно не входит.

  2. Time & Material (T&M)

    • Подходит для:

      • сложных, эволюционирующих проектов;

      • ситуаций, когда сам клиент до конца не понимает конечный объём;

      • долгосрочных историй (цифровая трансформация, постоянное развитие).

    • Что делаем:

      • согласовываем ежемесячный бюджет (N часов/человек-часов в месяц);

      • описываем формат работы (спринты, приоритизация задач, отчётность);

      • оцениваем примерную «длину пути» и первые шаги.

Обе модели мы прямо прописываем в КП, чтобы клиент понимал, почему фикс дороже и когда выгоднее работать по T&M.

6. Как мы готовим коммерческое предложение

У нас фактически два способа подготовить КП:

6.1. Ручное КП (под нестандартные проекты)

Используем, когда:

  • проект сильно кастомный;

  • стандартных форм недостаточно, нужно больше текста, аргументации, схем;

  • у клиента важен нарратив: описание решения, обоснование, риски, дорожная карта.

В ручном КП обычно есть:

  • краткое описание заказчика и контекста;

  • цели и задачи проекта;

  • предлагаемое решение (уровень концепции);

  • этапы работ и сроки;

  • модель ценообразования (fixed или T&M, либо комбинация);

  • стоимость по этапам;

  • условия поддержки/сопровождения.

6.2. КП на базе стандартной спецификации (Sheets-шаблон)

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

  • Внутри шаблона:

    • листы с входными параметрами (каналы, интеграции, нужные модули, типы ботов, хостинг, поддержка и т.д.);

    • листы с трудозатратами по ролям (аналитик, архитектор, разработчик, интегратор, тестировщик, проджект);

    • прайсы и формулы, которые автоматически считают стоимость;

    • итоговый лист/листы, которые печатаются как готовая КП-ка.

  • Мы заполняем только ключевые листы, а остальное генерится автоматически:

    • это экономит нам кучу времени;

    • уменьшает вероятность ошибок в расчётах;

    • стандартизирует подход к оценке.

В итоговом документе учитывается:

  • оценка работ (по часам и ставкам);

  • стоимость лицензий/коробки (если нужно);

  • стоимость хостинга/облака (по выбранному тарифу);

  • наличие/отсутствие сопровождения и его цена;

  • дополнительные работы (интеграции, аналитика, обучение и т.п.).

Пример.

7. Формат выдачи КП клиенту

На выходе этапа клиент получает один или несколько артефактов:

  1. Коммерческое предложение (в PDF/Excel/документе):

    • стоимость и структура работ;

    • модель оплаты (фикса или T&M);

    • базовые сроки и этапы;

    • условия запуска и сопровождения.

  2. Концептуальное описание проекта (по ситуации):

    • текстовое описание решения + простая структура сценариев;

    • иногда — базовая схема (CJM/диаграмма, структура бота);

    • фиксация ключевых допущений и ограничений.

  3. Дополнительные приложения (по необходимости):

    • официальное КП на бланке компании (для тендеров, закупок, крупных корпоратов);

    • черновое структурное ТЗ (как с ботом для разборки автозапчастей) — если нужно показать глубину понимания задачи.

8. Результат этапа и переход дальше

Этап считается завершённым, когда:

  1. Клиент понимает предлагаемое решение, его функциональность и границы проекта.

  2. Согласовано коммерческое предложение, включая:

    • стоимость работ (поэтапно или общая),

    • модель оплаты (фиксированная цена или T&M),

    • сроки и структура работ,

    • условия поддержки/хостинга/подписки (если применимо).

  3. Согласована модель юридического оформления:

    • обычное КП (в PDF/Excel);

    • официальное коммерческое предложение по требованию клиента;

    • либо стандартный пакет документов (счёт, договор, спецификация/приложение).

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

Стандартная модель запуска (наша базовая)

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

  1. Подписывается договор / оферта (если требуется юридически).

  2. Клиент вносит предоплату — обычно 50% стоимости проекта.
    Это покрывает:

    • старт аналитики,

    • планирование,

    • подготовку схемы,

    • начало разработческих работ.

  3. Мы начинаем этап 2 — аналитика, планирование, требования, ТЗ и схема.

  4. Далее проект разбивается на этапы/спринты, и оставшаяся часть стоимости оплачивается по факту выполнения этапов:

    • каждый крупный блок работ закрывается актом;

    • клиент оплачивает соответствующую часть после приёмки этапа.

Этот процесс удобен и прозрачный — он привязан к понятным артефактам: схема, требования, каркас, интеграции, тесты, сдача.

Корпоративная модель (для крупных компаний)

Некоторые корпоративные заказчики работают по "постоплате":

  • сначала подписывается договор, ТЗ или спецификация;

  • мы начинаем работы, потому что у них внутренние регламенты финансовых служб;

  • оплата производится после закрытия этапов или даже всего проекта;

  • иногда требуется выставление счёта только после факта выполнения работ.

Мы просто подстраиваемся под эту модель, если это укладывается в рамки проекта и позволяет кэшфлоу.
Структура этапов при этом остаётся прежней — меняется только порядок финансовых документов.

Переход к этапу 2

После закрытия этапа 1 и юридически-финансового старта начинается Этап 2: Проектирование и планирование.

Этап 2 — Проектирование и планирование 

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

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

Этот этап объединяет то, что обычно в компаниях разделено: аналитика, проектирование, архитектура, детализация сценариев, технические требования и планирование задач. Фактически это — центр принятия решений и закладка всей логики будущего продукта.

Цели этапа

  • Извлечь максимум информации от клиента и стейкхолдеров.

  • Превратить сырые пожелания и хаотичные мысли клиента в структурированные требования.

  • Построить архитектуру бота / ассистента / системы.

  • Создать схему (CJM / логическая диаграмма) как основу всех сценариев.

  • Сформировать техническое задание (ТЗ) / спецификацию — документ, в котором зафиксирована реальная логика продукта.

  • Определить объём работ, разбить его на задачи, понять роли, распределить нагрузку.

  • Подготовить команду: аналитика, архитектура, разработка, интеграции, маркетинг (если нужно).

Подэтапы Этапа 2

🔹 2.1. Интервьюирование и анализ контекста

Как бы ни выглядел исходный запрос клиента, мы всё равно извлекаем смысл “из первых уст”.

Что делаем:

  • Проводим серию интервью с:

    • заказчиком,

    • ключевыми сотрудниками,

    • операторами/менеджерами,

    • пользователями (если возможно).

  • Выясняем:

    • цели проекта,

    • реальные рабочие процессы,

    • pain points в организации,

    • бизнес-правила,

    • зоны риска,

    • где живут данные,

    • какие системы участвуют.

  • Параллельно мы обучаем клиента:

    • объясняем, что бот — это не только кнопки и тексты;

    • нужен объясняющий контент;

    • нужны входные и выходные сценарии;

    • нужны fallback-ветки, правильная навигация;

    • важно думать не только о функционале, но и о коммуникации.

Золотое правило:

Бот всегда должен содержать объясняющий контент, а не только функциональные переходы.

Артефакты:

  • записи созвонов,

  • транскрибации,

  • голосовые заметки,

  • первичные черновики структуры.

Это — сырьё, которое затем превращается в архитектуру бота.

🔹 2.2. Сбор технической информации

Здесь мы начинаем техническое “раскопывание”.

Мы собираем:

  • API-документацию клиента;

  • доступы к тестовым средам (если есть);

  • модели данных (CRM, ERP, СУЗ, 1С);

  • перечень необходимых интеграций;

  • сведения о правах доступа и ролях;

  • требования по безопасности;

  • перечень каналов и ограничения по ним;

  • существующие регламенты операторов, скрипты, бизнес-процессы.

Цель:

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

🔹 2.3. Формирование понимания сценариев и логики

Этот подэтап — сердце инженерии.

Здесь мы делаем:

  • сценарии входа (как пользователь впервые попадает в бота);

  • коммуникационные ветки;

  • сервисные ветки;

  • разделение интерфейса на логические зоны;

  • определение тона общения;

  • правила fallback (что происходит, если пользователь ошибся);

  • базовая структура меню;

  • типы рассылок и триггеров;

  • точки, где нужны интеграции;

  • точки, где нужна помощь разработчика.

Это важно: все эти вещи появляются не из ТЗ клиента, а из проектной экспертизы Metabot.

🔹 2.4. Создание схемы (CJM / диаграммы логики)

(Ключевой артефакт — критически важный этап)

Золотое правило:

Схема — это одновременно документация, проектная канва и средство коммуникации.

Что мы делаем:

  • Строим схему в Sboard / Miro и т.п.

  • Наносим всю логику:

    • меню,

    • триггеры,

    • интеграции,

    • сервисные ветки,

    • маршруты,

    • роли пользователей.

  • Обозначаем там зоны для разработчиков (интеграционная логика).

  • Прописываем переходы и состояния.

Почему это важно:

  • Клиент видит проект целиком (даже если не всё понимает).

  • Схема — это то, что можно согласовать.

  • Схема — это то, что можно актировать.

  • Схема экономит месяцы времени на разработке и десятки часов на согласованиях.

  • На схеме уже заранее видно архитектуру — где каркас, где модули, где интеграции.

🔹 2.5. Формирование технической спецификации / ТЗ

После интервью, анализа и схемы — формируется структурированное ТЗ, уже не сырое.

Документ включает:

  • описание целей проекта,

  • набор каналов,

  • структуру бота,

  • все ключевые сценарии,

  • логику переходов,

  • перечень интеграций,

  • параметры данных,

  • что должен делать каждый модуль,

  • зоны ответственности (аналитик, разработчик, интегратор),

  • план работ по этапам.

Это уже рабочий инженерный документ, в отличие от концепции, которая была в Этапе 1.

🔹 2.6. Планирование работ, ролей и загрузки

На основе схемы и спецификации:

  • распределяем задачи по этапам;

  • создаём бэклог проекта;

  • определяем, где нужны разработчики;

  • оцениваем, сколько займёт каждая часть;

  • формируем дорожную карту;

  • уточняем риски;

  • фиксируем актируемые точки.

Планирование делается в рамках бюджета, согласованного на Этапе 1.

Артефакты Этапа 2

К концу этапа у нас есть:

  1. Схема бота / ассистента — согласованная и принятая.

  2. Техническое задание (ТЗ) — структурированное, финальное.

  3. Спецификация / архитектурный документ — детальная логика.

  4. API-карта точек интеграций — набор методов, полей, сценариев.

  5. Медиаматериалы интервью — записи, транскрипции.

  6. План работ / дорожная карта — этапы, сроки, задачи, роли.

И главное — понимание всей архитектуры будущего решения и видение конечного результата.

Результат и переход к Этапу 3

Этап 2 считается завершённым, когда:

  • Клиент согласовал схему.

  • Клиент согласовал ТЗ / спецификацию.

  • Определены все интеграции.

  • Понятен объём и план работ.

  • Команда знает, что выполнять и в каком порядке.

  • Известны сроки.

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

Этап 3 — Разработка и сборка решения

После того как согласованы схема, ТЗ и спецификация, начинается производственный цикл — реализация сценариев, логики, интеграций и функционала согласно проектной архитектуре. На этом этапе схема превращается в рабочий бот, ассистента или комплексную систему на базе Metabot.

Здесь работа переходит от аналитики и проектирования — к реальному строительству.

Цели этапа

  • Перенести архитектуру и схемы из проектной среды в Metabot.

  • Собрать каркас бота: скрипты, команды, ветки, меню, сервисные точки.

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

  • Подготовить логику ИИ: ассистентов, промпты, модели, векторные базы.

  • Настроить триггеры, события, условия и системные механики.

  • Обеспечить тесную работу всех членов команды (аналитиков, архитекторов, разработчиков, интеграторов, AI-специалистов).

  • Провести первичное тестирование и отладку.

Ключевой принцип

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

Схема — это проектная канва, но реальная жизнь иногда требует скорректировать детали.

Подэтапы Этапа 3

🔹 3.1. Подготовка к сборке и распределение задач

Перед началом сборки архитектора бота / ведущий специалист, ответственный за проект:

  • открывает финальную схему;

  • делает ревью ТЗ, интеграционных точек, логики;

  • распределяет задачи по членам команды:

    • архитекторы/сборщики Metabot

    • разработчики (JS / плагины / интеграции)

    • специалисты по ИИ

    • контент-специалисты

    • QA

  • создаёт задания в системе (Redmine, ClickUp, Jira и т.д. — в зависимости от проекта);

  • привязывает каждую задачу к конкретным частям схемы.

Важное правило:

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

🔹 3.2. Перенос схемы в конструктор Metabot

Это основной блок работы специалиста Metabot.

Что делаем:

  • Создаём каркас секций, скриптов и узлов по схеме.

  • Переносим все узлы в один-в-один структуре, включая:

    • меню,

    • сценарии входа/выхода,

    • развилки,

    • сервисные цепочки,

    • fallback-ветки,

    • обработчики ошибок,

    • состояния,

    • технические точки.

  • Задаём уникальные коды, понятные связи, аккуратную структуру.

Двунаправленные ссылки

Это сильная сторона подхода:

  • В схеме (Sboard/Miro) в каждом узле ставим ссылку на соответствующий скрипт Metabot.

  • В каждом скрипте Metabot добавляем ссылку обратно на узел схемы.

Это создаёт идеальную навигацию и позволяет любому члену команды быстро найти контекст.

Важно: схема почти никогда не совпадает 1 в 1 с итоговым ботом — это нормально.

🔹 3.3. Встраивание интеграций

Когда в схеме есть точки, требующие программирования, делается следующее:

  • В скриптах Metabot заранее создаются “заглушки”:

    • блоки с комментариями

    • отключённый JS-код

    • инструкции разработчику

    • список данных, которые нужно обработать

  • Комментарии оформлены так, чтобы разработчик точно понимал:

    • что здесь будет происходить;

    • какие параметры нужно отправить/получить;

    • какие проверки сделать;

    • как обработать ошибку.

Задача архитектора — передать смысл и контекст, а не только техническое задание.

Затем:

  • разработчик пишет код (плагины, API-вызовы, обработчики, триггеры);

  • интеграции добавляются ровно в те точки, которые отмечены на схеме;

  • логика связывается с общей архитектурой.

🔹 3.4. Реализация AI-части (если есть)

Если проект включает ИИ, подключаются AI-инженеры.

Возможные задачи:

  • создание промптов и ассистентов;

  • настройка истории, памяти, контекста;

  • подготовка векторных баз знаний;

  • настройка RAG-архитектуры;

  • классификация интентов/ответов;

  • подготовка fallback-поведения моделей;

  • интеграция ИИ в общий пайплайн бота.

Эта часть идёт параллельно со сборкой каркаса.

🔹 3.5. Сборка контента и коммуникации

Для многих ботов важна не только логика, но и:

  • тон общения;

  • текстовые блоки;

  • объясняющие сообщения;

  • микро-копирайтинг;

  • пользовательские инструкции;

  • контентная часть ассистента;

  • FAQ / статьи / базы знаний.

Это подэтап, который архитекторы и контент-специалисты делают совместно.

Золотой правило:

бот должен объяснять, вести, подсказывать — а не просто “давать функции”.

🔹 3.6. Первичное тестирование и отладка в процессе разработки

Методология Metabot предполагает не ждать финальной сборки, а тестировать по ходу.

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

  • Специалист проходит пути вручную на своём тестовом аккаунте.

  • Проверяет каждый переход, развилку, действие.

  • Тестирует интеграции, получая ошибки в чат через режим разработчика.

  • Смотрит технические лог-сообщения.

  • Исправляет мелкие недочёты на лету.

Этот подход позволяет:

  • не копить ошибки;

  • не превращать тестирование в катастрофу;

  • ускорить этап QA в разы.

Артефакты Этапа 3

  1. Полностью собранный каркас бота.

  2. Реализованные интеграции (плагины, API, триггеры, JS).

  3. Настроенные ассистенты, промпты, AI-слои.

  4. Служебные скрипты, обработчики, fallback-логика.

  5. Двунаправленные связи между схемой и Metabot.

  6. Частично протестированный рабочий прототип.

  7. Подготовленный набор задач на финальное тестирование.

Результат Этапа 3 и переход к Этапу 4

Этап 3 завершён, когда:

  • весь функционал реализован;

  • интеграции работают и выдают данные;

  • AI-часть функционирует;

  • все основные сценарии собраны;

  • каркас бота полностью соответствует схеме (с допустимыми инженерными оптимизациями);

  • баги уровня “критично” устранены.

Далее начинается Этап 4: Тестирование и отладка, где происходит глубокое проходное тестирование, работа с ошибками, проверка на реальных данных и подготовка релиза.

Этап 4 — Тестирование и отладка

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

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

Цели этапа

  • Проверить работоспособность всех сценариев, описанных в схеме и ТЗ.

  • Убедиться, что логика соответствует архитектуре.

  • Проверить корректность интеграций (API, базы данных, CRM, телефония, AI-блоков).

  • Найти и устранить ошибки.

  • Протестировать работу каждого узла, ветки, триггера, сообщения и перехода.

  • Подготовить продукт к финальной демонстрации и приёмке.

Ключевые принципы тестирования Metabot

Алена очень точно подметила:

Чтобы качественно протестировать бота — нужно “прожить” его как реальный пользователь.

Поэтому тестирование всегда включает:

  • проверку разных типов пользователей,

  • прохождение сценариев с ошибками,

  • попытки “сломать” бота,

  • тестирование необычных или редких переходов,

  • проверку всех “если…” и “вдруг…”.

Подэтапы тестирования

🔹 4.1. Проход всех сценариев вручную

Команда проходит каждый путь:

  • от входа до выхода,

  • все ветки меню,

  • все развилки,

  • все обработчики ошибок,

  • все сервисные логики,

  • все скрытые сценарии,

  • все fallback-ситуации.

Используются:

  • тестовые лиды,

  • тестовые пользователи,

  • тестовые учётные записи CRM/ERP,

  • тестовые ключи интеграций.

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

🔹 4.2. Проверка интеграций

Интеграционные точки — зона повышенного риска.

Проверяем:

  • вызовы API

  • отправку данных

  • получение данных

  • корректность обработки ошибок

  • задержки

  • отправку email/SMS/webhook уведомлений

  • поведение триггеров и условий

Если интеграция нестабильна — проектная команда выясняет:

  • проблема в коде?

  • проблема в API клиента?

  • проблема в данных?

  • проблема в среде?

Алена подчёркивала:

Каждый интеграционный шаг должен иметь fallback или обработчик ошибки.

🔹 4.3. Отладка через режим разработчика

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

  • включается режим отладки,

  • все технические ошибки отправляются в мессенджер (TG/VK/WhatsApp),

  • получаем trace:

    • какое действие вызвало ошибку,

    • какая переменная пустая,

    • какой API ответ пришёл,

    • какой параметр не найден.

Этот режим — основной инструмент при разработке и тестировании.

🔹 4.4. Работа с логами (если доступно)

Важно:
в облачной версии Metabot логирование ограничено для обычных пользователей.

Доступ к логам есть:

  • у специалистов на выделенном сервере,

  • на коробочной версии,

  • или у команды Metabot (через поддержку).

Что можно делать на выделенном сервере:

  • смотреть системные логи,

  • видеть критические ошибки,

  • видеть очередь задач,

  • остановить или перезапустить сервисы,

  • заморозить бота, чтобы избежать некорректной рассылки/циклов.

Алена говорила:

Умеешь пользоваться логами — решаешь 90% проблем за минуты.

На общем облаке есть ограничения:

  • нет прямого доступа к логам,

  • нельзя остановить платформу вручную.

Обходные пути:

  • временно сменить токен бота в Telegram/VK — бот перестанет отвечать;

  • отключить интеграцию на панели;

  • обратиться в поддержку Metabot;

  • вынести рискованные узлы в закрытые секции.

🔹 4.5. Проверка AI-логики

Если проект включает ИИ, тестирование усложняется.

Проверяем:

  • корректность ответа ассистента,

  • устойчивость к ошибочным вводам,

  • работу памяти/контекста,

  • работу векторных поисков,

  • определение интентов,

  • fallback-механику AI,

  • скорость ответа.

Проводим несколько “прохождений”:

  1. идеально корректный пользователь,

  2. “средний пользователь”,

  3. “хаотичный пользователь, вводящий чушь”,

  4. стресс-тесты — 10–20 запросов подряд.

🔹 4.6. Финальная полировка

Когда основные ошибки устранены:

  • выравниваем тексты,

  • проверяем UX-логику,

  • обеспечиваем единообразный стиль,

  • проверяем скорость прохождения сценариев,

  • проверяем корректность меток, тегов, логирования, аналитики.

Это этап, который часто недооценивают, но он сильно влияет на впечатление заказчика.

Передача заказчику для приёмки

После внутреннего тестирования:

  • заказчику даётся доступ к боту;

  • он сам проходит ключевые сценарии;

  • фиксирует пожелания, правки, уточнения;

  • команда вносит разумные доработки;

  • проводится финальный прогон.

Алена говорила:

Это нормальная практика — заказчик увидит что-то новое, когда “подержит бота в руках”.

Главное — чтобы правки не ломали архитектуру.

Артефакты Этапа 4

  1. Полностью протестированный бот/ассистент.

  2. Список найденных и устранённых ошибок.

  3. Лог прохождения тестов.

  4. Отчёт о тестировании (по необходимости).

  5. Готовый к приёмке прототип без критических багов.

Результат Этапа 4 и переход к Этапу 5

Этап 4 завершён, когда:

  • все сценарии работают стабильно;

  • интеграции отрабатывают без ошибок;

  • AI-логика корректна;

  • критических и средних багов нет;

  • проект согласован командой;

  • заказчик прошёл бота и дал подтверждение.

После этого начинается:

Этап 5 — Сдача и ввод в эксплуатацию

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

Цель этапа — безопасно и предсказуемо запустить проект, обеспечить его стабильность в первые дни и недели, и провести заказчика через процесс приёмки.

Цели этапа

  • Подготовить проект к запуску — инфраструктурно, технически и организационно.

  • Передать заказчику работающее решение в полной готовности.

  • Настроить мониторинг и смотреть первые реакции пользователей.

  • Обеспечить стабильную работу бота/ассистента при реальной нагрузке.

  • Быстро реагировать на первые инциденты, править мелкие недочёты.

  • Дать клиенту инструкции, обучение и понимание, как жить дальше с системой.

Подэтапы Этапа 5

🔹 5.1. Финальная проверка перед релизом

Перед передачей клиенту команда проводит:

  • финальное тестирование всех ключевых сценариев;

  • проверку интеграций;

  • тест входных/выходных сценариев;

  • проверку обработчиков ошибок;

  • проверку правильности логирования и аналитики;

  • выравнивание коммуникационного стиля;

  • корректность fallback-веток.

Это тот самый «последний прогон», когда команда самолично убеждается, что решение стабильно.

🔹 5.2. Передача проекта заказчику

Заказчик получает:

  • доступ к боту, ассистенту или системе;

  • доступ к админ-панели (если предусмотрено);

  • доступ к документации (схема, ТЗ, пояснения, инструкции);

  • видео-/текстовый walkthrough по ключевым сценариям;

  • пояснение архитектуры (если требуется).

Клиент самостоятельно проходит сценарии:

  • кликает кнопки;

  • проверяет ветки;

  • тестирует интеграции;

  • пытается воспроизвести реальные ситуации.

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

Команда вносит правки в разумных пределах.

🔹 5.3. Подготовка к запуску и выбор стратегии релиза

Стратегия зависит от типа проекта.

1) Пилотный запуск (ограниченный доступ)

Используется, если:

  • функционал новый,

  • важно собрать UX-обратную связь,

  • есть риски высоких нагрузок,

  • нужен быстрый цикл корректировок.

Проводится:

  • запуск на малую группу пользователей (служба поддержки, операторы, часть отдела);

  • сбор обратной связи;

  • исправление найденного;

  • постепенное расширение охвата.

2) Мягкий старт (soft launch)

Постепенный запуск:

  • канал за каналом,

  • источник трафика за источником,

  • аудитория за аудиторией.

Используется для маркетинговых и коммуникационных проектов.

3) Полный запуск (full launch)

Используется:

  • если бот встроен в основной канал бизнеса (сайт, Telegram, WhatsApp, VK),

  • если нет возможности запускать постепенно,

  • если решение заменяет старую систему.

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

🔹 5.4. Мониторинг первых дней (критическая фаза)

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

Команда:

  • активно мониторит диалоги,

  • проверяет поведение интеграций,

  • отслеживает ошибки,

  • измеряет скорость ответов,

  • контролирует нагрузку,

  • оперативно вносит точечные правки.

Если используются AI-компоненты — наблюдение ещё важнее:

  • проверяем корректность ответов;

  • отслеживаем «дрейф» поведения моделей;

  • корректируем промпты, инструкции и fallback.

Система “должна не просто работать, а вести себя предсказуемо”.

🔹 5.5. Сбор аналитики

Сразу после запуска начинается сбор фактических данных:

  • количество входов,

  • завершение сценариев,

  • процент ошибок,

  • точки отказа,

  • время ответа,

  • конверсия по веткам,

  • тепловые карты переходов,

  • активность пользователей.

При анализе всегда найдутся места для улучшений — это нормально.

Эти данные переходят в дальнейшую поддержку и развитие.

🔹 5.6. Инструкции и обучение

Команда обучает заказчика:

  • как пользоваться системой,

  • как смотреть статистику,

  • как управлять контентом,

  • как включать/отключать каналы,

  • как пользоваться админкой,

  • как работать со сбором данных,

  • как реагировать на инциденты.

Обучение может быть:

  • видео,

  • звонок,

  • демонстрация,

  • мини-мануал.

🔹 5.7. Финальная приёмка работ

Когда заказчик проходит сценарии, тестирует систему и подтверждает, что всё работает:

  • оформляется акт выполненных работ;

  • заказчик принимает проект;

  • начинается следующая стадия — поддержка и развитие.

Артефакты Этапа 5

  1. Рабочий, запущенный бот/ассистент.

  2. Инструкции и документация.

  3. Список правок, внесённых после приёмки.

  4. Аналитика первых дней.

  5. Подтверждение заказчика о готовности решения.

Результат Этапа 5 и переход к Этапу 6

Этап 5 завершён, когда:

  • продукт запущен,

  • система работает стабильно,

  • заказчик принял решение,

  • собрана первичная аналитика,

  • выполнены корректировки,

  • продукт перешёл в штатную эксплуатацию.

Далее начинается Этап 6. Поддержка и развитие проекта — долгосрочная работа, в которой продукт живёт, улучшается и адаптируется под новые задачи клиента.

Этап 6 — Поддержка и развитие проекта

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

Поддержка и развитие — это долгосрочный цикл работы, в котором:

  • устраняются ошибки и инциденты;

  • вносятся мелкие правки;

  • добавляются улучшения;

  • обрабатываются новые бизнес-требования;

  • строится roadmap развития;

  • платформа может мигрировать в контур клиента;

  • обеспечивается стабильная работа всей инфраструктуры.

Цели этапа

  • Обеспечить стабильность и предсказуемость работы решения.

  • Быстро реагировать на ошибки, инциденты и изменения на стороне клиента.

  • Вносить мелкие правки и улучшения в рамках поддержки.

  • Реализовывать новые бизнес-требования и развивать функционал.

  • При необходимости переносить платформу или бота в инфраструктуру клиента.

  • Управлять ресурсами команды и давать заказчику прозрачный SLA.

Подэтапы Этапа 6

🔹 6.1. Вход в режим поддержки

После запуска команда и заказчик определяют формат дальнейшей работы:

Вариант 1 — Договор поддержки (SLA + развитие)

Наиболее удобный вариант, включающий:

  • резерв часов команды;

  • фиксированную доступность специалистов;

  • приоритет реакции;

  • возможность оперативно исправлять ошибки;

  • мелкие доработки без отдельного бюджетирования;

  • доступ к менеджеру проекта или продуктовой группе;

  • регулярные рабочие совещаний с заказчиком.

В этом режиме заказчику не нужно “перезаказывать” маленькие задачи — они выполняются автоматически в рамках пакета поддержки.

Вариант 2 — Поддержка без резерва (on demand)

Если заказчик не хочет резервировать время:

  • задачи принимаются по запросу;

  • работа оценивается отдельно;

  • ставки выше, т.к. специалисты отвлекаются от других проектов;

  • приоритет ниже, чем у проектов c SLA.

Работа без резерва — самый тяжёлый режим для клиента, т.к. ждать приходится дольше и стоит дороже.

🔹 6.2. Исправление ошибок и мелкие корректировки

В поддержку входят:

  • исправление багов;

  • корректировка текстов, веток, интерфейсов;

  • адаптация логики после изменений у клиента;

  • обновление интеграций после изменений API;

  • поддержка AI-части: промпты, модели, fallback;

  • мелкие улучшения функционала.

Поддержка — это не разработка, это сопровождение жизни продукта. Мелкие правки и шлифовка — обычный процесс.

🔹 6.3. Реализация новых бизнес-требований (развитие)

Когда задачи выходят за рамки SLA или требуют серьёзного объёма, запускается процесс Бизнес-Требований (BT/BRD):

  1. Формируется бизнес-требование от заказчика.

  2. Команда оценивает его:

    • объём работ,

    • сроки,

    • стоимость.

  3. Заказчик одобряет бюджет.

  4. Создаётся мини-этап проектирования:

    • схема,

    • ТЗ,

    • интеграции.

  5. Требование входит в очередь развития и выполняется как мини-проект.

Таким образом:

Проект живёт циклами: BT → проектирование → реализация → тестирование → запуск.

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

🔹 6.4. Управление ресурсами команды

В рамках SLA обычно резервируются:

  • часы проектной группы;

  • часы технической группы;

  • интеграторы;

  • разработчики;

  • AI-специалисты.

Заказчик может использовать эти ресурсы гибко.

Если ресурсы не резервируются заранее — они тарифицируются выше.

🔹 6.5. Поддержка инфраструктуры и серверов

Многие заказчики работают:

  • на общем облаке Metabot,

  • на выделенных серверах,

  • на коробочной версии внутри собственного контура.

На этом этапе может потребоваться:

  • развернуть коробочную версию у заказчика (часто в медицине и крупных компаниях);

  • перейти с облака Metabot на выделенный сервер;

  • разделить каналы по бизнес-единицам;

  • перенести базу данных или интеграционные модули.

Эти работы могут идти параллельно либо быть частью развития и оцениваются отдельно.

🔹 6.6. Мониторинг и реакция на инциденты (troubleshooting)

✔ Главное правило — не паниковать.

Любая ситуация решается, потому что:

  • мессенджер всегда сохраняет связь с пользователем;

  • можно отправить исправляющее сообщение;

  • можно отозвать сообщение (Telegram позволяет);

  • можно заморозить бота и прекратить отправку;

  • можно дослать информацию позже;

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

Возможные ситуации:

  • сломалась интеграция;

  • зависла внешняя система;

  • пришли неверные данные;

  • переполнен лимит API;

  • не отработала логика AI;

  • “повело” текст ассистента.

Что делать:

  1. Остановить некорректное поведение

    • отключить бота на платформе;

    • временно поменять токен в Telegram/VK;

    • выключить триггер;

    • на выделенном сервере — остановить сервис.

  2. Определить масштаб

    • сколько пользователей затронуло;

    • в какой момент произошло;

    • какой модуль виноват.

  3. Собрать данные

    • логи (на выделенном сервере);

    • техническое сообщение режима разработчика;

    • поведение интеграции.

  4. Выработать план действий

    • переслать корректирующее сообщение;

    • отозвать ошибочное;

    • обработать негатив пользователей, например, извиниться и объяснить ситуацию;

    • починить код или интеграцию;

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

Email-оповещения и наблюдение

В некоторых проектах у вас настроены:

  • email-уведомления на критических ошибках;

  • уведомления о падении API;

  • отчёты о сбоях интеграций;

  • тревоги по работам cron/бота.

Это ускоряет реакцию и позволяет чинить за минуты.

🔹 6.7. Аналитика и рост продукта

После запуска и поддержки начинается “взрослая жизнь” бота:

  • анализируются статистики;

  • находятся слабые места;

  • улучшаются воронки;

  • строятся новые каналы;

  • усиливаются AI-модули;

  • подключаются новые интеграции;

  • расширяется логика;

  • накапливаются бизнес-требования;

Таким образом:

поддержка → аналитика → улучшения → развитие → новый цикл проекта.

Артефакты Этапа 6

  1. Договор SLA или on-demand формат.

  2. План резервирования ресурсов.

  3. Журнал выполненной поддержки.

  4. Реализованные бизнес-требования.

  5. Новые схемы, ТЗ, мини-проекты.

  6. Инцидент-репорты и инструкции по устранению.

  7. Dashboard аналитики/BI (по необходимости).

  8. Итоговые версии систем и модулей.

Завершение Этапа 6

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

Именно на этом этапе происходят:

  • масштабирование,

  • запуск новых сценариев,

  • подключение AI-ассистентов,

  • расширение на новые каналы,

  • перенос в контур клиента,

  • рост пользовательской базы
    — и формирование долгосрочного партнерства.

Нет комментариев
Наверх