Диспетчерская общественного транспорта
Январь 2024 – Ноябрь 2024 · Ведущий продуктовый дизайнер · Web Service
Коротко о главном
Разработал модуль диспетчерского контроля для государственной транспортной системы Тюменской области. Провёл исследование с диспетчерами, отстоял архитектуру на основе данных, сдал в срок. Сократил время реакции диспетчера до 2 минут. Система масштабирована на весь регион — на неё приезжают учиться из соседних областей.
Контекст
Тюменская область реализует локальный проект по внедрению интеллектуальных транспортных систем в рамках федеральной программы — для городов с населением свыше 300 тысяч человек. Финансирование через субсидию из федерального бюджета. В рамках этого проекта ГКУ ТО «Центр информационных технологий» разместил госзакупку на 2 этап развития модуля УДОТ — части Региональной навигационно-информационной системы Тюменской области. Модуль уже существовал и использовался, задача — расширить функциональность диспетчерского контроля. Я получил задачу как единственный дизайнер на проекте. Сроки жёсткие: разработка, тестирование, инструктаж пользователей и приёмо-сдаточные испытания — всё до 22 ноября 2024.
Что усложняло работу
Госконтракт измеряется соответствием функциональным требованиям ТЗ, а не пользовательским опытом. Деньги выплачиваются по факту приёмки. Это означало: нельзя отступить от ТЗ, но при этом ТЗ описывало функции, а не сценарии. Я провёл исследование за рамками контракта — чтобы сделать продукт который реально работает, а не только проходит испытания.
С чем обратился заказчик
Диспетчеры работали в нескольких несовместимых инструментах одновременно: устаревшая карта, таблицы, мессенджеры, звонки водителям. Чтобы найти проблемное ТС и принять решение, уходило до 30 минут. В рамках госконтракта срыв рейса — это не только операционный сбой, но и нарушение условий контракта с финансовыми последствиями для перевозчика.
Моя задача
Спроектировать модуль диспетчерского контроля в составе РНИС ТО — Региональной навигационно-информационной системы Тюменской области. Никакого предшествующего дизайна, никакой пользовательской базы — только объёмное ТЗ госзаказчика, федеральные требования к ИТС и доступ к реальным диспетчерам.
Исследование
Я лично провёл качественное исследование с диспетчерами. Цель — понять не что они делают, а в каком порядке и почему. Эти данные легли в архитектуру и помогли отстоять решения перед командой и заказчиком.
Диспетчеры сначала фильтруют, потом работают. Никто не открывает «всё сразу» — сначала сужают контекст до нужных маршрутов и ТС. Это стало основой последовательного фильтра как обязательной точки входа.
Каждый сеанс — один конкретный сценарий. Диспетчер либо смотрит карточку ТС, либо разбирает остановку, либо фильтрует — но не всё одновременно. Это противоречило идее руководителя «показывать всё на одном экране».
Большинство действий происходит с ТС. Карточка ТС — главная рабочая единица. Из этого инсайта появились быстрые действия прямо в карточке.
Первая гипотеза
Если мы структурируем интерфейс вокруг последовательных сценариев диспетчера — фильтр → один фокус → действие — то диспетчер будет быстрее находить проблему и реагировать на неё, чем при работе с дашбордом где всё доступно сразу.
Как мерили успех
В проекте не было заранее определённых KPI — ТЗ госзакупки измерялось выполнением функциональных требований. Я самостоятельно выявил ключевые метрики на основе данных исследования и обосновал их команде до запуска.
  • 3 мин
    Время реакции на проблему
  • −20%
    Сорванные рейсы
  • −25%
    Ошибки в оперативном управлении
