Запуск и масштабирование команд по анализу данных: пособие по DS Manager

Запуск и масштабирование команд по анализу данных: пособие по DS Manager

Пособие по передовой практике для создания и управления вашей командой по анализу данных

Этот пост представляет собой руководство по передовым методам управления командой специалистов по анализу данных. Этот раздел взят из моего резюме по запуску и масштабированию групп обработки данных и частично совпадает с учебником ИС Data Science. Я нацелен на специалиста по данным, который добился успеха в качестве индивидуального сотрудника и в настоящее время борется с классическими управленческими вопросами: как мне масштабировать, нанимать, оценивать, общаться? В области науки о данных это еще более сложная проблема, учитывая огромные различия в квалификации квалифицированных кандидатов. Этот пост предназначен для людей, задающих вопрос: Я добился успеха как информационный агент по обработке данных и получил определенные обязанности. Мне было поручено вырастить и возглавить команду в ________. Что теперь?

Резюме из четырех предложений: Постоянно выравнивайте структуру вашей организации. Максимизируйте передачу знаний вашей команды. Будьте внимательны при расстановке приоритетов. Подчеркните минимальную сложность решения.

Постоянно согласовывайте структуру вашей организации

Из всех предложений в моем сборнике игр, краткое изложение четырех предложений, это, безусловно, самое общее / плохо определенное / непрозрачное. Мои извенения. Однако есть причина: выяснить, как создать команду по анализу данных, действительно сложно; не существует устоявшихся «передовых практик», это сильно зависит от компании и сотрудников, и это совершенно очевидно, учитывая, что какая бы настройка у вас ни была сейчас, она не будет правильной для шести месяцев назад или шести месяцев спустя. Ресурсы, которые я нашел, и менеджеры, с которыми я беседовал, предлагали разные и часто противоречивые решения. Я достаточно долго смотрел, как создать команду по анализу данных, чтобы быть уверенным, что нет правильного ответа. Лучшее, что вы можете сделать в качестве менеджера, - это постоянно корректировать структуру вашей организации, архитектуру данных, рабочий процесс и культуру, чтобы быть уверенным, что вы активно масштабируете свою команду для удовлетворения текущих и будущих потребностей вашей компании.

Самый большой вопрос в организации науки о данных: ваша команда централизована или встроена? Централизованный: команда по анализу данных, которая работает вместе, выполняя роль внутреннего консультанта. Время команды DS - это ресурс, выделяемый заинтересованным сторонам бизнеса. Встроенный: отдельные специалисты по обработке данных входят в состав определенных продуктовых групп, их повседневная работа в этой команде очень итеративна, а диапазон их проектов ограничен. DraftKings имеет централизованную команду, как и Zillow. У Wayfair есть и то, и другое. Airbnb перешел из централизованного в гибридный по следующим причинам:

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

В Chuong Do есть отличная статья о централизованном / встроенном, подчеркивающая некоторые из основных недостатков обоих подходов. Децентрализация может привести к разрозненности знаний, меньшим возможностям для сотрудничества, усложнению внедрения стандартов (от кодовых баз до найма) и трудностям при совместном использовании инфраструктуры / передового опыта. Централизация может привести к тому, что команды будут лишены бизнес-контекста или заинтересованности партнеров, а также могут привести к ситуациям, когда: Обработка данных рассматривается как вспомогательная функция, отвечающая на вопросы менеджеров по продуктам, а не действующая как истинные мыслительные партнеры и проактивное руководство. разговоры с точки зрения данных .

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

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

Внедряйте специалистов по анализу данных, когда проекты с тяжелыми алгоритмами становятся настолько большими, что они постоянно будут нуждаться в специалистах по данным. Wayfair постепенно включила специалистов по анализу данных в свои команды по ценообразованию, рекомендациям и маркетингу; осознавая, что эти бизнес-подразделения настолько основаны на алгоритмах и аналитике, что их должны возглавлять специалисты по данным, ориентированные на бизнес. Это верно и для команды Zestimate Zillow. У Wayfair и Zillow была централизованная команда специалистов по обработке и анализу данных для поддержки остальной части их бизнеса. Будьте осторожны, встраивание специалистов по данным труднее с точки зрения найма и управления ресурсами - эти ИС должны обладать большой деловой хваткой, и они не будут работать ни над чем другим. Таким образом, время является более важным при найме на встроенную структуру.

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

Когда вы растянуты, посмотрите наружу и увеличьте размер своей команды. Но будьте очень разборчивы, особенно раньше. Никогда не недооценивайте дополнительные расходы, связанные с плохим наймом. Обдуманно оценивайте не только талант, но и то, правильный ли это талант. Требуется ли вам нанять исследовательского персонала для последовательного совершенствования основной части бизнеса или вам нужен быстродействующий IC, который может поддерживать множество команд, решать множество задач за 2–3 дня, чтобы получить точный ответ на 90% и двигаться дальше к следующему? Как эти потребности изменятся в следующие шесть месяцев?

