Data Science — настолько широкая область, что в разных компаниях свои представления о том, что должен уметь дата-саентист. Но это всегда что-то на стыке программирования и исследований. В зависимости от компании/проектов/команды дата-саентист может быть и ресерчером, и инженером, и ML-Оps и ещё много кем. У всех этих ролей разный круг задач. Где-то меньше нужны навыки разработки и больше математический аппарат, где-то наоборот. Но всё-таки умение писать хороший код стало ключевым навыком, без которого не обойтись ни одному супергерою DS. Поэтому давайте смотреть, как дата-саентисту развивать свои навыки, при чём здесь команда и лид, и как всё это подружить с коммерческой и продуктовой разработкой.

Привет, Хабр! Меня зовут Вика Верезубова, в X5 Digital я руковожу группой машинного обучения. Сейчас у нас есть два основных направления — языковые модели и компьютерное зрение.

Я закончила бакалавриат и магистратуру ФКН НИУ ВШЭ по прикладной математике и информатике, анализу данных в биологии и медицине. Начала с системной и бизнес-аналитики, но быстро поняла, что это не моё. Хотелось больше соприкасаться с математикой и разработкой. А DS лучше всего отвечал этому запросу. Сначала я делала простые проекты в CV направлении. Потом занялась коммерческими проектами с компьютерным зрением. Прошла путь от джуна до лида команды DS в X5 Digital.

Но до того как стать лидом, я была разработчиком и подмечала вещи, которых мне не хватало в команде, чтобы расти как специалисту. Например, отсутствие чёткой системы оценки/ревью. Из-за отсутствия обратной связи было сложно понять собственные перспективы роста. Ведь не всегда получается самому определить, какие скиллы и как развивать, особенно на начальном этапе карьеры. Поэтому направление развития складывалось интуитивно, методом проб и ошибок. Где-то хотелось больше обмена опытом с коллегами, обсуждения тем, которые связаны не только с проектами. Например, свежих новостей отрасли или публикаций по DS.

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

Базовые знания

В DS, по сравнению, например, с бэкенд или фронтенд-разработкой, довольно высокий порог вхождения. Нужно качать и разработку, и ресёрч, и математику, вне зависимости от выбора направления или пути развития. В любом случае придётся овладеть и математической базой, и базовыми навыками разработки. 

Сейчас основном языком программирования DS является Python, но всё меняется. Через год стек уже может быть другим. DS динамически растёт и развивается. Поэтому, чтобы быть в теме новых разработок, нужен математический аппарат. По-другому успевать за ростом, разбирать статьи и понимать, как, что и почему работает, будет очень сложно. В то же время одной математической базы тоже недостаточно, потому что все наработки и модели важно доводить до понятного решения, которое можно встроить на тот же сайт или в приложение. А для этого необходимы навыки разработчика.

Работа дата-саентиста похожа на роль супергероя. Нужно всегда быть чуть-чуть «круче» всех. Быть немного программистом, немного исследователем и обязательно математиком.

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

Эта область сама по себе про гибкость и умение адаптироваться к контексту. Приходится качать все навыки параллельно. А помимо хард-скиллов не забывать про софты, ведь дата-саентисту также надо донести свои идеи и пользу от различных экспериментов до коллег и заказчиков.

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

На одном из проектов стояла задача по построению оптимальной стратегии для проведения геологоразведочных работ, которая оптимизирует заданную целевую функцию. Решение на основе классических подходов не давало нужных результатов. А я, незадолго до этого, как раз натыкалась на статьи о методах Reinforcement Learning. Одну из них даже помню — «Теоретический анализ глубокого Q-обучения». 

Раньше я с RL на практике никогда не сталкивалась, но возможность экспериментировать была, поэтому я решила попробовать применить эти методы для поставленной задачи. Чтобы найти применимость Reinforcement Learning, пришлось разбираться в её тонкостях и перекладывать на свой проект. Тут и пригодились теоретические знания. Я потратила приличное количество времени, но результат стоил того. Удалось получить решение, которое по скорости превышало решение на основе классических подходов примерно в 2.5 раза.

Наверное, тогда я впервые осознала, как важно держать руку на пульсе и изучать смежные темы. Если работаешь с компьютерным зрением, то всё равно интересоваться классическим ML или языковыми моделями, и наоборот. А ещё лучше прокачивать все аспекты не только самостоятельно, но и в команде, чтобы все находились в одном информационном поле. Тогда многие процессы не требуют дополнительного объяснения, а сэкономленное время можно использовать для исследований и разработки.

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

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

