Как стать автором
Обновить
61.21
Mindbox
Автоматизация маркетинга
Сначала показывать

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

Уровень сложностиСредний
Время на прочтение6 мин
Количество просмотров3K

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

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

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

Читать далее
Всего голосов 8: ↑8 и ↓0+10
Комментарии1

Как джуну отрастить софты: советы и реальные истории. Часть 3. Развиваться

Уровень сложностиПростой
Время на прочтение7 мин
Количество просмотров2.2K

Привет! На связи Митя Кожевников и Юра Соколов из Mindbox, и это третья, финальная часть гайда по софтам для джунов. В первой части мы говорили о том, что значит «приносить пользу» в разработке. Во второй — об ориентации на результат. В этой части речь пойдет о развитии: что делать, чтобы расти быстрее. 

О гайде. Этот гайд — внутренний документ разработчиков Mindbox. Его писали не один год, опираясь на ошибки тех, кто давно стал мидлами и синьорами. И хотя Mindbox — продуктовая компания с особенной культурой, большинство советов из гайда подойдут и для работы в других командах. 

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

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

Читать далее
Всего голосов 7: ↑5 и ↓2+6
Комментарии3

Медленная сборка кода с .NET Roslyn: как найти и устранить причину

Уровень сложностиСложный
Время на прочтение12 мин
Количество просмотров4.4K

.NET разработчики знают, что такое ждать сборки кода. Работать при этом невозможно: пока не увидишь, как обновится приложение, — не перейдешь к следующему шагу. А переключиться на другую задачу за это время не успеешь. Получается, если в день переписать код 5 раз, можно потерять полчаса при сборке, а то и больше.

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

Читать далее
Всего голосов 46: ↑46 и ↓0+53
Комментарии26

Без денег, репликации и кеша: ограничиваем нагрузку на сервисы, используя подходы из TCP

Уровень сложностиСложный
Время на прочтение9 мин
Количество просмотров3.8K

При росте нагрузки одна из частей системы может подтормаживать. Часто уязвимым местом оказывается база данных. Так произошло и в нашем случае.

Я работаю в Mindbox в команде, которая отвечает за выдачу товарных рекомендаций. Наша база периодически деградировала, заливать ее деньгами (скейлить) не хотелось, а кешировать запросы не позволяла специфика данных. 

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

Читать далее
Всего голосов 11: ↑10 и ↓1+10
Комментарии5

Как джуну отрастить софты: советы и реальные истории. Часть 2. Отвечать за результат

Уровень сложностиПростой
Время на прочтение7 мин
Количество просмотров3.6K

Привет! На связи Митя Кожевников и Юра Соколов из Mindbox, и это вторая часть гайда по софтам для джунов. В первой части мы говорили о том, что значит «приносить пользу» в разработке, а в этой поговорим об ориентации на результат.

О гайде. Этот гайд — внутренний документ разработчиков Mindbox. Его писали не один год, опираясь на ошибки тех, кто давно стал мидлами и синьорами. И хотя Mindbox — продуктовая компания с особенной культурой, большинство советов из гайда подойдут и для работы в других командах. 

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

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

Читать далее
Всего голосов 14: ↑11 и ↓3+11
Комментарии0

Как джуну отрастить софты: советы и реальные истории. Часть 1. Думать о пользе, а не о коде

Уровень сложностиПростой
Время на прочтение8 мин
Количество просмотров2.2K

Привет! На связи Митя Кожевников и Юра Соколов из Mindbox. В этой статье мы делимся внутренним гайдом, как джунам нарастить софскилы, быстрее закрепиться в команде и вырасти. Эта часть посвящена пользе.

О гайде. Этот гайд — внутренний документ разработчиков Mindbox. Его писали не один год, опираясь на ошибки тех, кто давно стал мидлами и синьорами. И хотя Mindbox — продуктовая компания с особенной культурой, большинство советов из гайда подойдут и для работы в других командах. 

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

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

Читать далее
Всего голосов 7: ↑2 и ↓5-1
Комментарии0

Релизный цикл без компромиссов: надежно для клиентов, удобно для разработки

Уровень сложностиСредний
Время на прочтение11 мин
Количество просмотров3.4K

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

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

О том, какой путь проходит релиз и какие инструменты обеспечивают его надежность, расскажет engineering manager Mindbox, Бадал.

Читать далее
Всего голосов 5: ↑5 и ↓0+5
Комментарии5

Слышать клиентов и решать их задачи вовремя: гайд по управлению бэклогом B2B-продукта

Уровень сложностиСредний
Время на прочтение10 мин
Количество просмотров999

