Growing and Running Your Data Science Team

eugeneyan

Начните здесь Статьи Выступления Прототипирование Обо мне

Как растить команду data science и управлять ею

[ leadership datascience ] · 16 мин чтения

Эффективная команда data science — как гусыня, несущая золотые яйца. Иногда мы слишком сосредотачиваемся на яйцах (то есть на результатах) — как получить их больше и быстрее? В итоге гусыней (то есть командой) можно начать пренебрегать.

Менеджер 3-й стадии: менеджер, для которого всё — бизнес и который воспринимает людей прежде всего как «ресурсы». Может заботиться о людях. Может даже заботиться очень сильно. Но гораздо больше его волнуют краткосрочные результаты и цели. Поэтому, когда одно вступает в конфликт с другим, он без зазрения совести отдаст приоритет краткосрочным результатам. — Shreyas Doshi (@shreyas) 30 января 2021

Здесь же мы сосредоточимся на гусыне. Я поделюсь тем, что узнал о том, как растить (наём, обучение) и как вести (инновации, дисциплина, товарищество) команды data science. Это основано на моём опыте в Lazada (где я был одним из первых DS и в итоге возглавил команду) и uCare (где мы запустили ML-систему для крупнейшей сети больниц Юго-Восточной Азии). Я оценивал себя по продуктивности, росту и благополучию команды. Вот что дало наибольший эффект.

Это было запрошено в опросе тем. Пожалуйста, добавляйте свои темы и голосуйте! 🙏

Наём: самое важное, что вы можете сделать

Наём — самое важное, что каждый в команде может сделать для нашего успеха. Мы всегда должны стараться поднимать планку, находя людей, которые улучшат пул талантов. Вот как я выявляю таких людей:

Что этот человек (потенциально) может делать лучше, чем кто-либо ещё в команде? Чему наша команда может у него научиться? Хотел бы я быть частью проекта, который ведёт этот человек?

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

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

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

Во-первых, они любопытны. Когда стейкхолдеры просят их решить проблему, они спрашивают: «Зачем? Как решение этой проблемы создаёт ценность?» (Это может раздражать стейкхолдеров, но, на мой взгляд, это правильное поведение). Получив доступ к данным, они прослеживают их вверх по цепочке, чтобы очистить и использовать их корректно, нередко выстраивая собственные пайплайны данных. Они докапываются до проблем, которые ещё не переросли в полноценные, привлекают к ним внимание и начинают их решать.

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

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

Нанимай за характер, обучай навыкам. — Peter Schutz

