Как гибкая архитектура стала новой стратегией «Леруа Мерлен», а её айтишники получили свободу действий

И главное — как это сказывается на клиентах.

До 2014 года «Леруа Мерлен» развивалась как любой другой традиционный ритейлер: ежегодно расширяла сеть физических магазинов, медленно развивала сайт — данные по ассортименту обновлялись редко и часто не соответствовали действительности. ИТ-ландшафт состоял из монолитных систем, одна часть которых поставлялась вендорами, а другая была наследием общекорпоративных решений, принятых на уровне группы ADEO, в которую входит компания.

«Когда ты отдаёшь в руки вендора управление жизненно важными системами, ты отдаёшь в его руки стратегию. Становится невозможно что-то менять, ведь всё зависит от другой компании и её готовности менять свой монолит», — говорит Арно Фётри, архитектор предприятия и лидер трансформации «Леруа Мерлен».

Примерно в том же 2014 году в России стал укрепляться тренд под условным названием ROPO («research online, purchase offline»): клиенты стали искать нужные товары в интернете, изучать их и только потом приходить за покупками в офлайн-магазины. Сторонние сервисы доставки также начали активно развиваться, и то, что раньше было преимуществом «Леруа Мерлен» (широкая представленность офлайн-магазинов с широким ассортиментом в разных городах), перестало быть таковым.

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

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

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

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

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

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

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

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

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

В итоге мы сформировали принципы новой — составной — архитектуры компании:

Следуя принципу модульности, мы внедрили систему доменов: каждый состоит из операционной и продуктовой команд. «Операционные команды придумывают для клиента и партнёра обёртку, а продуктовые — разрабатывают эту самую обёртку и делают всё, чтобы она выполняла свои задачи», — поясняет Дмитрий Мышков, продуктовый лидер домена «Услуги». При этом у команд в домене единые цели и KPI, но каждая обладает своими бизнес-компетенциями (business capabilities). Инициатором любого изменения может быть и продукт: ведь если у команд единые цели, улучшения предлагают и те, и другие.

Домены выполняют свои функции самостоятельно или объединяются в рамках решения трансверсальных задач — так реализуется принцип связности. Профиль домена определяет, как в нём подходят к управлению задачами — как их распределяют, в каком порядке они взаимодействуют друг с другом, какие инструменты для их решения выбирают.

Такая архитектура позволяет «Леруа Мерлен» безболезненно отказываться от неэффективных решений и быстро создавать новые автономные модули, если того требует ситуация.

«Мы знали, что от составной архитектуры (composable architecture) будут одни плюсы, но что их столько — даже не ожидали», — говорит Арно Фётри.

Почему? Во-первых, айтишники, как оказалось, зачастую гораздо лучше операционных отделов понимают, как оптимизировать процессы.

Во-вторых, инженеры получили карт-бланш и ресурсы для создания собственных продуктов. Теперь «Леруа Мерлен» в гораздо меньшей степени зависит от вендоров. И даже в случае со сложными ERP-системами может реорганизовать их функциональность через микросервисы.

В-третьих, продукты «Леруа Мерлен» теперь настолько качественно проработаны, что их можно поставлять внешним пользователям. Пример: Platformeco — лоу-код-платформа для создания и управления API и микросервисами. Она создавалась для внутреннего пользования в командах, а теперь успешно внедряется в крупных компаниях из совершенно разных отраслей.

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

В «Леруа Мерлен» этим занимается домен «Услуги». У него много кросс-функциональных задач, причём на разных этапах клиентского пути. Именно он ищет исполнителей, помогает клиенту заказать услугу, сопутствующую основной покупке (например, установить приобретённую дверь), и уведомляет его о визите мастера. На этот опыт также влияет та самая составная архитектура. Например, дома клиент добавляет нужные ему товары и услуги в корзину, а в магазине открывает её — и строит проект с той же точки.

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

В компании два типа продуктовых команд. Первые работают над базовыми (core) продуктами — например, для приёма заказа, доставки на склад, последующего хранения и сборки. Всё это разные функции и, следовательно, разные API. Но на бэкенде эти API абсолютно идентичны как для магазинов, так и для складов и дарксторов. А вот интерфейс для них нужен разный, и за эту фронтенд-часть отвечают уже другие продуктовые команды: они «визуализируют» пользовательский опыт. Так что за базовые продукты будет отвечать команда, состоящая прежде всего из продакт-менеджеров, технических аналитиков, архитекторов решений, дата-инженеров и разработчиков. А за пользовательский опыт — UX- и UI-дизайнеры и, может, один-два разработчика.

