Вернуться к блогу
В ритейле мобильное приложение почти никогда не начинается с чистого листа. Каталог живет в одной системе, остатки – в другой, правила лояльности – в третьей. Оплатой, доставкой и уведомлениями управляют отдельные сервисы.
Покупатель видит один экран. За ним работает целый контур.
Если подрядчик считает только экраны, риски остаются за рамками оценки. После запуска остаток может оказаться неактуальным, скидка на кассе – не совпасть с приложением, а оплаченный заказ – не попасть в учетную систему.
Поэтому до тендера важно обсудить не только интерфейс. Нужно понять, откуда приходят данные, кто отвечает за каждое действие и что произойдет при сбое. Ниже разберем, какие требования подготовить, как проверить команду и сравнить предложения по одинаковым критериям.
Два приложения могут выглядеть одинаково: каталог, карточка товара, корзина, бонусная карта и личный кабинет. Но трудозатраты будут отличаться в разы.
В одном проекте команда получает готовые данные через документированный API. В другом подключает несколько устаревших систем, учитывает разные правила для регионов и отдельно проектирует обмен данными. Интерфейс похожий, а технически это два разных продукта.
На оценку сильнее числа экранов влияют:
Если на первой встрече обсуждают только дизайн и функции, оценка может выглядеть точной, но надежной она не будет. До сметы нужно понять, какие системы выполняют каждое действие пользователя.
За интерфейсом приложения ритейла работают несколько систем, и каждая из них влияет на сложность и оценку проекта.
Формулировка «нужно приложение как у крупной сети» не помогает оценить проект. Команде нужно знать, какое поведение клиента должно измениться и какой показатель важен бизнесу.
Для первого релиза можно выбрать один основной сценарий:
Один приоритет не запрещает развивать остальные функции. Он отделяет ядро первой версии от идей, которые можно проверить после запуска. Попытка включить в первый релиз все сразу обычно заканчивается большим бэклогом и оценкой, которая быстро перестает быть актуальной.
До тендера соберите простую схему: какие системы уже работают, какие данные в них хранятся и кто отвечает за доступ.
Минимальный список вопросов:
На этом этапе не нужно проектировать всю архитектуру. Задача проще: показать границы продукта и найти зависимости, которые влияют на сроки и бюджет. Если карта систем еще не собрана, начать можно с системной аналитики и предпроектного обследования.
Обычный путь «открыть каталог и оформить заказ» покажет любая презентация. Качество решения проявится там, где что-то пошло не так.
Заранее обсудите:
Хороший подрядчик не обещает систему без ошибок. Он объясняет, как обнаружит проблему, ограничит последствия и восстановит корректное состояние данных.
Сначала определите источник истины для каждой группы данных. Каталог может обновляться раз в день, а остатки – каждые несколько минут. На экране они находятся рядом, но технически это разные потоки.
Нужно согласовать структуру категорий и фильтров, региональные цены, выбор магазина, допустимую задержку обновления, правила резервирования и поведение интерфейса при недоступности источника.
Отдельно разберите изображения и описания товаров: кто отвечает за качество и в каком формате они передаются. Без этих ответов проблема просто переедет в разработку.
Цифровая карта – только видимая часть программы лояльности. За ней стоят профиль клиента, бонусный баланс, уровни, начисления, списания, промокоды, сегменты и согласия на коммуникации.
До разработки определите, можно ли объединять профили, что происходит при смене номера телефона, как защищены операции с бонусами и где рассчитывается скидка. Если касса, сайт и приложение используют разные правила, конфликт увидит покупатель, а разбираться с ним придется поддержке.
Статус «заказ принят» должен одинаково пониматься приложением, учетной системой, магазином и доставкой. Иначе клиент видит одно состояние, а сотрудник – другое.
В требованиях опишите способы оплаты, подтверждение платежа, частичную отмену, замену товара и возврат. Туда же входят интервалы доставки, выдача по коду и самовывоз.
У каждого шага должен быть владелец – система или команда, которая меняет статус и обрабатывает ошибку. Если владельца нет, задача окажется между зонами ответственности.
Связь может идти через 1С, ERP, OMS, POS, iiko или промежуточный интеграционный слой. Само название системы ничего не говорит о сложности.
До оценки запросите документацию API, описание ограничений, тестовый контур и контакты ответственных специалистов. Если API еще нет, вынесите его разработку в отдельную задачу с владельцем, сроком и критериями готовности.
Срок мобильного релиза зависит от готовности ключевого обмена данными. Поэтому интеграции нужно планировать до разработки, а не после завершения интерфейсов.
Не каждой функции нужен полноценный офлайн. Иногда достаточно показать загруженный каталог, адреса магазинов или карту лояльности.
Но операции с остатком, балансом и платежным статусом требуют строгих правил. Нужно решить, какие данные кэшируются, сколько они актуальны и что произойдет при повторной отправке. Отдельный вопрос – как разрешаются конфликты после восстановления связи.
Формулировка «приложение должно работать офлайн» без сценариев не помогает: у заказчика и команды появятся разные ожидания.
Аналитику нельзя оставлять на период после релиза. До разработки команда должна знать, какие события покажут путь пользователя: просмотр карточки, добавление в корзину, начало оплаты, успешный заказ, отказ, ошибка и повторная попытка.
Отдельно нужен технический мониторинг. Он должен показывать стабильность приложения, ошибки API, время ответа критичных методов и сбои интеграций. Без мониторинга бизнес узнает о проблеме из отзывов покупателей.
До договора уточните, кто выпускает обновления под новые версии iOS и Android, разбирает инциденты и развивает продукт после запуска. Подготовка к релизу включает больше, чем финальный тест и публикацию в сторах.
Портфолио полезно, только если из него понятна роль команды. Студия могла сделать весь продукт, разработать один экран или подключиться к готовой системе на несколько месяцев.
Вместо вопроса «делали ли вы ритейл» разберите один сопоставимый проект. На встрече попросите команду:
Пригласите на встречу не только менеджера продаж. Нужны аналитик или технический лидер. По их вопросам быстро видно, понимает ли команда устройство продукта или пока считает интерфейс.
Отраслевой кейс снижает часть неопределенности, но не решает все. Команда без приложения именно для вашей категории тоже может подойти. Важнее подтвержденный опыт со сходными процессами: каталогом, заказами, платежами, лояльностью, высокой нагрузкой и интеграциями.
Сравнивать только итоговую сумму нельзя. Одна смета включает аналитику, дизайн, backend, интеграции, тестирование и публикацию. Вторая содержит только мобильный клиент.
Более дешевое предложение потом может обрасти работами, которые не посчитали на старте. В отдельном разборе стоимости мобильного приложения показано, какие этапы и зависимости сильнее всего влияют на бюджет.
Отправьте участникам одинаковый бриф. Попросите явно указать:
Хорошая предварительная оценка не обязана быть точной до рубля. Чем больше неизвестных в интеграциях и данных, тем честнее дать диапазон и список открытых вопросов. После обследования смету можно уточнить.
Сравнивайте не только деньги, но и результат каждого этапа: после аналитики остаются согласованные сценарии и требования, после дизайна – макеты с важными состояниями, после разработки – исходный код и рабочие сборки, после запуска – доступы, документация и процесс поддержки.
Предложения подрядчиков важно сравнивать по одинаковому составу работ, ответственности за интеграции и условиям поддержки.
Насторожитесь, если подрядчик:
Один признак еще не доказывает слабость команды. Но если подрядчик избегает разговора о рисках и границах ответственности, после старта эти вопросы почти неизбежно превратятся в дополнительные сроки и расходы.
В Amiga начинаем с бизнес-сценария, систем и данных: определяем, где хранятся каталог, цены и бонусы, кто управляет заказом и каких результатов бизнес ждет после запуска.
На системной аналитике фиксируем роли, статусы, интеграции и границы ответственности. Затем определяем состав первой версии и выбираем технологию под требования продукта, а не под удобство подрядчика.
До релиза проверяем основной путь и ошибки, а поддержку и мониторинг обсуждаем еще на этапе оценки. Подробнее – в разделе о мобильной разработке Amiga.
Работа над приложением начинается с бизнес-сценария и карты систем, затем команда определяет первую версию и готовит продукт к запуску.
Набор показателей зависит от цели приложения. Установки и регистрации сами по себе не показывают, приносит ли продукт пользу бизнесу.
Для розничного приложения можно отслеживать:
У каждой метрики должно быть управленческое действие. Если пользователи не доходят до оплаты, команда смотрит этапы воронки и ошибки платежа. Если после запуска выросло число обращений в поддержку, проверяет статусы заказов, уведомления и понятность интерфейса. Метрика без решения превращается в еще один отчет.
Нет. Важнее опыт с сопоставимыми процессами: каталогом, заказами, платежами, программой лояльности, высокой нагрузкой и интеграциями. Отраслевой кейс полезен, если из него понятны задача, роль команды и технические ограничения.
Передайте описание бизнес-цели, основной сценарий первой версии, список действующих систем, доступную документацию API, требования к платформам и известные ограничения. Если часть данных пока неизвестна, подрядчик должен зафиксировать допущения и объяснить, как они влияют на диапазон оценки.
Нет. Первый релиз лучше строить вокруг одного измеримого сценария. При этом архитектура должна учитывать развитие, чтобы добавление доставки, персонализации или новых способов оплаты не потребовало переписывать основу.
API может разрабатывать команда заказчика, мобильный подрядчик или отдельный интегратор. Важно до договора закрепить владельца, сроки, документацию, тестовый контур и критерии готовности. Иначе мобильная разработка будет зависеть от работы, которой нет в общем плане.
Да, если основная логика одинакова для iOS и Android и проект не требует большого количества специфичных платформенных функций. Каталог, личный кабинет, программа лояльности, заказы, платежи и push-коммуникации могут работать на Flutter. Ограничения нужно проверять по конкретным сценариям.
Передайте одинаковый бриф и сравнивайте не только сумму, но и состав работ, допущения, интеграции, тестирование, публикацию, права на код, гарантию и поддержку. Если состав результата различается, итоговые цены напрямую несопоставимы.
Только для определенных действий. Можно сохранить карту лояльности, адреса или часть каталога, но операции с остатками, бонусами и оплатой требуют правил синхронизации и защиты от повторного выполнения.
Ответственность нужно закрепить до договора. Подрядчик может поддерживать приложение и интеграции целиком или работать вместе с внутренней командой заказчика. В любом случае должны быть понятны каналы связи, приоритеты инцидентов, время реакции и порядок выпуска обновлений.
До подписания договора у заказчика должно появиться общее понимание продукта, а не только презентация студии. Нужно знать, что входит в первый релиз, какие системы участвуют в процессе, кто отвечает за каждую интеграцию, как принимаются этапы и сколько стоит эксплуатация после запуска.
Сильный подрядчик помогает сузить задачу, показывает риски и объясняет, какие решения пока рано фиксировать. Если после встреч стало больше ясности о продукте и меньше скрытых допущений, команда действительно участвует в проектировании. Если обсуждение все еще сводится к ставке и количеству экранов, сравнивать предложения рано.
Перед тендером зафиксируйте три вещи: основной сценарий первой версии, карту систем и владельцев данных, а также перечень критичных сбоев. Этого достаточно, чтобы получить не идеальную, но сопоставимую стартовую оценку и увидеть, какие вопросы подрядчик задает сам.
Продолжаем разбирать такие задачи в Telegram: в канале Amiga пишем о заказной разработке, процессах и кейсах, а в Flutter Amiga – о кроссплатформенной разработке, инструментах и практике команды. Там же публикуем новые материалы блога и новости проектов.
