ЦОП/МАРКЕТ | Трансформация работы аналитиков
E-commerce платформа с комплексными сценариями продаж и управления заказами

Индустрия: Телекоммуникации, E-Commerce
Тип продукта: Мобильное приложение для продаж и управления заказами (экраны продукта, корзины, доставки, оплаты)
Срок реализации: Весна 2023 – начало 2025 года
Explore
Результат:
  • Сокращение времени на фиксацию требований к экранам с 2-3 дней до 1 дня за счёт автоматической генерации сборок и автотестов из конфигурационных файлов на бэкенде.
  • Внедрение seamless end-to-end пользовательских потоков, включая покупку за один проход.
  • Ускорение time to market и процессы тестирования благодаря кастомным ревизиям и изолированным путям.
  • Полное владение процессом аналитиками: от сбора требований до реализации и тестирования.
«Решение позволило нам взять полную ответственность за реализацию, превращая требования в рабочие экраны эффективно — это настоящая трансформация работы аналитиков».
Батин Никита, Senior System Analyst, Стрим фронт платформ
Введение
Ранее команда занималась нативными приложениями на Android и iOS, расширилась до веб-разработки и исследовала способы повышения эффективности. Благодаря сильной аналитической базе в сборе и фиксации требований, они выявили возможность оптимизировать фронтенд без привлечения специализированных разработчиков.
Цели проекта
  • Снижение нагрузки на аналитика за счёт автоматизации процесса написания документации.
  • Количество выпускаемого программного кода и фич в рамках спринта значительно выросло.
  • Сохранить полный контроль над требованиями, минимизируя потери при интерпретации.
  • Поддержать сложные компоненты, такие как экраны продуктов, корзины и платежей, в едином пути.
По инициативе CTO Ярослава команда перешла на систему для фронтенд-разработки, чтобы использовать её интуитивные инструменты. Аналитики получили возможность напрямую воплощать свои идеи в интерфейсах, минуя долгие циклы согласования с разработчиками. Это сделало процесс быстрее, прозрачнее и эффективнее.
Фаза 1: Упрощение документации и переход к Server-Driven UI
Ранее создание одного экрана требовало 2–3 дня на подробную документацию: описание кейсов, условий отображения элементов и их состояний. Команда перешла на server-driven UI, где интерфейс управляется данными с бэкенда. Аналитики внедрили конфигурационные файлы, хранящиеся в репозиториях бэкенда, которые задавали флаги и состояния для фронтенда. Это позволило фронтенду автоматически отображать нужные элементы без лишних инструкций.
Ценности для команды:
  • Экономия времени: Время на подготовку экрана сократилось до 1 дня, включая готовую сборку и автотесты.
  • Автономия аналитиков: Аналитики сами задавали логику интерфейсов, минимизируя зависимость от разработчиков.
  • Точность: Требования фиксировались в виде таблиц, что исключало их искажение при передаче.
  • Продукт: Быстрее создавались рабочие прототипы, что позволяло стейкхолдерам видеть прогресс.
Фаза 2: Быстрое прототипирование с моками API
Команда активно сотрудничала с бэкендом, используя моки API для создания и тестирования экранов до появления рабочих эндпоинтов. Это позволило быстро верстать интерфейсы и вносить до 5–10 изменений в месяц на экран небольшой командой из двух аналитиков. Для гибкости ввели именованные идентификаторы экранов (например, "cart_screen"), которые позволяли управлять конфигурациями экранов до появления официальной системы ревизий на платформе.
Ценности для команды:
  • Скорость итераций: Моки ускорили прототипирование, позволяя тестировать идеи без ожидания готового бэкенда.
  • Гибкость: Именованные идентификаторы дали возможность легко переключаться между версиями экранов, адаптируясь к новым требованиям.
  • Экономия ресурсов: Небольшие команды могли быстро обновлять сложные экраны, такие как экран продукта или корзины.
  • Продукт: Быстрое прототипирование обеспечило стейкхолдерам ранний доступ к функционалу, улучшая обратную связь.
Фаза 3: Кастомные ревизии для параллельного тестирования
Команда разработала собственную систему ревизий, где каждый экран мог иметь несколько версий (например, от 8 операций в нулевой версии до 20+ в последующих). Аналитики могли загружать нужный набор ревизий через уникальный идентификатор (MSISDN), тестируя изолированные потоки без влияния на другие изменения. Это решение появилось раньше, чем нативные функции релизов в системе для фронтенд-разработки, обеспечивая точечное тестирование и устранение багов. Совместимость с GraphQL и выделенный бэкенд для обработки API-ответов упростили подготовку данных, минимизируя нагрузку на фронтенд.
Ценности для команды:
  • Изолированное тестирование: Каждый аналитик мог тестировать свою версию экрана, не затрагивая другие потоки, что упростило поиск и устранение багов.
  • Параллельная работа: Несколько аналитиков могли одновременно обновлять разные экраны, ускоряя общий прогресс.
  • Контроль качества: Изоляция ревизий позволяла точно отслеживать, где и кем внесены изменения, повышая надежность.
  • Продукт: Сложные сценарии, такие как переход от корзины к оплате, стали более устойчивыми и масштабируемыми.
Команда перешла на Kanban, что идеально подошло для новой роли аналитиков: они курировали дизайн, проектировали эндпоинты, создавали и тестировали экраны. Требования фиксировались в удобных артефактах, таких как карты экранов в BPMN-нотации, которые напрямую воплощались в системе для фронтенд-разработки. Это позволило создать единый пользовательский путь — от выбора продукта до оплаты — без разрывов и лишних согласований.
Сотрудничество с технической поддержкой через звонки быстро решало сложные задачи, такие как настройка выражений для динамических интерфейсов. Это повысило качество сборок.


Измеримые результаты:
  • Скорость разработки: Время на создание и тестирование экранов сократилось с 2–3 дней до 1 дня. Аналитики самостоятельно проводили регрессионное тестирование через кастомные пути, освобождая тестировщиков для финальных проверок на этапе релиза.
  • Быстрые итерации: Изолированные ревизии позволяли моментально выявлять и исправлять баги, не замедляя работу других членов команды.
  • Продуктивность команды: Бригада из аналитиков, тестировщиков и продуктовых менеджеров работала параллельно, используя конфигурации для одновременного тестирования разных сценариев.
  • Автономия и вдохновение: Аналитики получили полный контроль над процессом, от требований до готового интерфейса, что особенно вдохновило тех, кто имел опыт разработки.
  • Ценность для продукта: Плавные пользовательские пути, такие как покупка за один проход, стали более надежными и удобными, улучшая потенциальный пользовательский опыт.



Работая с развивающейся платформой, команда ЦОП/МАРКЕТ не только адаптировалась к её возможностям, но и создавала собственные решения, которые предвосхищали обновления платформы. Это сотрудничество превратило аналитиков в ключевых игроков разработки, а проект — в пример успешного внедрения low-code в телекоммуникациях.