Первые месяцы на работе Data Scientist

Это нормальный этап. Новичка проверяют не только Python, SQL и знание ML. Гораздо важнее другое: умеет ли человек спокойно входить в контекст, задавать вопросы, не ломать отношения с командой и не делать модель там, где сначала надо разобраться в данных.

Если вы только нашли первую роль, полезно держать рядом статью «Как искать первую работу в Data Science». А здесь поговорим о следующем шаге: что делать, когда работа уже началась и нужно не просто выжить в онбординге, а стать полезным человеком в команде.

Онбординг: что понять в первые недели

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

Я бы начинал не с вопроса «какую модель построить?», а с более приземлённых вещей: как компания зарабатывает, какие метрики смотрит руководитель, откуда приходят данные, кто владеет таблицами, как часто данные обновляются, где лежит документация и что уже пробовали до вас.

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

Как задавать вопросы, чтобы вас слышали

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

Хороший вопрос обычно состоит из трёх частей: что вы пытаетесь сделать, что уже проверили и где застряли. Не «я ничего не понимаю в таблице orders», а «я смотрю таблицу orders для расчёта повторных покупок, проверил поля user_id, created_at и status, но не понимаю, какой status считать завершённым заказом. Подскажете, где это принято смотреть?»

Такой вопрос экономит время коллеге. Он видит, что вы не перекладываете мышление на него, а пришли за конкретным недостающим кусочком.

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

Как выстраивать отношения с командой

Data Scientist почти никогда не работает в вакууме. Даже если вы единственный человек с такой должностью, рядом всё равно есть продакт, аналитик, backend-разработчик, data engineer, руководитель, бизнес-заказчик. И у каждого своя боль.

С аналитиками лучше дружить сразу. Они часто знают данные лучше всех: где ломается выгрузка, какая метрика исторически считается криво, какой dashboard все смотрят, но никто не любит. С backend и data engineers важно не приходить в стиле «дайте мне все данные». Лучше объяснить задачу и вместе понять, какой источник надёжнее.

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

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

Как понять данные компании

Данные компании — это не просто набор таблиц. Это следы процессов. Где-то пользователь нажал кнопку, где-то менеджер руками поменял статус, где-то интеграция не прислала событие, где-то поле начали заполнять только после редизайна формы.

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

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

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

И да, почти всегда всплывут странности. Это не повод сразу говорить «у вас плохие данные». Лучше описать спокойно: что проверено, где расхождение, насколько оно большое, на какие решения влияет. Такой тон быстро отличает специалиста от человека, который просто жалуется на грязный датасет.

Что делать, если данных нет или они грязные

Ситуация «данные есть, но пользоваться ими больно» встречается чаще, чем хотелось бы. Особенно в компаниях, где Data Science появился позже продукта. События логировались не для моделей, статусы менялись руками, документация устарела, а часть важных действий вообще живёт в Google Sheets.

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

Если бизнес просит «предсказывать отток», а у вас нет нормальной истории активности клиентов, это нужно сказать рано. Не в формате «невозможно», а в формате: «для честной модели сейчас не хватает таких-то событий; можем начать с анализа доступных данных, простого правила или настройки сбора событий». Подход похож на то, что я разбирал в статье «Почему проваливаются Data Science-проекты»: проблема часто не в алгоритме, а в том, что вокруг него.

Если ты первый Data Scientist в компании

Быть первым Data Scientist звучит красиво. На деле это может быть тяжёлой ролью: нет готовых процессов, нет старшего коллеги, нет ML-инфраструктуры, а ожидания иногда такие, будто вы принесёте компании искусственный интеллект в коробке.

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

Отдельно нужно проговорить границы ответственности. Кто помогает с доступами? Кто делает интеграцию? Кто отвечает за сервер? Кто принимает решение, что модель можно использовать? Если всё это молча повесить на первого Data Scientist, проект быстро станет неуправляемым.

Когда дело дойдёт до внедрения, пригодится материал «Развёртывание модели машинного обучения в продакшене». Но до production стоит дойти аккуратно: через задачу, данные, baseline, валидацию и понятную пользу.

Что делать в первые 30/60/90 дней

Классическая схема 30/60/90 иногда выглядит слишком корпоративно, но как ориентир она полезна.

Первые 30 дней: разобраться в продукте, людях, данных и текущих задачах. Не пытаться впечатлить сложностью. Лучше принести маленькую, но полезную ясность: карту таблиц, разбор метрики, список проблем в данных, аккуратный анализ.

К 60 дню: взять одну задачу и довести её до понятного результата. Это может быть EDA, baseline-модель, улучшение отчёта, проверка гипотезы, автоматизация ручного анализа. Главное — показать, что вы умеете не только учиться, но и закрывать рабочий кусок.

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

Часть этих разговоров похожа на продолжение интервью, только уже внутри команды. Если хочется заранее потренировать спокойные ответы про проекты, метрики и ограничения, пригодится статья «Собеседование Junior Data Scientist в 2026 году».

Типичные ошибки новичков

• Молчать слишком долго. Лучше задать один нормальный вопрос, чем неделю строить решение на неверном предположении.
• Сразу делать модель. Иногда задача решается SQL-запросом, отчётом или простым правилом.
• Стесняться непонимания данных. Внутренние данные компании почти всегда требуют расшифровки.
• Игнорировать отношения. Без аналитиков, инженеров и продакта DS-задачи быстро застревают.
• Обещать слишком много. Лучше осторожный срок и честные ограничения, чем красивое обещание без опоры.
• Не фиксировать договорённости. Устные решения легко теряются, особенно когда задач много.
• Пытаться выглядеть senior. На первых месяцах важнее надёжность, ясность и обучаемость.

Чек-лист первых месяцев

• Я понимаю, чем занимается продукт и как компания зарабатывает.
• Я знаю главные метрики и людей, которые за них отвечают.
• У меня есть карта основных таблиц, витрин и источников данных.
• Я понимаю, какие данные обновляются с задержкой и где есть проблемы качества.
• Я знаю, кому задавать вопросы по продукту, данным, инфраструктуре и бизнесу.
• Я фиксирую ответы и договорённости, а не держу всё в голове.
• У меня есть одна небольшая задача, которую можно довести до результата.
• Я не обещаю ML там, где сначала нужен data audit или baseline.
• Я регулярно сверяю ожидания с руководителем.

Вывод

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

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