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