Как мы спасли бизнес под санкциями: перезапустили платформу и сохранили всех клиентов
Рассказываем, как мы перепроектировали публичную часть продукта, улучшили пользовательский опыт и даже сохранили старый дизайн (почти).
💬 Привет! На обложке статьи — я, клиент, которому команда ADV помогла перезапустить онлайн-бизнес в России. Я хочу сохранить конфиденциальность проекта (международная компания), поэтому попросил ребят рассказать о кейсе обезличенно. Читая текст, вы можете представить бизнес в любой нише: косметика, спортивные товары, еда. Надеюсь, что вы не сердитесь на меня и вам будет так же интересно. Передаю микрофон ребятам. Они расскажут обо всём от и до: как мы начинали, какие были сложности и что вышло из нашей работы.
Один проект — две команды или Как мы начинали
К проекту мы подключились в августе 2024 года — это один из редких случаев, когда клиент приходит не сам, а через другую IT-компанию, с которой нам предстояло работать вместе.
После ужесточения санкций компания искала решение, которое позволило бы сохранить онлайн-бизнес в России. Стандартные коробочные решения оказались ограниченными, а разработка с нуля — рискованной. Было непонятно, нужно ли это вообще, если международная система продолжит работать. Но вскоре всё стало ясно: переход на новую платформу в России неизбежен. Так мы и начали работу, где наша команда занималась бизнес-анализом, UX/UI-дизайном и публичной частью продукта, а другая команда — системным анализом, бэком, фронтом админки и всей архитектурой.
Чтобы воссоздать полный функционал международной платформы, которая развивалась десятилетия, нужно два-три года. Мы делали это итерационно, и наш дедлайн был год, но нужно закладывать и возможные форс-мажоры, из-за которых срок ещё может сократиться. А значит, времени на раскачку не было. Нужно было действовать быстро: выделить самое необходимое — то, без чего бизнес не сможет работать, и реализовать это первым. А здесь уже дело за MVP — самой простой рабочей версией продукта.
Сначала — бизнес-анализ, потом — кнопки
Бизнес-анализ здесь — это понять, что важно для клиента, а потом оформить в пользовательский сценарий и решить, как это должно работать на фронте. Но в этом случае не получилось вести анализ по канонам. Вместо классического подхода, при котором аналитик сначала выясняет бизнес-задачу, потом даёт рекомендации, а дальше начинается реализация, мы перешли к работе с существующими решениями. Нужно было быстро воспроизвести то, что уже есть. Только так можно было не останавливать работу платформы (и пожертвовать идеальностью).
При этом по ходу дела многое менялось. Клиент часто решал не повторять старые, неудобные решения, даже если они уже были в системе. Иногда мы вместе находили варианты, как сделать лучше. А иногда, наоборот, приходилось сознательно копировать «костыль», потому что без него рушилась логика работы и менять всё было слишком рискованно.
Из-за особенностей процессов бизнес-анализ и системный анализ, который вели коллеги из другой IT-компании, начали пересекаться. Мы отвечали за бизнес-логику и интерфейсы, а коллеги из другой команды вели системный анализ. Иногда границы размывались: сроки поджимали, задачи росли, и часть бизнес-анализа по отдельным фичам коллеги брали на себя. Это скорее исключение, чем правило: обычно мы закрываем весь аналитический блок полностью. Но в этом проекте задачи распределялись гибко, в зависимости от контекста и скорости реакции.
💬 Ой, а это снова я — клиент, которому посвящена статья. И вот что я хочу добавить: на проекте было шесть аналитиков и параллельно с задачами, которые нужно было сделать ещё вчера, шла адаптация и погружение в продукт. Поэтому один из главных челленджей первых месяцев — не задачи, а темп. Он был высоким с самого начала, и приходилось учиться «в бою». Фух, теперь у вас полная информация и я спокоен. Давайте дальше.
На стороне аналитики получилась такая картина:
- Мы — бизнес-анализ. Сценарии, требования, макеты, работа с фронтом.
- Коллеги — системный анализ. Спецификации, архитектура, ограничения, алгоритмы.
- Вместе — плотная коммуникация.
Можно сказать, что основная задача здесь — воспроизвести текущую бизнес-логику: важно было сохранить то, что уже работает. Но это не значит, что обошлось без улучшений: они были как в публичной части, так и в админке. Где-то мы упростили сценарии, сделали интерфейс понятнее, отказались от лишнего. Архитектурно же проект стал совсем другим: тут мы отходили от старого подхода и строили систему под новые задачи с нуля. Так было и с дизайном: в него мы внесли много изменений.
Незаметный (в хорошем смысле) редизайн
Задача звучала так: сделать копию сайта и всё оставить как было (шрифты, стиль, UX). Если же дизайнеры увидят места, которые можно улучшить, пускай улучшают, но аккуратно.
На практике это означало сохранить узнаваемость бренда, общий вайб, поведение элементов, но при этом где-то облегчить путь пользователя и привести интерфейсы к современным e-com-стандартам. А это задача, противоположная озвученной «сделать копию сайта».
И всё-таки нам удалось усидеть на двух стульях. Сначала мы долго изучали старую платформу: что там привычно, что работает хорошо, а что давно пора отпустить. В итоге основная логика осталась, а детали, которые мешали, — нет. Мы внесли сотни мелких правок: где-то упростили путь пользователя, избавились от лишнего, сделали интерфейс чище и понятнее. Например, мы убрали серые кнопки без объяснений, переписали непонятные тексты, почистили карточки товаров от пустых блоков. Всё это дало новую, но при этом знакомую платформу.
💬 Разошлись-то как! А теперь давайте человеческим языком: нам хотелось, чтобы редизайн не бил по глазам, а воспринимался как «О, вроде всё как раньше… но удобнее». Вот к этому мы и шли, хотя сначала планировали только копию. А потом мы вместе начали вносить улучшения и поняли, что можно не просто копировать, а делать лучше — и команде это было интереснее. Мы наконец исправили то, что годами не нравилось. А раньше это было невозможно, потому что дизайн всегда шёл от международного руководства.
Мы старались сделать продукт не новым, а узнаваемым, и это сработало. Осталось только реализовать это на стороне разработки, о которой мы расскажем дальше.
Разработка и синхронизация с другой командой
Главное на этом проекте по части разработки — синхронизация. Представьте, что две разные команды пишут один и тот же документ. Одни думают, что главное — продумать, как выглядит и работает кнопка для пользователя, а другие — как её реализация повлияет на всю систему: не нарушит ли логику или безопасность. Когда работаешь с внешней командой, кажется, что проще самому всё сделать, чем объяснить. Но выбора не было: мы — за публичную часть, коллеги — за системный анализ, бэк и админку. Поэтому мы начали искать общий язык. Спойлер: нашли.
Работа по дизайну происходила так: сначала дизайн проверяли бизнес-аналитики, потом — системные аналитики и только после — клиент. Каждый этап требовал согласования и правок. А вот в аналитике и разработке пришлось синхронизироваться каждый день. Но мы смэтчились по общим опорам: Jira, Confluence, спринты, дейлики, roadmap. Но даже при общем «каркасе» внутри было много различий.
Особенно непросто было на старте фронтенд-команде. Мы начали с вёрстки, не дожидаясь готовности бэкенда и финальных API-контрактов, которые потом ещё несколько раз менялись. Из-за этого мы постоянно подстраивались, переделывали, затыкали баги и тратили время на доработки, которых можно было бы избежать. Это классическая ошибка — начинать раньше, чем готовы интеграции, но в условиях дедлайна иначе было нельзя.
Ситуацию осложняло ещё и то, что сначала у нас была только одна рабочая среда — так называемый DEV-стенд, где разработчики проверяют свою работу. А всё новое сразу выкатывалось в UAT — это тестовая среда, которую использует клиент. Из-за этого на клиентской стороне могли появляться ошибки, потому что изменения не проходили нормальную проверку. Только недавно мы вернулись к правильному процессу: сначала всё тестируем внутри команды на DEV, а потом — на UAT, где уже смотрит клиент.
💬 Синхронизация происходила не только на уровне документации и согласований. Многое команды обсуждали на звонках, где каждый мог сказать: «Это так не работает», — и проблема решалась. Но созвоны были не совсем типичные, а в виде бесконечного зума, куда каждый мог залететь в любое время, чтобы задать вопрос. То есть звонок вообще не заканчивался: разработчики собирались, чтобы решить задачу (или пообщаться).
Что забираем с собой в следующие проекты
Местами проект был про выживание, но зато мы поняли, как работать, когда всё постоянно меняется, а делать надо «уже вчера». Вот что забираем с собой дальше:
- Синхронизируемся. Когда требования дописываются на ходу, а к старым задачам нужно возвращаться из-за нововведений, важно, чтобы все были в курсе. В этом проекте мы научились договариваться и поняли, что в работе с внешней командой нужно прийти к чувству, будто вы из одной компании. В большей степени нам помог синхрон: дейлики, ежедневная сверка, планирование задач, спринты и фиксирование договорённостей. Но ещё важнее — участие клиента, который в этом кейсе не просто ставил задачи, а шёл с нами в одном ритме, как партнёр.
- Забиваем на идеал, если этого требует проект. Мы сознательно шли не от лучших решений, а от реалий, что-то упрощали или выносили «на потом». Где-то приходилось мириться с тем, что лучше сделать не получится из-за ограничений системы.
- Адаптируемся к любым условиям. Всё меняется, и даже то, что уже согласовано. Иногда бывает, что старая аналитика внезапно становится неактуальной. Проект живой, поэтому мы не закапываемся в «Но было написано по-другому», а быстро реагируем.
💬 Но на этом не всё: с самого начала мы строили систему так, чтобы её можно было масштабировать, поэтому проект только начинает развиваться. Впереди ещё долгий путь к «оригинальному» виду платформы и бэклог задач на годы вперёд.