Создать мобильное приложение для обмена сменами и управления доступностью

Определите проблему и метрики успеха

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

Кто получает выгоду (и что им нужно)

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

Руководители смен хотят быстрое покрытие с меньшим количеством переписок.

Менеджеры хотят, чтобы обмены проходили в соответствии с политиками и не создавали неожиданных переработок.

HR/бухгалтерия заботятся о чистых записях, соответствующих табелям и выплатам.

Если вы не согласуете эти группы на раннем этапе, вы создадите мобильное приложение для расписания, которое будет «удобно» для одной роли, но болезненно для другой.

Результаты, на которые стоит ориентироваться

Определите результаты, связанные с затратами, временем и справедливостью:

• Меньше текстов/звонков для заполнения смены (измерять еженедельно).
• Быстрое покрытие открытых смен (время от публикации → принятие).
• Быстрые утверждения (время от запроса → утверждён/отклонён).
• Чёткое соответствие календаря и правил доступности (процент обменов, соответствующих правилам отпуска и доступности).

Решите критерии успеха до запуска

Выберите небольшой набор метрик для MVP и зафиксируйте их сейчас. Примеры: увеличить коэффициент заполнения открытых смен на 20%, сократить время утверждения с 6 часов до 1 часа, или уменьшить число «непокрытых смен» на 30%.

Эти цели подсказывают продуктовые решения, помогают приоритизировать функции вроде push-уведомлений и показывают, работает ли развёртывание.

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

До того как проектировать экраны или строить функции, решите, для кого именно приложение и что означает «валидный обмен». На первый взгляд обмен сменами может выглядеть просто, но правила сильно отличаются по отраслям.

Выберите основных пользователей (и не смешивайте их слишком рано)

Начните с одной понятной аудитории:

• Почасовая розница: много неполной занятости, частые изменения в последний момент, простые навыки.
• Рестораны: распределение по ролям (хост/официант/повар), влияние на чаевые, быстрые утверждения.
• Здравоохранение: строгие сертификаты, правила старшинства, ограничения по переработкам.
• Логистика: требования к покрытию, правила безопасности, обязательные периоды отдыха.

Это решение влияет на всё в вашем приложении: какие данные собирать, какие утверждения нужны и насколько гибким может быть рабочий процесс.

Определите, как создаются смены

Модель расписания обычно одна из этих:

• Фиксированные шаблоны (повторяющиеся паттерны): проще проверять валидность обмена, выше предсказуемость.
• Еженедельные/дневные расписания (создаваемые менеджерами): больше вариативности, больше пограничных случаев.

Также определите атрибуты смен, важные для обменов (локация, роль, код оплаты, время начала/окончания).

Решите стиль утверждения обменов

Ясно определите, кто имеет финальный контроль:

• Peer-to-peer (между коллегами): сотрудники обмениваются напрямую; лучше для низкорисковых ролей.
• Manager-approved (утверждение менеджером): часто для команд с требованиями комплаенса.
• Auto-approved (автоутверждение): только если правила можно надёжно валидировать в системе.

Перечислите ограничения, которые нужно поддерживать

Запишите правила сейчас, а не после запуска:

• Правила профсоюза или договора (старшинство, системы заявок, премиальная оплата)
• Сертификаты/навыки (например, RN vs CNA, права на погрузчик)
• Минимальное время отдыха между сменами
• Ограничения по переработкам и макс. часам

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

Роли пользователей и права доступа

Роли определяют, кто что может делать в приложении — и, не менее важно, кто не может. Чёткие права предотвращают случайные изменения, снижают узкие места в утверждениях и упрощают аудит.

Основные роли для поддержки

Сотрудник

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

Менеджер

Менеджеры утверждают или отклоняют обмены, решают конфликты (переработки, требования по навыкам, недокомплект), создают и редактируют смены и следят за покрытием. В большинстве бизнесов менеджерам также нужна видимость предупреждений о правилах (например, «это превысит недельный лимит часов») и ясная история того, кто и когда запрашивал или утверждал изменения.

Админ

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

Опциональные роли, снижающие трения

Руководитель смены может утверждать обмены в ограниченном объёме (например, та же роль, тот же день) без полномочий полного менеджера.

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

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

Советы по дизайну прав доступа

Используйте RBAC (контроль доступа по ролям) плюс область (локация/команда). Разделяйте “просмотр” и “редактирование” и требуйте утверждений для действий с высоким влиянием — например, при обмене с выходом на переработку или смену в другой локации.

