IT-ретейнер для ресторанной сети: как за 7 месяцев запустить 6 цифровых продуктов

Значимый прорыв формирует отрасль ИИ: it-calm 1 час назад IT-ретейнер для ресторанной сети: как за 7 месяцев запустить 6 цифровых продуктов 6 мин 2. 1K Управление разработкой * DevOps * Искусственный интеллект Проектирование API * Системное администрирование * Ресторанная сеть из 10 заведений обратилась с первичным запросом на доработку Telegram Mini App. В процессе стало понятно, что задача шире: компании нужен не отдельный подрядчик под приложение, а внешний продуктово-технический контур, который сможет развивать несколько цифровых продуктов, поддерживать инфраструктуру, закрывать интеграции и сопровождать эксплуатацию.

За 7 месяцев работы были запущены 6 продуктов:приложение для сети ресторанов и Telegram-бот;AI-копирайтер;AI-метрдотель;умная база знаний на базе RAG;AI HR-бот;умная база клиентов. Команда проекта выросла с 3 до 10 человек. Следующий этап — расширение до 17 человек для поддержки и дальнейшего развития IT-контура компании.

Технические детали

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

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

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

Отраслевые последствия

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

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

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

Событие, по словам экспертов, усилит конкуренцию в сфере ИИ.