Разработка мобильного приложения на заказ: полевым, не стору

Разработка мобильного приложения на заказ: полевым, не стору

Разработка мобильного приложения на заказ это полевой клиент к уже живой системе: осмотр, рейс, смена, а не витрина стора с анимацией и без хозяина процесса. Headline (headln.ru) делает такой клиент как часть полного цикла: роли, офлайн-шаги, сервер, мониторинг.

Риелтор фотографирует объект в галерею телефона. Курьер отмечает адрес в личке. Мастер пишет факт смены в блокнот, который вечером кто-то занесёт в Excel. Данные можно оставить On-Premise. Не студия «нарисуем и сдадим ipa».

Как факт доходит из поля

Человек делает жест в поле. Фото или статус встают в очередь, если сети нет. Сервер принимает факт. Журнал держит, кто отправил.

Полевой жестФото или статусОчередь без сетиСерверная системаЖурнал факта

Кому своё приложение оправдано

Команде, у которой работа случается не за монитором. Осмотр квартиры. Приёмка на воротах. Рейс курьера. Обход точки. Смена в цехе. Если сотрудник уже обходит систему телефоном, программа должна прийти туда, а не ждать его в офисе.

Ясный пример с сайта: агентство «Мегаполис-Недвижимость», 25 риелторов. В контуре CRM: мобильное приложение для быстрой загрузки фото с места осмотра. Стек включал React Native рядом с Python/Django, React, PostgreSQL, Redis, Docker. Время на сделку: минус 30%. Кейс: CRM для недвижимости. Приложение там: кусок контура, не отдельный продукт «для стора».

Для доставки на сайте другой полевой контур: курьер в Telegram-боте, Node.js, Redis, статус клиенту. Иногда бота достаточно, и отдельное приложение рано. См. система мониторинга доставки. Приложение заказывают, когда нужны камера, офлайн, свой маршрут и роли, которых боту мало.

  • Полевые делают работу руками, а факт всё равно вносят вечером в офисе.
  • Фото, подпись, координата или скан нужны в момент события, не «потом пришлём».
  • Есть серверная система: CRM, склад, заказы. Телефон: клиент к ней, не отдельный мир.
  • База объектов, клиентов или маршрутов не должна уезжать в чужой мобильный backend.

Когда бот, когда PWA, когда нативное на заказ

Telegram-бот быстрее и дешевле, если хватает кнопок статуса. Курьер часто так и живёт. PWA уместна, если полевой иногда у компьютера и офлайн не критичен. Нативное или React Native: когда камера, пуш, офлайн-очередь и магазинная установка уже требование, не каприз дизайнера.

Витрина стора без процесса: самый дорогой сувенир. Если нет CRM, склада или рейса, некуда писать факт. Сначала контур, затем клиент. База: разработка ПО на заказ. Узкий пилот: один сценарий, две роли. Формат: MVP за 14 дней. Магазинная публикация, все платформы и офлайн на всю номенклатуру в этот срок не входят.

Коробка «мобильная CRM» подходит типовой воронке. В недвижимости коробка не держала доски и бронь: писали своё, включая мобильный кусок. Если боль в продажах, сначала честно смотрят заказную CRM и CRM для агентства недвижимости, а не иконку в сторе.

Документы с телефона не обязаны быть редактором договора. Полевому: фото акта, статус, шаблон. Сборку пакета закрывает КонтрактПРО в офисе: 5–15 минут вместо 1–2 часов. Статья: электронный документооборот.

Как Headline делает мобильный контур

Сначала сценарий в поле, не экраны. Что человек делает одной рукой, где нет сети, что нельзя потерять, кто видит чужие адреса. Без этого получите красивое приложение, которое снова обходят WhatsApp.

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

Деплой, подписи, обновления, мониторинг. On-Premise backend, если персональные данные и маршруты нельзя отдать чужому BaaS. Сопровождение после публикации: сломанный пуш убивает привычку быстрее, чем отсутствие приложения. Тема: сопровождение после запуска.

Что обычно входит в первую версию

  1. Один полевой путь: фото объекта, статус рейса, приёмка, обход точки.
  2. Вход и роли. Не общая учётка «водитель» на весь автопарк.
  3. Очередь на слабой сети: факт не должен исчезнуть в подвале.
  4. Связка с серверной системой, которая уже является источником правды.
  5. Журнал: кто что отправил, чтобы разбор спора не шёл по памяти.
  6. Контур обновлений и копий. Приложение без сервера: сувенир.