Что касается навыков, я заметил, что отличные сотрудники могли вести проекты преимущественно end-to-end. Поэтому они начинают — и продолжают — приносить ценность быстрее большинства. (Замечу: это наблюдение, вероятно, искажено моим опытом в стартапах и scale-up'ах). А если им не хватало навыка или знаний (например, Docker, CI/CD), они с энтузиазмом осваивали азы, что делало их продуктивнее на следующем проекте.

Вот несколько эвристик, которые я использую для оценки вышеперечисленного (caveat emptor — будьте осторожны):

Масштаб прошлой работы показывает, насколько развиты их навыки end-to-end. Личные проекты говорят о любопытстве учиться в своё свободное время. Аналогично, масштаб демонстрирует их способность работать end-to-end и упорство в доведении дела до конца, особенно если им пришлось чему-то новому учиться (например, деплою на AWS). Способность принимать обратную связь и действовать по ней во время дизайн-/кодинг-интервью может выявить эго (и недостаток скромности). Чрезмерная оборонительная реакция или нежелание рассматривать альтернативы могут быть тревожным сигналом. Занятия спортом на соревновательном уровне (например, марафоны, киберспорт) и наличие устойчивых привычек демонстрируют упорство и, в некоторой степени, надёжность.

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

Великие компании не нанимают умелых людей и не мотивируют их — они нанимают уже мотивированных людей и вдохновляют их. — Simon Sinek

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

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

Рекомендации и митапы/конференции были нашими лучшими каналами для найма — около 90% сотрудников пришли через них. В Lazada наш первый дата-инженер привёл других звёзд в области больших данных, один из которых в итоге стал нашим VP of data engineering. Рекомендации — отличный источник качественных кандидатов, так как мы обычно рекомендуем только тех, с кем (i) нам приятно работать и/или (ii) у кого можем учиться, особенно если рекомендуемый присоединяется к той же команде.

Наём через митапы — это лайфхак для дешёвого построения/масштабирования команды. Я наблюдал это воочию в сингапурской митап-сцене, где компании выступали на митапах ради найма. AXA, Twitter и Uber проводили митапы, когда открывали техно-хабы, а Go-Jek, HonestBee, Facebook и Shopee активно делились на митапах, чтобы масштабировать свои команды. Точно так же выступления Lazada на конференциях и митапах помогли с несколькими отличными наймами.

Обучение: похоже на transfer learning

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

Нет ничего важнее того, что мы делаем при найме и развитии людей. В конце концов, ставку делаешь на людей, а не на стратегии. — Lawrence Bossidy

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

Ещё одна любимая практика — paper-lunches (он же lunch-and-learn). Раз в две недели два человека разбирают по одной статье каждый. В идеале — что-то, что их увлекает и применимо к их работе. Они сосредотачиваются на том, чтобы досконально понять статью — это в любом случае происходит в рамках исследования по проекту — и дать по ней быстрый разбор. От остальной команды ожидается, что они прочитают статью заранее и придут подготовленными, с вопросами и темами для обсуждения. За год команда обсудит 50 статей! (Подробнее о том, почему стоит читать статьи.)

Ещё один подход — проведение ревью (например, код-ревью, дизайн-ревью). Ревью — это не просто процесс, в котором сеньоры проверяют дизайн-документы и код; это ещё и возможность для обучения и развития. Ревью pull request'ов — отличный способ для новых сотрудников освоиться с кодовой базой и стандартами. Это также возможность прояснить сомнения и дать обратную связь.

Участие в дизайн-ревью помогает членам команды понять, как мыслят бизнес-стейкхолдеры и старшие инженеры/учёные, как они балансируют компромиссы и принимают решения. Например, стейкхолдеры сосредоточены на бизнес-требованиях (например, итоговые метрики, пользовательский опыт) и ROI, инженеры — на технических требованиях (например, масштабируемость, задержка, отказоустойчивость) и долгосрочных операционных расходах. Учёные сосредоточены на потоках данных, методологии, результатах экспериментов, A/B-тестировании и т. д.

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

Инновации: поощрение творчества, идей и рисков

По мере того как команда data science добивается успеха и улучшает метрики, от нас будут ожидать продолжения линейного (или даже экспоненциального) роста этих метрик. Например, если выручка, приписываемая нашим ML-системам (например, рекомендациям, push-уведомлениям), выросла в прошлом году на 10%, цели на этот год будут такими же, если не выше. Такие требовательные ожидания могут не оставлять места для более рискованных, долгосрочных проектов.

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

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

Компании, которые не продолжают экспериментировать или принимать неудачи, в итоге оказываются в положении, когда единственное, что им остаётся, — сделать отчаянную ставку в конце своего корпоративного существования. — Jeff Bezos

В 70-х производители жёстких дисков сосредотачивались на выпуске дисков для производителей мейнфреймов. Эти производители мейнфреймов хотели больше объёма и более высокой скорости передачи, и устоявшиеся производители дисков давали им это.

Однако некоторые стартапы и небольшие компании пошли в противоположном направлении. Они начали производить жёсткие диски с меньшим объёмом и меньшей скоростью передачи, но вдвое меньшего размера. Эти диски предназначались в основном для тогда ещё зарождавшегося рынка мини-компьютеров.

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

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

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

Один из способов взращивать инновации — открыто говорить о неудачах. Когда члены команды делятся своими тревогами по поводу проекта и A/B-тестов, рассказ о моём провале их успокаивает. Я также открыто рассказываю о неудачах нашей команды и неудачных экспериментах (если все причастные на 100% не против). Делая так, я надеюсь привить установку — особенно среди стейкхолдеров, — что эксперименты и обучение на неудачах являются ключевой частью нашей работы. Как любил говорить мой бывший начальник Джон: «Это не ошибка, это возможность чему-то научиться!»

«Неудача здесь допустима. Если у вас ничего не проваливается, значит, вы недостаточно инновационны» — Elon Musk

Я также обнаружил, что полезно быть партнёром по подотчётности и «болельщиком» в 20%-проектах. Хотя 20%-проекты начинаются со страсти, их можно отодвинуть на задний план ради более срочной работы или они теряют запал из-за отсутствия подотчётности и видимости. Через год показать нечего — это разочаровывает и причастных людей, и бизнес.

Поэтому, когда кто-то предлагает 20%-проект, я работаю с ним, чтобы определить его границы, и время от времени проверяю, как идут дела, следя за тем, чтобы у него было пространство, время и ресурсы для работы над ним. Это также сигнализирует, что 20%-проект не менее важен, чем обычная работа, а то и более. И если проект оказывается успешным, он выпускается из «инкубации» и становится MVP, который мы можем показать клиентам и получить от них обратную связь.

Дисциплина: мост между идеями и результатами

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

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

Операционализировать это через one-pager очень полезно. One-pager определяет замысел, желаемый результат, поставляемые артефакты и ограничения. Затем он рассылается, чтобы достичь согласования со стейкхолдерами до того, как начнётся какая-либо существенная работа. Делая это заранее, мы гарантируем, что задаём правильные вопросы и решаем правильные проблемы, вместо того чтобы без необходимости уходить в дебри или пытаться объять необъятное.

Дисциплина важна и в исполнении. Я рассматриваю это как исполнение с чувством срочности. Basecamp обнаружили, что 6-недельные циклы работают для них лучше всего — они достаточно длинные, чтобы завершить что-то значимое, и достаточно короткие, чтобы ощущать срочность. На мой взгляд, большинство проектов data science стоит вести как стартап. Мы хотим выпускать рано и выпускать часто, чтобы быстро получать обратную связь от клиентов, итерировать и улучшаться.

Главный предсказатель успеха для очень молодого стартапа — скорость итераций. — Sam Altman

Это мышление объясняет мою склонность к scrum и тайм-боксингу в data science. Каждый спринт даёт результаты-вехи, которые мы можем принести стейкхолдерам и/или клиентам, чтобы получить их обратную связь. Мы хотим быть как стохастический градиентный спуск (то есть инкрементальные поставки), а не как пакетный градиентный спуск (то есть Big Bang-интеграция).

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

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

Товарищество: то, что скрепляет команду

Один из моих самых больших вкладов в руководстве командами — выстраивание товарищества. В Lazada мы вместе с VP of data engineering каждую пятницу открывали и закрывали «бар». (Мы запустили happy hour, чтобы команда могла указать на нас и присоединиться, а потом задержаться, чтобы убрать). На следующей работе happy hour не сработал, зато сработал Counterstrike. Фрагать друг друга (особенно QA и CTO) в пятницу вечером было отлично для сплочения команды.

Сплочение команды помогает строить доверие. При высоком уровне доверия больше нет сомнений. Я знаю, что ты критикуешь мою работу, потому что объективно считаешь, что есть куда улучшать, а не потому, что имеешь что-то личное против меня (то есть закон Крокера). Это позволяет нам открыто не соглашаться и находить наилучший возможный результат. Это также экономит время и когнитивные ресурсы. Не нужно читать между строк или пытаться понять, что человек на самом деле имел в виду.

Команда — это не группа людей, которые работают вместе. Команда — это группа людей, которые доверяют друг другу. — Simon Sinek

По мере того как доверие растёт, люди и делятся большим. Я заметил, что одна сотрудница вела себя чуть иначе и не так часто, как раньше, присоединялась к командным обедам, и невзначай спросил, всё ли у неё в порядке. Она рассказала, что, когда до конца её рабочей визы оставалось 6 месяцев, ей было трудно продлить аренду квартиры. У большинства арендодателей минимальный срок аренды был 1 год, и мало кто хотел брать на себя риск сдавать ей жильё. Узнав об этом, я поработал с HR, чтобы продлить её визу, косвенно помогая ей закрепить квартиру. Сняв эту тревогу, она смогла лучше сосредоточиться на работе.

Товарищество к тому же делает работу приятнее. Мы будем проводить с командой как минимум 8 часов в день, каждый рабочий день (хотя сейчас, с удалёнкой, меньше) — почему бы не сделать это весёлым? Исследования показывают, что командное товарищество может превращаться в измеримые результаты. Gallup обнаружили, что сотрудники, у которых есть лучший друг на работе, вдвое чаще вовлечены. Они также реже ищут или присматривают новые вакансии, что помогает улучшать удержание.

Заключение

Здорово иметь команду, ориентированную на результат, — она доставляет результаты! Тем не менее не забывайте также заботиться о гусыне, а не только о золотых яйцах.

Какие ещё практики оказались для вас полезными в построении и управлении эффективными командами data science? С удовольствием услышу от вас @eugeneyan или в комментариях ниже.

Как растить эффективную дата-команду и управлять ею? Вот что я узнал о: • Найме: самое важное • Обучении: передача знаний • Инновациях: поощрение творчества • Дисциплине: мост между идеями и результатами • Товариществе: то, что скрепляет команду https://t.co/NLZjFjvgg8 — Eugene Yan (@eugeneyan) 2 февраля 2021

Спасибо Yang Xinyi за чтение черновиков.

Если это оказалось вам полезным, пожалуйста, цитируйте эту заметку так:

Yan, Ziyou. (Jan 2021). Growing and Running Your Data Science Team. eugeneyan.com. https://eugeneyan.com/writing/data-science-teams/.

или

@article{yan2021team, title = {Growing and Running Your Data Science Team}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2021}, month = {Jan}, url = {https://eugeneyan.com/writing/data-science-teams/} }

Присоединяйтесь к 11 800+ читателям, получающим обновления о машинном обучении, RecSys, LLM и инженерии.