Иногда «Услуги» оказываются в управлении другого домена — это иллюстрация принципа связности, о котором мы говорили выше. Например, за заказ как за бизнес-компетенцию отвечает домен «Омниканальные продажи», а «Услуги» здесь представляют собой его составную часть и дают системе задание на исполнение услуги (это один из последних шагов в цепочке исполнения заказа).

Но чаще он, наоборот, выступает главным — управляющим. «Мы занимаемся полным жизненным циклом услуг и отвечаем за листинг и формирование ассортимента. Так что именно к нам обращаются остальные бизнес-департаменты: если нужно включить услугу в каталог или рассчитать её стоимость. Мы — поставщик мастер-данных и функций. Остальные — наши потребители», — объясняет Дмитрий Мышков, продуктовый лидер домена «Услуги».

Все домены «Леруа Мерлен» организованы по трёхслойной архитектуре. Бэкенд-разработчики работают с объектно-ориентированным языком Java, а теперь ещё с Kotlin. Фронтед-программисты — с JavaScript-библиотекой React. А инженеры, которые создают «прослойку» между клиентской стороной и программно-аппаратной частью сервиса) — с программной платформой Node.js.

Выбор инструментов объясняется просто. Во-первых, так сложилось исторически, и запросам они по-прежнему отвечают. Во-вторых, когда компания наращивала ИТ-мощности, она ориентировалась на те языки и движки, с которыми работало большинство разработчиков, — те же Java и React. Java — универсальный язык и поддерживает самые разные типы систем: базы данных, бизнес-процессы, микрофункции. А React на конец 2010-х казался перспективным трендом. «Многие тогда вкладывались в разработку на платформе Angular, но мы поставили на React и не прогадали. Сейчас специалистов с этими навыками больше», — говорит Дмитрий Мышков.

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

Составная архитектура, как мы говорили выше, следует принципу рациональности. Вот его иллюстрация: если потребуется самостоятельно изменить структуру данных или запустить новую функцию, достаточно запросить доступ к коду продукта. Эта концепция ещё называется Inner Source — открытый код, доступный всем внутренним разработчикам.

Чтобы принимать правильные архитектурные решения, в компании есть технический директор, его работу «поддерживают» технические лидеры каждого домена и технологический стек. Это инструмент, который показывает, какие технологии компания использует в проектах сейчас, к каким присматривается и какие решения морально устарели. В «Леруа Мерлен», например, долгое время работали с принципом сервисной шины — когда системы обмениваются сообщениями через единую точку. Однако он давно утратил ценность, и вскоре компания окончательно перейдёт на архитектурный стиль REST.

Технологии вне стека использовать нельзя, но любые технологии можно выдвинуть на рассмотрение. Домен «Услуги», например, видит интерес к языку программирования TypeScript, а также фреймворку Nest.js. Все идеи будут в отдельном порядке рассматривать на архитектурном комитете и технический директор, и техлиды в рамках каждой платформы и каждого отдельного домена.

Свобода действий продуктовых команд приносит компании прямую бизнес-выгоду. Операционные команды нередко просят разработчиков раскрутить новую воронку и сделать так, чтобы определённая товарная группа продавалась лучше именно благодаря услуге. Например, чтобы клиенты чаще покупали двери у нас, продакты предложили добавить бесплатный замер, а следом показать клиенту услугу по установке. Клиента располагала к магазину бесплатная услуга, так что он в итоге совершал заказ чаще, чем те, кто бесплатным замером не пользовался.

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

Преобразующим нововведением стал запуск биллинговой системы — автоматизации расчётов. Раньше компания работала с платёжными системами вендора, и партнёр получал выписку по заказам и прибыли только раз в месяц. Но число партнёров у «Леруа Мерлен» росло, особенно за счёт услуг, — так что продакты построили для них «умный» движок. Он сам рассчитывает комиссию, определяет способ платежа и присылает выплату сразу после оплаты заказа.

Без вызовов, впрочем, тоже не обходится. В трансверсальных проектах «заказчик» может быть не определён. А когда над проектом работает сразу несколько команд разных «профилей», синхронизироваться получается не всегда. «Как-то раз мы занимались разработкой функций для трансверсального проекта. Один из наших продуктов сопровождал только часть UJM. Когда мы подошли к этапу тестирования, то поняли, что не можем пройти изолированный UAT без полноценного end-to-end — ведь мы не могли симулировать другие продукты и могли сломать путь пользователя. В результате масштаб end-to-end-теста, который учитывал бы путь пользователя по всем продуктам цепочки, оказался гораздо больше, чем мы предполагали. Полноценный тест со всеми командами занял ещё два спринта», — вспоминает Дмитрий Мышков.

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