Ресторанная сеть из 10 заведений обратилась с первичным запросом на доработку Telegram Mini App. В процессе стало понятно, что задача шире: компании нужен не отдельный подрядчик под приложение, а внешний продуктово-технический контур, который сможет развивать несколько цифровых продуктов, поддерживать инфраструктуру, закрывать интеграции и сопровождать эксплуатацию.

За 7 месяцев работы были запущены 6 продуктов:

1. приложение для сети ресторанов и Telegram-бот;

2. AI-копирайтер;

3. AI-метрдотель;

4. умная база знаний на базе RAG;

5. AI HR-бот;

6. умная база клиентов.

Команда проекта выросла с 3 до 10 человек. Следующий этап — расширение до 17 человек для поддержки и дальнейшего развития IT-контура компании.

Исходная задача

Первоначально заказчик пришёл с задачей доработать приложение в формате Telegram Mini App. Но уже на раннем этапе стало ясно, что приложение не может развиваться изолированно.

Помимо разработки интерфейса, требовались:

• постоянная поддержка продукта;

• регулярное внедрение новых функций;

• интеграции с внешними системами;

• серверная инфраструктура;

• техническая поддержка пользователей;

• работа с AI-продуктами;

• документация;

• мониторинг и сопровождение;

• координация с IT-поставщиками.

Для такой конфигурации классическая модель подрядчиков «под отдельные задачи» плохо подходит. Каждый новый продукт затрагивает другие части цифрового контура: приложение, Telegram-бота, базу клиентов, RAG-систему, интеграции, аналитику и инфраструктуру.

Почему не подошла модель подрядчиков под задачи

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

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

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

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

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

Почему не был выбран собственный штат разработки

Альтернативный путь — собрать внутренний IT-отдел. Но для бизнеса без сильной технической экспертизы это отдельный сложный проект.

Нужно нанять разработчиков, продакт-менеджера, проектного менеджера, DevOps, аналитика, UX/UI-дизайнера, тестировщиков и специалистов поддержки. После этого нужно настроить процессы, управление задачами, спринты, релизы, документацию, мониторинг, контроль качества и работу с инцидентами.

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

Формат IT-ретейнера

Для проекта был выбран формат IT-ретейнера.

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

В этом формате команда отвечает не только за разработку отдельных функций, но и за весь цифровой контур:

• продуктовую разработку;

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

• серверную инфраструктуру;

• поддержку пользователей;

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

• коммуникацию с внешними IT-поставщиками;

• техническую документацию;

• аналитику;

• сопровождение релизов;

• предотвращение конфликтов между продуктами.

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

Как была устроена команда

Проект стартовал с 3 человек: project-менеджер; frontend-разработчик; backend-разработчик.

По мере роста количества продуктов и интеграций команда увеличилась примерно до 10 человек. В работу начали подключаться дополнительные роли: UX/UI, DevOps, системный аналитик, ассистент, специалисты по поддержке и другие участники производственного процесса.

Следующий плановый этап — расширение команды до 17 человек. Задача расширения — обеспечить устойчивость IT-контура и продолжить цифровизацию ресторанной сети без потери скорости разработки.

Какие продукты были реализованы

За 7 месяцев в рамках ретейнера были реализованы 6 основных направлений.

Приложение для сети ресторанов и Telegram-бот

Telegram Mini App и бот стали основой клиентского цифрового контура. Через них гости взаимодействуют с ресторанами, получают информацию, бронируют столы, покупают продукты, обращаются в поддержку и получают уведомления.

AI-копирайтер

AI-копирайтер используется для генерации и поддержки текстового контента. Такой инструмент помогает ускорять подготовку коммуникаций и снижать ручную нагрузку на команду.

AI-метрдотель

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

Умная база знаний на базе RAG

RAG-система используется как слой корпоративной памяти. Она позволяет работать с документами, регламентами и внутренними знаниями компании через запросы на естественном языке.

AI HR-бот

AI HR-бот закрывает часть внутренних HR-сценариев: ответы на вопросы сотрудников, доступ к регламентам, поддержка онбординга, работа с корпоративной базой знаний и разгрузка HR-команды.

Умная база клиентов

Умная база клиентов объединяет данные о гостях из разных систем: приложения, Telegram, бронирований, оплат, отзывов, чеков и технических логов. Она используется для сервиса, аналитики, сегментации и будущих AI-сценариев.

Рабочий процесс в ретейнере

Процесс работы построен как повторяемый цикл:

1. бизнес-запрос;

2. предпродакшн внутри команды;

3. спринт;

4. релиз;

5. сопровождение.

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

Получение запроса

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

Команда фиксирует суть задачи, уточняет детали только там, где без этого нельзя, и переводит бизнес-запрос в продуктовую постановку.

Предпродакшн

До попадания задачи в спринт проводится внутренняя проработка. На этом этапе уточняются:

• смысл задачи;

• критерии готовности;

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

• ограничения;

• зависимости от других продуктов;

• риски;

• возможные варианты реализации.

Если задача связана с интерфейсом, готовится дизайн или прототип. Обычно формируется 1–3 варианта реализации с оценкой сроков и рисков. После этого заказчик выбирает подходящий вариант и подтверждает приоритет.

Спринт и релиз

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

Работа идёт итерациями. По итогам спринта заказчик получает дайджест изменений: что было сделано, какие функции изменились, что можно передать ресторанам и сотрудникам.

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

Сопровождение и эксплуатация

Ретейнер включает не только разработку, но и сопровождение цифрового контура.

Команда следит за работой серверов, разбирает сбои, взаимодействует с партнёрами и поставщиками IT-услуг, ведёт документацию, фиксирует инциденты, покрывает функциональность тестами и проверяет, не конфликтуют ли новые изменения с уже запущенными продуктами.

Если у пользователя возникает проблема, команда может поднять логи, восстановить цепочку событий, определить причину и либо устранить ошибку, либо корректно объяснить, что произошло.

Что даёт ретейнер бизнесу

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

Основные преимущества формата:

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

• продукты развиваются в одной логике;

• архитектурные решения принимаются с учётом будущих интеграций;

• снижается риск технического долга;

• заказчик получает регулярные релизы;

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

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

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

Для ресторанной сети это важно из-за количества параллельных процессов. Один продукт влияет на другой: Telegram Mini App связан с ботом, бот — с клиентской базой, база — с AI-сервисами, AI-сервисы — с внутренними регламентами, а всё вместе зависит от инфраструктуры и внешних интеграций.

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

Итог

За 7 месяцев формат IT-ретейнера позволил ресторанной сети перейти от отдельного запроса на доработку Telegram Mini App к развитию полноценного цифрового контура.

Были запущены 6 продуктов: приложение и Telegram-бот, AI-копирайтер, AI-метрдотель, умная база знаний на базе RAG, AI HR-бот и умная база клиентов.

Команда выросла с 3 до 10 человек, а следующий этап предполагает расширение до 17 человек. Такой рост связан не только с увеличением объёма разработки, но и с необходимостью поддерживать инфраструктуру, интеграции, эксплуатацию, аналитику и дальнейшую цифровизацию.

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