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

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

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

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

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

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

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

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


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

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

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

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

1. Цели этапа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • Что делаем:

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

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

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

  2. Time & Material (T&M)

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

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

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

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

    • Что делаем:

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

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

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

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

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

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

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

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

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

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 — Проектирование и планирование 

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

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

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

Цели этапа

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

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

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

Что делаем:

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

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

Артефакты:

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

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

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

Мы собираем:

Цель:

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

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

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

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

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

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

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

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

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

Что мы делаем:
Почему это важно:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цели этапа

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

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

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

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

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

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

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

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

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

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

Что делаем:
Двунаправленные ссылки

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

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

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

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

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

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

Затем:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цели этапа

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

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

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

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

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

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

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

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

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

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

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

Проверяем:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проверяем:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цели этапа

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

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

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

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

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

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

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

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

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

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

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

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

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

Проводится:

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

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

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

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

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

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

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

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

Команда:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цели этапа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • сроки,

    • стоимость.

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

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

    • схема,

    • ТЗ,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Возможные ситуации:
Что делать:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Версия #8
Artem Garashko создал 28 November 2025 12:30:05
Artem Garashko обновил 29 November 2025 10:37:45