Концепт «Рядом»

Выбрать место, проверить свободный час и получить понятную бронь. Для администратора — единый календарь, правила доступа и исключения.

Концепт-проект: «Рядом» — вымышленная компания. Результатов работы здесь нет: только решения и гипотезы.

О заказчике

• Сценарий: Почасовые переговорные и рабочие места одной площадки
• Участники: Посетитель, организатор команды, администратор
• Первая версия: Выбор ресурса, доступность, бронь, перенос и календарь
• Граница: Без обещания готовой сети, платежей или достигнутой загрузки
• Данные: Названия, стоимость и события на экранах — условия учебного примера

Задача

В вымышленной сети рабочих пространств администратор принимает заявки в мессенджере, а свободные часы отмечает в таблице. Посетитель не видит подходящий ресурс и не знает, принята ли заявка. Одно помещение может попасть в два обещания, а перенос теряется между сообщениями.

Концепт рассматривает не туристический каталог, а почасовую работу пространства: переговорные, рабочие места и оборудование. Отдельные правила нужны для посетителя, организатора команды и администратора. Время связано с зоной площадки; изменение расписания не должно незаметно переносить подтверждённую встречу.

Риски исходного процесса

Свободный час обещан дважды

Доступность повторно проверяется при подтверждении. Конкурирующая бронь получает понятный отказ и альтернативы.

Посетитель не понимает статус

Выбор слота, ожидание подтверждения и принятая бронь имеют разные состояния. Потерянный ответ восстанавливается по операции.

Перенос теряется в переписке

Изменение сохраняет исходную бронь до принятия нового интервала; история показывает автора и уведомления.

Зона устройства меняет смысл

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

Решение

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

Личный кабинет показывает принятый результат, условия переноса и историю. Администратор видит календарь ресурса, обслуживание и исключения. Перенос проходит через проверку нового интервала и уведомление участников; прежняя бронь не исчезает раньше успешного принятия изменения. Оплата и сложные абонементы остаются отдельным этапом, если они нужны заказчику.

Как устроен продукт

1. Каталог пространства. Вместимость, оснащение, доступность и стоимость учебного примера. Зачем: Выбор начинается с реальных условий задачи.
2. Карточка переговорной. План помещения, оборудование и доступные интервалы выбранной даты. Зачем: Пользователь сравнивает ресурс до подтверждения.
3. Подтверждение. Дата, зона, длительность, участники и правила изменения. Зачем: Существенные условия видны в одной версии предложения.
4. Мои брони. Принятые события, история, перенос и отмена. Зачем: Потеря письма не лишает человека доступа к результату.
5. Календарь площадки. Ресурсы по времени, занятость и обслуживание. Зачем: Администратор видит конкретное пересечение.
6. Изменение расписания. Предпросмотр затронутых событий и решение по каждому. Зачем: Настройка не переписывает обязательства молча.

Что помогает пройти сценарий

Доступность перед принятием

Чтение свободного слота не является резервом. Подтверждение сверяет актуальную занятость и сохраняет один результат.

Перенос с контекстом

Видны старый и новый интервал, условия и участники. Устаревшая версия не заменяет изменение коллеги.

Понятное восстановление

Повтор подтверждения возвращает состояние той же попытки. Неизвестный результат не создаёт вторую бронь.

Ключевые сценарии

Забронировать переговорную

Выбор подходящего ресурса заканчивается принятым результатом.

На входе: Посетителю нужна переговорная на шесть человек с экраном на час. Выбранное окно может занять другой пользователь.

1. Сравнить вместимость и оснащение.
2. Выбрать интервал во времени площадки.
3. Проверить условия и участников.
4. Подтвердить актуальную доступность на сервере.

На выходе: Принятая бронь доступна в истории с ресурсом, интервалом и условиями.

Если что-то пошло не так: Если окно уже занято, прежнее предложение не объявляется успехом; показываем подходящие альтернативы.

Критерий приёмки: Две параллельные попытки не создают пересекающиеся принятые брони одного ресурса.

Перенести встречу

Изменение не теряет первоначальную договорённость.

На входе: Бронь принята; организатор выбирает другой час, пока коллега меняет список участников.

1. Открыть актуальную версию.
2. Выбрать новое окно и посмотреть разницу.
3. Подтвердить разрешённое изменение.
4. Сохранить историю и пересмотреть уведомления.

На выходе: Новый интервал принят, участники видят согласованный результат.

Если что-то пошло не так: Устаревшее подтверждение отклоняется; исходная бронь сохраняется до успешного переноса.

Критерий приёмки: История показывает старое и новое значение; старое напоминание не отправляется.

Закрыть ресурс на обслуживание

Администратор видит последствия до изменения расписания.

На входе: Помещение нужно закрыть на обслуживание; в интервале уже есть подтверждённая встреча.

1. Указать ресурс и период.
2. Показать затронутые брони.
3. Выбрать разрешённое решение для каждой.
4. Опубликовать новую доступность и уведомления.

На выходе: Новые брони не используют закрытый интервал; существующие обязательства обработаны явно.

Если что-то пошло не так: Незавершённое решение по принятой встрече блокирует молчаливое закрытие.

Критерий приёмки: Нет незаметно исчезнувших броней; журнал содержит автора и основания решения.

Роли пользователей

Посетитель

Находит подходящую переговорную и бронирует понятный интервал.

Место подходит и час действительно свободен?

Организатор

Проверяет участников, оборудование и условия встречи.

Кто приглашён и что включено в бронь?

Администратор

Управляет расписанием и исключениями без потери принятых обязательств.

Какие изменения затронут уже подтверждённые встречи?

Как устроено технически

Данные и интервалы

Ресурс, площадка, именованная зона, интервалы и версии расписания. Событие имеет однозначные начало и окончание.

Согласованное принятие

Серверная проверка пересечения и идемпотентная операция. Вариант реализации — PostgreSQL и явная модель состояний.

Уведомления

Задания связаны с принятой версией события. Перенос или отмена пересматривают старые напоминания.

Права и наблюдаемость

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

Что входит в разработку

• Одна площадка и модель ресурсов
• Каталог и карточка пространства
• Доступность на ограниченный горизонт
• Принятие и восстановление брони
• Кабинет посетителя
• Перенос и отмена с историей
• Календарь администратора
• Напоминания и журнал
• Приёмка конкурирующих запросов и времени

План реализации

1. Обследование: фиксируем роли, источники и границы первой версии.
2. Прототип: проверяем нормальную задачу и исключения с представителями ролей.
3. Вертикальный срез: связываем один маршрут с согласованными данными.
4. Параллельная проверка: сравниваем результат с исходным процессом.
5. Пилот: проверяем критерии, журнал и восстановление, затем определяем следующий этап.

Что замеряем после запуска

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

Стек

React, TypeScript, PostgreSQL, API учётной системы.

Все кейсы · Услуга · Калькулятор стоимости

Шесть экранов рабочего сценария

Полноценные макеты на русском: выбор, решение, история и мобильный маршрут. Данные вымышлены; достигнутые результаты не заявляются.