Информация
- В рейтинге
- 913-й
- Откуда
- Тверь, Тверская обл., Россия
- Работает в
- Дата рождения
- Зарегистрирован
- Активность
Специализация
Фулстек разработчик, Архитектор программного обеспечения
Средний
От 10 000 000 ₽
Git
SQL
PostgreSQL
MySQL
ООП
Базы данных
REST
PHP
PHPMyAdmin
JavaScript
Да, вы правильно подсветили несколько сложных мест.
Только я бы разделил это на текущий этап и будущую инфраструктуру.
Сейчас Gooly не интегрируется с системами бронирования площадок и не обрабатывает платежи внутри платформы. Оплата, если она есть, идёт напрямую между участником и организатором, а в системе фиксируется только организационный статус участия.
На текущем этапе задача проще: проверить, помогает ли структура события организатору собрать людей лучше, чем обычный чат.
Интеграция с площадками и бронированиями - это уже следующий слой, и там действительно появляются отдельные вопросы: безопасность, права доступа, синхронизация, юридическая модель, персональные данные и т.д.
Поэтому я не пытаюсь сразу строить «единую систему для всех площадок». Сейчас проверяю базовый сценарий: событие -> участники -> подтверждение -> повторяемость.
Если этот сценарий подтвердится, тогда уже можно аккуратно двигаться в сторону B2B и интеграций, но не наоборот.
Да, вы очень точно описали проблему.
Как только сценарий становится сложнее обычного «иду/не иду», организатор превращается уже не просто в человека, который создал чат, а в координатора всей логики: - кто идёт - кто голосовал - кто слился - как пересекаются интересы участников - как принять итоговое решение
И всё это приходится держать вручную.
Про интеграции с мессенджерами — хороший поинт, взял на заметку. Нужно подумать в этом направлении, потому что людям действительно важно оставаться в привычной среде.
На самом деле это как раз хороший пример того, как люди постепенно сами достраивают систему поверх обычного чата
Появляются: - правила - штрафы - отдельные чаты - фиксация оплат - ограничения - ручная модерация
И да, для многих сообществ этого действительно достаточно.
Но мне как раз стало интересно: можно ли часть этой организационной нагрузки снять с организатора и превратить это в более структурированный процесс.
Потому что чем больше людей, организаторов и регулярных активностей — тем сильнее всё начинает держаться на ручном администрировании и дисциплине участников.
Для разовых и небольших сборов - да, согласен
Я и сам так много лет собирался через чаты.
Проблемы начинаются обычно позже: - когда активности становятся регулярными - когда появляется несколько организаторов - когда нужно фиксировать оплаты - когда люди начинают сливаться в последний момент - когда нужно добирать участников - когда параллельно идут флуд, мемы и сам сбор
То есть Telegram отлично решает коммуникацию, но не очень хорошо решает именно структурирование повторяющихся офлайн-активностей.
Собственно, из наблюдения за этим и появилась идея Gooly.
Да, согласен 🙂
Я как раз постепенно к этому и пришёл в процессе.
Изначально смотрел на проблему только со стороны организаторов и участников, но потом понял, что площадки тоже теряют из-за всей этой неструктурированности:
- отмены в последний момент
- недоборы людей
- пустые слоты
- сложность с повторными бронированиями
Поэтому сейчас одна из идей развития - как раз подключение самих площадок в систему.
Чтобы это был уже не просто «чат для сборов», а нормальная инфраструктура:
участники ↔ организаторы ↔ площадки.
Скорее тут проблема была не столько у самих владельцев полей, сколько у людей, которые регулярно собирают игроков 🙂
Поле свою задачу выполняет: время забронировано - деньги получены.
А вот дальше начинается хаос уже на стороне организатора: кто придёт, кто оплатил, хватает ли людей, нужно ли срочно кого-то искать и т.д.
Но в процессе как раз понял, что площадки тоже могут получать пользу от такой системы. Например, через нормальную систему бронирований, автоматизацию и более стабильную загрузку.