• Опыт развития себя как специалиста, опыт развития членов команды как специалистов и опыт развития команды как единого, слаженного, эффективного механизма.

Я вывела для себя ряд подходов, которые применяю в команде (для меня это как база), чтобы развиваться самостоятельно и помогать развиваться сотрудникам (то, чего мне самой не хватало в начале карьеры):

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

• не пренебрегать семинарами/разборами статей, даже если кажется, что на это нет времени;

• использовать матрицу компетенций для составления плана развития.

Это действительно помогает добиваться результатов. И, конечно, должно работать не только в DS, но и в других направлениях. Но я могу поделиться только своим опытом, поэтому расскажу про их применение в команде дата-саентистов.

Особенности управления командой DS

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

Второй ключевой навык для тимлида команды DS — раскладывать задачу на составляющие и этапы, перекладывать всё это на язык математики, а также уметь отсеивать нереализуемые задачи. Например, такие, как 100% в генерации чего-нибудь.

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

Проблемы возникают тогда, когда у вас нет сотрудника с нужным опытом, а задача есть.

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

Матрица компетенций

Преимущественно задачи в команде распределяются в соответствие с сильными сторонами её участников. Если лид знает, что Бэтмен может сделать нужную задачу быстро, потому что уже неоднократно такие задачи выполнял, то задача, как правило, назначается ему. Но если так делать всегда, остальные члены команды не будут осваивать новые навыки и развиваться. Поэтому, когда позволяют сроки выполнения проекта, эту же задачу можно дать тому, у кого меньше опыта. Предположим, Робину. Робину возможность роста просто необходима. К тому же, Бэтмен может заболеть, уволиться или уйти в отпуск. И тогда срочную задачу просто некому будет выполнять. На такие случаи и нужно готовить Робинов.

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

Для того, чтобы использовать матрицу компетенций, нужно:

1. Определить ключевые компетенции

   • Отталкиваемся от навыков, которые критически важны именно для вашей команды.

   • Навыки можно разделить на несколько категорий (и в каждой категории выделить несколько пунктов):

     • Хард-скиллы: Python, обработка данных, ML-Ops, алгоритмы и т. д. (выделить и добавить нужное).

     • Исследования: математика, статистика, ресёрч, чтение статей, разбор новых подходов.

     • Софт-скиллы: коммуникация, презентация идей, коммуникация в команде, коммуникация с заказчиком.

     • Проектные: управление задачами, написание документации, планирование.

2. Оценить текущий уровень компетенций и сформировать матрицу

   • Проведение встреч 1-1 с каждым участником команды для самооценки и обсуждения сильных сторон и зон роста.

   • Использование примеров выполненных задач для объективной оценки уровня.

   • Внесение оценок в матрицу, чтобы получить общую картину навыков команды.

   • Анализ полученных результатов.

   Например, у Супермена сильные стороны — статистика и презентации, но есть пробелы в ML-Ops. А у Бэтмена хорошо развито взаимодействие с заказчиками, но не хватает навыков ресёрча.

3. Разработать план улучшения навыков

   • Для каждого сотрудника составляется индивидуальный план на основе оценки сильных и слабых сторон:

     • Если у сотрудника слабый ресёрч, его можно подключить к регулярному разбору статей. Например, предложить ему подготовить презентацию новой модели.

     • Если кому-то нужно подтянуть навыки разработки, можно дать задачи на оптимизацию моделей или написание модуля/пайплайна.

   • Пример задач для прокачки:

     • Ресёрч: чтение статей, написание обзоров, выступление на внутренних семинарах.

     • Софт-скиллы: внутренние встречи и встречи с заказчиками.

4. Обратная связь и обновление матрицы

   • Регулярные ревью (раз в 3-6 месяцев), чтобы пересматривать матрицу компетенций:

     • Оценивать прогресс сотрудников.

     • Добавлять новые навыки, которые стали важными для команды.

Это помогает не только отслеживать развитие, но и мотивировать команду.

Коммерческая разработка VS команда — как подружиться? 

Конечно, при внедрении любых подходов не стоит забывать о среде. Вводные везде разные. Условия работы в коммерческой и продуктовой разработке влияют на методику управления командой.

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

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

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