Всем привет! Меня зовут Марина, я product manager в Mindbox — сервисе автоматизации маркетинга.

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

Полгода мы наводили порядок в бэклоге и выстраивали процессы по работе с ним. Сейчас продуктовые команды сфокусировано работают и регулярно выпускают обновления. В статье расскажу, как пришли к этому. 

Если у вас компания на стадии масштабирования или небольшая организация, которая только строит продуктовые процессы, статья поможет выстроить порядок, не допустив наших ошибок. 

Читать далее
Всего голосов 4: ↑3 и ↓1+3
Комментарии2

Как разработчику использовать ChatGPT: разберемся, когда нейросеть помогает, а когда вредит

Уровень сложностиСредний
Время на прочтение12 мин
Количество просмотров5.4K

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

В этой статье data scientist Mindbox, в прошлом преподаватель и научный сотрудник РАН, без лишнего философствования расскажет о работе нейросетей типа ChatGPT. На своем примере он покажет, как упрощать повседневную работу с помощью ChatGPT и подобных моделей. А в конце приведет ссылки на полезные статьи.

Читать далее
Всего голосов 12: ↑10 и ↓2+8
Комментарии7

Как развивать продукт и не сгорать от поддержки — опыт работы по Pipedrive Agile Framework

Уровень сложностиСредний
Время на прочтение14 мин
Количество просмотров5.4K

На связи Антон Бевзюк и Дмитрий Кожевников, инженерные менеджеры Mindbox. 

В Mindbox большая команда, и мы долгое время искали способ, как масштабировать Agile. Пробовали Kanban, Scrum, XP, LeSS — все не то. Полгода назад перешли на Pipedrive Agile Framework и остались довольны: уменьшили количество рутинных задач, повысили уровень счастья среди разработчиков и стали быстрее выпускать фичи — реализовали обновления, которых клиенты ждали годами. Готовы поделиться опытом.

Статья будет полезна тем, кто хочет организовать работу команды из более чем 100 разработчиков и сбалансировать развитие продукта и поддержку. Мы подробно расскажем, какие сложности испытывали и как Pipedrive Agile Framework помог с ними справиться, какие ошибки допустили во время внедрения, поделимся советами, как их не повторить, и дадим подробные гайды по запуску фреймворка.

Читать далее
Всего голосов 10: ↑8 и ↓2+9
Комментарии3

Из менеджера клиентов во frontend-разработчика: как менять свои роли в компании

Уровень сложностиПростой
Время на прочтение6 мин
Количество просмотров1.3K

Привет! Меня зовут Петя Никитин. Я пришел в Mindbox менеджером клиентского сервиса и за четыре года перешел во frontend-разработку. Расскажу, как я учился и что помогло мне проходить внутренние собеседования.

Читать далее
Всего голосов 2: ↑1 и ↓10
Комментарии2

Бесперебойный деплой микрофронтендов с Kubernetes: как настроить

Время на прочтение13 мин
Количество просмотров4.6K

Фронтенд-разработка может жить без независимого деплоя, пока у нее не больше 7 микрофронтендов. Но, чем выше число, тем сильнее страдают процессы. Наша команда в Mindbox прошла через это с Octopus, когда деплоила в Yandex Cloud S3. Причем на все обновления был один свободный бакет. Заливаешь код в мастер, а в это время то же самое делают еще пять разработчиков. Скапливается очередь, код еле ползет, а через час деплой вообще обваливается — Octopus не справился с нагрузкой. Пока чинишь это, оказывается, что твои обновления уже попали в продакшен заодно с чужими. 

Когда число проектов возросло до 14, все это повторялось с каждым разработчиком по несколько раз в день. Поэтому мы решили вслед за коллегами-бэкендерами перейти на независимый деплой в Kubernetes.

В этой статье собран опыт платформы автоматизации маркетинга Mindbox по реформированию фронтенда:

Kubernetes вместо Yandex Cloud S3: деплоим микрофронтенды без сбоев

Автоматизированный вывод метаданных: экономим ресурсы разработки

Постепенный переход: меняем деплой без вреда для пользователей

Хот-тестинг: ускоряем обновление фронтенда

Советы: как улучшить деплой без микрофронтендов и Kubernetes

Читать далее
Всего голосов 11: ↑11 и ↓0+11
Комментарии3

Как инженеру выбрать работу

Время на прочтение18 мин
Количество просмотров14K

Даже на текущем рынке кандидата, каждая смена работы — это серьезное решение, инвестиция нескольких лет жизни или — неприятная строчка в резюме, причина для неудобных вопросов вроде «А почему вы ушли из компании X, проработав там немногим более года?».

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

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

