Как мы автоматизировали технадзор для «ПИК»
Привет!
Меня зовут Максим, я руковожу мобильной разработкой в KTS. Мы автоматизируем бизнес-процессы больших компаний, разрабатываем продукты для стартапов, рекламные спецпроекты и мобильные приложения. Сегодня расскажем про мобильное приложение, которое сделали для строительной компании ПИК.
Зачем строительной компании приложение
В 2017 году ПИК пришла к нам с задачей автоматизировать работу проверяющих технадзора. Это люди, отвечающие за качество выполненных работ. Раньше они ходили по домам, записывали все замечания на бумаге, а потом отправляли на рассмотрение и согласование.
ПИК ведет одновременное строительство десятков жилых комплексов, за каждым из которых закреплены проверяющие. Конечно, вести бумажные документы для такой огромной системы — утомительно и непродуктивно.
Если конкретизировать, проблемы были такие:
- Непонятно, выполняют ли сотрудники технадзора свою задачу.
- Проблемы приходят с опозданием: пока замечание про трещину в стене дошло до этапа исправления, эту стену уже заштукатурили и провели электрику. Приходится переделывать и тратить лишние время и деньги
- На строительных площадках плохо ловит Интернет на мобильных устройствах
- Нет системы: статистики замечаний нет, поэтому сложно понять, как улучшить процесс контроля качества
А решать их мы решили так:
- Собирать все данные в мобильном приложении и передавать замечания на исправления
- Сделать приложения способным работать в условиях стройки: сохранять данные и работать с ними в офлайн-режиме, а на сервер отправлять при появлении Интернета
- Собирать подробную статистику со всех жилых комплексов и анализировать её
Начало работы и выпуск MVP
Заказчик написал нам 11 июня. 12 июня мы встретились, а уже через месяц надо было запустить MVP. Сроки поджимали, поэтому дизайн сделали максимально простым.
Немного расскажем о том, как устроены замечания на стройке. Объекты строительства вложены друг в друга:
На каждом уровне можно создать замечание. Проверяющие привязывают замечания к объекту и детализируют, к чему именно они относятся: пол, комната, стена.
Сценарий работы на MVP
Для MVP мы совместно определили следующий сценарий работы приложения:
- Проверяющий авторизовывается в приложении
- Выбирает жилой комплекс
- Синхронизирует список замечаний с сервером: скачивает замечания
- Выбирает стадию стройки
- Выбирает объект с детализацией до уровня квартиры
- Просматривает замечания, привязанные к этому объекту, и стадию строительства
- Создает новые замечания в оффлайн-режиме
- Повторно синхронизирует замечания: созданные отправляются на сервер, с сервера скачиваются обновленные данные
Так это выглядело в реализованном виде:
Язык программирования
Приложение решили писать на языке Kotlin. Писать код на Kotlin быстрее и удобнее, чем на Java, но у него был еще один важный плюс.
Проект стартовал в 2017 году и развивался еще несколько лет. Если в 2017 найти Java-разработчиков под Android было несложно, то в 2019 это стало уже затруднительно. Google порекомендовал Kotlin как предпочтительный язык для Android, и новые разработчики сразу начинают с него. Своевременное внедрение актуальной технологии позволило не тратить время на поиск разработчиков под устаревшую.
Немного техники: как мы проектировали синхронизацию
При каждой синхронизации проверяющий должен скачать большое количество данных. Этот процесс идет долго, а замечания во время синхронизации вносить нельзя — иначе пострадает их согласованность.
Сначала на все время процесса добавили блокировку интерфейса. Так проверяющий точно не мог случайно внести замечания в записи в момент их синхронизации. А чтобы ускорить синхронизацию, сделали ее многопоточной. Данные, полученные в разных потоках, не должны конфликтовать, поэтому мы привязали потоки синхронизации к корпусам: их данные не зависят друг от друга.
Ручной и автоматический запуск синхронизации
Обычно синхронизация запускается автоматически, и это удобно. В 2017 году стандартным методом реализации автоматической синхронизации на Android был SyncAdapter. Но при проверке выяснилось, что он запускает синхронизацию при малейшем проявлении сети.
Нам этот вариант не подошел: если на объектах стройки и появлялась связь, она была слабой и кратковременной. Таких периодов появления связи не хватало для полноценной синхронизации, поэтому она проваливалась.
Поэтому мы выбрали ручную синхронизацию. Она хорошо ложится на режим работы сотрудника. Утром он приходит в офис и вручную синхронизирует замечания. Затем в течение дня без доступа к сети работает с ними на основе загруженных данных. Вечером возвращается в офис и снова синхронизируется.
Распространение обновлений
Чтобы минимально отвлекать сотрудников от работы, нужно распространять обновления с наименьшей головной болью для пользователей.
Для распространения приложения мы выбрали платформу HockeyApp. Сейчас она называется Appcenter. Для достижения наших целей у HockeyApp есть ряд преимуществ по сравнению Google Play:
- Простое распространение обновлений. Пользователь видит список всех версий, а при ошибках обновления может откатиться до предыдущей.
- Удобство тестирования. Тестировщикам HA позволяет отдельно проверять несколько фичей, которые разработчики собрали в разных версиях.
- Пользователи видят наличие новой версии прямо в приложении и сразу могут обновиться. Это фича «из коробки» HockeyApp.
Принудительное обновление. Некоторые версии можно отметить обязательными для установки. Тогда пользователь просто не пройдет дальше первого экрана, пока не обновит приложение. Так мы могли принудительно устанавливать критически важные обновления.
Сбор ошибок
Мы использовали инструмент Fabric — сейчас он называется Firebase Crashlytics. С его помощью можно определить конкретного пользователя, у которого возникла та или иная ошибка. Так мы могли максимально быстро узнавать об ошибках и устранять их.
Чтобы не тратить время разработки на некритичные баги, согласовали с заказчиком правило: правим только те ошибки в приложении, которые возникают более чем у 3 человек, или у одного человека более 10 раз.
Лайфхаки при внедрении
Переезжать из однои системы в другую всегда тяжело. ПИК переезжали из бумажной системы в информационную. Вот что сделала ĸоманда продуĸта на стороне заĸазчиĸа:
- Для начала команда сфокусировалась на максимизации количества замечаний: те, кто создавали больше всех замечаний, получали премию.
- Потом проверяющих обязали самостоятельно закрывать все замечания, которые они создали. Поэтому мелкие некритичные замечания работники не записывали, потому что за устранением замечания должен следить тот же человек, кто его внес.
Таким образом проверяющие старались вносить больше замечаний, но писали только существенные пункты.
Тест MVP на пользователях
По результатам тестирования добавили еще кое-что:
- выбор подрядчика, который должен устранить замечание
- прикрепление медиа: фото, видео, чертежи
- редактор фото: рисование, линейки, надписи
- редактор видео: обрезка, изменение качества. За основу взяли open source плеер из Телеграма
Так это выглядело в реализованном виде:
Результат
В итоге мобильное приложение дало ПИК несколько ключевых плюсов:
- Цифровизация: замечания переехали из бумажных бланков в информационную систему, улучшилась структура и методики анализа данных.
- Систематизация замечаний: теперь у заказчика есть возможность системно работать с замечаниями: в головном офисе видят все недочеты на стройках, а проверяющие работают быстрее и гораздо организованнее.
- Прозрачность процессов: все недостатки можно увидеть на фото и видео, а информация о них остается в приложении, пока замечания не исправят.
- Развитие: в дальнейшем мы усовершенствовали приложение: добавили новые функции и оптимизировали каждый процесс с учетом его особенностей.
В дальнейшем мы еще усовершенствовали приложение, а как именно — расскажем в следующих статьях.