Этот кейс подтвердил, что разбирать новые статьи, методики и модели, которые заранее готовят команду к возможным задачам – правда важно. Даже если в моменте кажется, что они не пригодятся.

А ещё это помогает сказать «НЕТ». Ведь при разработке коммерческих проектов в процессе у заказчика, не погружённого в техническую часть, могут возникать какие-то пожелания к решению, не всегда адекватные с точки зрения объёмов реализации и поставленных сроков. И для того, чтобы аргументированно донести то, что такую «хотелку» никак не получится реализовать, нужно уметь преподносить информацию так, чтобы человек, не разбирающийся в теме, всё понял. 

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

Мне, как лиду, это сильно помогло. Возрастающие навыки ребят из команды позволяют делегировать им рассказ о технических деталях проекта заказчику. Так они развивают софт-скиллы, получают более глубокое понимание проекта, а у меня освобождается время на новые задачи. Всем польза! Хотя, конечно, не стоит забывать о подстраховке на начальных этапах.

Продуктовая разработка и всё о ней

В продуктовой разработке важную роль играет не только проверка гипотез, но и доведение продукта до состояния стабильной и правильно функционирующей системы. Это включает в себя улучшение ключевых метрик, проведение множества тестов, масштабирование и постоянное развитие продукта. Однако такая специфика часто приводит к рутине, перегрузке и, как следствие, выгоранию команды. А с этим надо бороться. Поэтому, когда я столкнулась с подобными трудностями (выгорание сотрудников на таких проектах), то постепенно пришла к практике регулярной смены задач или ротации. 

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

Такой подход помогает команде оставаться мотивированной. Например, один из членов команды, который долгое время занимался оптимизацией метрик модели для задачи детекции, зашёл в тупик. И физический, и моральный: все классические CV-подходы для повышения метрик качества не давали целевых показателей. На одной из наших 1-1 встреч он поделился, что задача стала напоминать ему замкнутый круг, каждая новая неудачная попытка демотивировала. Поэтому мы решили, что единственный выход из сложившейся ситуации — на время переключиться на ресёрч для новой задачи. Эффект понравился всем! Буквально через спринт он пришёл со свежим взглядом, мотивацией добить ту задачу, которая ещё недавно напоминала замкнутый круг. У него, наконец, получилось подобрать нужную комбинацию подходов, которая дала нужный результат.

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

Как управлять DS-командой и не сойти с ума

Как я уже говорила – супергероями быть непросто. Нагрузка огромная, остановиться просто невозможно – нужно постоянно расти и развиваться. Прежние методы быстро устаревают и не дают результатов, поэтому приходится постоянно искать новые способы прокачки. Учиться, экспериментировать и двигаться только вперёд. Всё по классике, как во всех историях про супергероев.

Наверняка есть и другие классные подходы и методы, но лучше всего мне помогают практики, описанные выше. Разбор статей – позволяет оставаться в теме, а членам команды лучше узнавать друг друга, учиться коммуницировать и совместно решать задачи. Система ротации и делегирования – даёт возможность поменять вид деятельности, передохнуть и посмотреть на рабочие процессы со стороны. Матрица компетенций – позволяет отмечать сильные и слабые стороны и составлять понятный план действий для достижения целей команды.

А для того, чтобы всё работало, нужно создавать условия для поддержания этих процессов. Например, создание прозрачной коммуникации – это база. Когда каждый участник команды может легко выразить свои мысли, задать вопросы, озвучить проблемы – работа становится продуктивнее. Суперсила вашей команды – это доверие. Именно так можно решать самые трудные задачи без выгорания. А мне, как лиду, поддерживать такую атмосферу помогает «переключение» от работы для поиска вдохновения: на хобби, путешествия и т. д. 

Также важно помнить и о целеполагании: постановка понятных и достижимых целей помогает команде двигаться в правильном направлении, минимизирует путаницу и облегчает жизнь лиду. Чем меньше стресса и перегрузок в команде, тем проще с ней работать. Иногда даже для самого себя не очевидно, какой вклад ты вносишь. Поэтому надо отмечать даже небольшие успехи, как свои, так и участников команды. А ещё важно напоминать себе, что не все задачи могут быть выполнены сразу и идеально. Команда должна понимать, что ошибки — это не катастрофа, а возможность для роста и совершенствования.

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