Доступность: какие данные нужны и как их собирать

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

Типы доступности, которые стоит поддерживать

Большинству команд нужны три слоя данных:

• Повторяющаяся еженедельная доступность (например, «Пн–Пт, 9:00–15:00»)
• Разовые исключения (например, «в следующий вторник не могу работать после 13:00»)
• Запросы на отпуск (целый день или частично, желательно со статусом утверждения)

Практичная модель: еженедельный шаблон по умолчанию, исключения как переопределения и отпуск как блок «недоступен», который может требовать утверждения менеджера.

Предпочтения vs жёсткие ограничения

Чётко разграничьте это и в UI, и в данных:

• Недоступен (жёсткое ограничение): сотрудник не может быть назначен.
• Доступен (нейтрально): может работать.
• Предпочитает (мягкое): желает эти часы, но это не обязательно.

Это важно, когда логика планирования или утверждения решает, что блокировать, а что рекомендовать.

Правила валидации, предотвращающие плохие обмены

Даже на этапе MVP добавьте предохранители, чтобы доступность не конфликтовала с политикой:

• Период уведомления: изменения должны вноситься за X часов/дней заранее.
• Блокировочные даты: даты/времена, когда доступность менять нельзя (праздники, пиковые периоды).
• Макс. часов в неделе: предупреждение или блокировка при превышении.

Валидацию выполняйте при сохранении доступности и при применении её к обменам.

UX-совет: обновления меньше чем за 30 секунд

Используйте один экран «Доступность» с недельной сеткой и быстрыми действиями:

• Нажать на день → выбрать Недоступен/Доступен/Предпочтительно
• «Копировать на все будние» и «Повторять каждую неделю» переключатели
• Добавить исключение в один тап из календаря

Если пользователи не могут быстро обновить доступность, они этого не будут делать — в v1 приоритизируйте скорость над глубокой кастомизацией.

Рабочие процессы обмена сменами

Успех приложения часто определяется деталями рабочего процесса. Лучший поток прост для сотрудников, но строг для менеджеров, чтобы можно было доверять расписанию.

Основной поток обмена

Большинству команд нужен предсказуемый путь:

1. Запрос: сотрудник выбирает смену и нажимает «Обмен» (или «Отказаться от смены»).
2. Предложение / принятие: обмен предлагается подходящим коллегам или приглашается конкретный коллега. Коллега может принять (или предложить альтернативу).
3. Утверждение (если требуется): менеджер или супервизор рассматривает запрос.
4. Обновление расписания: после утверждения назначение меняется, и все видят обновление сразу.

Чтобы уменьшить переписку, показывайте инициатору, что будет дальше: «Ждём ответа от Алекса» → «Ждём утверждения менеджера» → «Обмен завершён.»

Полные обмены, частичные и разделение смены

Не каждое изменение — чистый обмен 1↔1.

• Полный обмен: сотрудник A и B меняются целыми сменами.
• Отдать + забрать: сотрудник A освобождает смену; сотрудник B её забирает (обычно в почасовых ролях).
• Частичный обмен / разделение: сотрудник A оставляет часть смены и передаёт остальную.

Если вы поддерживаете разделение, требуйте минимальной длины сегмента и чётких времён передачи, чтобы покрытие не разрушалось.

Проверки конфликтов (до утверждения)

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

• Перекрывающиеся смены (включая время на дорогу/буфер, если релевантно)
• Несоответствие роли (сотрудник не квалифицирован)
• Несоответствие локации (не закреплён за этим магазином/департаментом)

Если что-то не проходит, объясните причину простым языком и предложите исправления (например, «только обученный бармен может взять эту смену»).

Аудиторский след и ответственность

Каждый обмен должен создавать аудит: кто инициировал, кто принял, кто утвердил/отклонил, плюс метки времени и любые заметки. Это защищает сотрудников и менеджеров при последующих вопросах — особенно по оплате, посещаемости и соблюдению правил.

Мобильный UX: экраны и пользовательские потоки

Приложение живёт или умирает в понятности интерфейса. Люди открывают его между задачами, часто одной рукой, и должны за секунды понять «какую смену я работаю?» и «что происходит с моим запросом?».

Представления расписания, отвечающие на разные вопросы

Предлагайте несколько сфокусированных видов, а не один перегруженный календарь:

