Мобильное приложение для 40 торгпредов за 3 месяца: наш кейс с 1С

Мобильное приложение для 40 торговых представителей мы построили и запустили в 1С за 3 месяца — с недельными демо клиенту, готовым модулем обмена с 1С и жёстко урезанным MVP: заказ, остатки, синхронизация раз в 15 минут. Ускорил не героизм команды, а отказ от лишних экранов и правок на ходу.

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

Заказчик — оптовая компания из Подмосковья, поставляет стройматериалы в розничные точки. 40 торговых представителей объезжали магазины и фиксировали заказы в блокноте, а вечером вручную переносили их в 1С:Управление торговлей. Заказ мог провисеть сутки, пока его внесут, а остатки на складе к этому моменту уже не совпадали с тем, что реп видел утром.

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

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

как мы уложили разработку в 3 месяца: наш процесс

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

Вместо отдельного API-слоя между приложением и 1С мы взяли 1С:Мобильную платформу — она обменивается данными с 1С напрямую, и не пришлось с нуля писать и отлаживать REST-обвязку. На типовом проекте с внешним API этот слой обычно съедает три-четыре недели только на сверку форматов данных.

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

Третий спринт ушёл на интеграцию с 1С на копии базы, нагрузочный прогон на реальном числе позиций из прайса и публикацию в сторы. К концу двенадцатой недели 40 представителей уже могли открыть приложение и увидеть актуальные остатки.

что делать, если сроки срываются на этапе интеграции с 1С

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

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

У приложения есть доступ к контактам клиентов из 1С — ФИО, телефоны, адреса доставки. Это персональные данные, и их обмен с мобильными устройствами должен соответствовать 152-ФЗ: шифрованный канал, ограничение доступа по ролям и отсутствие лишних данных в кэше приложения. Эти требования закладываем в архитектуру на этапе интеграции, а не добавляем задним числом — переделка защиты данных после того, как приложение уже разошлось по 40 устройствам, обходится дороже, чем сделать правильно сразу.

как предотвратить срыв сроков в следующем мобильном проекте

Часть проблем на старте видна заранее, если знать, куда смотреть.

• ✓Фиксировать MVP в техзадании до начала разработки и не расширять список экранов в процессе спринта — новая функция входит во вторую очередь, а не в текущий релиз.
• ✓Закладывать в план неделю на модерацию в App Store и Google Play — сроки проверки не всегда предсказуемы, и это не должно ломать дату запуска.
• ✓Тестировать обмен с 1С на копии базы, а не на боевой, и держать окно синхронизации вне пиковой нагрузки бухгалтерии.
• ✓Собирать команду по минимуму — 1С-программист и мобильный разработчик, которые общаются напрямую, без цепочки менеджеров между ними и заказчиком.

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

сколько стоит разработка мобильного приложения за 3 месяца

Разработка мобильного приложения у нас начинается от 500 000 рублей. В эту сумму входит MVP с интеграцией в 1С, тестирование на копии базы и публикация в сторах — то есть ровно тот объём, который мы закрыли в кейсе с торговыми представителями. Итоговая цена зависит от числа экранов, глубины обмена данными с 1С и того, нужна ли синхронизация в реальном времени или раз в 15 минут достаточно.

Ниже — разница между тем, как обычно идёт похожий проект, и тем, что получилось у нас за счёт узкого MVP и готового механизма обмена с 1С.

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

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

Сколько стоит разработка мобильного приложения с интеграцией в 1С?

От 500 000 рублей — цена зависит от числа экранов, глубины интеграции с 1С и нужна ли синхронизация в реальном времени. Точную стоимость считаем после короткого ТЗ с фиксированным MVP-списком функций, это же ТЗ потом становится границей проекта, которую не расширяем на ходу.

Можно ли уложиться в 3 месяца, если приложение сложнее, чем заказ и остатки?

Да, если сузить MVP до одного ключевого сценария и вынести остальное во вторую очередь после запуска. Три месяца — реалистичный срок для одного модуля с интеграцией в 1С; несколько ролей пользователей или сложная аналитика обычно требуют отдельного этапа разработки.

Что происходит, если разработчик срывает сроки интеграции с 1С?

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

Нужно ли отдельно защищать персональные данные клиентов в мобильном приложении?

Да, если приложение передаёт на устройства представителей ФИО, телефоны или адреса клиентов — это персональные данные, и обмен должен соответствовать 152-ФЗ. Мы закладываем шифрование канала и ограничение доступа по ролям ещё на этапе интеграции с 1С.

Какая платформа быстрее — нативная разработка или 1С:Мобильная платформа?

Для B2B-сценариев с прямым обменом с 1С быстрее 1С:Мобильная платформа — она избавляет от отдельного API-слоя и ускоряет интеграцию. Для приложений со сложным UI или без 1С в основе чаще выбираем нативную или кроссплатформенную разработку под конкретную задачу.