Зачем нам в «Леруа Мерлен» нужен собственный российский отдел разработки на 200 человек

    Привет! Я Валерий Лаптев, руководитель разработки LM в России. За два года мне нужно было поднять огромный отдел, и это был довольно интересный опыт.

    Дело в том, что «Леруа Мерлен» есть во многих странах. Головная компания — во Франции, называется ADEO. Там пишут код под Францию, Италию, Испанию и Россию. Бизнес-модели у нас разные: если на российском рынке мы держим минимальные цены (ниже всех конкурентов в мониторинге), то в Европе всё иначе. На самом деле отличий море — начиная от особенностей локали и заканчивая другим законодательством. Есть особенности инфраструктуры России (те же очень большие задержки до Хабаровска) и другой жизненный цикл оформления заказа. Всё это порождает вот такой адский код, состоящий из огромных блоков IF:



    Два года назад у нас было 60 магазинов и много-много хотелок по фичам. Накатывались они примерно за полгода и не всегда правильно. Последней каплей после кучи отклонённых по низкому приоритету фич была просьба завести в заказ поле-строку, чтобы мы его уже потом сами парсили. Это нужно было для особенностей доставки в России, поскольку страна больше других стран присутствия LM. Нам отказали и в этом, точнее, сказали, что будет где-то через семь-восемь месяцев.

    Полугодовой цикл неспешной головной компании нам не подходил. Естественно, мы предложили написать свой код, отдать на ревью и подождать внедрения… Правда, из этого ничего хорошего не вышло.

    Почему фичи реализовывались медленно?


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

    Вторая особенность в том, что при накатывании любой фичи в мастер-ветку (вот в этот легаси-код на IF-IF-IF) нужно проверять, как она себя поведёт в других странах. Позволю себе цитату 441869 с Баша:
    Программист: Ну представь, что ты писатель и поддерживаешь проект «Война и мир». У тебя ТЗ — написать главу как Наташа Ростова гуляла под дождём по парку. Ты пишешь — «шёл дождь», сохраняешь, вылетает сообщение об ошибке: «Наташа Ростова умерла, продолжение невозможно». Почему умерла? Начинаешь разбираться. Выясняется, что у Пьера Безухова скользкие туфли, он упал, его пистолет ударился о землю и выстрелил в столб, а пуля от столба отрикошетила в Наташу. Что делать? Зарядить пистолет холостыми? Поменять туфли? Решили убрать столб. Получаем сообщение: «Поручик Ржевский умер». Выясняется, что он в следующей главе облокачивается о столб, которого уже нет...

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

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

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

    Решение проблемы


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

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

    Французы в ADEO хотели релизный цикл за накатку и установку новых версий через себя. Приняли наше предложение про одну ветку для опытов.

    Дали доступы, стали брать код на ревью. Оказалось, это всё равно медленно. Роллауты по нескольку месяцев — это не дело. Ну выиграли несколько недель, но всё равно процесс не подходил.

    Потом шесть месяцев не выходила важная нам фича в контентной части (управление данными о товаре, которые видит клиент). Мы сидели шесть месяцев без релиза. То у них фича не шла, то тесты не прошли, то реализовали не совсем то, что нам нужно. В итоге долго сидели на ключевой системе без обновлений. Там были NodeJS + PostgreSQL + Couchbase + Elasticsearch + Angular на фронте. В коде из-за ряда археологических слоёв встретили вещи вроде неверного использования SQL-базы и нереляционной базы. В одном из мест брался огромный кусок мастер-данных, вставлялся в одно поле SQL-базы, а потом в NoSQL-базе разбивался на сущности. На одну страницу сайта с показом товара приходились десятки и сотни таких запросов. При дальнейшем чтении этого легаси волосы на разных частях тела начали шевелиться. Мы поняли, с какими особенностями наслоений легаси сталкивается головной отдел.

    Собственная разработка


    Первая идея была в том, чтобы делать фичи вместе. На месте, то есть во Франции. Поехали вчетвером во Францию и стали сидеть рядом с коллегами, чтобы разобраться во всём вместе и сделать как нужно нам.

    Не работало. Всё равно всё было очень медленно.

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

    То есть мы планировали переписать целые блоки логики в виде своего кода. А для этого стали переключать часть сервисов на то, что могло бы быть сделано у нас. Начали набирать разработчиков. Тогда мы полностью следовали стеку головной компании — Java, Spring и всё рядом, вместо Couchbase была Монго (это похожая NoSQL-база).

    По мере развития проекта поняли, что нужно делать много чего по-своему (потому что так быстрее и проще, чтобы не поддерживать ненужное нам легаси, в частности), и стали расширяться уже и на другие технологии. Тогда были Java 7, Wildfly (бывший JBoss) и SVN. Мы спросили, почему они не переходят на Java 8, GIT и Tomcat. Оказалось, они были бы не против, но через пару лет. А пока, родные, пишите на старом стеке. Так мы слово за слово и решили отделяться окончательно. Бизнес разобрался, в чём вопрос, какие плюсы и минусы есть, и всецело поддержал.

    Почти сразу выкинули процентов 30 кода, написали вокруг много своих микросервисов. Из того, что не трогали, — это почти всё ядро транзакций бизнес-процессов по деньгам.

    Естественно, первое, о чём мы подумали, — это про то, как разграничить области разработки. Про это я бы ещё рассказал отдельно, но в общих чертах схема вот такая:



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

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

    Фича-команда — это небольшая группа людей (обычно аналитик, тестировщик, разработчик бека и разработчик фронта, опс). Аналитик обычно играет роль владельца продукта либо на это место приходит человек из бизнеса. У владельца есть беклог, приоритет, задачи. Он их диктует разработке. Разработчик выбирает вариант реализации сам, обсуждая в команде, что и как будет сделано. У нас нет тимлидов для оценки задачи, кодревью и принятия решения. Все делают всё. Обычно более опытные в команде дают мнения, на которые многие готовы положиться. Но любой может принять решение. Конечно, бывают конфликты, когда два разработчика не могут договориться про реализацию фичи. Если конфликт перешёл на личности — нужна эскалация до руководителя. Но большая часть — это выбор решения по реализации. Тогда все стоят и рисуют около доски пока не найдут устраивающий всех вариант. Обычно получается быстро, но были случаи, когда и целый день спорили. Когда спор заходит в тупик, часто зовут арбитра — человека из другой команды, мнению которого все доверяют. Ему объясняют суть проблемы, он решает. В этом процессе спора в теории может участвовать даже джун или практикант, но я знаю всего пару таких случаев — обычно у джунов есть наставник, которого они слушают.

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

    Изначально мы не хотели делать отдельных тестировщиков: был тренд, что разработчик должен либо идти по TDD-методологии, либо сам тестировать свой код до конца. На деле это оказалось не очень эффективно. Поначалу всё шло хорошо: написал — отвечаешь. Тесты нужны тебе для того, чтобы твоё приложение работало правильно. Но потом, чем больше становилось задач и приложений, тем было сложнее. Какие-то приложения отмирали, какие-то уходили на прод и не менялись месяцами. Стало тяжело писать тесты, поддерживать их и так далее. Аналитики в командах менялись. Относительно недавно договорились, что были неправы: тестировщики нужны. Но разработчики не перестают писать тесты и — иногда — делать TDD. Мы для себя осознали, что тесты, которые проверяют функционал (приложение работает правильно), и тесты, которые проверяют, что приложение работает в проблемных ситуациях, — это должны делать разные люди. И для второго нужны именно тестировщики, поскольку они покрывают возможные странные случаи не только юнит-тестами.

    Сейчас чисто разработчиков 60 человек — бек, фронт, фуллстеки. Ещё есть аналитики, тестировщики и поддержка. И плюс дополнительно ещё семь девопсов. Но всё равно 200 планируемых людей из заголовка не набирается, поэтому мы сейчас ищем новых людей, потому что поле работы огромное. Вакансии есть на Моём круге, если что. То есть из разработки у нас сейчас 74 примерно из 200.

    InnerSource


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

    В рамках группы ADEO всех подразделений по странам весь код лежит в облачном Гитхабе. Проект оформляется по единым правилам оформления. Ограничений по стилю, технологиям и инструментам нет. Когда у тебя открытый код и понятные правила оформления — любой разработчик на стеке может контрибьютить. Чтобы законтрибьютить тебе в код, нужно прочитать доку, клонировать репозиторий, внести правку, отправить пулл-реквест.

    В настоящее время Бразилия, Россия и Франция очень активно используют эту общую базу.

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

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

    Ещё немного нюансов


    Когда начали, не было ничего вообще. Параллельно с разработчиками набирали девопсов. Сейчас девопс-услуги либо предоставляются как сервис (тем, кому нужно), либо в продуктовой команде есть собственный опс, который уже определяет, что и как.

    Сборка делается в Jenkins, код прогоняется в Сонаре (точнее, уже SonarQube). Не прошёл Сонар — нет релиза. Тестировщики пишут автотесты, владельцы кода — функциональные тесты. База данных даётся как сервис инфраструктурщиками. Полноценное нагрузочное тестирование делается в редких случаях, поскольку структуры тестовой базы и основной отличаются: на препроде у нас хаотичные данные, а не обезличенные реальные (это один из шагов в будущем), поэтому накатывать надо нежно и не всё сразу.

    Скоро должны поехать в Kubernetes (а часть новых продуктов вроде маркетплейса уже изначально там), как только разберёмся с планом перехода и договоримся по всем мелочам в инфраструктуре.

    Мы с коллегами продолжим рассказывать про то, как какая часть работы устроена, потому что почти везде можно углубляться бесконечно. Ну а вы можете следить за нашим реалити-шоу (потому что всё только строится и быстро меняется) и делать ставки, облажаемся мы или нет.
    Леруа Мерлен
    220,56
    Компания
    Поделиться публикацией

    Комментарии 48

      +14
      Всё это конечно круто! Но сделайте уже, чтоб не приходилось при каждом заходе на сайт указывать город и любимый магазин. Доступ к геолокации есть, даже в куках город правильный есть, даже адрес доставки в личном кабинете есть, но каждый раз приходится выбирать город и магазин.
        0
        Но сделайте уже, чтоб не приходилось при каждом заходе на сайт указывать город и любимый магазин

        А вдруг кто-то умрет…
          +3

          Да пусть хоть поиск нормальный сделают. Вообще же ничего не найти.

            0
            А если и найдёшь — по приезду в магазин товара нет в наличии…
            –3
            Задача не такая простая, как может показаться на первый взгляд, возможно, даже напишем приключенческий пост, как мы это решаем. Нельзя просто поставить редирект с основного домена на домен региона, нужно учитывать много факторов. Был основной вариант смотреть на куку и редиректить только в этом случае, скорее всего так и поступим в ближайших релизах.

            В любом случае буду рад, если поделитесь своей экспертизой в этом вопросе.
              +2
              включил анонимайзер — сбросили город. Нашел товар на сайте леруа через гугл — сбросил город. Да что ж такое то!
                0
                Вариант с привязкой к cookies, конечно, город в анонимайзере не сохранит, но решит проблему при переходе из поисковиков. Попрошу команду, занимающейся этой фичей, поскорее её зарелизить.
                +14
                Если у вас в отделе разработки 200 человек и вы не можете починить геолокацию, ребят, может стоит серьезно задуматься о качестве этих кадров и чем они заняты?
                  0
                  Сейчас нет 200 разрабов, это наша цель. Как раз, чтоб была возможность исправить все, что сейчас работает не так, как мы хотим. Ссылка на вакансию для тех, кто хочет помочь.
                    +3

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

                    +5

                    Экспертиза — это услуга. А поделиться можно опытом.

                      0
                      Зато, звучит то как…
                        0
                        это устоявшееся выражение в it.
                        0
                        экспертиза означает еще и опыт в определенной доменной области. поэтому человека, владеющего таким опытом, называют экспертом. а не потому, что он оказывает услугу.
                          0
                          Это распространённое заблуждение. Последнее время так часто говорят, потому что как и заметил r00tGER просто звучит круто/пафосно. Режет слух.
                        0
                        И убрали бы уже редирект на основную при нажатии на кнопку «каталог», интуитивно ожидаешь раскрытия каталога, а он уже итак работает по ховеру.
                      +3
                      Впечатление от всех этих технологий разбивается об простые факты. К примеру на то, что служба доставки ЛМ(СПб) сама решает, когда клиенту будет доставлен заказанный товар. И нет возможности выбрать даже первую, либо вторую половину дня. Год назад так было, недавно заказывал — всё тоже самое.
                        +4
                        Когда — это половина вопроса. У нас больше проблема, что они сами решают сколько будет стоить доставка. Написано на стенде, доставка до 1500кг в пределах 6-ти км стоит $10. Окей. Подхожу к ним, а они мне: будет стоить $30. Спрашиваю — почему, вес чуть больше тонны, расстояние 1км? Отвечают — потому что. Вот как с ними работать? Дистрибьюторы в магазине сами ищут стороннюю доставку, так как «встроенная» — фуфло. Зато 200 чел разработчиков.
                          0
                          т.е. у них дезинформация покупателей насчет цен за доставку?
                          кстати о ценах — проверяйте чеки когда делаете покупки, как то покупал скобы металлические маленькие — они мне на кассе насчитали больше 1000 руб за 12 штук, в то время как ценник им было примерно 100 руб, извинились и пересчитали. В другой раз покупал битум в банках — на стеллаже цена была 200 руб за банку а на кассе за 1000 руб, тоже — просто не стал брать.
                          Когда покупаешь немного всего то нестыковки заметны в итоговой сумме, а вот когда берешь сразу много — можно и не заметить такое в итоговой сумме. Но это к любому магазину относится.
                            –1
                            Неправда Ваша, вот например французский же ашан за все 6 лет общения ни разу не позволил себе такого — в чеке всегда то что на ценниках (жана перепроверяет опка идём к машине)
                          0
                          Так они разработкой сейчас занимаются. На то, чтобы поставить на ноги логистику, времени уже не остаётся.
                          +1
                          Заметил, что сейчас СПИСОК ПОКУПОК и др. списки на каждом устройстве свои. Раньше замечал, что в браузере и мобильном приложении различные списки(дома на компе добавил в список покупок, пришел в магаз, зашел в приложение, а там пусто, а через браузер все есть). Это нормально?
                            0
                            Статус такой — задача знакома, стоит сейчас в анализе. Планируем решить в августе/сентябре.
                            +1
                            Какая цель темы? Если цель — рассказать ИТ сообществу по специфике Вашей компании, то несколько уточняющих вопросов.
                            1. «В общем, когда у нас внедряется что-то для российских касс, где-то в Бразилии у кого-то может отрикошетить. „
                            — это означает, что у вас единая база? Единая конфигурация фронта для всех стран ?? Тогда конечно неизбежны проблемы, которых могло бы не быть при локализации по странам.
                            2. Как распределены программисты по странам/типам баз? Фронт/бэк?
                            3. Если основной упор на учет и логистику товаров (что логично для товароторгующей компании), то используются ли приложения специализированные для учета (SAP, 1C и тп)? А то впечатление, что используете языки общего назначения (Джава) там, где производительнее использовать учетные приложения.
                              +1
                              1. «В общем, когда у нас внедряется что-то для российских касс, где-то в Бразилии у кого-то может отрикошетить.
                              — это означает, что у вас единая база? Единая конфигурация фронта для всех стран ?? Тогда конечно неизбежны проблемы, которых могло бы не быть при локализации по странам.


                              «Автоматизация бардака приводит к автоматизированному бардаку»

                                0
                                1. Раньше было именно так. Сейчас — нет. Сейчас очень много ПО мы используем своего.
                                2. Пока разработчики в каждом бизнес-юните по большей части пишут для себя. Кроме разработчиков ADEO, которые как раз пишут для всех БЮ. Но мы идём (на самом деле, уже бежим вприпрыжку) в сторону InnerSource, что позволит без напрягов шарить код между всеми разработчиками группы.
                                3. Конечно, для ERP и бухгалтерии используются подобные приложения. Но ими занимаются другие отделы и/или (реже) подрядчики. И мы пока не уверены, что хотим (способны?) забрать разработку этих «монстров» к себе в Фабрику разработки.
                                0
                                В статье в абзаце про фича-команды расписано про решение конфликтов реализации по этапам: личный баттл, [привлечение начальства,] совместное рисование, привлечение арбитра. Не пробовали ввести позицию Архитектора? Привлекаемые арбитры неявно и исполняют роль архитектора, но если в каждом случае это разные специалисты, то к этапу зрелости продукта вы получите неоднородную кодовую базу и кучу уникальных нетиражированных решений. Архитектор нужен для распространения единого видения, подходов, стиля и опыта между всеми командами.
                                  0
                                  Да, мы привлекаем и архитекторов. Более того, они всегда есть в команде. Но они отвечают больше за энтерпрайз архитектуру в целом, как раз те самые подходы, стили и видение. А техническая архитектура в ответственности команды разработки. И т.к. команда полностью отвечает за свое приложение (you build it, you run it), она и несёт ответственность за это решение даже с привлечением «арбитра». Т.е. потом сказать, дескать, «Это не я предложил, это он, все вопросы к нему» — не получится.
                                    0
                                    Но они отвечают больше за энтерпрайз архитектуру в целом

                                    Возможно дело как раз в этом: в командах участвует enterprise-архитектор, а должен solution architect, который чуть ближе к внутренностям.
                                  +1
                                  Зачем на 200 разработчиков в Леруа Мерлен?


                                  Чтобы потом вылить в production баг с header'ом. (Наведите на пункт каталог, потом наведите мышку на один из выпадающих пунктов, и скрольте вниз)
                                    +1
                                    Когда фича-команда сделает микросервис и распадётся (люди соберутся в другие команды), то кто остаётся ответственным за него? Не будет ли это приводить к заброшенкам, про которые через некоторое время никто не знает?
                                      0
                                      Такая проблема, конечно, существует. И существует везде, вне зависимости от структуры команд и организации. Приложения, которые долго не меняются, оказываются «забыты» командой. Но при этом оно не является брошенным. Любое приложение относится к одной из программ (горизонтальные стримы на картинке со структурой нашей дирекции ИТ). Таким образом всегда есть кто-то, кто отвечает за работоспособность любого приложения. К тому же у нас довольна маленькая текучка, и найти разработчика, который это разрабатывал, как правило, удаётся.
                                      0

                                      А когда в ЛК будут заказы из ПУЗ2?

                                        0
                                        ПУЗ2 сейчас проходит пилот только в одном магазине. Задача такая есть. Время реализации —
                                        1-2 месяца.
                                        0
                                        Интересно конечно, а как ситуация в других странах ЕАС где присутствует ЛМ? Они вашими наработками пользуются?
                                          0
                                          Сейчас, в основном, разработчики каждого бизнес-юнита пишут для себя. Но у нас есть амбиции делать это для всей группы ADEO. И именно поэтому мы совместно с Францией и Бразилией запустили переход к InnerSource, который и позволит нам делать приложения, которые можно будет использовать (адаптировать, дописывать свой код) в других странах. Но, конечно, InnerSource — это всего лишь один из шагов. Сейчас мы очень много внимания уделяем этому вопросу.
                                          0
                                          Всё это порождает вот такой адский код, состоящий из огромных блоков IF:
                                          вы серьезно? термины domain specific language, rules engine, workflow engine / BPMS — никаких ассоциаций не навевают?
                                          У вас система «класса ERP» и, такое, ощущение, что вся бизнес-логика в коде и минимум конфигураций.
                                          Конечно нужно 200 разработчиков :), зато «мы в тренде и у нас kubernetes».
                                            0
                                            А к ПО непосредственно на кассах вы причастны?
                                            Там до сих пор нельзя вводить одинаковый товар, просто пропикивая его.
                                            Девочкам (и мальчикам конечно) кассирам приходится сперва разбирать всё по штучкам, смотреть сколько где-чего, пикать одну и вводить вручную количество.

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

                                              Интересно перекликается со статьей недельной давности от наемного директора завода.
                                                0
                                                решите еще вопрос с привязкой сервисной карты к аккаунту. Уже несколько раз пытался привязаться, приходит письмо со ссылкой для подтверждения, при переходе по которой выскакивает попап с нерабочей формой. В js сыплются ошибки и не дает отправить форму, валидатор не срабатывает. А с выключенным js вообще ничего не работает.
                                                  0
                                                  А ещё у Леруа в разных городах разные шаблоны сайтов. Очень неудобно парсить ваши товары. Тем более это приходится часто, т.к. по изменению количества непрерывно отслеживаю ваши продажи, выручку и т.д. И да, сделайте уже синхронизацию сайта и склада по расписанию, а то обновления приходят в случайное время, и приходится не за что напрягать и свои, и ваши серверы… А ещё лучше сразу публикуйте данные по продажам по товарным группам, выручке и прибыли, чтобы мне не приходилось так мучаться.

                                                  У Петровича, Касторамы гораздо удобнее такую инфу парсить.
                                                    0
                                                    Как уже сказали выше, могут эти 200 человек пожалуйста пофиксить поиск? А потом уже заниматься акциями и прочим. Введите например «труба 110» на своем сайте и на сайте петровича, и посмотрите, как должен работать поиск.
                                                      0
                                                      По-моему, конкретно «труба 110» — антипример, потому что Петрович находит цифру 110 в поле товара «Могут понадобиться» и выдача становится нерелевантной
                                                      leroymerlin.ru/search/?q=%D1%82%D1%80%D1%83%D0%B1%D0%B0%20110
                                                      moscow.petrovich.ru/search/?q=%D1%82%D1%80%D1%83%D0%B1%D0%B0%20110
                                                        0
                                                        У Петровича нерелевантная выдача — 6 результатов из 112 (50-е трубы). У ЛМ почти все результаты нерелевантные, куча вообще непонятно чего и отсутствие на первой странице оранжевых 110 труб
                                                      0
                                                      спасибо за описание и тему. Очень интересно почитать об опыте!
                                                        0
                                                        да, еще ужасна мобильная версия тем, что пока загрузка полностью всей страницы не прошла — ни в коем случае нельзя жать на кнопку поиск. Она не заработает и потом. Очень муторно ждать всего контента каждый раз при рефреше. Если кнопки показались, все — я имею права на них нажимать. Толку то их показывать…
                                                          0
                                                          200 человек вряд ли помогут с тем, что некоторых магазинов нет на сайте.

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

                                                          Самое читаемое