Привет! Меня зовут Петя Никитин. Я пришел в Mindbox менеджером клиентского сервиса и за четыре года перешел во frontend-разработку. Расскажу, как я учился и что помогло мне проходить внутренние собеседования.
Фронтенд-разработка может жить без независимого деплоя, пока у нее не больше 7 микрофронтендов. Но, чем выше число, тем сильнее страдают процессы. Наша команда в Mindbox прошла через это с Octopus, когда деплоила в Yandex Cloud S3. Причем на все обновления был один свободный бакет. Заливаешь код в мастер, а в это время то же самое делают еще пять разработчиков. Скапливается очередь, код еле ползет, а через час деплой вообще обваливается — Octopus не справился с нагрузкой. Пока чинишь это, оказывается, что твои обновления уже попали в продакшен заодно с чужими.
Когда число проектов возросло до 14, все это повторялось с каждым разработчиком по несколько раз в день. Поэтому мы решили вслед за коллегами-бэкендерами перейти на независимый деплой в Kubernetes.
В этой статье собран опыт платформы автоматизации маркетинга Mindbox по реформированию фронтенда:
Kubernetes вместо Yandex Cloud S3: деплоим микрофронтенды без сбоев
Автоматизированный вывод метаданных: экономим ресурсы разработки
Постепенный переход: меняем деплой без вреда для пользователей
Хот-тестинг: ускоряем обновление фронтенда
Советы: как улучшить деплой без микрофронтендов и Kubernetes
Даже на текущем рынке кандидата, каждая смена работы — это серьезное решение, инвестиция нескольких лет жизни или — неприятная строчка в резюме, причина для неудобных вопросов вроде «А почему вы ушли из компании X, проработав там немногим более года?».
Основные риски при неправильном выборе работы — сложности с поиском работы в будущем. Резюме без достижений или лоскутное, несоответствие квалификации запросу по деньгам и уровню потребления, другие нерыночные требования к работодателям. Результат — выгорание и демотивация, необходимость революции в середине карьеры.
При этом большинство людей выбирают работу скорее на чуйке, чем логически, или на каком-то одном факторе, например деньгах. Особенно в начале карьеры. Я и сам так делал. Это нормально: трудно выстроить систему на том небольшом количестве компаний, с которыми знакомится средний кандидат в жизни. С другой стороны, интуиция, тренированная на малом количествах точек, работает не лучшим образом.
За 18 лет в индустрии, в том числе на роли исполнительного директора и позднее CEO, мне удалось познакомиться с большим количеством бизнесов и поучаствовать примерно в тысяче инженерных интервью. На основе этого опыта и опыта коллег по Mindbox сложилась система, которой тут делюсь. И буду благодарен за предложения в комментариях, как ее улучшить.
Хоть я лицо и заинтересованное, надеюсь помочь и себе, и вам. Благо, в моих интересах не заманить всех и каждого, а чтобы приходящие к нам делали свой выбор рационально. Работали у нас долго, были довольны и мотивированы.
Массовый переход от монолитов к микросервисам решает ряд проблем:
• раздельный деплой и рефакторинг;
• удобное масштабирование частей системы;
• прозрачное разграничение ответственности команд;
• снижение бласт-радиуса;
• снижение когнитивной нагрузки на разработчика.
При этом создает другие проблемы: взаимодействие сервисов существенно сложнее и дороже, чем взаимодействие объектов в памяти. Частично упростить его можно с помощью протокола gRPC.
gRPC дает возможность зафиксировать в репозитории контракты межсервисных вызовов, строгую типизацию, стриминг, кросс-платформенную кодогенерацию и множество других полезных для межсервисного общения вещей.
Из этой статьи вы узнаете, когда стоит применять gRPC, а когда лучше воздержаться, как решаются типичные задачи, включая конфигурирование, отладку, healthcheck, а также то, о чем умалчивает документация.
По материалам выступления на конференции DotNext.
в 23 раза
больше целевых отправок email с помощью нейросети по сравнению с триггером
в 8,5 раз
увеличился доход от email-рассылки по атрибуции last click
в 2 раза
уменьшился процент отписок
в 17 раз
выросло число открытий в абсолютном значении
Mario Berluchi — российский производитель обуви, сумок и аксессуаров с пятью офлайн-магазинами в Москве и онлайн-магазином.
Масштаб. 200 тысяч посетителей сайта в месяц.
ИТ. Сайт на Bitrix, бэк-офис на «1С», платформа клиентских данных Mindbox.
Задача. Повысить выручку за счет работы с накопленными данными.
Результат. Рост конверсии сайта на 16,5% в рамках AB-теста, рост ARPU на 35,7%, снижение доли брошенных корзин на 17,2%.
Прошлой весной мы начали каждую пятницу страдать от массовых рассылок: письма копились в очереди и уходили с большим опозданием. Это были обычные серые пятницы. Уже тогда, за полгода до черной пятницы, стало понятно, что осенью будет непросто. Пришлось масштабироваться. Рассказываю, как всё прошло.
Наши клиенты-магазины хотят делать крутой маркетинг. Чтобы люди больше покупали, они регулярно шлют им email-рассылки. И каждый раз думают: “Что же написать в письме?”.
Можно писать просто: “Покупайте у нас почаще!”, но это не очень-то работает. Идея получше — вставлять в письмо рекламу товаров. Желательно, рекламу товаров, которые заинтересуют покупателей.
Дальше расскажу о том, как мы с нуля делали настоящие персональные рекомендации.
Ретроспектива — сложный формат совместной работы группой, содержащий элементы брейншторма (совета), коачинга и обратной связи.
Регулярные ретроспективы вызывающие изменения снизу — важнейший признак организовавшейся живой команды.
К сожалению, достаточно часто ретроспективы становятся скучным формальным ритуалом не приводящим к изменениям, или вовсе сходят на нет. Возможно, это происходит из-за потери сути ретро, как встречи для работы с эмоциями.
Для проведения ретроспективы желателен опытный фасилитатор. Особенно это важно в стартующих командах.
Если вы такой человек и хотите углубить ретро, в статье вы найдете советы и оригинальный взляд на эту встречу с т.ч. работы мозга и цели стимуляции личностного роста участников.
Распространено мнение, что цель ретроспективы — улучшить работу. Это упускает ключевую деталь — самостоятельность. Считаю, цель ретроспективы — чтобы команда сама улучшила свою работу.
А значит цель — изменение людей. Т.е. ретроспектива, это чуть-чуть психотерапия. Нужно создать новые привычки, изменить взгляд на что-то, продать всем изменения, а не просто придумать новые инструкции.
Для контроля инструкций нужен менеджер. А автономная команда должна сама их контролировать, что требует принятия решений членами команды на личностном уровне.
Таком образом, ретроспектива это, по сути, коачинг команды. Исходя из этого можно переложить на группу стандартный коачинговый подход и посмотреть на структуру встречи через эту призму.
Недавно мы рассказали, почему придумали свой RFM-сегментатор, который помогает сделать RFM-анализ за 20 секунд, и показали, как использовать его результаты в маркетинге.
Теперь рассказываем, как он устроен.
С тех пор как в компании Mindbox впервые произнесли Machine Learning, общей целью стала Большая Зеленая Кнопка. Это такая кнопка во весь экран, при нажатии на которую всё работает само и приносит прибыль.
В аналитическом проекте «RFM» цель менее амбициозная — Маленькая зеленая кнопка. Нажимаешь, и база автоматически делится на сегменты, по которым запускается отправка писем (например).
Чтобы добиться цели, мы написали автоматический RFM-сегментатор и разработали специальный отчет, чтобы наглядно представлять результаты.
Рассказываем, как это все случилось и почему теперь можно обойтись без аналитиков уделять больше времени менее тривиальным задачам .
