Полевые сотрудники
Задания на день, отметка о выполнении, фотофиксация, чек-листы, подписи и геопозиция. Приложение работает там, где сотрудник не сидит за компьютером.
Обход объектов, выездные бригады, замеры, обслуживание.
Приложения для клиентов и для сотрудников: полевые задачи, склад, доставка, обход объектов. Начинаем с проверки, действительно ли нужно приложение, — потому что оно требует не только разработки, но и постоянного содержания.
Об этом редко говорят на старте. Мобильные платформы обновляются, требования магазинов приложений меняются, старые версии перестают собираться, библиотеки устаревают. Приложение, которое год никто не трогал, в какой-то момент просто исчезает из магазина или перестаёт запускаться на новых телефонах. Разработка — это первый платёж, а не единственный.
Поэтому мы начинаем не с обсуждения экранов, а с вопроса, зачем приложение нужно. Если задача — дать клиенту удобный доступ к личному кабинету, часто дешевле и надёжнее сделать адаптивный веб-сервис: он открывается по ссылке, не требует установки и обновляется на сервере. Приложение оправдано там, где без него не обойтись, — и об этом честный разговор ниже.
Задания на день, отметка о выполнении, фотофиксация, чек-листы, подписи и геопозиция. Приложение работает там, где сотрудник не сидит за компьютером.
Обход объектов, выездные бригады, замеры, обслуживание.
Сканирование штрихкодов камерой или терминалом сбора данных, приёмка, отгрузка, инвентаризация, перемещения. Данные уходят в учётную систему сразу.
Убирает пересчёт по бумажным листам и ошибки ввода.
Маршрут курьера, статусы заказов, подтверждение вручения, приём оплаты, обратная связь диспетчеру. Клиент видит, где его заказ.
Диспетчер перестаёт обзванивать курьеров ради статусов.
Заказы, запись, история, документы, накопительная программа, уведомления. Имеет смысл, когда клиент возвращается регулярно, а не раз в год.
Если пользуются редко — обсудим веб-версию вместо установки.
Любое приложение опирается на сервер: данные, авторизация, уведомления, обмен с внутренними системами. Разворачиваем её на своём сервере и следим за ней.
Приложение без живого сервера — просто иконка на экране.
Поддерживаем совместимость с новыми версиями операционных систем, обновляем сборки в магазинах, исправляем ошибки, добавляем функции по обратной связи.
Планировать это нужно до начала разработки, а не после.
Главный вопрос проекта. Ниже — признаки, по которым обычно становится понятно, какой вариант ваш.
| Что важно в задаче | Мобильное приложение | Адаптивный веб-сервис |
|---|---|---|
| Работа без стабильного интернета | Данные сохраняются на устройстве и отправляются, когда связь появится | Требует соединения — в поле это ограничение критично |
| Камера, сканер штрихкодов, геопозиция | Полный доступ к возможностям устройства и внешним сканерам | Базовые возможности доступны, но с ограничениями |
| Частота использования | Оправдано, когда открывают ежедневно | Лучше для редких визитов: не нужно ничего устанавливать |
| Скорость выпуска изменений | Каждое обновление проходит проверку в магазине приложений | Изменения появляются у всех сразу после выкатки на сервер |
| Стоимость владения | Требует регулярных обновлений под новые версии систем | Одна версия для всех устройств, содержание заметно проще |
| Уведомления пользователю | Полноценные уведомления на экране устройства | Есть, но работают не везде одинаково; часто хватает почты и сообщений |
Внутренний инструмент. Аудитория известна, установка контролируется компанией, а успех измеряется тем, насколько быстрее и точнее стала работа на местах.
Публичный продукт. Его нужно уговорить установить, удержать на экране и поддерживать в актуальном состоянии — иначе оно тихо удаляется после первого неудачного открытия.
Для внутренних приложений порог входа ниже: их не нужно продвигать и можно раздавать напрямую на устройства компании. Поэтому проекты для сотрудников чаще окупаются быстрее клиентских.
Для внутренних приложений часто нет: если компания сама выдаёт устройства сотрудникам, достаточно одной платформы, и это заметно дешевле. Для клиентских приложений обычно нужны обе, иначе часть аудитории останется без сервиса. Решение принимается по реальному составу устройств, а не по привычке.
Очень часто да. Если не нужны работа без сети, сканер штрихкодов и постоянные уведомления, адаптивный веб-сервис закроет задачу: он открывается по ссылке, работает на любом устройстве, обновляется мгновенно и не требует прохождения проверок в магазинах. Мы предлагаем этот вариант, когда он объективно лучше.
Постепенно оно перестаёт работать. Новые версии операционных систем меняют требования, магазины ужесточают правила публикации, устаревшие компоненты перестают поддерживаться. Сначала появляются мелкие сбои, затем приложение может быть скрыто из магазина или откажется запускаться на новых устройствах. Поэтому регулярное сопровождение — обязательная часть проекта.
Да, если это заложено в проект. Данные сохраняются на устройстве и синхронизируются с сервером, когда связь появится, а пользователь видит, что уже отправлено, а что ещё нет. Такой режим особенно нужен на объектах, складах и в разъездах — и продумывать его нужно с самого начала.
Учётные записи разработчика оформляются на вашу компанию — это принципиально, иначе приложение фактически принадлежит подрядчику. Мы помогаем с оформлением, подготовкой материалов и прохождением проверок, а сама публикация идёт от лица компании. Внутренние приложения можно раздавать на устройства сотрудников без магазинов.
Да, если есть исходный код и доступ к учётным записям разработчика. Начинаем с разбора: на чём написано, что с зависимостями, собирается ли проект вообще, где серверная часть. Иногда честный вывод — что дешевле переписать, чем возвращать к жизни; в таком случае мы объясняем, из чего складывается такая оценка.
Расскажите, кто будет им пользоваться и в каких условиях. Проверим, нужно ли приложение, и посчитаем работы вместе с серверной частью.
Мобильный проект отличается от веб-проекта тем, что часть решений в нём необратима, а часть расходов — постоянна. Ниже собрано то, о чём мы предупреждаем заказчиков заранее, даже когда это уменьшает вероятность заказа.
После выпуска приложение живёт в чужой среде: операционные системы обновляются, правила магазинов меняются, инструменты сборки требуют новых версий. Даже если вы не добавляете ни одной функции, приложение нужно периодически пересобирать и переиздавать, иначе оно постепенно перестанет работать у пользователей. Это нормальная часть проекта, и её лучше заложить в план сразу, а не обнаружить в момент, когда сотрудники жалуются, что приложение не запускается.
Если сотрудник работает в подвале, на удалённом объекте или в дороге, приложение должно уметь копить данные локально и синхронизировать их позже. Это значит: разрешение конфликтов, версии записей, понятный пользователю статус отправки. Такая логика делается в самом начале — вписать её в готовое приложение обычно означает переделать его наполовину.
Приложение почти всегда только витрина: данные, права, уведомления и обмен с внутренними системами живут на сервере. Мы разрабатываем эту часть вместе с приложением и размещаем её на виртуальном сервере с резервным копированием, а выкатку обновлений настраиваем средствами DevOps. Разделять эти работы между разными подрядчиками — верный способ получить спор о том, чья сторона виновата в ошибке.
Если клиенты обращаются к вам несколько раз в год, они не станут держать ваше приложение на телефоне. Если сотрудникам нужно просто заполнять форму при наличии связи, мобильная версия веб-сервиса закроет задачу дешевле и без магазинов приложений. Мы говорим об этом прямо: браться за проект, который не окупится содержанием, невыгодно и нам тоже — такие продукты умирают, а вместе с ними портится опыт совместной работы.
После выпуска начинается самое интересное: видно, какими экранами пользуются, а какие открывают один раз. Мы собираем обратную связь от реальных пользователей и планируем доработки по ней, а не по первоначальному списку пожеланий. Технические обращения и обновления идут через поддержку сервисов, а если нужна помощь и с устройствами сотрудников — через сопровождение ИТ.
