В e-commerce приходят из самых разных областей: финтеха, софтверной разработки, телекома. И довольно быстро обнаруживают, что тут у нас тоже довольно нескучно. Мы поговорили с представителями разных направлений IT департамента о неожиданных профессиональных вызовах, рабочих задачах и точках роста.
Меня зовут Александр Афенов, я руководитель направления разработки для коммерческого отдела, сам себя называю тимлидом тимлидов. До перехода в Lamoda занимался аутсорс-разработкой для сотовых операторов. За 4,5 года в Lamoda я прошел путь от мидл-разработчика до руководителя направления.
Как был устроен этот рост?
Процесс онбординга построен так, что в течение испытательного срока разработчики выкатывают новые фичи (а иногда даже целые проекты) в продакшен. Задачи и цели на испытательный подбираются в зависимости от грейда и особенностей нового сотрудника, и даже после первых трёх месяцев продолжают учить его и погружают в бизнес и специфику IT-систем: через автотесты показывают течение бизнес-процессов, на code review делятся основами внутренней культуры разработки, объясняют какие части проектов можно рефакторить, а что скоро вынесут в новые сервисы. Тем не менее, по-настоящему глубокое представление о работе системы появляется не сразу. Для этого, на мой взгляд, надо проработать около года.
Чтобы быстрее освоиться и всё пощупать руками, и также для ротации знаний внутри команд, существуют саппорт дежурства (вот тут про это был мой большой доклад на Teamleadconf). В течение недели один из инженеров решает вопросы, которые прилетают по системе, когда приоритетные задачи заканчиваются, он берет их из технического бэклога.
Для смелых и отчаянных, и тех, кто хочет поддерживать систему, существуют ночные дежурства. Это интересный челлендж, для тех, кто хочет быстро прокачаться. Ночью можно по-настоящему вступить с системой в близкие отношения, потому что часть бизнес-процессов протекают в строго нерабочее время.
Например, я сижу днем и что-то программирую, катятся релизы и все хорошо, а потом я заступаю на дежурство и поздним вечером вижу, что на одном из транзитных складов происходит приёмка товаров, и из-за ошибки в IT-системе что-то разрывает в клочья бизнес-процесс. На практике получается так: несколько торговых представителей сидят на складе, не могут закончить рабочий день и поехать домой. В этот момент можно и нужно руками пощупать бизнес-процесс, починить, помочь и понять, как все работает. А в другое время ты с этим и не сталкиваешься, и можешь не сталкиваться годами. В сочетании с финансовой мотивацией и драйвом – очень прикольно.
А что сейчас?
Сейчас у меня есть глобальная управленческая задача — сблизить и унифицировать все команды, работающие с коммерческими функциями. Решать это мы будем двумя способами: через ротацию задач среди команд, и через привлечение к работе наших «шерстяных волчар» — системных архитекторов, которые в том числе будут следить за горизонтальными связями внутри и между командами. Чтобы каждая команда стала самостоятельной, порою нужно развивать ребят и давать им разные задачи и возможность осваивать новые технологии: иногда PHP-разработчики подключаются к проектам на Java и Go. С 2018 года все в моём направлении работают с Kafka, ставшей важной частью нашей инфраструктуры, общепринятой технологией и одним из самых популярных способов обмена данными между системами. (Вот тут доклад о том, как у нас это устроено)
Все разработчики и другие члены команд должны не только что-то свое пилить в уголке, но и понимать, что делают соседи. Мы хотим, чтобы они собственными руками потрогали чужие системы: в дальнейшем это делает команды более самостоятельными и позволяет им набегать в нужные для решения бизнес-задачи системы.
Что тебя удивило, когда ты пришел в e-com?
В Lamoda для меня на передний план вышла коммуникация с клиентом и то, как действия IT влияют на жизнь людей и их реальный опыт. Здесь интересуются не выгодой в моменте, а скорее лояльностью в долгосрочной перспективе. Мы хотим, чтобы нашим продуктом пользовались на регулярной основе. Главная специфика для разработки – это необходимость оперативно реагировать на проблемы. Например, у нас что-то сломалось, а в пункте выдачи товаров стоит живой человек и не может оплатить свое пальто.
Мы видим, когда из-за наших ошибок страдают люди на складе и в доставке. И радуемся вместе с клиентами, например, когда мы полностью переработали процесс обработки платежей и запустили гифт-карты, которые все очень ждали.
Я Александра Камзеева — раньше я работала в системной интеграции, три с половиной года назад стала работать системным аналитиком в Lamoda.
Зачем нужен аналитик в разработке?
Это первый вопрос многих разработчиков. Но потом, когда они поработают с хорошим системным аналитиком, то входят во вкус и просят звать аналитиков на каждый проект. Разработчики не посвящены в тонкости бизнес-процессов, а без этих знаний сложно сделать решение, которое идеально подойдет бизнесу. Аналитик нужен, чтобы сделать подробное исследование до начала разработки, задать вопросы, получить ответы и все учесть в составленной спецификации. Это сводит количество итераций и ошибок к минимуму и экономит время и нервы разработчиков.
Какая у тебя была первая серьезная задача в e-commerce?
Мой самый глобальный и интересный челлендж пока — это новая система автоматизации процесса возврата денег на карту клиента. Это было одно из самых слабых мест нашей системы, она писалась, ещё когда Lamoda была стартапом. Там было очень много ручных операций, которые повышали риск ошибок. Мы начали обдумывать подходы к изменению этой системы, и тут случился «волшебный пинок» от государства: был принят ФЗ №54. По этому закону все компании, предлагающие товары и услуги физическим лицам, должны передавать данные о продаже в налоговую через ОФД (оператор фискальных данных), указывая, что именно продали, когда и через каких посредников. Все это печатается на чеке. Работает и в обратную сторону: помимо данных о том, что продано, нужно передавать, за что возвращены деньги, и печатать чек.
Мы разделили проект на 7 фаз, это позволяло нам в каждой фазе фокусироваться на конкретной фиче и выпускать их в прод одну за другой. В результате автоматизировали по возвратам всё, что могли, чтобы в налоговую передавать корректные данные без лишних ручных исправлений.
Меня зовут Игорь Грамматчиков, и я пришел в команду разработки онлайн-магазина полтора года назад из крупной компании по автоматизации бизнес-процессов. Сейчас я frontend-разработчик, делаю сайт Lamoda. До этого я разрабатывал интерфейсы для внутренних систем автоматизации в больших сетевых магазинах, там это была просто разработка для какого-то абстрактного клиента. Сейчас я чувствую, что это мой продукт, и я хочу, чтобы он нравился не только пользователям, но и мне самому. Я сам регулярно покупаю на Lamoda, все коллеги и друзья пользуются, и мы сами иногда видим косяки, которые можем исправить.
Задачи бывают разные. Например, у меня была задача сделать выпадающую корзину на сайте, чтобы она работала на всех страницах, которые уже переписаны на новый фреймворк vue.js и на тех, которые остались на старом коде backbone.js, jquery. Я больше месяца над этой задачей корпел и столкнулся с многими проблемами. Но в итоге, после долгих совместных обдумываний мы выработали метод, отточили его, и теперь им все могут пользоваться легко и просто.
Мы занимаемся не только массовыми проблемами. Недавно мы боролись со специфичным багом, который возникал только у одного пользователя. На прошлых моих работах все бы просто придумали вежливое объяснение и забили, а тут мы чиним все, что работает не так, как должно.
Я первый раз по-настоящему работаю по agile: у нас ежедневные стендапы, много встреч с менеджером и с дизайнером. И разработчик – не только исполнитель, он еще и соавтор. На всех совещаниях к моему мнению и правда прислушиваются, а не просто — записал и пошел пилить. Говоришь, что не будет работать, давайте переделаем? И команда начинает думать, как лучше.
Я Виктор Барсуков — разработчик одной из команд автоматизации склада. В команде я работаю полгода, а до этого работал в финтехе и в операторе фискальных данных. Мы постоянно общаемся с сотрудниками склада — пользователями наших систем, которые дают нам качественный фидбек. В финтехе такого не было – мы написали и забыли. А оно потом кем-то тестируется, кем-то деплоится. То, что мы каждый день общаемся с нашими непосредственными пользователями, и жесткий code review меня очень мотивирует на дальнейшее развитие. У нас прямо лозунг: ребята делайте ревью кода друг друга! Чтобы задача дальше двинулась, ее должны посмотреть два инженера и кто-то из тимлидов. Это очень классная практика: помимо стендапов, ревью и ретроспективных разборов ты вживую видишь изменение кода. Так появляется общая картина разработки.
А какие бизнес-процессы вы автоматизируете?
В работе над автоматизацией склада есть множество задач: работа с поставками товаров, размещением товаров на полках, управлением процессами сортировки, упаковки, сбора заказов. Здесь же и взаимодействие с сотрудниками склада: от подсчета KPI до выбора оптимального маршрута перемещения между полками.
У нас бывают мелкие задачи, а бывают похожие на детектив, когда ты по логам смотришь, что где и когда пошло не так. Это увлекательно. Сейчас мы решаем глобальную задачу — переход с Java на Kotlin в Android-приложении, это даст больше возможностей с точки зрения разработки.
Какую самую масштабную бизнес-задачу вы решаете сейчас?
Cейчас команда разработки склада реализует еще один крупный проект – Склад-2. Раньше мы работали с одним физическим складом, а подключение второго потребует серьезных изменений во всех бизнес-процессах, а значит и в системах, которые их автоматизируют. Второй юнит будет на старте аналогичен первому (про первый мы писали отдельную статью). Но в дальнейшем второй склад будет больше, а уровень автоматизации бизнес-процессов выше и современнее.
Одна из задач — синхронизация данных между будущими системами, чтобы данные между ними не дублировались и не конфликтовали.
Я настраивал шину обмена данными на базе фреймворка Camel. Собственно, это был мой первый опыт работы с Camel, поэтому была задача не только доработать маршруты с учетом второго склада, но и разобраться с самим фреймворком.
Я Елизавета Науменко, и я уже год работаю в команде саппорта и разработки отдела ERP (Enterprise Resource Planning) на позиции консультанта поддержки. Наш отдел занимается автоматизацией всей финансовой отчетности, бухгалтерии и товародвижения.
Система построена в основном на Axapta и немного на 1С. Axapta взаимодействует с десятками наших внутренних систем, так как она источник мастер-данных по закупкам и по финансам. К Axapta постоянно обращаются и другие наши платформы, поэтому интеграции и поддержки здесь много.
Главным челленджем для меня стало быстрое погружение в процесс, пришлось очень быстро учиться и развиваться. За три месяца испытательного срока я изучила, как работают наши процессы на Axapta. Я чувствовала будто получаю еще одно высшее образование (про то, как мы делимся знаниями внутри команды подробнее можно почитать вот тут).
Что самое сложное в твоей работе?
Самое сложное — это срочные задачи по поддержке. По SLA на решение критических ошибок есть буквально несколько часов. Бывают и сложные задачи, которые могут растянуться, потому что нужен более глубокий анализ. Если не получается справиться самостоятельно, то я могу пойти к своему руководителю и попросить помощи. Даже к руководителю ERP разработки подойти и сказать, что я не знаю, что делать и как решить задачу. И это скорее поощряется, потому что мы все понимаем, что если вовремя не исправить ошибку, то возможна стоп-ситуация для бизнеса, а это для команды критично, так как это деньги компании. Если такое произошло, то обязательно будет ретроспективный разбор инцидента: что делать и как предотвратить ошибки в следующий раз.
Я Тимур Нурутдинов, отвечаю за всю разработку в Lamoda. С моей точки зрения, у нас большой e-com с огромным количеством процессов, в котором работает много людей, а еще больше людей пользуется нашими сервисами. Чтобы всё это работало, мы используем почти все современные технологии, так как нам приходится решать почти все возможные IT-задачи. На нашем техрадаре настоящий зоопарк, но он контактный, всё можно попробовать. Конечно, у нас меньше собственной разработки, чем у IT-гигантов, но задачи и проекты не проще, чем у них.
А что нравится лично тебе в твоей работе?
У IT-департамента Lamoda множество пользователей: покупатели, бизнес-клиенты, сотрудники компании. И для меня особое удовольствие видеть результат своего труда — когда мы оперативно решаем их задачи. Я об этом выступал с целым докладом на HL++2019, где подробно рассказывал, какие еще вызовы ставит перед инженером индустрия e-commerce, и почему мы от этого получаем удовольствие.
Драйв, кайф и быстрая обратная связь
Меня зовут Александр Афенов, я руководитель направления разработки для коммерческого отдела, сам себя называю тимлидом тимлидов. До перехода в Lamoda занимался аутсорс-разработкой для сотовых операторов. За 4,5 года в Lamoda я прошел путь от мидл-разработчика до руководителя направления.Как был устроен этот рост?
Процесс онбординга построен так, что в течение испытательного срока разработчики выкатывают новые фичи (а иногда даже целые проекты) в продакшен. Задачи и цели на испытательный подбираются в зависимости от грейда и особенностей нового сотрудника, и даже после первых трёх месяцев продолжают учить его и погружают в бизнес и специфику IT-систем: через автотесты показывают течение бизнес-процессов, на code review делятся основами внутренней культуры разработки, объясняют какие части проектов можно рефакторить, а что скоро вынесут в новые сервисы. Тем не менее, по-настоящему глубокое представление о работе системы появляется не сразу. Для этого, на мой взгляд, надо проработать около года.
Чтобы быстрее освоиться и всё пощупать руками, и также для ротации знаний внутри команд, существуют саппорт дежурства (вот тут про это был мой большой доклад на Teamleadconf). В течение недели один из инженеров решает вопросы, которые прилетают по системе, когда приоритетные задачи заканчиваются, он берет их из технического бэклога.
Для смелых и отчаянных, и тех, кто хочет поддерживать систему, существуют ночные дежурства. Это интересный челлендж, для тех, кто хочет быстро прокачаться. Ночью можно по-настоящему вступить с системой в близкие отношения, потому что часть бизнес-процессов протекают в строго нерабочее время.
Например, я сижу днем и что-то программирую, катятся релизы и все хорошо, а потом я заступаю на дежурство и поздним вечером вижу, что на одном из транзитных складов происходит приёмка товаров, и из-за ошибки в IT-системе что-то разрывает в клочья бизнес-процесс. На практике получается так: несколько торговых представителей сидят на складе, не могут закончить рабочий день и поехать домой. В этот момент можно и нужно руками пощупать бизнес-процесс, починить, помочь и понять, как все работает. А в другое время ты с этим и не сталкиваешься, и можешь не сталкиваться годами. В сочетании с финансовой мотивацией и драйвом – очень прикольно.
А что сейчас?
Сейчас у меня есть глобальная управленческая задача — сблизить и унифицировать все команды, работающие с коммерческими функциями. Решать это мы будем двумя способами: через ротацию задач среди команд, и через привлечение к работе наших «шерстяных волчар» — системных архитекторов, которые в том числе будут следить за горизонтальными связями внутри и между командами. Чтобы каждая команда стала самостоятельной, порою нужно развивать ребят и давать им разные задачи и возможность осваивать новые технологии: иногда PHP-разработчики подключаются к проектам на Java и Go. С 2018 года все в моём направлении работают с Kafka, ставшей важной частью нашей инфраструктуры, общепринятой технологией и одним из самых популярных способов обмена данными между системами. (Вот тут доклад о том, как у нас это устроено)
Все разработчики и другие члены команд должны не только что-то свое пилить в уголке, но и понимать, что делают соседи. Мы хотим, чтобы они собственными руками потрогали чужие системы: в дальнейшем это делает команды более самостоятельными и позволяет им набегать в нужные для решения бизнес-задачи системы.
Что тебя удивило, когда ты пришел в e-com?
В Lamoda для меня на передний план вышла коммуникация с клиентом и то, как действия IT влияют на жизнь людей и их реальный опыт. Здесь интересуются не выгодой в моменте, а скорее лояльностью в долгосрочной перспективе. Мы хотим, чтобы нашим продуктом пользовались на регулярной основе. Главная специфика для разработки – это необходимость оперативно реагировать на проблемы. Например, у нас что-то сломалось, а в пункте выдачи товаров стоит живой человек и не может оплатить свое пальто.
Мы видим, когда из-за наших ошибок страдают люди на складе и в доставке. И радуемся вместе с клиентами, например, когда мы полностью переработали процесс обработки платежей и запустили гифт-карты, которые все очень ждали.
Переделать все с нуля
Я Александра Камзеева — раньше я работала в системной интеграции, три с половиной года назад стала работать системным аналитиком в Lamoda. Зачем нужен аналитик в разработке?
Это первый вопрос многих разработчиков. Но потом, когда они поработают с хорошим системным аналитиком, то входят во вкус и просят звать аналитиков на каждый проект. Разработчики не посвящены в тонкости бизнес-процессов, а без этих знаний сложно сделать решение, которое идеально подойдет бизнесу. Аналитик нужен, чтобы сделать подробное исследование до начала разработки, задать вопросы, получить ответы и все учесть в составленной спецификации. Это сводит количество итераций и ошибок к минимуму и экономит время и нервы разработчиков.
Какая у тебя была первая серьезная задача в e-commerce?
Мой самый глобальный и интересный челлендж пока — это новая система автоматизации процесса возврата денег на карту клиента. Это было одно из самых слабых мест нашей системы, она писалась, ещё когда Lamoda была стартапом. Там было очень много ручных операций, которые повышали риск ошибок. Мы начали обдумывать подходы к изменению этой системы, и тут случился «волшебный пинок» от государства: был принят ФЗ №54. По этому закону все компании, предлагающие товары и услуги физическим лицам, должны передавать данные о продаже в налоговую через ОФД (оператор фискальных данных), указывая, что именно продали, когда и через каких посредников. Все это печатается на чеке. Работает и в обратную сторону: помимо данных о том, что продано, нужно передавать, за что возвращены деньги, и печатать чек.
Мы разделили проект на 7 фаз, это позволяло нам в каждой фазе фокусироваться на конкретной фиче и выпускать их в прод одну за другой. В результате автоматизировали по возвратам всё, что могли, чтобы в налоговую передавать корректные данные без лишних ручных исправлений.
Не только исполнитель, но ещё и соавтор
Меня зовут Игорь Грамматчиков, и я пришел в команду разработки онлайн-магазина полтора года назад из крупной компании по автоматизации бизнес-процессов. Сейчас я frontend-разработчик, делаю сайт Lamoda. До этого я разрабатывал интерфейсы для внутренних систем автоматизации в больших сетевых магазинах, там это была просто разработка для какого-то абстрактного клиента. Сейчас я чувствую, что это мой продукт, и я хочу, чтобы он нравился не только пользователям, но и мне самому. Я сам регулярно покупаю на Lamoda, все коллеги и друзья пользуются, и мы сами иногда видим косяки, которые можем исправить. Задачи бывают разные. Например, у меня была задача сделать выпадающую корзину на сайте, чтобы она работала на всех страницах, которые уже переписаны на новый фреймворк vue.js и на тех, которые остались на старом коде backbone.js, jquery. Я больше месяца над этой задачей корпел и столкнулся с многими проблемами. Но в итоге, после долгих совместных обдумываний мы выработали метод, отточили его, и теперь им все могут пользоваться легко и просто.
Мы занимаемся не только массовыми проблемами. Недавно мы боролись со специфичным багом, который возникал только у одного пользователя. На прошлых моих работах все бы просто придумали вежливое объяснение и забили, а тут мы чиним все, что работает не так, как должно.
Я первый раз по-настоящему работаю по agile: у нас ежедневные стендапы, много встреч с менеджером и с дизайнером. И разработчик – не только исполнитель, он еще и соавтор. На всех совещаниях к моему мнению и правда прислушиваются, а не просто — записал и пошел пилить. Говоришь, что не будет работать, давайте переделаем? И команда начинает думать, как лучше.
Фидбек пользователя и code review как драйверы развития
Я Виктор Барсуков — разработчик одной из команд автоматизации склада. В команде я работаю полгода, а до этого работал в финтехе и в операторе фискальных данных. Мы постоянно общаемся с сотрудниками склада — пользователями наших систем, которые дают нам качественный фидбек. В финтехе такого не было – мы написали и забыли. А оно потом кем-то тестируется, кем-то деплоится. То, что мы каждый день общаемся с нашими непосредственными пользователями, и жесткий code review меня очень мотивирует на дальнейшее развитие. У нас прямо лозунг: ребята делайте ревью кода друг друга! Чтобы задача дальше двинулась, ее должны посмотреть два инженера и кто-то из тимлидов. Это очень классная практика: помимо стендапов, ревью и ретроспективных разборов ты вживую видишь изменение кода. Так появляется общая картина разработки. А какие бизнес-процессы вы автоматизируете?
В работе над автоматизацией склада есть множество задач: работа с поставками товаров, размещением товаров на полках, управлением процессами сортировки, упаковки, сбора заказов. Здесь же и взаимодействие с сотрудниками склада: от подсчета KPI до выбора оптимального маршрута перемещения между полками.
У нас бывают мелкие задачи, а бывают похожие на детектив, когда ты по логам смотришь, что где и когда пошло не так. Это увлекательно. Сейчас мы решаем глобальную задачу — переход с Java на Kotlin в Android-приложении, это даст больше возможностей с точки зрения разработки.
Какую самую масштабную бизнес-задачу вы решаете сейчас?
Cейчас команда разработки склада реализует еще один крупный проект – Склад-2. Раньше мы работали с одним физическим складом, а подключение второго потребует серьезных изменений во всех бизнес-процессах, а значит и в системах, которые их автоматизируют. Второй юнит будет на старте аналогичен первому (про первый мы писали отдельную статью). Но в дальнейшем второй склад будет больше, а уровень автоматизации бизнес-процессов выше и современнее.
Одна из задач — синхронизация данных между будущими системами, чтобы данные между ними не дублировались и не конфликтовали.
Я настраивал шину обмена данными на базе фреймворка Camel. Собственно, это был мой первый опыт работы с Camel, поэтому была задача не только доработать маршруты с учетом второго склада, но и разобраться с самим фреймворком.
Axapta за три месяца
Я Елизавета Науменко, и я уже год работаю в команде саппорта и разработки отдела ERP (Enterprise Resource Planning) на позиции консультанта поддержки. Наш отдел занимается автоматизацией всей финансовой отчетности, бухгалтерии и товародвижения. Система построена в основном на Axapta и немного на 1С. Axapta взаимодействует с десятками наших внутренних систем, так как она источник мастер-данных по закупкам и по финансам. К Axapta постоянно обращаются и другие наши платформы, поэтому интеграции и поддержки здесь много.
Главным челленджем для меня стало быстрое погружение в процесс, пришлось очень быстро учиться и развиваться. За три месяца испытательного срока я изучила, как работают наши процессы на Axapta. Я чувствовала будто получаю еще одно высшее образование (про то, как мы делимся знаниями внутри команды подробнее можно почитать вот тут).
Что самое сложное в твоей работе?
Самое сложное — это срочные задачи по поддержке. По SLA на решение критических ошибок есть буквально несколько часов. Бывают и сложные задачи, которые могут растянуться, потому что нужен более глубокий анализ. Если не получается справиться самостоятельно, то я могу пойти к своему руководителю и попросить помощи. Даже к руководителю ERP разработки подойти и сказать, что я не знаю, что делать и как решить задачу. И это скорее поощряется, потому что мы все понимаем, что если вовремя не исправить ошибку, то возможна стоп-ситуация для бизнеса, а это для команды критично, так как это деньги компании. Если такое произошло, то обязательно будет ретроспективный разбор инцидента: что делать и как предотвратить ошибки в следующий раз.
Технологическое разнообразие: Зоопарк, но контактный
Я Тимур Нурутдинов, отвечаю за всю разработку в Lamoda. С моей точки зрения, у нас большой e-com с огромным количеством процессов, в котором работает много людей, а еще больше людей пользуется нашими сервисами. Чтобы всё это работало, мы используем почти все современные технологии, так как нам приходится решать почти все возможные IT-задачи. На нашем техрадаре настоящий зоопарк, но он контактный, всё можно попробовать. Конечно, у нас меньше собственной разработки, чем у IT-гигантов, но задачи и проекты не проще, чем у них. А что нравится лично тебе в твоей работе?
У IT-департамента Lamoda множество пользователей: покупатели, бизнес-клиенты, сотрудники компании. И для меня особое удовольствие видеть результат своего труда — когда мы оперативно решаем их задачи. Я об этом выступал с целым докладом на HL++2019, где подробно рассказывал, какие еще вызовы ставит перед инженером индустрия e-commerce, и почему мы от этого получаем удовольствие.