За 18 лет в индустрии, в том числе на роли исполнительного директора и позднее CEO, мне удалось познакомиться с большим количеством бизнесов и поучаствовать примерно в тысяче инженерных интервью. На основе этого опыта и опыта коллег по Mindbox сложилась система, которой тут делюсь. И буду благодарен за предложения в комментариях, как ее улучшить.

Хоть я лицо и заинтересованное, надеюсь помочь и себе, и вам. Благо, в моих интересах не заманить всех и каждого, а чтобы приходящие к нам делали свой выбор рационально. Работали у нас долго, были довольны и мотивированы. 

Читать далее
Всего голосов 27: ↑26 и ↓1+29
Комментарии23

gRPC в .NET — рецепты счастья

Время на прочтение12 мин
Количество просмотров23K

Массовый переход от монолитов к микросервисам решает ряд проблем:

раздельный деплой и рефакторинг;

удобное масштабирование частей системы;

прозрачное разграничение ответственности команд;

снижение бласт-радиуса;

снижение когнитивной нагрузки на разработчика.

При этом создает другие проблемы: взаимодействие сервисов существенно сложнее и дороже, чем взаимодействие объектов в памяти. Частично упростить его можно с помощью протокола gRPC.

gRPC дает возможность зафиксировать в репозитории контракты межсервисных вызовов, строгую типизацию, стриминг, кросс-платформенную кодогенерацию и множество других полезных для межсервисного общения вещей.

Из этой статьи вы узнаете, когда стоит применять gRPC, а когда лучше воздержаться, как решаются типичные задачи, включая конфигурирование, отладку, healthcheck, а также то, о чем умалчивает документация. 

По материалам выступления на конференции DotNext.

Читать далее
Всего голосов 23: ↑23 и ↓0+23
Комментарии63

Миллиард отправок в неделю и 730 тысяч запросов в минуту. Как справляемся с ежегодным удвоением и не унываем

Время на прочтение5 мин
Количество просмотров3.9K
Четвертый ежегодный отчет о развитии разработки Mindbox по итогам черной пятницы — недели максимальной нагрузки.

Маркетинговая CDP — это не только коммуникации, приносящие значимую долю выручки, но и механики реального времени: расчет чеков, персонализация мобильных приложений и сайтов. Mindbox задуман и всё чаще работает как центральная back-end система бизнеса, интегрирующая другие. Так, например, выглядит схема интеграций одного из давних и продвинутых клиентов:

image

Поэтому клиентам важно понимать, можно ли на нас положиться сегодня и в будущем. Ниже приглашаю прочитать:

  • как справляемся с надежностью при росте нагрузке (кажется, неплохо);
  • что для этого уже сделали;
  • что будем делать дальше: планы по технике и продукту.
Читать дальше →
Всего голосов 5: ↑3 и ↓2+3
Комментарии5

Как грумить задачу: чек-лист с примерами

Время на прочтение8 мин
Количество просмотров12K
Наша разработка постоянно растет, поэтому приходится онбордить по несколько человек в месяц и каждому рассказывать, как правильно грумить задачи. Обучать груму «вручную» больно, потому что это отнимает много времени, какие-то знания теряются по дороге и выскакивают ошибки, которых можно было избежать. Чтобы облегчить жизнь лидам и новичкам, мы собрали чек-лист с описанием этапов грума и примерами. Он будет полезен разработчикам продуктовых компаний, которые онбордят или которых недавно приняли в штат. Чек-лист поможет разбивать задачи на этапы, чтобы ничего не терялось и результат соответствовал ожиданиям.

Все примеры ниже — специфичные и подойдут не каждому, они построены в основном на продуктах Mindbox «Рассылки» и «Программа лояльности». Продукты помогают нашим клиентам запускать автоматические рассылки по триггерам (действиям или событиям), чтобы не спамить пользователей, выдавать промокоды и выстраивать бонусные системы. Если поймете, что чек-лист полезен, можете заменить примеры на свои и использовать.

Ниже подробнее о том, как сделать качественный грум:

  • цель грума,
  • необходимый минимум,
  • уточнение требований и контекста,
  • типичные этапы,
  • особенности при доработке механик.
Читать дальше →
Всего голосов 8: ↑4 и ↓40
Комментарии13

Как уменьшить размерность метрик в Prometheus, если вы не DevOps