Наконец, принимайте кадровые решения с учетом уровня и поддержки вашей нетехнической бизнес-команды. Насколько они способны? Что значит быть аналитиком в этой компании: легкий опыт работы с Excel или тяжелый SQL? Насколько согласована с командой по анализу данных остальная часть вашей компании? Стремятся ли заинтересованные стороны бизнеса к решениям DS или они сопротивляются изменениям? Большинство компаний, с которыми я разговаривал, являются технологичными (

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

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

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

Я начал свой проект, чтобы сообщить об этом, и я не могу это подчеркнуть. Специалисты по обработке данных IC могут относиться к своей работе как к индивидуальному спорту, и ваша задача - заставить их работать в команде. Kaggle и большинство образовательных ресурсов по науке о данных - это сольные проекты. Вы не можете предположить, что совместная команда с определенным рабочим процессом и стандартами кодирования появится сама по себе, на самом деле, я видел обратное - когда люди работают бок о бок, решая одни и те же проблемы несколько раз на своих локальных машинах, в Python 2.7, 3.5 и R.

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

Проверка кода: часто люди предполагают, что это способ обнаружить дефектный код до того, как он отключит веб-сайт. Это, безусловно, хорошо и необходимо (мне бы понравился обзор кода, если бы я забыл «DESC» в «ORDER BY» для сортировки рейтингов продуктов, из-за чего Wayfair рекомендовал товары от худших к лучшим в течение четырех часов, что в то время было Ошибка в 200 тысяч долларов), но часто проверка кода рассматривается как НЕ обязательная, когда код не может отключить веб-сайт или никто не обладает такими техническими возможностями, как человек, который его написал.

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

• Этот код удобочитаем, устойчив, хорошо комментируется и соответствует стандартам команды? Это правильный уровень абстракции / параметризации / модульности? (принципы информатики)
• Насколько надежны эти методы науки о данных и статистических методов? (принципы науки о данных)
• Эффективны ли эти объединения, оптимально ли структурированы эти таблицы для ежедневных вставок, правильно ли они спроектированы в зависимости от того, должны ли они быть прочитаны или прочитаны / записаны? Это важно для команды, использующей Hive / HDFS / Presto или ETL в любом случае. (Принципы DBA)
• Правильная ли эта работа, действенна, убедительна, хорошо представлена, реализуема? (принципы ведения бизнеса)

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

Наша команда использует те же версии и библиотеки Python, Scikit Learn, Presto, Tensorflow с DBeaver в качестве IDE SQL, Jupyter в качестве IDE Python и Airflow для планирования заданий. У людей разные предпочтения и разные базы знаний во всех этих областях. Это сильная сторона - помогите нам разработать новые и улучшенные конвейеры и стандарты. В той же мере, в какой люди поощряются и вознаграждаются за положительное влияние на бизнес, они должны ПОСТОЯННО искать более эффективные или действенные способы улучшить рабочий процесс и привычки команды. Будет проводиться проверка кода, как для экономического обоснования, так и для случая эффективности, а также для проверки правильности написания кода. (Совместимость с PEP8, линтеры). Будет зафиксирован только правильно отформатированный код. Обзор кода рассматривается как возможность учить и учиться, а также выявлять ошибки. Репозитории организуются на уровне проекта с людьми, работающими совместно, чтобы быстро освоить новые ИС и дать опытным ИС возможность взять на себя обучающую / руководящую роль.

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

Любое из этих решений может работать в команде в определенный момент времени, но многие люди, с которыми я говорил, предупреждали, что они плохо масштабируются. О мероприятиях по повествованию: «Раньше у нас были две команды, которые выступали раз в месяц. Сейчас есть девять команд - у меня есть люди, которые работают шесть месяцев и не знают, чем занимаются три команды ». О сессиях мозгового штурма: «Это сработало, когда мы были меньше, теперь у меня есть люди, которых я не встречал, которые давали мне советы о том, как решить проблему, с которой они раньше не сталкивались». На обеде и узнает: «Люди перестали ходить, как только он стал слишком большим».

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

Будьте внимательны при расстановке приоритетов

Как специалисты по обработке данных, так и представители бизнеса часто возражали против того, что они понятия не имеют, как расставлены приоритеты для проектов. Приоритезация варьируется от сильно ориентированной на данные («Мы смотрим на все, исходя из предполагаемого увеличения дохода за каждую неделю специалиста по данным») до сознательно не ориентированной на данные («Приоритезация не требуется, мы просто работаем над тем, что важно, вещи не должны быть оправданным или иметь приоритет ») до отчасти политического (« Это достаточно маленькая компания, чтобы знать, чрезмерно ли вы используете или недостаточно используются ресурсы науки о данных ») до очень политического (« Каждая команда, которую мы поддерживаем, получает равный доступ к нашему времени »). Точно так же роль специалистов по данным ИС варьировалась от «Я выбираю свои проекты» до «Я не выбираю свои проекты, десять проектов назначаются десяти людям, и они не знают почему».

Как лидер в области науки о данных, вы должны заставить свою компанию согласовывать то, что такое влияние на бизнес, и способы его измерения, и вы должны убедиться, что разговоры о приоритезации ведутся снизу вверх и сверху вниз между вашими IC и заинтересованными сторонами. Вы должны ввести прозрачность, обычно не связанную с командами по анализу данных. Один менеджер DS сказал мне: У каждого проекта своя ценность, мы не можем сравнивать их друг с другом. Если вы не можете сравнивать проекты, как вы можете выделить их, кроме как политически? В той же степени вы должны признать, что (опять же, релевантный XKCD) в науке о данных может быть трудно объяснить разницу между простым и практически невозможным. У ваших специалистов по данным определенно есть несовершенная информация о бизнес-проблеме, которую необходимо решить, у ваших заинтересованных сторон определенно есть несовершенная информация о том, сколько работы необходимо для решения. Вы должны получить проекты от заинтересованных сторон бизнеса и IC, собрать полный набор информации об ожидаемых затратах / выгодах этих проектов, собрать эти данные и представить их таким образом, чтобы приоритезация была очевидна для всех сторон.

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

Подчеркните минимальную сложность решения

Между разделом Know When You’re Done в Руководстве по анализу данных IC и этим разделом очень много общего. Повторение: специалисты по обработке данных IC, получившие образование в академических или онлайн-программах, не обучены оценивать сложность своих алгоритмов. Многие IC признали, что не знают, когда была решена проблема, большинство заявили, что управление временем - это то, над чем они работают. Ваша задача - установить основы для компромисса точности с учетом времени и сложности, а также помочь вашим непосредственным подчиненным понять, когда им следует двигаться дальше. Помните, что ваши ИС будут иметь естественную тенденцию слишком долго создавать слишком сложные решения. Установление ограждения - огромная часть работы, так же как и развитие здравого смысла и интуиции в команде, чтобы правильно начать решать проблему.

Вы должны сбалансировать эти стандарты с личным развитием: признать, что людям действительно нужно пространство для обучения и роста, а это требует решения новых проблем с помощью новых технологий. Как известно, организации, занимающиеся наукой о данных, страдают от зацикленности на инструментах, с которыми я работал по обе стороны: я сознательно поставил себя на проекты с более низким приоритетом, чтобы изучить принципы распределенных вычислений / Hadoop / Hive в начале своей карьеры, и я был разочарован, когда товарищи по команде сделали то же самое, построив сверточные нейронные сети ради построения сверточных нейронных сетей (позже мы выясним, как классификация изображений улучшает бизнес). В настоящее время эта фиксация на инструментах - это Tensorflow, Spark Streaming, GAN и RNN, но это было другое в прошлом и будет другим в будущем. Domino называет это «культурой мышления« серебряной пулей », при которой некоторые специалисты по данным считают, что просто получение Spark Streaming и TensorFlow решит все их проблемы ... Во многих случаях специалисты по обработке данных носят свои инструменты как почетный знак, и значок завернут. в их личности. " Одна внутренняя комиссия сказала мне: «Я знаю, что Tensorflow - неправильный способ решения моих проблем, но всегда есть давление со стороны коллег, чтобы они использовали эту крутую штуку. Сообщения в блогах компании и академии обучения не о сокращении оттока клиентов с помощью случайных лесных классификаторов. Эта отрасль развивается так быстро, и мне нужно не отставать ». Другая сказала, что она измеряет свой личный рост, какие новые технологии она внедряет.

Ни один специалист по данным не ошибается в этом. Опыт работы с Tensorflow и Spark Streaming может иметь большое значение для резюме, и вы не научитесь так много, решая немного разные проблемы с помощью одних и тех же инструментов. Менеджеры DS должны осознавать противоречие между решениями с правильными инструментами / сложностью и решениями как возможностью для обучения. Вы должны правильно сочетать инженерные решения с командным счастьем и развитием. Как и все остальное, поймите, что это то, в чем вам нужно быть преднамеренным, прозрачным и гибким. Отличное решение - дать вашей команде четко определенный период времени, в течение которого они могут работать над тем, что они хотят, с инструментами, которые они хотят изучить, но также предоставить им рекомендации и отпор: «Если вы хотите сделать более сложное мышление , скажи мне, почему ты собираешься заплатить такую ​​цену ». Поговорите со своей командой, чтобы убедиться, что они чувствуют, что они учатся, и распределяйте «растянутые» проекты соответственно, когда у вас есть возможность позволить кому-то решить реальную проблему с помощью нового для него решения или технологии.