Как мы создавали сервис для улучшения города в Ташкенте (Узбекистан)
Этот материал посвящен сервису Xalq Nazorati (Народный Контроль) — с ним люди могут пожаловаться на нерабочий лифт, яму на дороге, сломанный светофор или стертую дорожную разметку. В статье расскажем, с чего мы начинали проект, какие ошибки допускали, как их исправляли и где в итоге оказались.
Резюме
Сегодня в сервис Народный Контроль уже поступило более 17 тыс. обращений от горожан — чаще всего люди жалуются на проблемы на дорогах, ЖКХ и экологические проблемы.
92% всех обращений были в итоге решены.
Чтобы контролировать работу сервиса и обеспечить реальное решение проблем, мы разработали рейтинг районов города, тем самым мотивируя чиновников не отмахиваться от проблем.
Чтобы лучше обозначать раскрытие темы, используем индикатор из хорошо знакомой многим игры. Так интереснее.
Итак, начнём:
Задача
Начнём с определения требований — что должен был делать сервис, зачем он нужен? Ведь и так много разных порталов для подачи заявлений и жалоб на работу госорганов. Посмотрев все, мы поняли, что при всех прочих равных у таких сервисов есть три больших минуса.
Первое — госорган должен обязательно ответить письмом (бумажкой) так как все заявки были приравнены к закону о подаче обращений (там 15–30 дней, официальное письмо и всё такое), что значительно тормозит процесс ответа, даже если он есть вот тут, под рукой. Меня как гражданина это никак не успокаивает.
Второе — на той стороне экрана (мир исполнителей данных заявок) ничего для удобства исполнителей не сделано. Они просто получают письмо, распечатывают его и несутся исполнять, но бюрократическая машина превращает это в бег с препятствиями. Так как созданная система не подразумевает только получение по электрической электронной почте и отправку по ней же. Причём отсканированным письмом за подписью руководителя.
Конечно, у этого процесса есть свои цели, в основном сделать ответ официально оформленным и возложить ответственность на руководителя. Поэтому, даже если у исполнителя ответ готов за 3 дня или за 7, в любом случае процесс его оформления занимает пару дней, а иногда и больше.
А еще, пока ответ исполнителя дойдет до гражданина по почте, пройдет еще несколько дней.
Также важно учитывать что бумажные письма доставляются исполнителям через канцелярию —, а это люди, а не автоматизированная система. Поэтому обычно письмо проходит 3–4 руки перед доставкой непосредственно самому исполнителю —, а это лишнее время.
Третье — это отсутствие человека, который должен контролировать качество работы исполнителей: они правда пытаются решить проблему или стараются просто избавиться от назойливой жалобы?
Итак основная задача была задана: сделать удобный сервис по подаче и получению ответа и общению между исполнителями и заявителями. Удобный сервис для обеих «сторон экрана». Скажем так, сократить расстояние между участниками процесса.
ну и как мы все знаем правильно поставленная задача укрепит твой фундамент-ступни
Архитектура сервиса
Архитектура сервиса — удобное понятие, которым многие пользуются по-своему и не всегда правильно. Никто из нас не заканчивал «сервисо-архитектурный университет» и не обладает знаниями глубинного познания чудотворной архитектуры, которая позволит тебе и твоему сервису работать как швейцарский нож швейцарские часы. Но чтобы такие часы создать, мы должны были выстроить логику сервиса как в CRM (customer relationship management), поскольку нам нужна была система, которая может одновременно обслуживать большое количество клиентов, при этом не ломаясь и выдавая своевременный фидбек всем участникам.
Также нам было важно, чтобы в системе была возможность обсуждения проблемы не просто двумя сторонами, но и тремя или даже четырьмя: например, в чате одновременно могут общаться горожанин, представитель районного хокимията, представитель Тошиссиккувват (отвечает за горячую воду и отопление в городе) и, скажем, ГУЖКО (координирующий орган по вопросам ЖКХ).
В качестве БД мы выбрали Postgresql, потому что это проверенное временем, надежное, масштабируемое решение, а также оно интегрируется с Django сразу из коробки. Типом нашего хранилища выступил PostgreSQL — преимущественно реляционная СУБД, так что и модель данных, соответственно, реляционная. У нас все сущности предметной области довольно четко структурированы и прописаны, так что не было необходимости заводить какие-то иные по типу хранилища данных. Ну мы еще использовали redis как буфер для некритичных временных данных и для всякого кеширования.
На бэке у нас — python, django, а на фронте у части пользователей Vue JS, а у другой — никакого фреймворка, потому что изначально проект планировался как одна форма отправки обращений, а когда он начал расширяться, уже было поздно и накладно что-либо коренным образом менять. Кстати, скоро мы как раз планируем переписать эту часть проекта на реакте, чтобы структурировать фронт и отделить логику сервиса от логики представления.
та самая архитектура
Идентификацию через государственный центр персонализации мы сделали обязательной. Потому что, мы понимали, что если сделать возможность отправки заявок анонимно, то продуктивной работы бы не было. Элементарно, мы не смогли бы отфильтровать действительный заявки от заявок-хулиганства. При чем, даже учитывая регистрацию по паспортным данным, в начале старта сервиса, были заявки, сделанные ради забавы, некоторыми пользователями.
При этом, вся система авторизации и идентификации работает по защищенному шлюзу — как своеобразный G2G VPN.
Далее свое место занимает система распределения заявок по темам — она важна, чтобы мы не теряли «хвосты» заявок, понимали, к какой проблеме какая заявка относится и к кому ее нужно направить для решения.
Благодаря тщательной работе по анализу и каталогизированию гос.струкур, у нас есть таблицы соответствия категорий проблем, организаций, направлений, исполнителей. Имея четкую структуру того, кто за что отвечает и кто кому подчиняется, сделать все это просто: при отправке заявки смотрим, к какой категории относится заявка, затем берем соответствующего исполнителя и назначаем его на решение данной заявки. Это исполнитель первого уровня. Чаще всего на каждую заявку есть один такой исполнитель — в начале мы пытались назначать несколько исполнителей, но оказалось, что они перекладывают друг на друга ответственность и эффективность работы падает.
А чтобы с поступающими заявками было проще работать, мы нанесли их на географическую плоскость — карту города. Для этого применяли методы геокодирования и связывали заявки с конкретными точками на карте Ташкента.
Современные сервисы без мобильного приложения — дичь. Поэтому мы сделали наше приложение для двух платформ: Android и iOS. Основным языком программирования для мобилки мы взяли язык Dart и его фреймворк Flutter. Выбор этой технологии основывался на том, что в краткий срок мы могли получить аппку для двух платформ сразу. Мы не планировали много анимаций, поэтому даже версия Flutter-a 2021 года полностью удовлетворяла нашим требованиям.
Мобильное приложение напрямую связывается с Сервером и выводит все данные в реальном времени. Связь с беком производится с помощью протокола http1.0 и клиент-серверным интерфейсом RestAPI. В самом приложении использовано архитектура BLoC, которая широко используется в фреймворке Flutter.
Почему Flutter?
Тесты для Android
источник: https://habr.com/ru/company/vdsina/blog/509048/
источник: https://habr.com/ru/company/vdsina/blog/509048/
Ещё есть:
Обо всем этом подробнее расскажу ниже.
вот теперь фундамент точно готов
Размыть границы
Для упрощения и ускорения решений жалоб горожан мы разработали систему автоматической привязки исполнителя к заявке — сервис, принимая жалобы от горожан автоматически считывает тему обращения и направляет его к нужной службе. Например, жалоба о нерабочем светофоре идет напрямую в ЦОДД, а заявка о сломанном лифте — в ЖКХ.
В целом исполнитель назначается по следующим критериям:
организация исполнителя совпадает с организацией, ответственной за категорию заявки;
район, к которому принадлежит исполнитель, совпадает с районом подачи заявки;
направление деятельности исполнителя совпадает с обозначенным направлением категории заявки.
Когда заявитель и исполнитель нашли друг-друга, задача сервиса — поддерживать их диалог, пока проблема не будет решена. Эту задачу закрывает чат.
В чат имеют доступ и модераторы сервиса, они следят за тем, чтобы исполнители не уклонялись от работы, а заявители выдвигали адекватные требования. У каждого модератора есть свой набор инструментов и удобный личный кабинет.
Рисунок взаимодействия пользователей системы
Такие же личные кабинеты есть и для высшего руководства города — там можно посмотреть статистику по районам, количество жалоб, проблемные участки и направления города. Это все нужно, чтобы чиновники могли вовремя отреагировать на системную проблему и начать ее решать.
А публичным маркером работы чиновников служит наш рейтинг районов, о котором мы упоминали в начале материала.
рейтинг
Еще одна удобная функция нашего сервиса — система оповещения жителей об авариях. Например, если горожанин зарегистрирован в нашем сервисе, он сможет заранее узнать о том, что завтра у него отключат горячую воду, или что где-то случилась авария, и ему придется несколько дней прожить без газа.
не всё так просто и быстро
Типы пользователей
Она довольно сложная, ведь в процессе обработки заявки участвует сразу 5 типов пользователей:
Клиент (он же пользователь)
Администратор
Модератор
Исполнитель
Наблюдатель
И все эти пользователи работают не только вертикально, но и горизонтально — например, модераторы могут вмешиваться в процесс буквально на любой стадии.
Логика доставки заявки до исполнителя
Когда мы шли к этой логике, где у всех есть свой личный кабинет и возможность так или иначе влиять на процесс, мы проводили серию встреч и интервью со всеми государственными службами, чтобы понять, что им было бы важно получить в таком сервисе, а что наоборот — только бы помешало.
Мы поняли, что большинству организаций комфортно в текущей системе ролевых моделей, в которой есть ощутимый минус в виде сотрудников промежуточных звеньев, которые не создают никакой ценности при работе с заявками, а в большинстве своем выполняют функцию маршрутизации, которую мы можем автоматизировать. Поэтому мы их исключили из цепочки Исполнителей и сфокусировались на том, что Заявка должна попадать тем лицам, кто непосредственно близок к тем, кто работает с решением заявок.
мы близки
Разработка сервиса
По-началу, разработка сервиса вызывала лишь раздражение — никому не нужен еще один сайт, куда нужно вписывать отчеты. В идеале исполнителям нужна была удобная платформа, как мессенджер, чтобы без лишней волокиты делать свою работу.
Чтобы дать им инструмент мечты мы создавали мокапы и строили User Story.
В итоге, мы переделали почти все, что было сделано на начальной стадии, ведь то, что нам казалось очень удобным и правильным, в реальном мире работало криво и неэффективно — заявки не решались и никто не знал за что отвечает.
и когда мы думали, что уже всё…
Запуск
При запуске мы столкнулись с несколькими проблемами, как организационного, так и технического характера:
С момента обучения Исполнителей, до момента релиза прошло около 2х месяцев. В течение которого в некоторых организациях произошли кадровые перемены, а поскольку в г. Ташкент отсутствует единая платформа где бы велся учет персонала, то на этапе старта оказалось, что Исполнител есть, но за заявками никто не следил и они шли в никуда.
После запуска сервиса, в течение 3–4х дней начались проблемы у министерской защищенной сети МСПД, через которую мы обращались к бэку ГЦП (Государственного Центра Персонализации) и в результате пользователи не могли пройти регистрацию, что вызвало обоснованный шквал негодования и наш саппорт даже после восстановления работоспособности сервиса, разгребал тикеты в телеграм-боте.
оказалось нам показалось…
Работа над ошибками и система оповещения
После запуска мы провели работу над ошибками.
Изначально регистрация проходила через номер мобильного телефона, а также через серию паспорта и ПИНФЛ (он не меняется, даже если человек поменяет паспорт).
Для облегчения сбора данных, мы сделали для Флаттера сканер паспорта, но не на всех устройствах он работал хорошо, особенно на дешевых смартфонах с плохой камерой
Жители начали жаловаться в наш телеграм-бот о том, что сканирование проходит тяжело и не всегда работает правильно, поэтому, мы изменили набор паспортных данных на серию паспорта и дату рождения.
Наблюдение
Вся история о «выполнении и наказании» конечно не может существовать без контроля и статистики. Для управления всем этим делом мы решили создать кабинет наблюдателя. Почему именно наблюдателя? Так как этот инструмент для руководителя, напрямую из системы он не должен влиять на результат. Тут можно увидеть всё. Заявки и их содержимое, сортировать его по всем признакам, посмотреть на рейтинги.
Тут же можно раскрыть заявки и посмотреть на их содержимое и на переписку во внутреннем мессенджере. Но в данном инструменте не предусмотрена связь с исполнителем или заявителем в любом виде. Это инструмент верхнеуровневого управления, чтобы быть в курсе всего и если нужно изучить всё до деталей.
кабинет исполнителя: главная страница
Ну и конечно для удобного визуального контроля был сделан дэшборд для которого была использована платформа Visiology. Весь процесс постройки дэшборда был проделан в ней и с помощью iframe интегрирован в кабинет наблюдателя.
кабинет исполнителя: дэшборд
Сводные данные портала «Халк Назорати» зафиксированы в дэшборде, с целью получения актуальной информации жизни города. Данные хранятся в более чем семидесяти таблицах, которые посредством присоединения друг к другу образуют единую большую таблицу. Что из себя представляют эти данные: Количество заявок, поступающие в портал, после распределяются по исполнителям в каждом районе по всему городу. Заявка на момент поступления имеет статус «На рассмотрении», после получения исполнителями, она меняет статус на «Рассмотрено» и отправляется обратно к заявителю. В зависимости от того, какой ответ даст заявитель «Подтвердить решение» либо «Не согласен с решением», она может получать статусы «Закрыто» или «На рассмотрении» соответственно. Также, заявитель может закрыть заявку до рассмотрения исполнителем, тем самым поменяв её статус на «Неактуально». За правильностью распределения и исполнения заявок следят модераторы портала «Халк Назорати». В свою очередь, модераторы имеют возможность закрыть заявку принудительно, если она не подходит под условия, поменяв её статус на «Закрыто модератором».
Заявки подразделяются на Темы, категории и подкатегории, процент которых показан на дэшборде. Отсюда мы можем заметить, что самой актуальной темой за всё время существования портала является «Моя дорога». В данную тему входят категории, которые позволяют заявителям отправить заявку по дорогам, если на них есть ямы и ухабы.
Распределяя заявки по районам, можно судить о том, какой из районов является самым активным по подаче заявок. Отметим Юнусабадский и Мирзо-Улугбекский районы, число поданных заявок которых составляет 3000.
Также в дэшборде представлена динамика зарегистрированных новых пользователей в разрезе по дням, а также их возрастной диапазон. Отметим, что основная аудитория это люди в возрасте с 25–44 лет.
О том как мы начинали работать c BI платформой Visiology я писал в ранних статьях.
https://habr.com/ru/company/visiology/blog/662019/
https://habr.com/ru/company/visiology/blog/667450/
точно всё?
Что еще мы планируем сделать…
Разного рода фидбэки и общение с диспетчерской службы породило идею создания системы оповещения при отключении «жизненно» важных коммунальных услуг. Проблема была в том, что при отключении электричества, газа или воды люди тут же начинают беспокоится и звонить во все возможные службы с одним и тем же вопросом, почему отключили и когда включат. Конечно есть стандартные отключения при неоплате про них люди и сами знают, а вот при авариях или плановых работах нет. Мы решили сделать систему оповещения о таких случаях. Мол выключился свет, тут зарегистрированным пользователям будет приходить пуш-уведомление, что по их адресу было отключено электричество в связи с аварией на станции или плановыми работами и включится в такое то время. В идеале это должно сократить звонки диспетчерам и дать понять, что ситуация под контролем и оповестить о примерном или точном времени подключения услуги.
Мы планируем начать с электричества, обычно с ним бывает больше всего проблем.
А вообще, у нас много идей того какие новые фичи добавить в продукт, но не хотим спойлерить, чтобы не портить сюрприз жителям.
А с читателями Хабра, о новых фичах расскажем после релиза.
