Как ПИК запустил мобильное приложение для технадзора за месяц

Привет, это Максим Павлов из KTS. Мы создаём веб-сервисы и мобильные приложения для бизнеса.

Мобильное приложение для ПИК упрощает контроль качества в строительстве. Рассказываем, как разработали приложение за месяц, какие функции вошли в первый релиз и как ПИК успешно внедрил его среди сотрудников, которые не особенно этого ждали.

Кейс компании ПИК — не новый. Мы запустили MVP в 2017-ом году всего за месяц, а после прошли с клиентом полный цикл: помогли перейти от ведения бумажных документов в цифру, автоматизировали и полноценно цифровизировали систему учета замечаний проверяющих.

Этот проект стал одним из первых значимых для нас кейсов по разработке offline-first приложений для полевых сотрудников.

Разработка для ПИК шла в три этапа по году, сегодня расскажу о первом из них.

ПИК — лидер рынка недвижимости, который строит десятки жилых комплексов одновременно. За каждым из комплексов закреплены проверяющие. Они приезжают на стройплощадку и оценивают качество строительства.

Раньше проверяющие ходили по объектам, записывали все замечания на бумаге и отправляли их на рассмотрение и согласование.

В рамках такого процесса сложно определить, качественно ли проверяющие делают свою работу. К тому же из-за бумажных отчетов замечания приходили с опозданием.

В 2017 году ПИК обратились к нам с задачей автоматизировать работу проверяющих технадзора — то есть, помочь упростить проверку качества строительства.

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

Первым делом нам было важно узнать, с какими ещё проблемами сталкивается руководство компании. Их было четыре. Конкретизирую:

Чтобы уложиться в сроки, дизайн сделали максимально простым. Так выглядела первая версия приложения, запущенная через месяц:

Проверяющий заходит в приложение, выбирает нужный ЖК, стадию строительства и объект, видит старые замечания и оставляет новые. Все данные сохраняются и при появлении сети отправляются на сервер.

Разработать приложение — это ещё полдела. Чтобы получить эффект для бизнеса, надо его внедрить в рабочий процесс. Вот, что сделала команда продукта на стороне заказчика, чтобы успешно внедрить приложение:

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

После внедрения ПИК собрал фидбек от пользователей. Постепенно пришли идеи того, что можно добавить и улучшить.

Так появились:

Приложение активно развивалось, поэтому нужно было позаботиться о том, чтобы обновления быстро доставлялись до сотрудников. Причем так, чтобы минимально отвлекать их от работы. Для распространения приложения мы выбрали платформу HockeyApp (сейчас она называется Appcenter).

По сравнению с Google Play, у HockeyApp был ряд преимуществ:

Эта история типична для тестирования веб-проектов на отдельных фича-серверах — недавно писали, как фича-серверы ускоряют Time to Market.

Уже через месяц мобильное приложение дало ПИК несколько ключевых преимуществ: информатизация системы, систематизацию в работе с замечаниями и обеспечение прозрачности процессов.

Проектирование синхронизации

Обычно синхронизация запускается автоматически, и это удобно. В 2017 году стандартным методом для Android был SyncAdapter. Но при проверке выяснилось, что он запускает синхронизацию при малейшем появлении сети.

Такой вариант нам не подошел: если на объектах стройки и появлялась связь, она была слабой и кратковременной. Поэтому идея оказалась нерабочей.

При каждой синхронизации проверяющий должен скачать большое количество данных. Этот процесс идет долго, а замечания во время синхронизации вносить нельзя, иначе пострадает их согласованность. Чтобы это решить, на все время процесса мы добавили блокировку интерфейса. Так проверяющий точно не мог случайно внести замечания в записи в момент их синхронизации.

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

А чтобы ускорить синхронизацию, сделали ее многопоточной. Данные, полученные разными потоками, не должны конфликтовать. Мы привязали потоки синхронизации к корпусам: их данные не зависят друг от друга.

Как организовали сбор ошибок

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

Мы использовали инструмент Fabric — сейчас он называется Firebase Crashlytics. Он помогает узнать, у какого пользователя ошибка.

Чтобы не тратить время разработчиков на некритичные ошибки, согласовали с заказчиком правило: исправляем только те ошибки в приложении, которые встречаются более чем у 3 человек, или у одного человека более 10 раз.

Этап 2017 года — самый первый. В дальнейшем мы развивали и улучшали приложение, оптимизировали каждый процесс с учетом его особенностей. Как именно — расскажем в следующих статьях.