Pull to refresh

Comments 49

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

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

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

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

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

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

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

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


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

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

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


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

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

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

У Петровича, Касторамы гораздо удобнее такую инфу парсить.
UFO just landed and posted this here
По-моему, конкретно «труба 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
UFO just landed and posted this here
спасибо за описание и тему. Очень интересно почитать об опыте!
да, еще ужасна мобильная версия тем, что пока загрузка полностью всей страницы не прошла — ни в коем случае нельзя жать на кнопку поиск. Она не заработает и потом. Очень муторно ждать всего контента каждый раз при рефреше. Если кнопки показались, все — я имею права на них нажимать. Толку то их показывать…
200 человек вряд ли помогут с тем, что некоторых магазинов нет на сайте.

Интересный кейс на тему organizational behavior. Из-за значительных различий в бизнес-условиях компания аж IT отделы разделила. Как-то я скептически отношусь к этому, но время покажет. 90% через 2-3 года какое-нибудь высокое начальство во Франции начнет оптимизировать затраты и вас прикроет. Лишние 10-15 мио евро в год кому не хочется сэкономить? 10% вы сможете ваш монолит перелопатить в набор стройных сервисов и будете такими классными, что начнете писать для Франции.


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

Наплачитесь с кубернейтсами. Сначала рефакторинг своего монолита завершите. А потом, может и не захотите)

Sign up to leave a comment.