Студенты магистратуры Skillfactory и МИФИ «Разработка программного обеспечения» приняли участие в хакатоне, где работали над задачей от Neoflex — разработкой сервиса администрирования чат-бота Flexiq.
Команде нужно было не просто собрать прототип по ТЗ, а выстроить архитектуру и разобраться с новым стеком в сжатые сроки. Рассказываем, как они организовали работу, с какими ограничениями они столкнулись , и каким получился итоговый проект.
Не просто чат-бот, а управляемый продукт: с каким брифом пришли партнеры
Учебный центр компании Neoflex развивает собственный чат-бот Flexiq, который помогает работать с кандидатами и студентами —: от первых шагов в IT до обучения и взаимодействия с центром. По мере роста продукта возникла практическая задача — упростить и систематизировать управление.
Речь шла не о доработке самого чат-бота, а о создании отдельного сервиса администрирования: интерфейса, через который можно управлять логикой бота, сценариями и данными без ручных правок в коде. Такой сервис должен был стать точкой контроля и ускорить работу команды с продуктом.
На хакатоне студентам предложили разработать MVP этого решения. Важно было не просто описать архитектуру, а собрать работающий прототип.
В качестве ориентиров партнер задал конкретные технические рамки:
— реализация на Python или Java;
— база данных PostgreSQL;
— микросервисная архитектура;
— строгое следование ТЗ и готовым макетам.
При этом задачу можно было решать по-разному — это можно было рассматривать как единую систему или разбить ее на несколько частей. Главное, чтобы на выходе получилось целостное и воспроизводимое решение.
Отдельный акцент партнеры сделали на практической ценности. Сервис должен был не просто «выглядеть как продукт», а реально позволять управлять чат-ботом и демонстрировать эту логику в работе.
«Часть стека осваивали в процессе»: как студенты разрабатывали решение
Работу над проектом команда выстроила вокруг многослойной архитектуры. В ее основе — слой безопасности с авторизацией через Keycloak (OAuth 2), который отвечает за регистрацию пользователей и контроль доступа. Следом идет слой работы с данными: через JPA и репозитории команда организовала хранение и управление сущностями. Поверх — слой бизнес-логики и пользовательский интерфейс.
Такое разделение позволило изолировать компоненты системы: каждую часть можно дорабатывать отдельно, не затрагивая остальные. Это особенно важно для прототипа, который в будущем можно расширять.
Одной из главных сложностей стало то, что команда работала с новым для себя стеком. У большинства участников был опыт в Python, C++ и Java, а вот Vaadin пришлось осваивать уже по ходу проекта. Это напрямую повлияло на решения в интерфейсе: команда сознательно отказалась от сложных кастомных элементов в пользу стандартных компонентов фреймворка.
Например, боковую панель редактирования (Right Drawer), заложенную в макетах, заменили на стандартный диалог. Такой вариант проще в реализации, но при этом архитектура осталась гибкой — при необходимости диалог можно заменить на более сложный интерфейс без изменений в бизнес-логике.
Работая с Vaadin, команда столкнулась с рядом ограничений:
— в таблицах нельзя одновременно реализовать сложную фильтрацию и сортировку;
— нет сохранения состояния колонок между сессиями;
— ограничены возможности drag-and-drop;
— часть компонентов (например, rich-text-редактор) доступна только в платной версии.
Чтобы не тормозить разработку, студенты упростили UX и предложили свои решения:
— общий поиск по таблице через единое поле;
— сортировка по клику на заголовок;
— настройка отображения колонок через popover;
— фиксация первой колонки и ручное изменение ширины.
Это позволило сохранить базовую функциональность интерфейса без сложной доработки фреймворка.
С этим стеком мы раньше не работали, поэтому многое приходилось осваивать в процессе. В MVP не вошли экспорт данных и отчеты, а интеграцию с ботом решили оставить за пределами прототипа. При этом архитектура позволяет это добавить — например, через событийную модель и расширение сервисного слоя.
В итоге разработка стала не только задачей на реализацию продукта, но и полноценной инженерной практикой: студенты принимали архитектурные решения, адаптировались к ограничениям инструментов и постоянно балансировали между «как правильно» и «как успеть и запустить».
«Интерфейс — выше всяких похвал»: каким получился итоговый продукт
На выходе команда представила работающий MVP сервиса администрирования чат-бота — систему, через которую можно управлять пользователями, диалогами и рассылками без прямого вмешательства в код.
Основой стал единый веб-сервис с интерфейсом администратора. Несмотря на изначальный ориентир на микросервисы, архитектуру реализовали в виде монолита: такой подход позволил быстрее собрать стабильный прототип и не распыляться на инфраструктурные сложности.
Фронтенд и бэкенд объединили в одном стеке — на Java с использованием Vaadin. Это упростило разработку: интерфейс и бизнес-логика связаны напрямую, без отдельного REST API и дополнительного слоя на JavaScript. В результате команда смогла быстрее перейти от проектирования к рабочим сценариям.
В MVP реализовали ключевые функции, необходимые для администрирования чат-бота:
— управление пользователями (студенты, кураторы, эксперты);
— работу с диалогами и данными бота через базу;
— создание и отправку рассылок;
— фильтрацию аудитории по параметрам (например, по направлениям и городам);
— базовую ролевую модель с разграничением доступа.
Работа с телеграм-ботом в MVP реализована косвенно: действия администратора фиксируются в базе данных (users, dialogs, mailings), а отправка сообщений моделируется через записи в таблицах. Это позволило сосредоточиться на логике управления, не усложняя прототип интеграциями.
Часть функциональности команда сознательно сократила — по согласованию с заказчиком:
— отказались от интеграции с NeoStudy (Moodle) и внешними системами;
— убрали планирование рассылок, оставив только мгновенную отправку;
— использовали сервисы-заглушки для недостающих данных (например, списка городов);
— адаптировали интерфейс под возможности выбранного фреймворка вместо точного повторения макетов.
Такие решения помогли не перегрузить проект и довести до рабочего состояния именно те сценарии, которые важны для демонстрации ценности продукта.
Дополнительно команда сразу заложила возможность масштабирования: вынесла текстовые элементы в properties-файлы для поддержки нескольких языков и настроила кастомную тему интерфейса.
MVP покрывает ключевые сценарии администрирования и может быть базой для дальнейшего развития — с добавлением интеграций, расширением API и возможностью перейти к более сложной архитектуре.
Проект студентов превзошел наши ожидания, интерфейс выше всяких похвал, архитектурные решения и база данных реализованы отлично. Особенно подкупило, что тимлид специально под проект изучил новый для себя стек и показал результат в такие короткие сроки.
По итогам сотрудничества компания Neoflex забрала резюме тимлида команды Skillfactory в кадровый резерв для возможного сотрудничества в будущем.
