Проблема: мероприятие держалось на трёх сотрудниках и флипчарте
Крупная московская организация, поддерживающая экспортно ориентированные компании, регулярно проводит деловые и спортивные мероприятия для бизнес-сообщества. Очередной корпоративный турнир по паделу обещал собрать сотни участников и зрителей: несколько параллельных кортов, десятки матчей в один день.
Подготовка к таким событиям годами велась вручную. Заявки собирали через почту и мессенджеры, затем сводили в таблицы. Жеребьёвку проводили на бумаге, результаты переносили в Excel. Расписание матчей по кортам рисовали маркером на флипчарте — любое изменение означало переписывание всей сетки заново. Счёт на табло обновляли голосом или в лучшем случае в чате: зрители узнавали результат через 10–15 минут после окончания игры. В день турнира судьи, оператор, хостес и игроки работали каждый в своём файле, и данные не сходились.
Главная боль: мероприятие на 200+ человек держалось на ручном труде трёх сотрудников. Одна ошибка в расписании — и половина сетки «плыла».
Цель: единая платформа от регистрации до награждения
Заказчик хотел получить цифровую систему, которая закроет весь турнир.
Конкретные требования:
Решение: 29 дней от старта до боевого запуска
Работа началась 17 июля, турнир был назначен на 15 августа. На всё про всё — 29 дней.
Неделя 1 — архитектура и прототип. Собрали требования с организатором и главным судьёй. Определили роли: участник, судья, оператор, хостес, зритель. Спроектировали схему данных: команды, группы, матчи, корты, раунды. Сразу заложили WebSocket-канал для обновления табло — чтобы не перезагружать страницу.
Неделя 2 — регистрация и жеребьёвка. Сделали публичную анкету участника. Настроили формирование команд и автоматическую жеребьёвку по группам. Заказчик хотел, чтобы сильные игроки не попали в одну группу, — добавили механику посева. Это было нестандартно: обычно жеребьёвка случайная, а тут пришлось учитывать рейтинг.
Неделя 3 — групповой этап и расписание. Реализовали круговую систему. Алгоритм сам строил расписание: сколько кортов, сколько раундов, кто с кем и во сколько. Если матч затягивался, оператор мог сдвинуть время, и расписание пересчитывалось на лету.
Неделя 4 — плей-офф, табло и админка. Собрали сетку плей-офф, сводную таблицу уровней с медалями. Сделали админ-панель для ввода результатов. Судья вводит счёт — табло у всех зрителей обновляется за секунду. Плюс автоматическая подстраховка: если WebSocket отвалился, данные подтягиваются через резервный канал.
Что было нестандартного:
Результат: цифры до и после
Турнир прошёл. Платформа отработала под реальной нагрузкой. В день соревнований ей одновременно пользовались судьи, оператор, хостес и сами игроки. Команда была на связи и решала запросы прямо во время события.
Турнир прошёл. Платформа отработала под реальной нагрузкой. В день соревнований ей одновременно пользовались судьи, оператор, хостес и сами игроки. Команда была на связи и решала запросы прямо во время события.
Комментарий заказчика
«Это получилась система, которой пользовались и судьи, и оператор, и хостес, и игроки. Мощная штука, и она выдержала. Отдельное спасибо, что были на связи и оперативно решали наши запросы».
Комментарий исполнителя
«Главная сложность была не в коде, а в том, чтобы уложить в 29 дней согласование ролей и сценариев. Мы намеренно заложили WebSocket и резервный канал на первой неделе — это дало запас прочности на день турнира. Механика посева при жеребьёвке тоже потребовала отдельной логики: обычно всё случайно, а здесь нужно было учитывать рейтинг игроков. В день события платформа выдержала сотни одновременных зрителей, а расписание пересчитывалось без остановки матчей. Именно это и было целью: убрать ручной труд и дать организаторам единый инструмент».
Названия компаний и имена не раскрываются по условиям NDA.