Разработка мобильных приложений для сотрудников и клиентов

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

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

Две разные задачи

Что обычно нужно в приложении для сотрудников

1. Работа без связи. На объекте, в подвале, в поле сети нет. Данные должны вводиться и сохраняться локально, а потом уезжать на сервер. Это главное техническое требование, и оно определяет архитектуру.
2. Список задач на день. Что делать, где, во сколько, в каком порядке. С маршрутом, если точек несколько, и с понятным статусом каждой.
3. Фотофиксация. Снимок как доказательство выполнения, с датой, временем и координатами. Чаще всего это и есть главная ценность приложения для руководителя.
4. Сканер. Штрихкод или QR вместо поиска позиции в списке. Экономит часы в неделю на каждом человеке и убирает ошибки ввода.
5. Подпись клиента на экране. Закрывающий документ подписывается на месте, а не везется в офис через три дня.
6. Простые формы. Минимум полей, выбор из списка вместо ввода, значения по умолчанию. Каждое лишнее поле — это отказ от заполнения и данные, которых у вас не будет.

Что происходит с данными офлайн

Что нужно в приложении для клиентов

• Понятная ценность на первом экране. Человек должен за двадцать секунд увидеть, зачем это ему. Обучающий тур из семи слайдов эту задачу не решает.
• Вход без мучений. По номеру телефона с кодом, без придумывания паролей. Каждый лишний шаг на входе стоит части пользователей.
• То, за чем реально приходят. Статус заказа, история, документы, повторный заказ, запись, оплата. Не копия всего сайта в маленьком экране.
• Уведомления по делу. О статусе заказа — да. Рекламные каждый день — прямой путь к удалению приложения.
• Работа при плохой связи. Не полный офлайн, но корректное поведение: показать, что уже загружено, и не терять введенное.
• Честная работа с данными. Запрашивать доступ к камере и геолокации в момент, когда это нужно, и объяснять зачем. Иначе часть пользователей откажет, и функция не заработает.

Как делаем

1. Определяем, кому и зачем. Сотрудники или клиенты, какие задачи решаются в приложении, а какие остаются на сайте или в системе. Здесь же честно разбираемся, нужно ли вообще отдельное приложение.
2. Выбираем технологию. Одно кроссплатформенное приложение для двух систем закрывает большинство задач и стоит заметно дешевле двух отдельных. Отдельная нативная разработка нужна там, где важны специфические возможности устройства или предельная производительность.
3. Прототип на телефоне. Не картинки на мониторе, а кликабельные экраны в руках у тех, кто будет пользоваться. Размер кнопок и читаемость на солнце проверяются только так.
4. Разработка частями. Сборка на вашем устройстве каждые одну-две недели. Приложение для сотрудников тестируется в реальных условиях: на объекте, в машине, в перчатках.
5. Публикация или раздача. Для клиентских — размещение в магазинах приложений с прохождением проверки. Для внутренних — корпоративная раздача без магазинов.
6. Сопровождение. Системы обновляются дважды в год, и приложение требует поддержки, иначе через полтора года оно перестает запускаться на новых телефонах.

Где такие приложения работают

• Сервис и выездные бригады. Наряд на телефоне, фотофиксация до и после, подпись клиента, списание запчастей. Самый частый и самый окупаемый случай: время от выполнения до закрытого документа сокращается с дней до минут.
• Логистика и доставка. Маршрут, статусы точек, сканирование груза, фото при передаче, подтверждение получения. Здесь офлайн обязателен: связь пропадает регулярно.
• Склад и инвентаризация. Терминал сбора данных можно заменить обычным телефоном со сканером в приложении. Экономия на оборудовании часто окупает разработку сразу.
• Производство и обходы. Обходы оборудования по графику, отметка о проверке, показания, заявка на ремонт прямо с места.
• Торговые представители. Заказ у клиента на месте, остатки, долги, фотоотчет о выкладке, геометка визита.
• Клиентские кабинеты. Статусы, история, документы, повторный заказ, запись, оплата — для бизнеса, где клиент обращается регулярно.

Одно приложение или два

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

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

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

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

Где здесь искусственный интеллект

• Распознавание с камеры. Номер, серийник, показания счетчика, текст с документа — вместо ручного ввода в неудобных условиях. Для полевых сотрудников это самая заметная экономия.
• Голосовой ввод отчета. Наговорить, что сделано, проще, чем набрать на телефоне в машине. Модель превращает речь в заполненные поля.
• Проверка качества фотографий. Приложение сразу говорит, что снимок смазан или не тот объект, — пока человек еще на месте, а не когда он уехал.
• Подсказки по задаче. Модель по описанию неисправности предлагает вероятную причину и список запчастей, опираясь на историю похожих случаев.
• Умный порядок задач. Маршрут и очередность с учетом адресов, сроков и загрузки, а не по порядку поступления.

Сроки и стоимость

На стоимость влияют офлайн (он дороже, чем кажется), количество ролей, интеграции с вашими системами и необходимость публикации. Отдельная строка — поддержка: приложению нужны обновления при выходе новых версий систем, и это нормальная постоянная статья расходов, а не признак плохой работы.

Частые ошибки

• Переносят весь сайт в приложение. Получается медленный неудобный браузер. В приложение переносят два-три сценария, за которыми приходят чаще всего.
• Не проверяют в реальных условиях. Приложение прекрасно работает в офисе и не читается на солнце, не нажимается в перчатках и падает без связи.
• Экономят на офлайне. «У них же везде интернет» — до первого подвала. Дописывать офлайн в готовое приложение дороже, чем заложить сразу.
• Забывают про старые телефоны. У полевых сотрудников часто устройства, которым несколько лет. Требования к минимальной версии определяются по факту, а не по желанию.
• Считают публикацию формальностью. Проверка в магазинах занимает время и может закончиться отказом по причинам, которые лучше знать заранее.
• Не планируют поддержку. Приложение без обновлений через полтора года перестает работать на новых телефонах, и это не чья-то ошибка, а свойство платформы.

Что остается у вас

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

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

Дальше по теме