Как команде учиться вместе, когда все такие разные

Владислав Тушканов

Group Manager команды Machine Learning Technologу Research «Лаборатории Касперского»

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

Чтобы работа в команде была продуктивной, нужно найти для всех общий знаменатель с точки зрения знаний и постепенно расширять эту базу, чтобы лингвистам было проще общаться с ML-инженерами, а аналитикам с MLOpsa’ми. Причем хочется делать это так, чтобы всем в команде это было полезно и интересно. В статье я расскажу, как мы решали эту задачу.

Кейс 1: курс по машинному обучению

Началось все в 2020 году, когда я был единственным дата-сайентистом в одной команде. Ко мне часто обращались с вопросами про машинное обучение. Наши разработчики (крутые специалисты по C++, C# и веб-разработке на Python) спрашивали меня время от времени о том, как работают нейросети и чем они отличаются от других алгоритмов.

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

В качестве материала мы взяли уже готовый курс — Practical Deep Learning for Coders от fast.ai. Казалось бы, то, что нужно — практический курс с необходимым количеством теории, специально нацеленный на разработчиков. В качестве формата выбрали так называемый «перевернутый класс»: когда готовые лекции смотрите в своем темпе и встречаетесь на семинарские занятия, где разбираете сложные части уроков, обсуждаете интересные моменты, а семинарист (то есть я) отвечает на вопросы.

В команде у нас в основном были люди, которые пишут на C++ и C#. На первом семинаре все в первую очередь обсуждали, как питонисты живут без типов и насколько изящно (или не очень) переопределен оператор деления в pathlib. В чате, где мы все координировались, перед вторым семинаром не появилось ни одного вопроса — а если нет вопросов, то и встречаться незачем. Не уверен, смотрел ли кто-то вообще третью лекцию. После нее (напомню, это был 2020 год) начался карантин и наши очные встречи закончились.

Зачем и как учиться на работе?

Для чего вообще профессионалы учатся на работе? В первую очередь, чтобы получать новые знания. Это нужно и чтобы решать задачи, в которых не хватает компетенций, и чтобы находить новые подходы к старым кейсам: например, если раньше мы деплоили сервисы на виртуалках, а теперь будем делать то же самое, но в Docker-контейнерах на кластере Kubernetes. Кроме того, люди могут учиться просто потому, что им это нравится, а компания это поощряет, или потому что у них синдром самозванца и они не чувствуют себя спокойно, если не изучили за этот месяц ни одной новой технологии.

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

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

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

Совместным обучением можно достичь и иных целей. Это может быть и тимбилдинг, когда все в одно время собираются и вместе читают статьи (возможно, с пиццей). Или ощущение, что мы работаем в R&D и занимаемся чем-то наукоемким — вместе изучаем что-то новое, находясь на острие знаний. В процессе мы также погружаемся в проекты друг друга и обмениваемся нашей уникальной экспертизой. Наконец, можно развивать культуру дискуссии: обсуждение статей, например, позволяет более безопасно обдумывать и критиковать идеи, чем когда речь заходит о коде коллег.

Но кросс-функциональность команды накладывает определенные требования к выстраиванию совместного обучения. Представьте команду исследователей, которая занимается компьютерным зрением, допустим, улучшением алгоритмов распознавания лиц. Для них таким совместным форматом может стать чтение статей c state-of-the-art в той теме, которая им интересна. Например, чем YOLOv8 отличается от предыдущего или додумался ли кто-то приделать модные диффузии к распознаванию лиц.

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

• NLP-исследователь. Ему может быть не очень интересно разбираться в Kubernetes и слушать про лучшие практики в Docker.
• Data Scientist, который больше общается с бизнесом и занимается поддержкой цикла проекта. От одного словосочетания «гиперболические эмбеддинги» (обсудить которые до появления мощных языковых моделей любили NLP’шники) его начинает клонить в сон.
• MLOps, на плечах которого ML-инфраструктура. Слушать про бизнес-темы, в частности, про то, что такое AI Canvas и как он помогает в разработке проекта, ему не очень интересно.

Очевидно, что собрать их в одной комнате, чтобы вместе узнать что-то новое и помочь начать говорить на одном языке, не так просто.

Почему онлайн-курс не удался?

Вернемся к разбору первого кейса и ответим на вопрос: почему не получилось?

На самом деле, главная ошибка — неверно поставленная цель. Я увлекался нейросетями, для меня цель была — поделиться со всеми знаниями. Но какая была цель для команды? Узнать побольше про новую технологию — звучит здорово, но недостаточно мотивирующе. Особенно когда твоя основная работа — писать высокопроизводительный низкоуровневый код.

Кроме того, был выбран неподходящий формат. Лекции длительностью под два часа (пусть на них и было выделено время) легко оставить на последний момент, тогда обязательно появляется срочная рабочая задача или незапланированная встреча. Кроме того, если человек, профессионал с отличным фундаментальным образованием, заранее посмотрел вводную лекцию по новому предмету, зачем ему ждать неделю семинара, если он вполне может сам разобраться?

Кейс 2: исследовательский семинар

В одной из наших ML-команд есть традиция исследовательских семинаров, зародившаяся еще в 2012 году. Коллеги собираются вместе, выводят формулы, читают достаточно насыщенные статьи, например, вот такие:

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

Когда появилась наша (тогда еще отдельная) ML-команда, мы подумали, что неплохо бы присоединиться к этому формату и посмотреть, что получится. К сожалению, люди вызывались рассказывать про статьи редко, а те, кто вызывался, часто не успевали подготовить материал, и семинары постоянно переносились, что немного расстраивало коллег из первой команды.

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

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

Мы снова задались вопросом, почему все сломалось. Для первой команды, которая проводила семинары с 2012 года, как мне кажется, основная цель — это тимбилдинг: собраться вместе, повыводить формулы, почувствовать, что команда занимается фундаментальной наукой и находится на острие темы искусственного интеллекта. Мы будто ожидали закрытия какой-то другой потребности (конкретные применимые знания), что плохо сказывалось на мотивации.

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

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

Кейс 3: книжный клуб

Иногда все может пойти не так с самого начала. Например, однажды сотрудница предложила устроить книжный клуб. Идея такая: выбираем книжку (пускай, с кабанчиком), берем по главе раз в две недели, читаем и очно или онлайн обсуждаем. Мы создали в корпоративной вики страницу, начали выбирать книгу… В итоге на этом пункте мы застряли, и встреча книжного клуба так и не состоялась.

Почему?

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

Кейс 4: Friday Wins&Fails

Еще одна коллега пришла с идеей рассказывать про проекты с точки зрения бизнеса. Называлось это Friday Wins&Fails. Идея была такая: раз в несколько недель кто-то вызывается и проводит в пятницу небольшую презентацию об удачном или неудачном опыте. В этот раз цель была понятная — показать, что даже исследовательские проекты не существуют в вакууме, а имеют заказчиков, метрики успеха и необходимость об этом думать.

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

Основные ошибки

Я рассмотрел четыре неудачных кейса. В чем же были ошибки:

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

Кейс 5: снова онлайн-курс

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

Мы декомпозировали задачу на две части:

• найти такой контент, который будет относительно релевантен всем, то есть все смогут из него почерпнуть что-то интересное;
• сделать все хорошо с точки зрения формата и организации.

Начали с целеполагания.

Чем мы занимаемся? Берем задачу, анализируем данные, создаем ML-систему и поставляем клиенту. Человек, который общается с заказчиком, занимается статистикой и анализирует метрики, должен взаимодействовать с тем, кто непосредственно обучает модель. А тому, кто ее разрабатывает и выбирает подходы, нужно взаимодействовать с MLOps’ом, который это выкатывает и обеспечивает мониторинг метрик, который должен быть удобен первому человеку. То есть нам нужно надежно делать весь цикл и говорить друг с другом на одном языке.

Исходя из цели «говорить на одном языке» мы и выбирали материалы. В итоге сошлись на бесплатном курсе Full Stack Deep Learning. Он посвящен тому, как на практике вести ML-проекты от поиска идеи до мониторинга, а также используемым для этого инструментам.

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

В качестве формата снова выбрали перевернутый класс, но на каждый семинар выбирался ответственный, который кратко (на 20 минут) подсвечивал основные моменты в лекции через призму тех задач, с которыми встречаемся мы. Расписание и список рассказчиков с темами были заранее зафиксированы в вики. После рассказа каждый по очереди должен был за 2-5 минут поделиться своими соображениями о материале. Обсуждения вместе с идеями, что где можно попробовать или сделать лучше, и соответствующими action items фиксировались на отдельной странице.

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

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

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

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

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

Подводя итоги

Можно вывести ингредиенты успеха для совместного обучения в команде:

• Целеполагание. Нужно понять, чего вы хотите добиться, организуя совместное обучение. Мало поставить цель, важно еще и донести ее до команды и убедиться, что она ее приняла. Без этого едва ли получится достичь нужного уровня мотивации и вовлеченности.
• Формат. Важно продумать формат с учетом факторов гибридной или удаленной работы, других регулярных задач и прочих возможных ожидаемых и неожиданных проблем вроде потенциальной загруженности.
• Администрирование. Даже самой классной и ответственной команде иногда нужен волшебный пинок, который заставит их все-таки прочитать материал и посмотреть семинар. В самом мягком варианте — заранее назначенные ответственные и встреча в календаре.
• Ритм. Очень важно, чтобы встречи происходили с заранее обговоренной периодичностью, чтобы поддерживать привычку и не терять мотивацию.
• Релевантность. Материал должен быть релевантен рабочим задачам, которые выполняют участники. Если им кажется, что это не так (а вы уверены, что материал полезный), их нужно в этом убедить.
• Планирование. Лучше все шаги, встречи и даже сбор фидбэка продумать заранее. Если начать с мыслью, что «как-нибудь разберемся», любые потенциальные проблемы могут выбить из ритма.

Мы продолжаем совершенствовать процессы обучения и развития нашей команды, придумывать новые форматы и всячески экспериментировать. Если вам хочется взяться за такие эксперименты или у вас уже есть целый чемодан рабочих практик, приходите работать к нам в «Лабораторию Касперского». Мы нанимаем тимлидов и руководителей более высокого уровня и рады тем, кто готов руководить кроссфункциональными командами.