Привет, Хабр! Меня зовут Василий Сизов. По образованию я инженер-конструктор, а сейчас работаю тимлидом в ВТБ и занимаюсь машинным обучением в CRM и проектами с LLM.
В какой-то момент мне доверили кросс-функциональную команду — и тут пришлось разбираться не только в моделях, но и в процессах, которые обеспечивают их жизнеспособность. В этой статье расскажу, как мы пересобрали эти процессы и сократили Time to Market на 20%. Возможно, вы узнаете в этих историях свои задачи и вызовы – и найдете идеи, которые помогут их решить.
Если вам ближе видеоформат — с этой темой я выступал на Data Fest 2025.
Кейс 1. «Что тут вообще происходит?» Разбираемся в процессах
Когда я стал тимлидом, к нашей Data Science-команде присоединились инженеры данных и MLOps-специалисты. Команда выросла, а прозрачность – наоборот, упала. Я хорошо понимал DS-логику, но хуже ориентировался в проде и витринах. Поэтому первым шагом решил навести порядок и буквально разложить все по шагам.
Я опросил участников процесса, зафиксировал последовательность действий и описал каждый этап по единому шаблону:
Название — чтобы говорить на одном языке;
Цель — чтобы отсечь лишние процессы, живущие «по инерции»;
Вход и выход — чтобы понимать, что происходит до и после шага;
Роли и инструменты;
Инструкция — как именно выполняется шаг;
Требования и критерии — например, к коду или документации.
Совет из практики: нумеруйте шаги не 1, 2, 3, а 10, 20, 30. Если появится новый шаг, не придется все перенумеровывать — мелочь, а спасает.
Параллельно мы завели базу знаний с ответственным за ее актуальность.
Результат оказался заметным: команда наконец начала говорить на одном языке, onboarding новых коллег стал быстрее и спокойнее, а Time to Market сократился примерно на 20%.
Кейс 2. «Когда всё ломается». Чиним процессы, а не избегаем проблему
Когда процессы наконец описаны, кажется, что все должно работать как часы. Но формальные схемы не спасают от реальности — сбои все равно случаются.
Вот три истории, где мы столкнулись с неожиданными проблемами и научились чинить процессы, а не просто затыкать дыры.
2.1. Спиллы в Spark
Иногда проблема выглядит сложной, но решается одной строчкой запроса.
Однажды пайплайны начали работать заметно медленнее. Мы заподозрили спиллы — ситуации, когда Spark выгружает данные из памяти на диск, чтобы освободить ресурсы.
Посчитать их быстро мы не могли: в нашей среде не было доступа к Spark API. Решение оказалось простым — запросили доступ через стандартную процедуру. Получили, проверили, зафиксировали.
Скорость вернулась, нервы сэкономили.
Вывод: иногда все решается обычным «попросили — сделали».
2.2. Документация
Казалось бы, базовая задача — оформить документ. На деле на нее уходило слишком много времени.
Разработчик писал в одном формате, аналитик переписывал в другом, после чего документ снова уходил на доработку. Цепочка без добавленной ценности.
Проблема оказалась банальной — у всех был свой шаблон. Мы заранее утвердили итоговую структуру, договорились о формате и закрепили его в базе знаний.
Вывод: стандартизация экономит время и убирает лишние согласования.
2.3. Code-review
Формально ревью было, но по сути — имитация: комментарии редкие, ошибки не ловятся, кодовая база становится все менее надежной.
Мы настроили нормальный git flow с ревью через pull request’ы.
После этого ревью стало живым этапом работы, а не пунктом чек-листа. Повысилось качество кода, и наш подход позже масштабировали на другие команды.
Вывод: ревью должно быть процессом, а не ритуалом.
Кейс 3. «Развитие в рутине». Как мы воспользовались паузой, чтобы прокачать команду
С заказчиком в CRM мы работали уже три года. Модели были готовы: оттоки, прогнозы, look-alike — всё функционировало стабильно, библиотека моделирования использовалась всей командой.
Задач стало меньше, проекты вошли в фазу сопровождения, и наступила привычная рутина.
Обычно в таких ситуациях команда просто поддерживает существующее, но мы решили использовать паузу как возможность обновить инфраструктуру.
Первое, что бросалось в глаза — большинство скриптов для обучения и применения моделей лежали рядом с ноутбуками. В проде же код выглядел иначе. Значит, пора унифицировать.
Что сделали:
попросили коллег из backend-команды провести ревью библиотеки и подсветить проблемные места;
начали системно разбирать базу: логирование, типизацию, структуру кода — каждую неделю обсуждали по одному блоку;
переписали стандартные скрипты и саму библиотеку, избавившись от костылей и условных конструкций вида if CatBoost, if XGBoost.
Результат:
вместо ноутбуков — понятные, типизированные, логированные скрипты, которые легко разворачиваются и поддерживаются;
библиотека стала модульной: добавление новых фичей теперь не требует обходных путей;
T2M сократился, а добавление нового функционала ускорилось примерно в три раза.
Рутина оказалась не тормозом, а точкой роста. Когда оперативных задач становится меньше, появляется время заняться качеством — и это инвестиция, которая потом возвращается ускорением на каждом релизе.
Что я понял
Даже небольшое изменение процесса может дать результат, который раньше пытались добиться месяцами тюнинга моделей.
Рутину не стоит бояться — она дает время подумать, как сделать систему устойчивее.
Формализованные процессы, прозрачные роли и единая база знаний освобождают энергию команды для реальной работы, а не бесконечных уточнений.
ML — это не только про алгоритмы. Это про то, как команда взаимодействует, как принимает решения и как учится на ошибках.
Иногда «починить» процессы — значит сделать шаг к лучшим моделям, более спокойной работе и большему удовольствию от того, что ты делаешь.
Также оставлю ссылку на Telegram-канал DS-сообщества ВТБ.
Спасибо!