Типичный рабочий день специалиста по Data Science

Павел Панкин, data scientist в ИТ-компании КРОК, в своей статье на сайте tproger.ru рассказал о своей обычной рабочей рутине. Мы думаем, что это будет интересно всем, кто намеревается стать специалистом по работе с данными.

Первое и самое главное — не существует такой вещи, как «типичный рабочий день специалиста по Data Science». Новый день может полностью отличаться от предыдущего: сегодня вы пишете нейросеть, которая будет распознавать тысячи мелких предметов на заводе, а завтра весь день пилите презентации и документацию для заказчиков. Однако, даже если data scientist постоянно живет в эпоху перемен, некоторые общие аспекты можно выделить: работа с данными (sic!), людьми и задачами.

С чего начинается день?

С чтения Хабра и Open Data Science — беглое знакомство с новостями мира ML помогает быть в курсе того, что происходит в профессии. Но если Хабр не полностью ориентирован на DS и ML, хотя иногда там можно встретить интересные статьи или переводы англоязычных материалов со ссылками на оригиналы, то ODS — классный источник свежей информации.

Далее распорядок зависит от того, идёт ли работа над проектом, и если да — на какой она стадии.

Задачи во время работы над проектом

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

Мой персональный список задач:

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

В работе я использую стандартные инструменты сегодняшнего дата-сатаниста: Python (все основные либы, включая pandas, NumPy, scikit-learn, matplotlib, Tensorflow/PyTorch), PySpark, SQL.

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

Самое приятное в работе

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

Например, мы не могли автоматизировать поиск нужной области с целевыми объектами на фотографиях. С командой бились несколько месяцев над этой проблемой, пытаясь реализовать это с помощью классического компьютерного зрения. Учитывая требование клиента сделать решение, работающее на ЦПУ, мы изначально отказались от создания нейросети. Опасались, что она получится тяжёлой и будет долго исполняться. Но всё равно пришли к выводу многих коллег: «Есть проблема — пиши сетку». За один день собрались, разметили данные, написали рабочий прототип, который показал свою эффективность. Получилось быстрое решение за счёт раздувания объёма памяти, но RAM, в отличие от VRAM, можно легко увеличить. В итоге, вместо месяца мы сделали рабочий прототип за один день (и немного ночи).

Наименее приятное

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

Что делаешь, когда нет проекта?

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

Коммуникация

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

Коммуникация с людьми, не погруженными в ML

Вопреки распространённому мнению, важные инструменты специалиста по данным — Word, Outlook и PowerPoint. Со стороны кажется, что ML-разработка — плавание по волнам кода и данных, но значительную часть твоего дня составляет общение: с коллегами, с заказчиком, с менеджером проекта. В конечном счёте наша работа заключается в решении проблем, а не в построении моделей.

Если общение внутри коллектива программистов может идти неформально, то с заказчиком необходимо выстраивать как можно более конструктивный диалог. Самое сложное тут — донести, что некоторые пожелания неосуществимы по объективным причинам, а не потому что ты не умеешь: недостаточно данных, задача неосуществима на данном процессе/железе/фреймворке, её невозможно решить физически (например отследить определённый объект, заваленный кучей других объектов).

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

Коммуникация с командой

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

Типичный рабочий день специалиста по Data Science

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

Можно ли было описать любой свой день и назвать его «Рабочий день специалиста по Data Science»? Да, но тогда я бы соврал. Ведь наши дни настолько разнообразны, насколько разнообразны сферы применения науки о данных, которой я отдал уже много лет.

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх