Time to market мобильного приложения: где теряют недели до сторов

Time to market мобильного приложения — срок от решения «делаем» до дня, когда первый пользователь реально открыл рабочее приложение в сторе. Разработка кода редко срывает график: чаще подводят интеграция с 1С backend заказчика, юридическая проверка персональных данных и повторные отклонения на модерации. Сократить срок помогает не ускорение программистов, а управление именно этими точками с первого дня проекта.

где на самом деле утекают недели: шесть этапов от идеи до стора

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

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

скрытый этап, который не попадает в смету

Если приложение собирает телефон, адрес доставки или геолокацию сотрудника, перед публикацией нужна публичная политика обработки персональных данных и правовое основание по 152-ФЗ. Юридическая проверка обычно всплывает не на старте, а за неделю до релиза — когда сторы уже требуют ссылку на политику конфиденциальности в карточке приложения, а её ещё не согласовал юрист заказчика. Итог один: готовое приложение лежит и ждёт подписи на документе, который можно было согласовать ещё на этапе технического задания.

три пути ускорить разработку — и чем каждый платит за скорость

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

когда важна скорость выхода, а не уникальный дизайн

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

когда скорость уступает место контролю над UX

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

четвёртый вариант — доработка готового каркаса под похожий сценарий

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

что из этого решает именно для вашего проекта

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

интеграция с 1С — этап, который чаще всего рвёт график

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

Цена простоя здесь не абстрактная. Торговые представители продолжают писать заказы в блокнот и Excel, склад отгружает по вчерашним остаткам, а конкурент, который раздал планшеты сотрудникам в начале квартала, уже забирает часть оптовых заказов на день раньше. Приложение при этом технически готово — просто не может говорить с учётной системой, и от этого не легче ни продажам, ни складу.

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

модерация в App Store и Google Play: что реально ускоряет проверку

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

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

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

публикация в сторе — не финиш, если клиент из госсектора

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

как сокращаем срок выхода в сторы в UKVED

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

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

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

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

Срок зависит от подхода и глубины интеграции с 1С. Нативная разработка обычно занимает от 4 месяцев, кроссплатформенная — от 2-3 месяцев, а приложение поверх 1С:Мобильной платформы или готового каркаса — от нескольких недель, потому что часть логики уже готова.

Что чаще всего срывает срок выпуска приложения в сторы?

Чаще всего не код, а интеграция с 1С backend заказчика без готового тестового API, юридическая проверка обработки персональных данных и повторные отклонения при модерации из-за неполных метаданных или отсутствия демо-доступа для проверяющих.

Можно ли ускорить саму модерацию в App Store и Google Play?

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

Нативное приложение или кроссплатформенное, если нужно быстрее выйти в сторы?

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

Что делать, если целевой клиент — государственная организация?

Закладывать включение в реестр российского ПО отдельным треком заранее: процедура идёт независимо от разработки и может занять дольше, чем написание кода, а без записи в реестре крупный B2G-клиент часто не может провести закупку по 44-ФЗ или 223-ФЗ.