Dev Crabs

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

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

  • Платформы и состав работ согласуем до разработки
  • Стоимость и сроки — после разбора сценариев

Попробуйте сценарий

Работа продолжается, даже когда пропала связь

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

Демонстрация

Вымышленное приложение выездной команды

Условия в примере

Нет связи · ожидает отправки: 0

Выездная командаОфлайн

Мои задания

D-01 · Учебный объект · Север

Осмотр оборудования

Результат · пример заполнения

Осмотр завершён, нужна замена фильтра

Черновик на устройстве

Система компании · демо

Результаты из приложения

Сохранённые задания появятся здесь после синхронизации. В примере передача запускается кнопкой.

Принято заданий: 0 из 2

Пока нет переданных результатов.

Включите связь в демо, чтобы передать сохранённые задания.

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

    Видно, где находятся данные

    Сохранение на телефоне и приём сервером — разные состояния. Пользователь должен видеть, что уже передано, а что ещё ожидает связи.

  • Приёмка

    Проверяем путь целиком

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

Когда это нужно

Какие мобильные приложения можем разработать

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

  1. Сервис для ваших клиентов

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

  2. Инструмент для сотрудников на выезде

    Задания, чек-листы, отметки о выполнении и вложения с телефона. Если связь нестабильна, определяем, что можно делать без сети и как передавать изменения позже. Отдельно описываем, кто назначает задание, кто его выполняет и кто принимает результат.

  3. Приложение для партнёров

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

  4. Мобильная часть действующего продукта

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

Когда стоит начать с более простого формата

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

От экрана до результата

Что можно включить в приложение

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

  • Аккаунты и права

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

  • Работа с возможностями телефона

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

  • Данные без постоянной связи

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

  • Связь с системой компании

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

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

Как работаем

Как проходит разработка мобильного приложения

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

  1. Задача

    Определяем первую версию

    Уточняем аудиторию, основное действие, платформы и условия использования. Разбираем существующие системы и материалы. Фиксируем состав работ, зависимости, вопросы к заказчику и то, что пока остаётся за пределами версии.

  2. Прототип

    Проходим путь по экранам

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

  3. Разработка

    Собираем приложение и обмен данными

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

  4. Проверка

    Проверяем целевые устройства

    Сверяем сценарии с критериями приёмки на согласованном наборе устройств и версий ОС. Проверяем сеть, разрешения, возврат из фона и работу с ошибками. Дефекты фиксируем с условиями воспроизведения и повторно проверяем после исправления.

  5. Выпуск

    Готовим релиз и передачу

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

Как это устроено

Как выбираем платформы и устройство приложения

  • iOS, Android или одна платформа на старте

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

  • Нативный или кроссплатформенный подход

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

  • Серверная часть и управление

    Мобильный экран отображает данные, а сервер отвечает за бизнес-правила и права доступа. Если нужна панель для сотрудников, выделяем её в состав работ. Существующий веб-кабинет можно сохранить как отдельный канал доступа к тем же данным.

    Разработка личных кабинетов →
  • Согласованный способ распространения

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

Отличие

Отдельное приложение или веб-формат

Сравниваем формат по действиям пользователя и условиям работы. Наличие приложения в магазине само по себе не делает сервис удобнее: у человека должна быть причина установить его и возвращаться.

Мобильный сайт или Mini AppОтдельное приложение
Как начатьОткрыть ссылку в браузере или мессенджере.Установить приложение выбранным способом и пройти первый вход.
Регулярная работаПодходит для сценария, в который удобно возвращаться по ссылке или через мессенджер.Собственный интерфейс и навигация под повторяющиеся действия на телефоне.
Функции устройстваДоступность зависит от браузера или среды мессенджера.Нужные функции подключаем с учётом разрешений и ограничений ОС.
Работа без сетиВозможности зависят от реализации и среды; их нужно проверять для конкретной задачи.Можно спроектировать локальные данные и очередь изменений. Их состав и синхронизацию определяем заранее.
ОбновленияБольшинство изменений веб-интерфейса доставляется при следующем открытии.Учитываем выпуск новых сборок, версии на устройствах и совместимость с сервером.

Если сценарий лучше укладывается в Telegram или MAX, рассмотрим Mini App. Если важна проверка спроса, отдельно определим объём MVP. Эти решения могут предшествовать полноценному мобильному продукту.

Стоимость

От чего зависит стоимость разработки мобильного приложения

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

  • Платформы и интерфейс

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

  • Сервер и интеграции

    Готовность API, качество документации, авторизация, связи с учётными системами и необходимость административной панели. Если интерфейс обмена ещё нужно разработать, это влияет и на цену, и на последовательность этапов.

  • Офлайн и функции устройства

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

  • Выпуск и дальнейшая работа

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

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

Вопросы

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

Что входит в разработку мобильных приложений под ключ?

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

Можно ли начать с одной платформы?

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

Когда подходит кроссплатформенная разработка?

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

Сможет ли приложение работать без интернета?

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

Можно ли подключить существующий сайт или CRM?

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

Вы гарантируете прохождение проверки магазина?

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

Как определяются стоимость и срок?

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

Что будет передано после разработки?

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

Смежные задачи

Все услуги →

Ваше приложение

Обсудим первую версию

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

Или напрямую: Telegram ↗ · +7 931 203-30-78 · hello@dev-crabs.ru