Кадры или, если брать шире, люди по-прежнему решают все, и сфера Machine Learning — не исключение. Но подбор специалистов, поддержание работоспособности команды, отношения с заказчиками — все в этой области имеет определенную специфику.
Как проводить собеседования, что общего между сеньорами и ворами в законе, зачем тимлиду быть еще и психологом, наконец, какие magic tools облегчают жизнь команде? Обо всем этом нам рассказал senior-разработчик и DL-инженер Роман Тезиков, который собаку съел в работе с людьми на ML-проектах. Передаем ему слово.
Как проводить собеседования для ML-проектов: гномики ни к чему
Как правило, сначала собеседуют нас, а потом — мы, когда становимся начальниками. В хайринге персонала тимлидам и старшим разработчикам полезно вспомнить свой опыт и ощущения в кресле кандидата. Так проще выстроить диалог, который поможет человеку по-настоящему раскрыться.
Например, я терпеть не мог решать популярные сегодня «задачи про гномиков». В стрессовой ситуации (а даже удачное собеседование — стресс) они могут ввести в ступор даже самых талантливых и сообразительных разрабов. Вместо этого, например, при найме джуна я стараюсь начинать с совсем базовых вопросов о метриках, ROC AUC, валидации временных рядов и т. д. Если с теоретической базой все в порядке, то неплохо бы поставить соискателя в какую-нибудь характерную рабочую ситуацию, пусть и в несколько упрощенном виде.
Допустим, команда трудится над ML-решением для модного магазина, и нужно реализовать по картинке получение разных атрибутов одежды (цвет, принты, вырезы шеи и т. д.). По каждому из них налицо дисбаланс: в цветах доминирует сначала черный, потом белый и еще какой-нибудь, в вырезах — явный перекос в сторону круглых или, напротив, V-образных и т. д. Вопрос: как правильно составить метрики, и можно ли их свести в одну?
Пусть кандидат и не даст четкого рецепта или даже где-то ошибется, зато покажет логику своих рассуждений. Многие подходят к проблеме творчески, предлагают несколько альтернативных вариантов решения, что говорит в их пользу. Задача специалиста в рамках собеседования — направлять беседу, постоянно задавать наводящие вопросы, «подкидывать» дополнительные вводные. Хорошо, если образ мысли соискателя импонирует тому, кто проводит собеседование, и совпадает с видением будущей команды.
По моему опыту, описанный прием одинаково эффективен при найме специалистов любой квалификации. Только сложность и нетривиальность поставленной задачи повышается в зависимости от того, подбирается джун, мидл или сеньор.
Кстати, логика размышлений при ответе обычно сильно различается. Джуны часто цепляются за какие-то заученные факты, обкатанные методики и пытаются «эталонно» применить их в предложенной ситуации. Сеньоры нередко вспоминают похожие кейсы из своей предыдущей практики и ищут решения по аналогии. Либо сразу обрушиваются на тимлида с кулаками с кучей уточнений, например, каковы бизнес-цели проекта, кто основной заказчик и т. д. Ведь от подобных нюансов зависит дальнейший вектор работы.
При подборе специалистов мидл+ важно понимать, что обсудить все вопросы и оценить каждый навык не удастся — нужно сконцентрироваться на основном. В противном случае собеседование растянется до «студенческой сессии». И вообще про старших разработчиков есть шутка, что они как воры в законе: стать сеньором можно только тогда, когда тебя признают таковым другие сеньоры. Задача тимлида при первом знакомстве — увидеть в человеке потенциал к этому.
Другую часть собеседования оптимально посвятить софт-скилам. Как кандидат обучается и повышает квалификацию, организует свое время и применяет ли инструменты тайм-менеджмента. Касательно мидла или сеньора есть еще один существенный момент: может ли он вести команду и организовывать рабочие процессы, имеется ли у него такой опыт.
Отдельного внимания заслуживает поведение специалиста в конфликтных ситуациях. Как хотя бы в теории планирует действовать кандидат: сразу пойдет жаловаться тимлиду, попытается сначала сгладить углы в беседе с оппонентом или же «упрется рогом», если уверен в своей правоте? Конечно, все зависит от конкретной ситуации, да и не факт, что соискатель будет до конца откровенен на собеседовании. Здесь важна, опять же, логика его рассуждений и сама реакция на поставленный вопрос.
Как поддерживать здоровье команды при реализации ML-проектов
Хайринг хайрингом, но подобрать специалистов — только первый шаг. Команду требуется постоянно поддерживать в боеспособном состоянии. Не перегружены ли разрабы, всем ли комфортно взаимодействовать друг с другом и нет ли трений? Здесь тимлид выступает не только как руководитель и организатор, но и как психолог или даже полноценный процессный доктор. Недаром так много внимания в ML-сфере и не только сегодня уделяется здоровью команды.
Профилактика лучше лечения
Как бы избито ни звучала эта медицинская поговорка, она абсолютно правомочна, в том числе, в управлении командами ML-проектов. Чтобы на запускать проблемы и «резать, не дожидаясь перитонитов», тимлид должен постоянно общаться с коллегами. Нужны регулярные встречи и созвоны (форматов коснемся чуть позже), на которых любой специалист способен поделиться своими болями. В итоге получится не только разобраться в каждом отдельном случае, но и вскрыть системные камни преткновения.
Например, разрабы постоянно жалуются, что перегружены работой с какими-то data-pipeline. Ими приходится заниматься чаще, чем обрабатывать данные или запускать нейронку. Вероятно, если позволяет ситуация, стоит на какое-то время отложить другие дела и всей командой навалиться на разбор данных, чтобы написать удобоваримые пайплайны, положить их на сервер и потом воспроизводить одним кликом.
Или же выясняется, что команда в принципе не может воспроизвести ни один проведенный эксперимент. Никаких настроенных пайплайнов, автоматизации сбора и препроцессинга данных, обучения модели, валидации попросту нет. Все выполняется ручным исправлением каких-то конфигурационных файлов. Так почему бы не внедрить специализированные фреймворки для управления версиями и трекинга экспериментов (DVC и ClearML), которые значительно облегчат жизнь? Они помогут версионировать датасеты, сравнивать метрики, настраивать гиперпараметры, обучать модели в DAG-структуре, находить нужные эксперименты и т. д.
Словом, можно вскрыть и устранить любую сложность, если уметь вести диалог с командой, а без открытой коммуникации многие попросту отмалчиваются, тихо ненавидят свою работу и в конечном итоге выгорают.
Методы работы с командой: конструктив и безопасная среда вместо анонимного «переливания помоев»
Как же тимлиду добиться доверительных отношений с командой? Никакой Америки здесь уже не открыть: эффективные способы давно придуманы и обкатаны. Вот только, по моему опыту, они почему-то применяются далеко не всегда.
Перечислять все возможные форматы командной коммуникации, такие как базовые групповые созвоны и прочие, не стану. Выделю лишь два из них: самый действенный и тот, что нужно применять с осторожностью. Сразу оговорюсь: это мое субъективное мнение. Если не согласны, не стесняйтесь — делитесь мыслями в комментариях.
one-to-one
Итак, начнем с регулярных one-to-one встреч. В моей практике как разработчика такие мероприятия устраивались практически везде. Встав по другую сторону баррикад, я тоже начал проводить one-to-one с сотрудниками.
При отсутствии трений между специалистом и тимлидом подобные беседы оказываются безопасной средой, где можно откровенно обсудить любые проблемы. В итоге оne-to-one повышают уровень доверия сотрудника к руководителю, если, конечно, видно реальное решение обсуждаемых вопросов.
Кто-то возразит, что практически в любой команде и так регулярно проводятся групповые совещания. В компактных командах этого вполне достаточно: какой смысл по отдельности мучить «полтора землекопа» разговорами по душам?
Общие созвоны — и вправду первое командообразующее мероприятие, которое стоит внедрить уже на старте. Однако там основное внимание уделяется процессам и глобальным проблемам, касающимся всех. Каждый член команды в лучшем случае успеет кратко упомянуть какие-то свои «боли» в общем контексте, иначе совещание превратится в бесконечный сеанс групповой терапии. Да и не каждый готов делиться наболевшим сразу со всеми коллегами — многим комфортнее пообщаться тет-а-тет с тимлидом. Последнему проще найти подход к собеседнику именно в приватной беседе: разговорить, успокоить, дать понять, что нет цели его осудить или наказать из-за возникших трудностей.
Оценка 360 градусов
Теперь перейдем к чуть менее популярному, но тоже довольно распространенному инструменту — обратной связи «360 градусов».
Такое массовое анкетирование может дать ценные сведения о здоровье команды и взаимодействии между ее участниками. При этом на сбор информации не придется тратить много времени. Когда у тебя, скажем, несколько десятков человек в команде, один на один со всеми не наговоришься.
Однако иногда есть риск получить скорее негативный эффект. Особенно это актуально, опять же, для небольших и статичных групп разработки. Если несколько человек постоянно трудятся плечом к плечу, с одной стороны, они лучше «притираются» друг к другу, с другой — во взаимоотношениях нет-нет, да и запахнет токсинами. Анонимность же обратной связи «360 градусов» может спровоцировать отдельных людей просто вывалить в анкету накопившийся негатив и претензии вместо объективного фидбэка. Порой в каких-то спорных ситуациях виноват сам респондент, а достается все равно оцениваемому сотруднику.
К слову, если испытываешь затруднения при общении с коллегой –— считаешь его подходы неправильными или просто не можешь найти общий язык — такую тему вполне можно обсудить в формате one-to-one. Главное, сохранять конструктив и не сбиваться на обиды и «переливание помоев».
Другой недостаток обратной связи «360 градусов» в том, что собирать ее часто не получится (обычно это делается раз в квартал). Тимлид же должен постоянно держать руку на пульсе здоровья своей команды.
Разумеется, вышесказанное не значит, что такой инструмент не бывает полезным. Нужно лишь понять, насколько он уместен и как его правильно использовать. Во-первых, наибольшую эффективность обратная связь «360 градусов» обычно показывает в корпорациях с большим штатом специалистов и динамичными составами команд. Тогда между людьми не успевает накопиться много противоречий, а значит в анкетах пониженный градус токсичности. Правда, следует все же убедиться, что опрашиваются коллеги, которые хотя бы периодически взаимодействуют с сотрудником, а не только здороваются с ним в коридоре. Другая предпосылка к применению такого инструмента — обширная территориально распределенная структура компании: HR-подразделению и руководству проще отслеживать отношения в командах в разных филиалах.
Во-вторых, не следует делать основную ставку на подобное анонимное анкетирование. Первым делом стоит внедрить общие командные созвоны, затем — поставить на поток регулярные one-to-one со специалистами. Лишь после имеет смысл задумываться об опросниках, как о вспомогательном источнике информации.
Как взаимодействовать с заказчиками в ходе ML-проектов или Никаких разговоров глухих со слепыми
Если внутри команды тимлид все же имеет определенные рычаги воздействия на участников, то в коммуникациях за ее пределами ситуация иная. Даже когда заказчик — внутренний, нельзя провести с ним one-to-one. В некоторых ситуациях приходится выполнять полноценный ресерч, готовить подробное обоснование, чтобы аргументированно ответить «нет» на заведомо невыполнимое требование.
Скажем, заказчик из агрохолдинга хочет, чтобы у него маскировались и трекались все коровы из огромного стада, производилось Re-identification на нескольких камерах разрешением всего 480p. Да еще и подавай точность 99,99%. Для ML-разработчика недостижимость таких показателей очевидна, но доходчиво объяснить это человеку, который не погружен в технические детали, бывает непросто.
Здесь важно помнить, что есть два типа метрик: ML-ные и бизнесовые. Первые заботят только самих разработчиков. Нет никакого смысла разжевывать заказчику какую-нибудь сложную F1-метрику модели, демонстрировать замысловатые формулы и расчеты. Ему интересен конкретный результат и польза для бизнеса: например, те самые 99,99% точности при маскировании объектов. Не помешает разве что в самых общих чертах разъяснить заказчику какие-нибудь простые DS-метрики в разрезе того, как они влияют на его основную «хотелку». Допустим, растолковать, почему обычная точность — не самый адекватный показатель и скорее нужно ориентироваться на Recall и Precision. Главное здесь — не переборщить с техническими деталями и сохранять фокус на бизнес-пользу. Иначе получится разговор слепого с глухим.
Следующий шаг к дзену в общении с заказчиками — разработать методику перевода бизнес-метрик в ML-ные и наоборот. Тогда выйдет сразу оценить реальность достижения поставленных целей, ведь бывают и не столь очевидные ситуации, как в примере с маскированием стада. На первый взгляд задача может показаться достижимой, и команда даже возьмет на себя определенные обязательства. А в ходе работы выяснится, что миссия невыполнима. На такой случай не повредит перестраховаться и, если снова вернуться к нашим баранам коровам, соотнести, какого процента точности реально достичь при тех или иных F1-метриках модели. Наладив подобную практику, ML-разработка сможет более аргументированно общаться с заказчиками и обосновывать свою позицию.
Вместо заключения
Вывести выверенный, как в аптеке, рецепт эффективной работы с командой и вообще с людьми в ходе ML-проектов едва ли получится. Слишком многое зависит от специфики конкретного проекта, возможностей компании-разработчика, но можно выделить отдельные must have-практики:
При подборе специалистов бывает полезно сформулировать и дать на рассмотрение типичную для вашей ML-команды задачу. Даже если кандидат ошибется или не сможет решить проблему, станет понятна логика его рассуждений.
Чтобы поддерживать здоровье команды, тимлид должен находиться в постоянном контакте с ее членами. Наиболее эффективный формат взаимодействия — регулярные беседы one-to-one. В свою очередь, анонимные опросы «360 градусов» следует применять с осторожностью и не делать на них основную ставку.
Если говорить о коммуникации с заказчиками, то важнейший лайфхак — научиться переводить ML-метрики в бизнесовые и наоборот. Это поможет аргументировано отстаивать свою позицию в случаях, когда на повестке дня появляются технически невыполнимые задачи.
