«Ашан» и Ensi. От нуля до 10% выручки в екоме

Так, были определены требования:

Сборка состоит из 4 этапов:

Вместе с этим разрабатывалась и ключевые возможности:

Не все ошибки можно исправить возвращением к предыдущей версии. Иногда их нужно принять и сделать выводы, чтобы не совершать в дальнейшем. Так получилось с OMS.

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

Не все обновления оправдывают затраченные ресурсы. Стоит сосредоточиться на задачах с понятным бизнес-эффектом и минимизировать работу в зонах с малым влиянием на измеримые показатели.

Летом параллельно существовало две системы: Magento оставалась основной, а на Ensi Platform запустилась доставка свежих продуктов. К осени Magento была отключена — состоялся полный переход на Ensi. С тех пор поставлена цель развиваться дальше: сформирован долгосрочный бэклог.

Из-за срочности у «Ашана» и Ensi не было времени на формирование процессов разработки. Потрачено много ресурсов и вынужденно накоплен технический, управленческий и архитектурный долг. Несмотря на это, год выдался результативный: поставленные задачи решены в кратчайшее время. Бизнес полноценно запустил направление онлайн-продаж и обеспечил стабильный фундамент для дальнейшего роста.

Когда еком запустился, появилось время оптимизировать процесс разработки. Следующий этап — интеграция системы лояльности Comarch — уже был тщательно распланирован и разбит на спринты.

Запуск программы лояльности стал грандиозным событием. Решена сложная технологическая задача: консолидировать данные клиентов «Ашана», собранные за долгие годы работы в офлайне, и новых покупателей интернет-магазина.

Вместе с этим в Ensi Platform добавлена детальная информация обо всех купленных товарах, в том числе в гипермаркетах. Для этой цели PIM дообогатился всем ассортиментом Ашана: SKU превысило отметку в 600 тысяч.

В архитектуре вновь возникли сложности: интеграция напрямую связала сервисы Ensi Platform и Comarch, и образовалась новая точка отказа. С развитием системы лояльности риск становился все серьезнее, ведь чем сложнее становится решение, тем выше вероятность ошибок. При этом отключение Comarch могло спровоцировать падение Ensi Platform и привести к полной остановке продаж. Чтобы этого не происходило, реализовали сценарий graceful dagradation: «К сожалению, баллы использовать нельзя — они начислятся позже». Клиентский опыт снижается, но главное, что покупка возможна. И это хороший пример устойчивости IT к внешним явлениям.

Развитие ритейлеров непременно связано с увеличением числа сервисов и усложнения связей между ними. Вместе с этим растут и риски отказа этих систем. При достижении определенного уровня зрелости становится недостаточно думать только о новой функциональности — на первый план выходит стабильность платформы в целом. И дело не в конкретных продуктах или командах разработки, а в зависимостях между компонентами, которые сказываются на всем контуре.

В первую очередь необходимо обеспечить устойчивость критического пути, то есть позволить приобретать товары даже в случаях недоступности отдельных компонентов. Архитектура должна содержать конкретные инструменты, чтобы изолировать сервисы от сторонних угроз.

Опыт работы с архитектурными зависимостями пригодился и при интеграции с системой управления сборкой и доставкой от «Сбермаркета». Обработка заказов постепенно переводилась в сервис «Шоппер», товары становились доступны в приложении «Сбермаркета» — появилась задача синхронизировать две системы.

Первоначальная схема синхронизации

Итоговая схема синхронизации

Следующая глобальная цель: качественное повышение CX через полное визуальное обновление интернет-магазина и мобильного приложения «Ашан».

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

Рассматривали три возможные стратегии:

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

Три главных достижения при обновлении:

В проектах такого уровня невозможно обойтись без грамотного сочетания разработчиков высшего класса и уровней пониже. Бывают проекты, которые можно сделать middle и junior специалистами, но им не хватает компетенций для решения масштабных проблем. Встречались ситуации, когда у клиента много денег, а команда состоит исключительно из senior — это тоже неэффективно, потому что часть из них будет занята рядовыми задачами.

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

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

IT-ландшафт «Ашана» и большинства других компаний состоит не только из микросервисов. Отдельные зоны — возможно, но полный отказ от legacy, шин данных и прочих монолитов может занимать годы и стоить сотни миллионов. Уже спроектированные и работающие решения были созданы с учетом другой структуры бизнес-подразделений, а также бюджета, сроков, технических ограничений, инфраструктуры или информационной безопасности.

Все чаще мы встречаемся с негодованием бизнеса из-за бутылочного горлышка в виде IT-департамента. Компании выбирают продуктовый подход с кросс-функциональными командами для доставки большего количества обновлений и снижения Time-to-Market. В реальности же после внедрения продуктового подхода и изменения всех бизнес процессов оказывается, что IT не меняется быстро:

Бизнес сталкивается с проблемами:

Изолировать систему под меняющуюся структуру гибридных команд не получится — это приведет к высоким OPEX затратам и парадоксу Ахиллеса и черепахи. Поэтому невозможно в полной мере исключить взаимодействие нескольких команд с одним набором сервисов. Организационная структура бизнеса всегда будет превалировать над создаваемой системой, а структуры системы — отставать от бизнеса.

Поэтому нужен кросс-командный подход для контроля вносимых изменений в IT. При этом важно оценивать не только технологические аспекты, но и создание бизнес-ценности. Сейчас в «Ашане» формируется платформенная команда, состоящая из техлидов и product owner’ов из кросс-функциональных команд.

К задачам такой команды можно отнести:

За 4 года проекта запущено 20 сервисов Ensi и подключены десятки внешних систем. Каждое из решений имеет свои особенности, может сбоить или технологически не отвечать «модным» трендам. Но что более важно, все вместе они образуют единую платформу, которая приносит прибыль и бизнесу, и нашей команде.