• Личный список (agenda): простой перечень ближайших смен (сегодня, неделя) с временем, локацией и ролью.
• Командная сетка: быстрый просмотр покрытия по ролям или отделам (полезно для лидов и менеджеров).
• Календарь локации: календарь, отфильтрованный по одному магазину/сайту, чтобы заметить пробелы и пиковые периоды.

Сохраняйте фильтры (локация, роль, диапазон дат), чтобы пользователи не повторяли настройку каждый раз.

Ключевые экраны для снижения трения

Дизайн вокруг основных действий, с консистентным путём назад к расписанию:

• Детали смены: кто, где, когда, роль, заметки и подсказки по правилам (например, «обмен требует утверждения менеджера»).
• Запрос обмена: выбор целевой смены или подходящих коллег, добавление сообщения и показ проверок правил перед отправкой.
• Редактор доступности: быстрые переключатели «может/не может работать», повторяющиеся паттерны и исключения по дате.
• Входящие: единое место для утверждений, вопросов и обновлений — пользователям не должно приходиться искать по вкладкам.

Статусы, предотвращающие недоразумения

Используйте небольшой и последовательный набор статусов с простыми словами и метками времени:

• Pending (Ожидает)
• Accepted (Принято)
• Approved (Утверждено)
• Denied (Отклонено)

Показывайте текущий статус везде, где встречается запрос (карточка смены, детали, входящие).

Базовая доступность

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

Уведомления и сообщения

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

Критические моменты для уведомлений

Фокусируйтесь на событиях, которые прямо меняют рабочий день:

• Новая смена опубликована или назначена (особенно срочные)
• Получен запрос на обмен (для того, кого пригласили)
• Решение по утверждению (утверждён/отклонён)
• Напоминания (запрос скоро истекает, смена начнётся через X часов, вы не ответили)

Каждое уведомление должно отвечать: Что произошло? Что мне нужно сделать? До какого срока? Включайте deep link прямо в экран (например, «Просмотреть запрос на обмен»).

Давайте пользователям выбирать каналы — но не теряйте контроль

Предлагайте push по умолчанию, затем email и по желанию SMS (если поддерживается). Люди разные: медсестра на смене может полагаться на push, а неполный сотрудник — на почту.

Упрощённые настройки:

• Переключатели по событиям (запросы, утверждения, напоминания)
• Тихие часы (например, без оповещений 22:00–7:00)
• Опции эскалации (например, «если я не ответил в 30 минут, также отправить SMS»)

Избегайте спама и усталости от уведомлений

Группируйте, где можно: «3 новые открытые смены на выходных» вместо трёх отдельных пингов. Используйте напоминания экономно и прекращайте их сразу после действия пользователя.

Запасные планы, когда пользователь офлайн или push отключён

Предположите, что push может не работать. Делайте заметный встроенный вход с количеством непрочитанных и выделяйте срочные элементы на главном экране. Если пользователь отключил push, один раз предложите выбрать email/SMS, чтобы срочные запросы не застревали.

Бэкенд и основы модели данных

Приложение выглядит простым в телефоне, но бэкенд должен строго контролировать «кто может работать где и когда». Чистая модель данных предотвращает большинство багов до их появления в интерфейсе.

Основные сущности

Как минимум, планируйте эти строительные блоки:

• Пользователи: сотрудники и менеджеры (профиль, контакты, статус)
• Локации: магазины, клиники, площадки (важен часовой пояс)
• Роли: кассир, медсестра, повар (навыки/сертификаты)
• Смены: дата/время, локация, требуемая роль, назначенный сотрудник
• Доступность: окна «может/не может работать», а также блоки отпуска
• Запросы на обмен: запись предлагаемого обмена, включая решения

Связи (как элементы соединяются)

Практичная стартовая модель:

• Один пользователь имеет много смен (назначенные смены с течением времени).
• Каждая смена принадлежит одной локации и требует одной роли.
• Запрос на обмен связывает двух пользователей (инициатор + целевой) и одну или две смены, в зависимости от типа обмена (отдать vs обмен).

Пример (упрощённо):

Shift(id, location_id, role_id, starts_at, ends_at, assigned_user_id)
SwapRequest(id, offered_shift_id, requested_shift_id?, from_user_id, to_user_id, status)

Состояния запросов на обмен («истина» приложения)

Обращайтесь с обменами как с машиной состояний, чтобы все видели одинаковую реальность:

• pending → accepted или declined
• accepted → approved (если нужно менеджерское утверждение)
• В любой момент: canceled (отменено инициатором), expired (истёкло по таймауту)

Предотвращение двойного бронирования

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

Для команд с высокой нагрузкой добавьте лёгкую блокировку (например, номер версии у смены) для детектирования конфликтов надёжно.

API, синхронизация и производительность

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

Основные API-эндпоинты

Сделайте первую версию компактной и ориентированной на задачи:

• Schedule: получить командное расписание (по локации/команде/диапазону дат), получить детали смены
• Availability: задать/обновить блоки доступности, получить доступность пользователя/диапазон дат
• Swap actions: создать запрос на обмен, принять/отклонить, отменить, просмотреть статус обмена
• Approvals: список ожиданий для менеджера, утвердить/отклонить с указанием причины

Формируйте ответы так, чтобы мобильное приложение рендерило быстро (например, возвращайте смены вместе с минимальной информацией о сотрудниках для показа).

Реальное время: простая синхронизация для MVP

Для MVP используйте пуллинг с «умными» интервалами (обновление при открытии приложения, pull-to-refresh и каждые несколько минут на экране расписания). Добавьте timestamps updated_at на сервере, чтобы приложение могло делать инкрементные запросы.

Webhooks и сокеты можно отложить, если нет острой потребности в обновлениях каждую секунду. Если позже добавите сокеты, начните с событий изменения статуса обмена.

Часовые пояса и переходы на летнее/зимнее время

Храните времена начала/окончания смен в каноничном формате (UTC) плюс часовой пояс рабочей локации. Всегда вычисляйте отображаемое время с использованием часового пояса локации.

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

Выбор хранилища

Используйте реляционную базу для запросов с правилами (конфликты доступности, права). Добавьте кэширование (например, кэш по команде и диапазону дат) для ускорения календарных видов, с инвалидизацией кэша при правках смен и утверждениях обменов.

Безопасность, приватность и комплаенс

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

Аутентификация и безопасность сессий

Решите, как пользователи входят, исходя из реалий заказчика:

• Email/пароль для простых развёртываний
• SSO (Google/Microsoft/Okta) для крупных организаций
• Коды приглашений / magic links чтобы уменьшить работу с паролями

Независимо от выбора, управляйте сессиями: короткоживущие access-токены, refresh-токены и автоматический выход при подозрительной активности (например, токен используется с двух далёких устройств).

Авторизация на каждом запросе

Не полагайтесь на UI, чтобы «скрыть» действия. Применяйте права на каждом API-вызове. Типичные правила:

• Сотрудники могут запрашивать обмены и редактировать свою доступность
• Менеджеры могут утверждать/отклонять и смотреть покрытие команды
• Админы могут управлять локациями, политиками и экспортами

Это предотвращает вызовы приватных эндпоинтов напрямую.

Защита персональных данных по дизайну

Собирайте минимум необходимого для планирования. Шифруйте данные при передаче (TLS) и в покое. Разделяйте чувствительные поля (например, телефоны) и ограничивайте доступ по ролям.

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

Логи аудита и контроль экспорта

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

Добавьте контроль экспорта: ограничьте круг лиц, которые могут экспортировать, ставьте водяные знаки в CSV/PDF и записывайте активность экспорта в лог. Это часто критично для внутренних политик и проверок.

Интеграции: payroll, трекинг времени и календари

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

Payroll и трекинг времени: что синхронизировать

Большинству систем важны отработанные часы и кто был назначен в момент начала смены, а не вся переписка по обмену.

Планируйте экспорт/синхронизацию минимального набора:

• Идентификаторы сотрудников (внутренний ID + внешний ID для payroll/time)
• Локация/код департамента/должности (чтобы правильно применялись ставки и правила)
• Время начала/окончания смен и правила по перерывам
• Финальный назначенец и ссылка на аудиторскую запись (ID обмена, метки времени утверждений)

Если приложение поддерживает премии (триггеры по переработке, дифференциалы), решите, кто это рассчитывает — payroll (предпочтительно) или ваше приложение. В сомнении отправляйте чистые часы и дайте payroll применять правила оплаты.

Синхронизация с календарём (опционально) без чрезмерного разглашения

Полезная функция — read-only доступ к личному календарю, чтобы предупреждать о конфликтах при предложении/принятии смены.

