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

Но красивый интерфейс — лишь верхушка айсберга.

Самое интересное началось тогда, когда мы стали реализовывать реальные рабочие сценарии.

Потому что между «сделать приложение со списком задач» и «создать систему, которой сотрудники пользуются каждый день» — огромная разница.

Архитектура

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

🐧 Debian — серверная операционная система. 🐍 Django — backend и бизнес-логика. 🐘 PostgreSQL — хранение данных. ⚙️ Gunicorn + Nginx — обработка запросов и выдача файлов. 📱 Android — приложение для сотрудников. 🌐 Веб-интерфейс — управление и контроль для руководителей.

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

Проблема №1. Фотофиксация

Для контроля качества недостаточно поставить галочку «Готово».

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

Мы реализовали настройку требований к фото на уровне типа объекта.

Но тут возникает другая проблема.

150–170 уборок ежедневно — это огромный поток изображений.

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

Поэтому предусмотрели отдельную политику хранения: фотографии в рабочей системе автоматически удаляются после установленного срока.

А материалы, которые необходимо сохранить в рамках обращений, остаются в отдельной системе заявок.

Проблема №2. Доработка — не новая уборка

Один из самых интересных сценариев.

Горничная завершила уборку. Супервайзер проверил результат и обнаружил замечание.

Что делать?

Наивный вариант — создать новую задачу или сбросить старую.

Но тогда теряется история, время и уже отмеченные пункты.

Мы реализовали отдельный цикл доработки.

Супервайзер указывает замечания. Горничная получает задачу обратно, устраняет недочёты и повторно отправляет результат.

При этом чек-лист сохраняется, а время выполнения продолжает учитываться.

Мелочь на уровне интерфейса, но довольно важное решение на уровне бизнес-логики.

Проблема №3. Интерфейс, который мешает работать

Поначалу столкнулись с неожиданным эффектом.

Сотрудник отмечает пункт чек-листа, страница обновляется и прокручивается наверх.

Представьте, как раздражает это при десятках повторяющихся действий.

Пришлось оптимизировать обновление данных и сохранение состояния интерфейса.

Ещё один момент — скорость работы при просмотре фотографий и переключении между задачами.

Здесь стало очевидно: приложение должно подстраиваться под рабочий процесс, а не заставлять сотрудника подстраиваться под приложение.

Проблема №4. Обновления Android-приложения

Разрабатывать APK недостаточно.

Нужно ещё обеспечить его распространение и обновление.

Поэтому в backend предусмотрели отдельный API для обновлений мобильного приложения.

Это позволяет централизовать работу с версиями APK и не превращать каждое обновление в отдельную техническую операцию.

Что в итоге?

Получилась не просто программа для горничных.

Мы разработали собственную клиент-серверную платформу с ролями, бизнес-процессами, фотофиксацией, контролем качества, историей выполнения и управлением объектами.

И главное — она создавалась не ради технологии.

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

Для меня это и есть самая интересная сторона IT: не просто поддерживать инфраструктуру, а создавать инструменты, которые меняют повседневную работу.

А какой самый неожиданный нюанс бизнес-процесса вам приходилось учитывать при разработке?