В «Леруа Мерлен» на выбор техстека влияют инженеры компании

С подробностями рассказываем, как внедряем новые технологии в разработку.

С 2018 года «Леруа Мерлен» придерживается модели платформы и экосистемы. Это связано с большим количеством бизнес-направлений: работа с B2C- и ПРО-клиентами, услуги, проектные продажи, онлайн/офлайн, поставщики... Всё это требует технических решений и десятков сервисов. И чем больше появлялось продуктов и новых запросов у клиентов, партнёров и самой компании, тем больше технологий она использовала.

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

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

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

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

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

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

Тогда в 2020 году технологический комитет «Леруа Мерлен» — группа из технических архитекторов и техлидеров доменов — решил составить вместо радара таблицу технологий. В ней есть три параметра:

• Тип — это язык, инструмент или фреймворк.

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

Команда из десяти членов техкомитета на протяжении недели ежедневно созванивалась, чтобы обсудить все инструменты, которые используются в продуктах: клеила стикеры на виртуальной доске Miro, спорила. А ещё объясняла свои приоритеты в заметках для рядовых сотрудников. Чтобы они не думали, что теперь работают преимущественно с Java, потому что на собрании было слишком много «ярых джавистов». Или что Python исключили из той или иной сферы, потому что начальник Василий его не любит. Цель обсуждения — доказать, что приоритетные технологии приносят компании бизнес-пользу.

С тех пор использовать инструменты, которые не входят в стек, в компании не рекомендовано. Но это ещё не значит, что стек нельзя менять.

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

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

«Исследуем» или Research. Если 40% членов техкомитета соглашаются рассмотреть технологию, команда на старте прописывает часть вводных эксперимента:

• что хочет проверить (например, качество библиотек на Node.js);

• что вынуждает её это делать (библиотеки на текущих платформах работают плохо);
• что должно измениться согласно гипотезе (компании будет проще хранить и выбирать объекты в библиотеках);
• кто заинтересован (скажем, бэкенд-разработчики и разработчики с Node.js);
• сколько времени нужно и какие метрики будут измеряться (допустим, скорость работы и простота использования).

А затем отчитывается по результатам: удалось ли выполнить задачи и почему (например, не удалось, потому что непонятно, как работают внутренние механизмы инструмента). Но если результаты положительные и 50% техкомитета удовлетворены, технология переходит на следующий этап.

«Тестируем» или Trial. Теперь команда может проверить одобренную технологию в ограниченном формате на проде. Если она не оправдает себя, её отложат. Если принесёт ощутимую выгоду и будет одобрена 80% техкомитета, сможет перейти в следующую категорию.

«Предпочитаем» или Best choice. Сюда попадают технологии, которые техкомитет рекомендует использовать. Это ориентир для тех, кто берётся за новый продукт, и для тех, кто только пришёл в компанию.

«Отложили» или Hold. Это либо технологии, которые не принесли никаких положительных изменений после пребывания в первых двух категориях, либо решения компании, которые уже устарели.

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

Чтобы обсудить изменения и решить судьбу технологии, техкомитет встречается раз в две недели. Но фактические изменения вносят раз в квартал — чтобы за событиями было проще следить.

Стратегия не только привела список технологий в порядок, но и сделала процессы прозрачнее, упростила взаимодействие внутри продуктовых коллективов. И доказала: каждый голос в компании имеет значение.

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

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

Именно благодаря инициативам «снизу вверх» у «Леруа Мерлен» одной из первых в России появился набор инструментов Kotlin Multiplatform Mobile, или KMM. До 2018 года команды, ответственные за приложения для iOS и Android, работали в отрыве друг от друга — сервисы делались асинхронно, и каждое отличалось огромным легаси, что не давало вносить быстрые изменения и делиться знаниями друг с другом. KMM как кросс-платформенное средство помогло эффективнее переписать код для обоих приложений, поскольку позволяло командам работать над общими кодовыми базами и обмениваться опытом. И заодно экономило 50–70 часов разработки в месяц.

Будущий сотрудник знает, с чем сможет работать. Конечно, в требованиях к конкретной вакансии кандидат заранее видит, в каких языках и фреймворках должен разбираться.

Так ещё на старте понятно, что можно поработать с Kotlin и Typescript, даже если ты идёшь писать на Django, Java и Go. А ещё можно оценить весь технологический стек, убедиться, что в работе нет устаревших технологий, а легаси минимальное.

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

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

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

Если команда разработки хочет выбрать подходящую технологию для нового продукта, она обращается к таблице технологий, где всегда может найти подходящее решение. Например, выбирая решение для BFF, команда увидит, что рекомендовано использовать Platformeco, и всегда может спросить отзыв команд, которые уже используют платформу в других продуктах.

Рядовой инженер может влиять на стек всей компании. Даже если инженер начал работать две недели назад, он может сделать это.

В «Леруа Мерлен» есть внутренние профессиональные сообщества (communities) и особые группы по интересам (special interest groups, или SIGs), например по фронтенд-разработке. В сообщество могут вступить все желающие, кому интересен, например, фронтенд (неважно, дизайнер ты, аналитик или разраб). В SIG — только фронтенд-разработчики, но зато независимо от домена. SIG возглавляют лидеры компетенций.

• Что получает сотрудник: возможность влиять на техстек, расширение зоны влияния в компании, обмен опытом с коллегами и контакт с новыми технологиями в рамках процесса RnD.
• Что получает компания: управление технологическим стеком, построенное на центрах компетенций и профильных сообществах, лояльность и вовлечённость инженеров.
  

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