Делайте это приватно: храните только busy/free блоки (без заголовков/участников), показывайте конфликты локально и делайте опцию добровольной.

Webhooks, экспорты и дизайн «добавить позже»

Некоторым клиентам нужны real-time обновления, другим — ночная выгрузка.

Постройте слой интеграций, который поддерживает:

• Webhooks (например, shift.updated, swap.approved) для внешних систем
• Плановые экспорты (CSV/SFTP) для устаревших бухгалтерий

Чтобы избежать переработок позже, скрывайте интеграции за стабильной внутренней моделью событий и таблицами сопоставления (внутренние ID ↔ внешние ID). Тогда добавление провайдера — это конфигурация и трансляция, а не переработка ядра рабочего процесса.

Объём MVP и роадмап продукта

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

MVP: минимальный набор ценности

Стартуйте с функций, которые закрывают повседневный цикл:

• Просмотр расписания (по неделе/дню, роль, локация)
• Установка доступности (предпочитаемые времена, жёсткие блоки «не могу»)
• Запрос обмена (выбрать смену, предложить коллегу, добавить примечание)
• Потоки утверждений (утверждение менеджера и/или согласие коллеги в зависимости от правил)
• Уведомления о новых запросах, утверждениях и срочных изменениях

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

Если вы хотите двигаться быстро и не переделывать стек позже, платформа типа vibe-coding, такая как Koder.ai, может помочь за прототипировать поток целиком (мобильный UI + бэкенд + БД) из структурированного чат-специфика. Команды часто используют её, чтобы проверить машину состояний обменов, права и триггеры уведомлений рано — затем экспортировать код при необходимости глубокой кастомизации.

Полезные фичи на будущее (после стабилизации MVP)

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

• Автоподбор замен на основе доступности и квалификации
• Доска открытых смен, где сотрудники могут брать незанятые смены
• Аукцион/биддинг смен (полезно для востребованных смен, требует чётких правил)

Дорожная карта, уменьшающая риски

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

Отслеживайте метрики: время заполнения смены, число пропущенных смен и сокращение переписок. При планировании вех имейте чеклист готовности (права, правила, уведомления, логи). При необходимости см. /blog/scheduling-mvp-checklist.

Тестирование, пилот и запуск

Тестирование — это не только «кнопки работают», а проверка, что расписание остаётся корректным в реальных условиях. Фокусируйтесь на сценариях, которые рушат доверие.

Сценарии с высоким риском

Проводите энд‑ту‑энд тесты с реалистичными данными (несколько локаций, ролей и правил) и проверяйте итоговое расписание каждый раз:

• Пересечения смен: обмен не должен создавать двойное назначение для одного сотрудника, даже если запросы приходят почти одновременно.
• Истечение запросов: запрос должен автоматически истечь к ясному дедлайну (например, за 2 часа до старта) и уведомления должны прекратиться.
• Менеджерский оверрайд: проверьте, что происходит, когда менеджер утверждает/отклоняет после дедлайна или принудительно назначает смену — история аудита должна сохранять, кто и когда изменил.
• Пограничные временные зоны: тестируйте переходы на DST, сотрудников в разъездах и менеджеров из других часовых поясов; смена должна корректно отображаться и храниться.

План пилота для честной обратной связи

Начните с небольшой группы (одна команда или локация) на 1–2 недели. Поддерживайте короткую обратную связь: ежедневное сообщение и одна 15‑минутная еженедельная ретроспектива.

Организуйте один канал поддержки (например, выделенный email или /support) и соблюдайте обещанные сроки ответа, чтобы пользователи не вернулись к текстам и офлайн‑разговорам.

Измеряйте внедрение и результаты

Отслеживайте несколько метрик, отражающих реальную ценность:

• Активные пользователи (недельные): сколько сотрудников и менеджеров реально используют систему.
• Время завершения обмена: медиана от запроса до финального решения.
• Частота изменений расписания: как часто расписание меняется после публикации (помогает отличить хаос от здоровой гибкости).

Чеклист перед полным запуском

Перед открытием всем:

• Онбординг: 60‑секундный walkthrough и первые подсказки
• Документация: простые страницы «как обменять» и «как работают утверждения»
• Подсказки в приложении: напоминания о дедлайнах и обязательных утверждениях
• План отката: возможность временно отключить запросы на обмен и откатиться к последнему валидному расписанию, если что‑то пойдёт не так