Пять​ ​главных​ ​навыков​ ​хорошего​ ​data​ ​scientist,​ ​которым​ ​не​ ​учат​ ​в​ ​книгах

О том, какие навыки на самом деле нужны аналитикам данных и специалистам по машинному обучению, — взгляд основателя компаний InsideDNA и Skinomica, ранее — ведущего специалиста Booking.com Анны Костиковой.

Сегодня data scientist (DS) — одна из самых востребованных профессий на рынке труда. Высокие зарплаты, большой интерес со стороны работодателей, шквал вакансий. Но примерно пять лет назад всё было иначе: когда после защиты кандидатской в Швейцарии и нескольких лет работы в Швейцарском институте биоинформатики я искала работу, на территории Швейцарии нашлась всего одна вакансия DS — в Цюрихском офисе Google. Для сравнения, если сегодня вбить "data scientist" на Glassdoor (Швейцария) — выпадет более трёхсот вакансий.

В Цюрихский офис Google я так и не попала — на тот момент они решили не формировать новую команду. Зато несколько лет отработала ведущим специалистом по DS и ML в Booking.com.

За три года работы в Booking, наша команда DS и ML выросла с 25 человек и четырёх небольших команд до почти 200 человек и примерно пяти отделов. Мы реализовали ряд успешных и, разумеется, в разы больше неуспешных проектов, сформировали отличный технологический стек по DS и ML, и в целом закрепили за Booking.com статус одной из наиболее data-driven компаний в отрасли.

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

За время работы я провела около 150 интервью (телефонных и f2f) и ниже расскажу о том, на основании чего в конечном счёте принималось решение о приёме кандидата в команду как в Booking.com, так и в компанию, где я работаю теперь — InsideDNA.

Есть пять основных умений DS-специалиста, при наличии которых он будет приносить реальную пользу компании. Профессионалы с такими способностями встречаются редко, но это не значит, что их не стоит искать и пытаться привлекать в команду. Сразу оговорюсь, речь будет о требованиях к специалистам в относительно большую компанию и не в отдел научных разработок и исследований (R&D), а в операционный бизнес.

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

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

Если начальник или куратор проекта не может чётко ответить на эти вопросы — его надо отправить подумать или сесть подумать вместе с ним.

Если начальник сумел ответить на вопросы выше, задачу нужно транслировать в техническое решение. Это почти всегда нетривиальный момент.

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

И в Booking.com, и в моей текущей компании на собеседовании мы всегда даём реальный кейс и просим человека рассказать, как он будет подходить к его решению. Если вдруг вместо обсуждения «смысла» задачи, он сходу начинает применять стохастическую рекуррентную нейронную сеть — почти без сожаления можно прекращать разговор. Толка от такого специалиста будет очень немного, а вот недопонимание между ним и другими членами команды будет расти в геометрической прогрессии.

Рынок желающих стать DS в Европе и США наводнён выходцами из академии — post PhD или Postdoc. Печальным следствием этого является склонность к перфекционизму и попытка потратить много месяцев на получение «идеального продукта» или ещё хуже — попытка улучшить уже существующий алгоритм. Возможно, это не очень плохо в научных кругах, но для бизнеса это реальная головная боль.

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

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

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

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

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

Надо также учитывать, что на внедрение и «фиксацию» модели в бизнес-процессах, а также убеждение всех окружающих в полезности подхода по сравнению с business as usual у вас уйдёт 95% времени. Не на разработку, не на выпуск в производство, а на то, чтобы ваше решение действительно стало частью бизнеса.

Эти пять навыков можно обобщить одним словом — ownership. На моей практике только такие DS-специалисты действительно полезны компании.

А как же написание фломастерами на доске формул оптимизации стохастического градиентного спуска? Где же упоминание технологий Hadoop, Spark или H2O? Где, в конце-концов, Python, R или Scala, а также scikit-learn, numpy, ggplot, спросите вы. Ведь именно про это все книги о том, как стать DS-специалистом.

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

И в заключении о том, что же на самом деле делает data scientist.

Анна Костикова — основатель InsideDNA — компании, которая помогает биотех и фармкомпаниям разрабатывать лекарства против рака с помощью анализа ДНК и машинного обучения. Основатель проекта Skinomica — здоровая кожа на основе данных микробиоты.