Инфраструктура та же, что у остального ПО: обслуживание серверов. Периметр и закон: On-Premise и 152-ФЗ.

Риски мобильной разработки «как у стартапа»

Риск начать со стора. Публикация, отзывы, бренд. Полевой так и не получил кнопку, которая быстрее чата. Сначала внутренний контур, затем стор, если он вообще нужен.

Риск двух платформ сразу и десяти экранов. iOS, Android, офлайн, карты, чат, платежи в первой версии. Срок сгорает. Режут до боли: один факт, который сейчас теряют.

Риск офлайна «потом». В подвале, на складе, в лифте сети нет. Если факт критичен, очередь проектируют сразу. Иначе приложение винят в тот день, когда оно честно не отправило.

Риск чужого backend. Аналитика, пуш, файлы улетают в сервис, из которого нет выхода. Для объектов, паспортов и маршрутов это плохая сделка. On-Premise важнее удобной консоли вендора.

Риск ждать, что приложение заменит дисциплину. Если риелтор может не загрузить фото и всё равно провести показ, контур снова пустой. Нужен хозяин процесса. Подрядчик даёт клиент, не заменяет РОПа и старшего смены.

  • Нет серверной системы: некуда писать факт.
  • Нет пилотных пользователей в поле: приёмка по макетам в офисе.
  • Нет критерия: «удобно» вместо «факт дошёл за минуту».
  • Нет сопровождения: после релиза пуш и сертификаты умирают тихо.

Как проверить полевой сценарий, не рисуя витрину

Выйдите в поле на один день. Запишите, куда смотрит человек, что фотографирует, кому пишет, что теряет. Это постановка. Не стостраничное ТЗ. Если за день не находится один повторяемый жест, рано кодировать.

Пилот дают двум-трём людям, которые делают работу руками. Не IT и не собственнику «на демо». В кейсе недвижимости мобильный кусок имел смысл, потому что осмотр уже был ежедневным жестом, не идеей.

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

ИИ в камере: описание объекта по фото, разбор накладной. Имеет смысл, когда фото уже стабильно попадает в карточку. Иначе модель описывает хаос. Тема: внедрение ИИ в бизнес.

Складскому полевому часто нужен ТСД-сценарий, не потребительское приложение. Это ближе к WMS для склада, чем к стору. Не мешайте витрину и отбор в одном брифе без рамки.

Если поле уже теряет факт, в письме достаточно: кто в поле, какой жест повторяется каждый день, и в какую систему этот факт должен сесть.

Стор, подпись и обновления: когда это вообще нужно

Внутреннему контуру стор часто не нужен. Риелтор, курьер, мастер ставят приложение из вашей ссылки или MDM. Публикация имеет смысл, если клиент ваш должен скачать витрину. Для поля это редкость. Не начинайте проект с аккаунта разработчика в сторе.

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

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

Частые вопросы

01

Чем разработка мобильного приложения на заказ отличается от студии «под стор»?

Мы делаем клиент к вашему процессу и серверу: осмотр, рейс, смена. Не витрину ради публикации. Полный цикл: код, backend, мониторинг, сопровождение.

02

Было ли мобильное в кейсах Headline?

В CRM «Мегаполис-Недвижимость»: React Native для фото с осмотра, 25 риелторов, минус 30% времени на сделку. Для доставки на сайте: Telegram-бот, не отдельное приложение. Имя банка или «миллиона скачиваний» не выдумываем.

03

Когда хватит бота вместо приложения?

Когда нужны статусы и уведомления, а камера и офлайн не критичны. Мониторинг доставки на сайте как раз собран через Telegram API, Node.js и Redis.

04

Можно оставить данные на наших серверах?

Да. On-Premise backend: базовый вариант, когда объекты, телефоны и маршруты не должны уезжать в чужой мобильный облачный контур.

05

Приложение за 14 дней: что реально?

Один полевой сценарий и связь с уже живым сервером. Не две витрины стора, не офлайн на весь каталог, не публикация «как у банка».

06

Возьмёте приложение, которое писала другая команда?

Да. Аудит, узкие места, плавный переход, сопровождение. Поле не останавливаем ради красивого переписывания.

07

Как поставить задачу?

Опишите один жест в поле и систему, куда должен сесть факт. Письмо: welcome@headln.ru.

Если поле уже теряет фото, статус или подпись, напишите на welcome@headln.ru: кто работает вне офиса и какой факт должен доходить сразу, а не вечером.

Обсудить проект

welcome@headln.ru

Все статьи