На связи Кирилл Козлов, data‑инженер Mindbox. Наша команда регулярно пересчитывает бизнес‑метрики для клиентов. Для этого нам приходится формировать витрины данных для биллинга и аналитики на основе десятков источников.

Долгое время мы обрабатывали данные для расчетов на PySpark — инструменте, с которым сложно работать без опыта программирования на Python. Чтобы создать любой пайплайн, приходилось привлекать разработчиков. Это затягивало процесс на несколько недельных спринтов.

В статье расскажу, как мы построили внутреннюю data‑платформу, где аналитик или продакт может создать регулярно обновляемый пайплайн, описав его в четырех YAML‑файлах.

На связи Антон Черный, лид команды продуктового дизайна. На примере типовой задачи рассказываю, как мы пересобрали UX-процесс и ускорили проверку гипотез с помощью AI-first прототипирования.

Статья для junior‑разработчиков C#, которые хотят развиваться в профессии, но теряются в разнообразии источников знаний: книги, подкасты, видео, разборы, ChatGPT. Читать и смотреть все подряд никакой жизни не хватит, а выделить нужный базовый стэк сложно — не хватает знаний и опыта. В статье даем структуру: какие темы и по каким источникам изучать, чтобы получить необходимую базу для профессионального роста.

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

В статье поговорим про разные стратегии тестирования под разные риски и кейсы. Поднимемся над привычными unit‑тестами и заглянем, что там есть еще. Спойлер: а еще там workflow‑, integration‑, property‑based‑ и resilience‑тесты.

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

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

В 2023 году к нам регулярно приходили разработчики с вопросом: «Кажется, тупит сеть. Посмотрите?» Вопросы были по делу, и каждый раз отвечать было сложно. Когда тойл от подобных обращений превысил разумные пределы, мы решили разработать SLO на летенси в Ingress. Но оказалось, что это не так уж просто.

Всем привет! Я Николай Якимовец, продуктовый менеджер в Mindbox. Сейчас работаю над продуктом, который автоматизирует работу категорийных менеджеров: управление ассортиментом товаров, ценами и складскими остатками. 

Без автоматизации такие задачи решают с помощью таблиц Excel на 50+ столбцов и десятки тысяч строк. Поэтому нормальный рабочий объем для нашей продуктовой команды — это огромные выгрузки по продажам, склейка файлов, расчеты метрик, проверка гипотез, дашборды. Плюс при запуске нового продукта приходится сверять, что система считает правильно: сравнивать выгрузки, подбивать результаты.

Чтобы погрузиться в эту среду, мне нужно было быстро освоить сценарии управления товарами и ключевые товарные метрики. Сэкономить время помог ИИ, с которым я работаю еще с выхода ChatGPT 3.5. Сегодня нейросети для меня — инструмент, который забирает на себя рутину и ускоряет обучение.

В поддержку Mindbox ежегодно поступает более 50 000 обращений. Чтобы справляться с таким потоком, требуется 16 специалистов поддержки. Они разбирают документацию, находят ответы и помогают клиентам.

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

Теперь бот закрывает 15–20% запросов и отвечает за 25 секунд. Нагрузка на команду поддержки снизилась, а удовлетворенность клиентов (CSAT) AI-помощником поддержки составила около 90%. В этой статье — кейс, как нам удалось сделать такого бота своими силами. 

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

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

На связи Святослав Сычев, инженерный менеджер, ответственный за результаты и развитие нескольких команд, разрабатывающих высоконагруженные системы в Mindbox.

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

• как радикальные решения могут улучшить ситуацию с техдолгом;

• почему термин «техническая задача» только мешает;

• как продавать бизнесу задачи, которые кажутся «чисто техническими»;

• почему выделять определённую часть  времени на техдолг — недостаточно;

• как ускорить отдачу техдолга за счёт усиления фокуса;

• как лиду перейти от ручного контроля к автономной работе команды.

Фреймворк STAR (Situation, Task, Action, Result) лет 20 применяют в найме: кандидаты с его помощью структурируют кейсы, чтобы наглядно показать свой опыт. Мы в Mindbox применили его в дизайне: научились анализировать пользовательские сценарии и проектировать интерфейсы.

Меня зовут Антон Черный, я лид продуктовой дизайн-драйвер команды. В этой статье я расскажу, как и для чего применять STAR в дизайне интерфейсов. А еще на реальных фейлах Mindbox покажу, что бывает, если игнорировать части этого подхода.

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

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

Далее >>>

Об авторе

Меня зовут Глеб Ковалев, я ведущий frontend-разработчик в Mindbox. Пару лет назад я начал проводить стажировки для frontend-разработчиков. А сейчас начинающих фронтов мы нанимаем преимущественно через стажировки. О том, как это происходит, расскажу в этой статье.

История, как в Mindbox выстраивали продуктовый подход: о неудачных запусках, поиске роли продакт-менеджера и испробованных за это время фреймворках. По докладу CPO Mindbox на Product Sense.

Всем привет, на связи Петр Никитин, frontend-разработчик Mindbox.

Mindbox — это платформа автоматизации маркетинга. Одна из задач, которую наши клиенты решают с помощью нее — запуск email-рассылок и сценариев. Чтобы облегчить им задачу и не заставлять маркетологов писать HTML-код, мы разработали конструктор рассылок: письмо собирается из готовых блоков, а содержание можно настраивать под свои задачи.

В этой статье я расскажу про процесс разработки конструктора, с какими вызовами мы сталкивались и как находили решения. Например, почему в какой-то момент мы решили, что нам тесно в рамках HTML и решили поменять способ разметки шаблонов, а для этого понадобился собственный язык на базе C# — Quokka Mindbox

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

Меня зовут Михаил Новиков, я архитектор в команде, которая развивает один из пользовательских сервисов. В статье расскажу, зачем мы за 5,5 недель внедрили хаос-тесты, что учли при их настройке и почему ломаем прод Mindbox. 

Привет, Хабр!

Меня зовут Тимур Маннапов, и я самый обычный senior-разработчик в Mindbox.

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

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

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

Чтобы ускорить сборку, разработали систему из шаблона и CLI утилиты. Теперь новый микрофронтенд со всей обвязкой создается за 20 минут. В статье — подробное решение для тех, кто захочет повторить.

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

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

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