Расписание учебных групп: кастомный модуль поверх CRM вместо ручного планирования.

Что было: расписание собирали руками до 15-го числа.

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

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

Цена ошибки здесь отложенная. Накладка двух групп не подсвечивается в момент, когда её делают, — она просто становится видимой, когда слушатели уже пришли на занятие. И исправляют её не в системе, а люди.

Почему не «донастроить CRM», а писать модуль.

Коробочная CRM хорошо делает то, для чего она сделана: карточки, списки, канбан, права, бизнес-процессы. Но она не умеет раскладывать часы по рабочим дням по отраслевым правилам конкретного учебного центра — и никакая настройка полей этого не даст. Здесь нужен не конструктор, а код.

Ключевое ограничение мы поставили себе сами: никаких изменений в ядре платформы. Весь модуль живёт в собственном изолированном каталоге и пользуется штатными механизмами — своими таблицами, контроллерами, расширениями интерфейса, API смарт-процессов. Это скучное на вид требование, от которого зависит всё: клиент должен обновлять свою CRM дальше, и обновления не должны ломать то, что мы дописали.

Что построили.

В главном меню CRM появился пункт «Расписание групп» с двумя основными экранами — календарём и черновиком.

Календарь показывает сетку рабочих дней с плашками групп: название курса, тип (длинная или короткая), номер группы, количество слушателей. Если на один день приходится больше двух групп, лишние сворачиваются в бейдж «+N». Группы, начавшиеся в прошлом месяце и продолжающиеся дальше, помечаются маркером «ПР». Группы, которые после ручных правок начали накладываться друг на друга вопреки правилам, подсвечиваются красным — сразу, а не задним числом.

• Фильтры: период (месяц, неделя, произвольный диапазон), курсы мультивыбором, тип курса, состояние сертификатов — сформированы или нет.
• Печать расписания за текущий период с учётом применённых фильтров, в вёрстке под A4.
• Клик по курсу или номеру группы открывает соответствующую карточку в боковой панели — без перехода на другую страницу.
• Три роли: инспектор смотрит и печатает, методист формирует и настраивает, администратор может ещё и перегенерировать уже финализированное расписание.

Второй экран — черновик. Методист нажимает «Сформировать», и система по настройкам курсов раскладывает группы на следующий месяц. Это ещё не реальные группы, а черновик, который видно и можно поправить: микроблок группы перетаскивается на другой день, после чего пересчитываются даты начала и завершения, занятость часов и конфликты. Когда картина устраивает — «Сформировать» второй раз. Только теперь система назначает номера в формате «год/номер», фиксирует время и создаёт реальные элементы смарт-процесса «Группы».

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

Две детали, от которых зависит, будет ли такой модуль работать.

Первая — планировщик «волн». Группы одного курса разбиваются на волны: параллельные идут в одном временном слоте, последовательные — одна за другой. Волна заполняет восьмичасовой день; если не вмещается — переходит на следующий рабочий день, а если заканчивается в середине дня — остаток отдаётся следующей волне. Выходные пропускаются. Планирование ведётся в часах с поддержкой дробных значений — это понадобится, когда дойдёт очередь до поурочного плана подготовки.

Вторая — двухфазная финализация. Создание элементов CRM не завернёшь в транзакцию базы данных, поэтому сбой посередине оставил бы половину групп созданными, а половину — нет. Поэтому модуль сначала создаёт элементы в CRM, затем в транзакции обновляет собственные таблицы, и если вторая фаза падает — откатывает первую, удаляя только что созданные группы. Повторное нажатие «Сформировать» не плодит дублей. Каждое значимое действие — генерация, перетаскивание, финализация — пишется в журнал: кто, что и когда.

Сколько это заняло.

Оценка на старте была 60 часов разработки и 2,5–3 месяца календарного времени. Рабочая версия стояла на сервере клиента через две недели от первого коммита — дальше шла приёмка, правки по замечаниям методистов и финальное закрытие задачи. Мы не называем это «сделали за две недели»: писать код и сдать систему в эксплуатацию — разные по длительности вещи, и честнее показывать обе.

• Около 6 500 строк собственного кода — бэкенд, интерфейс, стили.
• 73 юнит-теста на планировщик волн, детектор конфликтов, нумерацию групп и проверку прав.
• Три собственные таблицы базы под настройки, запуски формирования и элементы черновика.
• Ноль изменений в ядре платформы — модуль переживает обновления коробки.

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

Что из этого выносить.

Когда бизнес упирается в то, что CRM «почти подходит», решений обычно рассматривают два: терпеть или менять систему. Есть третье — дописать недостающую часть поверх имеющейся. Данные, права, карточки клиентов, сделки и привычки команды остаются на месте; добавляется ровно тот кусок, которого не хватало. Auspex делает такие доработки отдельными модулями — именно чтобы их можно было развивать дальше и не бояться обновлений.