Почти 10 лет эволюции мобильного приложения для мерчендайзеров: от простого ТЗ до B2B-платформы
В 2017 году к нам пришёл клиент с запросом на мобильное приложение для мерчендайзеров. Ничего грандиозного — ТЗ уместилось на паре страниц: сотрудник получает задание на день, проходит по точкам, заполняет чек-лист, прикрепляет фото и отправляет отчёт. Мы сделали приложения под iOS и Android — нативные, каждое под свою платформу — и запустили. Думали, проект закрыт.
Оказалось — только начинается. Спустя почти 10 лет это уже не «приложение для мерчендайзеров», а полноценная B2B-платформа, которой ежедневно пользуются тысячи человек. Вот что мы прошли за эти годы и чему научились.
Что клиент просит и чем реально пользуются — часто разные вещи
Первое, что мы заметили после запуска: половина отчётов, которые заказчик называл критически важными, пылилась без дела. Супервайзеры, для которых они делались, просто ими не пользовались — у них сложились свои рабочие привычки, и дополнительные экраны оказались лишними.
Сами мерчендайзеры в полях использовали только базовый сценарий: получить задание → пройти чек-лист → сфотографировать → отправить. Всё. Остальные функции — мимо.
Когда обсуждаешь требования с клиентом, недостаточно записать «нужен отчёт по эффективности». Надо сесть и буквально проиграть каждый сценарий: кто, в какой момент, с какой целью открывает этот экран. Если такого сценария нет в рабочем дне реального человека, функция, скорее всего, не взлетит. Теперь мы всегда прорабатываем сценарии использования до старта разработки.
Почему терминология клиента важнее, чем кажется
На старте в коде у нас были «магазины». Через год выяснилось, что у клиента не магазины, а «партнёры», у которых могут быть «торговые площади». Те же сущности в реальном мире — но в архитектуре приложения это совсем другая структура данных.
Мы перекраивали логику на ходу. Фатального ничего не случилось, но накладные расходы на поддержку растут: чем дальше проект уходит от изначальной модели данных, тем тяжелее его развивать. У нас есть для этого метафора: сначала построили шалаш под конкретную задачу, потом пристроили сарайку, потом гараж, а теперь это уже дом — но фундамент остался от шалаша. Рано или поздно приходится перепроектировать.
Теперь, когда мы слышим от клиента термины, которые могут со временем стать абстрактнее, закладываем гибкость сразу. Лучше немного перепроектировать на старте, чем перелопачивать через три года.
Как мы строили защиту от находчивых пользователей
Приложение должно было подтверждать, что мерчендайзер действительно находится в торговой точке и делает фото на месте. Звучит просто. На практике это превратилось в череду доработок, растянувшуюся на годы.
Сезон 1. Фото из галереи
Сотрудники делали снимки на точке заранее, а потом пачками загружали их из дома. Решение: убрали возможность выбора фото из галереи, оставили только съёмку через камеру.
Сезон 2. Кастомные камеры
Следующий ход: люди начали ставить приложения, которые подменяют системную камеру и опять дают доступ к галерее. Пришлось написать свою камеру, встроенную прямо в приложение, — она не зависит от системной и не даёт выбрать готовый снимок.
Сезон 3. Подмена GPS
Появились программы, подменяющие геолокацию, — можно сидеть дома, а телефон «думает», что ты на точке. Решение: добавили детектор таких приложений — если на устройстве установлен GPS-спуфер, приложение не запускается.
Сезон 4. Старые версии
А часть пользователей вообще не обновлялась и продолжала работать на версиях, где этих ограничений ещё не было. Пришлось ввести принудительное обновление — сервер блокирует работу старых версий, пока не установишь актуальную.
Сезон 5. Фото экрана ноутбука
Самое изобретательное: человек сохранял фото точки на ноутбук, проезжал мимо неё на автобусе (чтобы GPS показал нужный радиус), открывал приложение на телефоне и фотографировал экран ноутбука. Решение: ужесточили радиус GPS-контроля и подключили нейросеть для анализа снимков — она умеет определять признаки того, что фото сделано не напрямую, а с экрана.
Сезон 6. «У меня всё стёрлось!»
Отдельный жанр — звонок вечером: «Я весь день работал, а приложение всё удалило, ничего не сохранилось». Мы долго не могли понять, в чём дело, пока не заметили закономерность: человек удалил и заново установил приложение полчаса назад. Решение оказалось простым: добавили на экран отчёта дату первой установки приложения на устройство. Когда сотрудник жалуется в 20:00, а дата установки — 19:55, вопросы снимаются сами собой. После этого «пропажи данных» прекратились.
После всего этого мы поняли простую вещь: если ваше приложение работает в поле и контролирует сотрудников, закладывайте защиту от манипуляций на старте. Это норма для такого класса систем. Люди творчески подходят к оптимизации своего труда, и ваша задача — направить эту энергию в конструктивное русло, а не играть в догонялки.
С чем ещё сталкиваешься, когда проект живёт почти 10 лет
Кроме антифрода, за эти годы мы прошли через несколько вещей, к которым небольшое приложение оказалось не готово — и которые стоит держать в голове, если вы задумываете похожий продукт.
Лавина данных
Когда пользователей становится не десятки, а тысячи, и каждый ежедневно создаёт десятки фото и позиций в отчётах, — данные начинают расти экспоненциально. Мы столкнулись с терабайтами фотографий и сотнями тысяч отчётов. Пришлось серьёзно вложиться в оптимизацию базы данных: переписывать тяжёлые запросы, внедрять индексы, следить, чтобы итоговые отчёты формировались быстро, а не «подумайте пару минут». Выгрузка архива с фото, которая на старте занимала пару секунд, с ростом объёма стала занимать минуты — сейчас решаем это переносом в фоновые очереди.
Оффлайн-режим
Приложение должно работать без интернета — мерчендайзеры бывают в точках, где связи нет. Это must-have, но у него есть обратная сторона: каждая новая версия может менять структуру локальной базы данных на устройстве. Если миграция написана с ошибкой или не протестирована на переходе со старой версии — у пользователя приложение просто «умирает» при обновлении. С переходом на Flutter в 2022 году таких проблем стало меньше, но правило осталось железным: тестировать миграции между версиями так же тщательно, как и саму новую функциональность. И не только на чистой установке, а именно на обновлении.
Интеграции только через API
В какой-то момент к проекту подключилась нейросеть для анализа фото (подсчёт товаров на полке, проверка соответствия планограмме). Её делал сторонний подрядчик, и для скорости интеграцию сделали через прямой доступ к базе данных. Это работает, но любое изменение структуры БД ломает внешнюю систему, а отследить все зависимости сложно. С тех пор правило железное: любые внешние интеграции — только через API. Никаких прямых подключений к базе, никаких исключений.
Роли и доступы
На старте было три роли: админ, мерчендайзер, супервайзер. Со временем выросла целая иерархия: добавились аудиторы, представители клиента с возможностью управлять своими сотрудниками, разные уровни доступа к отчётам. Система прав, спроектированная под три роли, не масштабируется на десять. Пришлось перепроектировать. Теперь при проектировании любой системы с пользователями мы сразу закладываем гибкую ролевую модель — даже если на старте ролей всего две.
Что сейчас и куда дальше
За почти 10 лет проект прошёл путь от нативных iOS и Android к Flutter, прошёл редизайн и продолжает развиваться. Технические детали и скриншоты я собрал на странице кейса .
Сейчас мы готовим большой рефакторинг бэкенда — переезд на Laravel и перепроектирование архитектуры, которая росла вместе с проектом. Тот самый фундамент от шалаша пора менять на фундамент под дом.
Этот проект — не просто строчка в портфолио. Это живой продукт, который почти 10 лет помогает реальным людям делать свою работу. И для нас он стал лучшей школой: мало какой учебный курс даст столько опыта, сколько семь лет непрерывной разработки одного продукта.
Если вы задумываете похожий продукт — приложение для полевых сотрудников с фотоотчётами, геолокацией и оффлайн-режимом — вот что я бы посоветовал, имея за плечами этот опыт.
- Первое: потратьте время на сценарии. Не на список функций в ТЗ, а на то, как реальный человек откроет приложение утром, что сделает в течение дня и что ему действительно пригодится. Половина того, что заказчик называет критически важным, может оказаться бесполезным.
- Второе: закладывайте гибкость в архитектуру и ролевую модель. Через пару лет сущностей и ролей будет в разы больше, чем на старте, и перепроектировать на ходу больно.
- И третье: антифрод. Если ваше приложение контролирует людей в полях — защиту от манипуляций делайте в числе первых функций. Встроить её сразу дешевле и проще, чем догонять потом.
Технические детали, функции и скриншоты проекта →читайте в нашем кейсе .
