Рассказываем, как переделали структуру базы знаний бота и генерируем ее автоматически с помощью AI. Внутри подробно описываем:

1. Почему решили прокачать базу знаний: бот закрывал только 18% обращений, ему не хватало «эрудиции».

2. Как изменилась структура: вместо сырых диалогов поддержки стали наполнять базу статьями и FAQ, которые создает нейросеть;

3. С какими проблемами столкнулись и как следим за качеством базы знаний.

4. Чего добились в итоге: бот закрывает 45% обращений и работает на второй линии поддержки, а база знаний служит источником информации о продукте для сотрудников компании.

На связи Дмитрий Рыбалка, SRE‑инженер Mindbox. В статье описываю стандартный инструмент для нагрузочного тестирования k6 в новом амплуа: как агента для мониторинга, который в ряде случаев работает лучше, чем привычные инструменты. 

В материале рассказываю, как настроить К6, что смотреть в итоговом отчете и как анализировать метрики. А еще делюсь реальными кейсами применения агента.

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

На связи Кирилл Козлов, 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 тысяч строк в минуту в одну таблицу. Поделюсь, как его преодолеть, не потратив годы на разработку и миллионы на новый сервер.