Пятёрочки
Мобильное приложение
для работы со строительными замечаниями
для работы со строительными замечаниями
Рассказываем, как сделали сервис для контроля качества работ на стройке
Сервис для системной работы
Технадзора
Технадзора
Проблемы и решения
В июне 2017 года
группа компаний ПИК пришла к нам с задачей:
автоматизировать работу проверяющих на стройке.
группа компаний ПИК пришла к нам с задачей:
автоматизировать работу проверяющих на стройке.
У ПИК была своя команда разработчиков: руководитель проекта, бэкендеры, дизайнеры, тестировщики. Они уже разрабатывали веб-версию сервиса автоматизации, и в дальнейшем мы работали совместно.
«ПИК ведет одновременное строительство десятков жилых комплексов, за каждым из которых закреплены проверяющие. Это люди, отвечающие за качество выполненных работ. Раньше они ходили по домам, записывали все замечания на бумаге, а потом отправляли на рассмотрение и согласование».
Роман Жуков
Руководитель проектов в 2017-2019 гг
- Непонятно, выполняют ли сотрудники технадзора свои обязанностиРешение: собирать данные в одном месте и передавать замечания на исправление01
- Проблемы приходят с опозданиемПока замечание про трещину в стене дошло до этапа исправления, эту стену уже заштукатурили и провели электрику.
Решение: все вопросы сотрудники решали через телефон, поэтому собирать их надо в мобильном приложении.02 - На строительных площадках плохо ловит интернет на мобильных устройствахРешение: мобильное приложение должно уметь сохранять данные и работать с ними в офлайн-режиме, а на сервер отправлять при появлении интернета.03
- Нет возможности системно работать с ошибками.Не зная статистики замечаний, сложно улучшить процесс контроля качества.
Решение: нужно собирать подробную статистику со всех жилых комплексов и анализировать её.04
Начали работу и выпустили MVP
Заказчик написал нам 11 июня.
12 июня мы встретились, а уже через месяц надо было запустить MVP. Сроки поджимали, поэтому дизайн сделали максимально простым.
12 июня мы встретились, а уже через месяц надо было запустить MVP. Сроки поджимали, поэтому дизайн сделали максимально простым.
Как устроены замечания на стройке
Объекты строительства вложены друг в друга:
Жилой комплекс → Корпус → Подъезд → Этаж → Квартира
На каждом уровне можно создать замечание. Проверяющие привязывают замечания к объекту и детализируют, к чему именно они относятся: пол, комната, стена.
Жилой комплекс → Корпус → Подъезд → Этаж → Квартира
На каждом уровне можно создать замечание. Проверяющие привязывают замечания к объекту и детализируют, к чему именно они относятся: пол, комната, стена.
Сценарий работы MVP
Наше приложение взаимодействовало с действующим бэкендом, который разрабатывали в команде ПИКа.
Для MVP мы совместно определили следующий сценарий работы приложения:
Для MVP мы совместно определили следующий сценарий работы приложения:
Подготовка
Проверяющий авторизовывается в приложении и выбирает ЖК
Синхронизация
Список замечаний синхронизируется с сервером
Выбор этапа
Проверяющий выбирает стадию стройки и объект с детализацией до уровня квартиры
Просмотр замечаний
Проверяющий видит все замечания по выбранному объекту
Создание замечаний
Проверяющий создает новые замечания в режиме без интернета
Повторная синхронизация
При появлении интернета внесенные замечания отправляются на сервер, а замечания других проверяющих скачиваются в приложение
Язык программирования
Приложение решили писать на языке Kotlin. К моменту начала разработки он только вышел в релиз, но у нас уже был опыт работы с ним. Писать код на Kotlin быстрее и удобнее, чем на Java, но у него был еще один важный плюс.
Проект стартовал в 2017 году и развивался еще несколько лет. Если в 2017 найти разработчиков на Java под Android было несложно, то в 2019 это стало уже затруднительно: Google стал рекомендовать Kotlin как предпочтительный язык для Android. Новые разработчики сразу начинают с него. Своевременное внедрение актуальной технологии позволило не тратить время на поиск разработчиков под устаревшую.
Проект стартовал в 2017 году и развивался еще несколько лет. Если в 2017 найти разработчиков на Java под Android было несложно, то в 2019 это стало уже затруднительно: Google стал рекомендовать Kotlin как предпочтительный язык для Android. Новые разработчики сразу начинают с него. Своевременное внедрение актуальной технологии позволило не тратить время на поиск разработчиков под устаревшую.
Как мы проектировали синхронизацию
Блокировка интерфейса
Сначала на все время процесса добавили блокировку интерфейса. Так проверяющий точно не мог случайно внести замечания в записи в момент их синхронизации.
Многопоточность
Чем ближе срок сдачи корпуса, тем больше накапливается замечаний. Их синхронизация может длиться очень долго.
Чтобы ускорить синхронизацию, мы сделали ее многопоточной. Данные, полученные в разных потоках, не должны конфликтовать, поэтому мы привязали потоки синхронизации к корпусам: их данные не зависят друг от друга.
Максимальное количество потоков — 64. Обычно этого достаточно: редкий проверяющий скачивает данные по большему количеству корпусов. Но зато это ограничение позволяет не плодить лишние потоки и открытые HTTP-соединения, не увеличивать количество потребляемой памяти приложением.
Чтобы ускорить синхронизацию, мы сделали ее многопоточной. Данные, полученные в разных потоках, не должны конфликтовать, поэтому мы привязали потоки синхронизации к корпусам: их данные не зависят друг от друга.
Максимальное количество потоков — 64. Обычно этого достаточно: редкий проверяющий скачивает данные по большему количеству корпусов. Но зато это ограничение позволяет не плодить лишние потоки и открытые HTTP-соединения, не увеличивать количество потребляемой памяти приложением.
При каждой синхронизации проверяющий должен скачать большое количество данных. Этот процесс идет долго, а замечания во время синхронизации вносить нельзя — иначе пострадает их согласованность.
Типовое решение не работает
Ручной и автоматический
запуск синхронизации
запуск синхронизации
Обычно синхронизация запускается автоматически, и это удобно. В 2017 году стандартным методом реализации автоматической синхронизации на Android был SyncAdapter. Но при проверке выяснилось, что он запускает синхронизацию при малейшем проявлении сети.
Нам этот вариант не подошел: если на объектах стройки и появлялась связь, она была слабой и кратковременной. Таких периодов появления связи не хватало для полноценной синхронизации, поэтому она проваливалась.
Поэтому мы выбрали ручную синхронизацию. Она хорошо ложится на режим работы сотрудника. Утром он приходит в офис и вручную синхронизирует замечания. Затем в течение дня без доступа к сети работает с ними на основе загруженных данных. Вечером возвращается в офис и снова синхронизируется.
Поэтому мы выбрали ручную синхронизацию. Она хорошо ложится на режим работы сотрудника. Утром он приходит в офис и вручную синхронизирует замечания. Затем в течение дня без доступа к сети работает с ними на основе загруженных данных. Вечером возвращается в офис и снова синхронизируется.
«При синхронизации нужно учесть возможность разрыва соединения в процессе обмена данными с сервером.
Представим, что сервер уже принял сущность от клиента, и после этого при отправке ответа случился разрыв соединения. В результате клиент не узнал, что сервер сохранил сущность. При повторной синхронизации сущность будет отправляться заново, из-за этого возможно дублирование данных на сервере. Чтобы избежать этого, добавляем к каждой сущности сгенерированную рандомную последовательность и храним ее локально неизменной. В случае повторной синхронизации по этой неизменной последовательности сервер сможет понять, что эта сущность уже сохранялась раньше и не создавать новую, а обновить существующую».
Максим Мялкин
Руководитель мобильной разработки KTS
Авторизоваться
Запустили MVP
Через месяц после старта разработки в приложении можно было:
Создать замечание
Смотреть замечания
Без доступа к сети
В десктопном веб-сервисе, который разработала команда ПИК
Даже в такие короткие сроки мы уделили внимание двум важным для запуска мобильного приложения процессам:
распространению обновлений и сбору ошибок.
распространению обновлений и сбору ошибок.
Распространение обновлений
Чтобы минимально отвлекать сотрудников от работы, нужно распространять обновления с наименьшей головной болью для пользователей.
Для распространения приложения мы выбрали платформу HockeyApp. Сейчас она называется Appcenter. Для достижения наших целей у HockeyApp есть ряд преимуществ по сравнению Google Play:
Принудительное обновление. Некоторые версии можно отметить обязательными для установки. Тогда пользователь просто не пройдет дальше первого экрана, пока не обновит приложение. Так мы могли принудительно устанавливать критически важные обновления.
Для распространения приложения мы выбрали платформу HockeyApp. Сейчас она называется Appcenter. Для достижения наших целей у HockeyApp есть ряд преимуществ по сравнению Google Play:
- Простое распространение обновлений. Пользователь видит список всех версий и при ошибках обновления может откатиться до предыдущей.
- Удобство тестирования. Тестировщикам HA позволяет отдельно проверять несколько фичей, которые разработчики собрали в разных версиях.
- Пользователи видят наличие новой версии прямо в приложении и сразу могут обновиться. Это фича «из коробки» HockeyApp. К сожалению, с этой активированной функцией нельзя выпускать приложение в Google Play в дальнейшем.
Принудительное обновление. Некоторые версии можно отметить обязательными для установки. Тогда пользователь просто не пройдет дальше первого экрана, пока не обновит приложение. Так мы могли принудительно устанавливать критически важные обновления.
Сбор ошибок
Мы использовали инструмент Fabric — сейчас он называется Firebase Crashlytics. С его помощью можно определить конкретного пользователя, у которого возникла та или иная ошибка. Так мы могли максимально быстро узнавать об ошибках и устранять их.
Чтобы не тратить время разработки на некритичные баги, согласовали с заказчиком правило: правим только те ошибки в приложении, которые возникают более чем у 3 человек, или у одного человека более 10 раз.
Чтобы не тратить время разработки на некритичные баги, согласовали с заказчиком правило: правим только те ошибки в приложении, которые возникают более чем у 3 человек, или у одного человека более 10 раз.
Лайфхаки при внедрении
Переезжать с бумаги в информационную систему, или из одной системы в другую тяжело.
Команда продуĸта на стороне заĸазчиĸа решила облегчить внедрение такими шагами:
- 1Поощрять использование приложенияДля начала команда сфокусировалась на максимизации количества замечаний: те, кто создавали больше всех замечаний, получали премию.
- 2Обязать доводить замечания до концаПотом проверяющих обязали самостоятельно закрывать все замечания, которые они создали. Поэтому мелкие некритичные замечания работники не записывали, потому что за устранением замечания должен следить тот же человек, кто его внес.
Таким образом система сбалансировалась: проверяющие старались вносить больше замечаний, но писали только существенные пункты.
Протестировали MVP и добавили новые фичи
Выбор подрядчика
Прикрепление медиа
Редактор фото
Редактор видео
Результаты
- ЦифровизацияЗамечания переехали из бумажных бланков в информационную систему.
- Систематизация замечанийТеперь у заказчика есть возможность системно работать с замечаниями: в головном офисе видят все недочеты на стройках, а проверяющие работают быстрее и гораздо организованнее.
- Прозрачность процессовВсе недостатки можно увидеть на фото и видео, а информация о них остается в приложении, пока замечания не исправят.
- РазвитиеВ дальнейшем мы усовершенствовали приложение: добавили новые функции и оптимизировали каждый процесс с учетом его особенностей.
Заказать разработку мобильного приложения
Не хотите писать? Позвоните нашему менеджеру по телефону +7 926 735-45-32 и расскажите про ваш проект