Метрики зафиксированы по итогам тестирования на пользователях до запуска в продакшн. Постпродакшн аналитику заказчик не предоставил — это типично для госпроектов с приёмкой по ТЗ.
Решение и макеты
Мультивыбор перед переходом на карту. Диспетчер сначала определяет контекст — какие маршруты нужны — и только потом переходит к работе. Поток «фильтр → действие» закреплён в самой структуре экрана.
Цветовые статусы и сортировка. Нештатные ТС автоматически наверху и выделены цветом. Диспетчер считывает проблему за секунду — не читая текст, не сканируя весь список.
Переключение карта / схема. Таб вверху позволяет перейти к мнемосхеме не теряя выбранный контекст.
Боковая панель не перегружена. Только нужные маршруты и их ТС — те, что выбрал диспетчер на предыдущем шаге.
Контекстное меню по ТС. Все действия в одном клике прямо на карте — без перехода на другой экран и потери пространственного контекста.
Остановки распределены равномерно. Я разделил сценарии: мнемосхема — для контроля интервалов, карта — для расстояний.
Цветовые интервалы. Зелёный — в расписании, синий — незначительное отклонение, красный — значительное. Проблемное ТС заметно мгновенно.
Несколько маршрутов одновременно. Каждый — отдельная строка. Контролёр с несколькими перевозчиками видит всё без переключения.
Контекст прямо в уведомлении. Маршрут, госномер, описание нарушения — диспетчер понимает ситуацию до открытия карточки.
«Написать водителю» из уведомления. Один клик без поиска ТС на карте. До этого диспетчер тратил время на поиск автобуса, звонил по телефону или писал в сторонний мессенджер.
План/Факт наверху. +20 минут опоздания — первое что видит диспетчер. Не нужно искать значение в отдельной таблице.
Список остановок с текущей позицией. Диспетчер видит где ТС сейчас и куда движется — без переключения на карту.
Все действия в одном месте. Написать водителю, изменить статус, история, справочник — без лишних переходов. Именно этого не было в старых инструментах.
График скорости и трек синхронизированы. При наведении на график — точка на карте. Диспетчер видит скорость, статус и время в любой момент истории.
Добавление других ТС. Сравнение треков нескольких автобусов — полезно при разборе инцидентов на маршруте.
Связь с водителем — одно из главных действий. Раньше это был звонок или сторонний мессенджер.
Карта остаётся видна. Чат открывается поверх карты — диспетчер продолжает видеть положение ТС во время переписки.
Работа с командой
Конфликт с руководителем проекта: он предлагал дашборд «всё сразу», основываясь на личном суждении. Я показал данные сессий: диспетчеры работают последовательно, каждый сеанс — один сценарий. Дашборд создал бы когнитивную перегрузку и замедлил реакцию. Аргумент приняли — архитектура построена на данных исследования.
Аналитик: «расстояния на мнемосхеме должны соответствовать реальным». На межмуниципальных маршрутах разброс расстояний — от 2 до 40 км. Пропорциональные сегменты сделали бы схему нечитаемой. Я предложил разделить сценарии карты и мнемохем. Каждый инструмент решает одну задачу — интерфейс не пытается совместить несовместимое.
Аналитик: «переименовать "Контроль графика" в "Выставление сходов"». Функция охватывает установку и снятие сходов, а также замену транспорта — название «Выставление сходов» описывает только часть. Я сослался на единообразие системы: название устоялось в других разделах платформы, смешение понятий создаёт путаницу для пользователей которые работают с системой каждый день. Оставили «Контроль графика».
Мой личный вклад
Я провёл качественное исследование с диспетчерами, сформулировал инсайты которые изменили архитектуру, спроектировал все экраны, тестировал макеты на пользователях и проработал корнер-кейсы. Трижды отстоял решения перед командой, оперируя данными а не мнением.
Нельзя было отступить от ТЗ, но при этом нужно было сделать продукт который реально решает проблему диспетчера, а не только закрывает пункты технического задания.
Без исследования проект пошёл бы по пути перегруженного дашборда, который закрывал бы требования ТЗ, но не решал реальную проблему.
Тесты до релиза
Дизайн дорабатывался параллельно с обсуждениями с заказчиком. Каждая итерация — реальная задача из бэклога, которая прошла обсуждение и тестирование до приёмо-сдаточных испытаний. На испытаниях удалось измерить только время реакции, оно составило 2 минуты — остальные метрики (сорванные рейсы, ошибки управления) отслеживаются в операционной работе, к которой доступа после сдачи не было.
Расширили карточку: план/факт, остановки, водитель, быстрый доступ к рейсам. Закрепило инсайт из исследования — большинство действий диспетчера происходит с ТС.
Итерация со схемой маршрута выявила конфликт сценариев — карта для пространства, мнемосхема для интервалов. Отсюда таб-переключатель и равномерное распределение остановок.
После детального разбора ТЗ с заказчиком скорректировали ряд экранов: уточнили поведение грида, доработали логику уведомлений, согласовали отображение нештатных статусов.
Результаты
Модуль сдан в срок — 22 ноября 2024 года, прошёл приёмо-сдаточные испытания и запущен в продакшн в составе РНИС ТО. Диспетчерская — часть системы которая работает на уровне всего региона и получила публичное признание.
Масштаб: весь регион. Подсистема управления общественным транспортом масштабируется с Тюмени на всю Тюменскую область. Операторы ситуационного центра в режиме реального времени отслеживают автобусы, например, в Ишимском районе.
Связь с пассажирским опытом. Система трансформировалась в приложения «Транспорт 72» и «Тюменский транспорт» для жителей области. Работа диспетчера напрямую влияет на качество данных которые пассажир видит в приложении.
Межрегиональное признание. Замминистра транспорта Свердловской области приезжал в ситуационный центр ИТС изучать тюменский опыт как лучшую практику. Регионы договорились об обмене практиками.
Федеральный уровень. Система представлялась участнику президентской программы «Время героев» и демонстрировалась на форуме «ИНФОТЕХ-2024». Создана в рамках нацпроекта «Безопасные качественные дороги».
Предыдущий проект
На главную
Новости о проекте
7+ лет опыта работы · от первых идей до разработки продукта
Давайте работать вместе!