Время на прочтение5 мин
Количество просмотров4.2K
Иногда команда разработки сталкивается с задачей, в которой у неё мало экспертного опыта, и через пробы и ошибки она находит неочевидное решение. Так произошло и с нами, когда понадобилось перенести сбор метрик из Infux в Prometheus. Их итоговая размерность оказалась 1,5 миллиона, и мы решили ее уменьшать. Инфраструктуру по сбору метрик (Prometheus, k8s, деплой через Helm) создавали DevOps-инженеры из другой команды, у которых не было ресурсов для нашей задачи. Поэтому мы заручились их советами, изучили документацию и решили снижать размерность метрик силами разработки.

Эта статья не подойдет опытным DevOps-инженерам, но будет полезна разработчикам, которые хотят уменьшить размерность метрик и не желают погружаться в документацию. Или тем, кто намеренно отказывается от иерархической федерации и ищет обходное решение, но не хочет наступить на наши грабли. Расскажем:

  • как в два шага уменьшить размерность метрик с помощью двух ServiceMonitor,
  • какой есть эталонный способ уменьшить размерность метрик без «костылей»,
  • почему не стоит тратить время на снижение размерности метрик с помощью Pushgateway.
Читать дальше →
Всего голосов 4: ↑3 и ↓1+5
Комментарии8

Как масштабировать разработку при 400 000 RPM и не надорваться

Время на прочтение10 мин
Количество просмотров3.6K
Если бизнес идет вверх, то запросы и нагрузка на разработку увеличиваются в разы. Рано или поздно каждый управленец сталкивается с выбором из двух крайностей: встать на сторону бизнеса, двигать продукт и демотивировать разработчиков бесконечным техдолгом или дать свободу разработке и потерять контроль над задачами бизнеса.

Mindbox 15 лет развивает B2B-продукт и вырос с 3 до 70 человек в разработке. Мы тестировали разные подходы к масштабированию и готовы поделиться опытом, чтобы вам не пришлось наступать на те же грабли. Ниже расскажу, как попробовали полную автономию команд и централизацию, роняли надежность, демотивировали команды, как в результате с этим справились и выработали свою систему масштабирования.

По материалам выступления на Agile Days 2021:


Всего голосов 4: ↑4 и ↓0+4
Комментарии2

Стоит ли переходить с Powershell DSC на Ansible и как это сделать

Время на прочтение11 мин
Количество просмотров5.4K
Об IaC под Windows пишут мало, потому что DevOps/SRE ассоциируется в основном c Linux и Kubernetes. Мы решили исправить эту ситуацию и сравнить инструменты, которыми можно управлять IaC на базе Windows. Статья будет полезна разработчикам, которые работают с Windows-инфраструктурой и выбирают способы управления, и тем, кто уже внедрил Powershell DSC или Ansible, но сомневается в своем решении. Ниже поделимся опытом и расскажем:
  • как устроен Powershell DSC и чем он отличается от Ansible при управлении инфраструктурой на Windows;
  • почему мы перешли на Ansible;
  • с какими проблемами столкнулись и как их решали;
  • как соотносятся ожидания и реальность после перехода на Ansible;
  • кому стоит выбрать Powershell DSC, а кому — Ansible.
Читать дальше →
Всего голосов 7: ↑7 и ↓0+7
Комментарии5

Как с помощью нейросети определить лучшую дату отправки email и повысить доход рассылки в 8,5 раз

Время на прочтение6 мин
Количество просмотров6.8K
Чтобы email-рассылка не затерялась во входящих, а клиенты чаще открывали письма и покупали, важно угадать правильное время отправки. С помощью нейросети мы проанализировали поведение клиентов и спрогнозировали дату отправки следующего email, чтобы порекомендовать клиенту товары в то время, когда он захочет их купить. Протестировали в зоомагазинах на рассылках с предложением повторной покупки и оценили результат с помощью AB-тестов. Получили следующие результаты:

в 23 раза
больше целевых отправок email с помощью нейросети по сравнению с триггером

в 8,5 раз
увеличился доход от email-рассылки по атрибуции last click

в 2 раза
уменьшился процент отписок

в 17 раз
выросло число открытий в абсолютном значении


Ниже поделимся опытом и расскажем:

  • почему решили использовать LSTM-модель нейросети для предсказания даты отправки email вместо алгоритма градиентного бустинга;
  • как устроена LSTM;
  • какие данные нейросеть использует для обучения;
  • какую архитектуру нейросети использовали и с какими сложностями столкнулись;
  • каких результатов достигли и как их оценивали.
Читать дальше →
Всего голосов 17: ↑6 и ↓11+1
Комментарии24

Информация

Сайт
www.mindbox.ru
Дата регистрации
Численность
201–500 человек
Местоположение
Россия