Как мы сделали полностью автоматизированный спортзал для пинг-понга

Небольшая история о том, как мы – VVERH DIGITAL, сделали спортзал для пинг-понга без единого администратора.

К нам обратились два предпринимателя – Дмитрий и Лев из студии Калинин/Маврин. Они хотели сделать мобильное приложение для бронирование теннисных столов в своем спортзале.

Причём они хотели максимальную автоматизацию с минимумом человеческой вовлечённости. Чтобы никаких администраторов, менеджеров, а только камеры, умный свет и автоматические двери.

Ещё летом 2023 года Дмитрий со Львом обращались к нам для реализации их другой идеи — проекта «Александр Ярославович». Это веб-комикс про исторические похождения Александра Невского. К слову, на основе их же книжной версии комикса.

Тем жарким летом мы меньше чем за месяц сделали, протестировали и даже доработали, на основе обратной связи, веб-версию комикса.

Вставить видео-тур по Невскому.

Им понравилась наша работа, а нам понравилось работать с ними. Поэтому, спустя 3 года, Дмитрий и Лев вспомнили о нас и пришли с уже новой идеей к нам на консультацию…

Изначально у заказчика было много идей: двери с временными кодовыми замками, умный свет, камеры с захватом движений и распознавание, с помощью ИИ, «крутых» игровых моментов. Ну чтобы потом делать из этого мини-клипы и отправлять игрокам на почту.

Но никто не знал, выстрелит идея или нет, поэтому ограничились базовыми минимумом для сохранения бюджета — видеонаблюдением и дверьми с персональными кодами доступа (далее СКУД).

Так как мы сами не занимаемся видеонаблюдением и СКУД, мы лишь помогли клиенту в выборе системы. Нам нужно было что-то такое, где есть удобное API, которое можно связать с нашей системой.

Решение нашли довольно быстро — Trassir. Коробочное решение с видеонаблюдением и готовым СКУД. Как раз то, что нужно.

Во время первичной консультации было выявлено много спорных моментов и «слепых зон», связанных с финансами.

Никто не знал ответов на эти вопросы, поэтому мы решили «обкатать» несколько разных вариантов в разные промежутки времени. И в этом нам помог Telegram.

Для начала мы продумали основной базовый сценарий бронирования, оплаты и посещения помещения.

Пока команда мобильной разработки готовила макеты и дизайн будущего мобильного приложения, команда бэкенда решила сделать Telegram-бота и API к нему, чтобы обкатать некоторые процессы работы пользователя с приложением.

В боте мы сделали простое бронирование в три шага, подключили эквайринг и обкатывали несколько недель разные версии бота на одних и тех же людях. Мы протестировали API, систему штрафов с рекуррентными платежами, разные виды автопродления и работу СКУД.

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

Для заказчика нашими разработчиками была создана внушительная панель управления, в которой можно:

А также еще десяток мелких полезных точечных настроек.

Панель управления работает от API, которое поддерживает не только её саму, но и Telegram‑бота, а также будущее мобильное приложение. Всё проходит через одну точку с единой бизнес‑логикой, позволяя одним патчем изменений менять работу сразу двух клиентских узлов (бота и приложения).

Само API написано на Bun — сверхбыстром серверном JavaScript, — чтобы обеспечить высокую скорость работы с тремя важными внешними сервисами: эквайрингом банка, API Telegram и API СКУД Trassir.

Все процессы зафиксированы на бумаге, каждый маршрут API задокументирован, дабы другие разработчики в любой момент могли создать новый клиентский узел, например — сайт или иной веб‑кабинет с бронированием столов. Это было в будущих планах клиента, если концепция «выстрелит». Наша задача — лишь заложить прочный фундамент, и мы с ней справились.

Во время разработки Telegram‑бота и API мы нашли слабые места в процессах, а также набрали большое количество обратной связи, как положительной, так и негативной.

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

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

А ещё немало крови выпил СКУД от Trassir, который первое время любил отключаться по своему желанию в определённое время, блокируя генерацию кода для посетителя зала. И пока инженеры‑интеграторы настраивали и регулировали Trassir, чтобы минимизировать сбои, мы разработали клиенту модуль в панели управления, откуда можно создавать временные коды доступа.

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

Само приложение было решено делать на нативе: для iOS мы использовали Swift, а для Android — Kotlin. Теоретически мы могли бы использовать кроссплатформу, например какой‑нибудь React или Flutter, но:

Во‑первых, мы хотели сохранить нативное ощущение от использования мобильного приложения у пользователей iOS, ведь кроссплатформа с этой задачей не справляется. А пользователей «яблочной» операционной системы у нас оказалось большинство среди всех клиентов заказчика, судя по аналитике, которую мы собирали в Telegram‑боте.

Во‑вторых, клиент хотел в будущем добавить интеграцию с просмотром записей с камер в спортзале… А наша команда на этом в своё время «собаку съела», и мы точно знали, что при работе с видеопотоками трансляций кроссплатформа сделает нам больно — в отличие от чистой разработки на Swift и Kotlin.

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

А за это время, пока мы делали свою кодерскую работу, заказчик доводил до ума пространство спортзала, ведь за тестовый запуск через Telegram набралось достаточно обратной связи: то мячи улетали далеко, то ракетки терялись, то воды питьевой не хватало.

Клиент это учел и повесил на стены сетки, для ракеток создал специальные стенды, ну а с водой все проще – её стало больше. Также, клиент оборудовал помещение сидячими местами для зрителей.

Улучшения происходили со всех сторон — не только в онлайне, но и офлайн работал. Поэтому наша совместная работа с заказчиком создала вот такой интересный проект, о котором не стыдно рассказать. Если будете в Екатеринбурге, то заходите в ПИНГСПОТ на Свердлова 56.

Это была краткая история. Если хотите заглянуть под капот глубже — технологии, этапы, решения — весь кейс целиком ждёт вас здесь: ПИНГСПОТ.

А если вам нужна такая же крутая разработка с продуктовым подходом — переходите на сайт Vverh.digital и оставляйте заявку!