Роман Зыков - Роман с Data Science. Как монетизировать большие данные [litres]

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

Есть один минус полного перехода в менеджмент – атрофия технических навыков. Менеджеру будет сложно вернуться в работу руками, а такое иногда бывает, например, когда создают стартап. По этому поводу Колсон написал [20], что «истинный лидер аналитики никогда не утратит любопытства и поздними вечерами или утром в выходные может самостоятельно покопаться в данных, строить простейшие графики и самостоятельно сделать выводы. Это даст ему понимание данных, которое нельзя получить никаким другим способом, кроме как погрузив туда руки». Что повысит вашу самооценку и поможет мотивировать ваших сотрудников быть любознательными и любить свою профессию. Я очень люблю свое ремесло, даже когда управляю чем-то, мне всегда интересно посмотреть код – как это работает внутри черного ящика.

Почти все задачи аналитики делятся по направлениям, и к каждому нужен свой подход:

• Инженерные задачи.

• Найти причину какого-либо явления (инсайт).

• Проверить гипотезу или провести исследование.

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

• Задача пришла от заказчика (New).

• Задача получила приоритет, оценку трудоемкости и поставлена в очередь на исполнение (To Do).

• Задача взята в работу (In Progress).

• Задача проходит проверку на правильность реализации (Review).

• Задача проходит тестирование заказчиком (Test).

• Задача выполнена (Done).

Рис. 3.1.Доска Канбан

Вся эта схема типовая и вытекает из здравого смысла. Любая задача может быть принята к исполнению или отвергнута по разным причинам (это сделать мы не можем, нужна виза руководителя). Далее команда аналитиков берет такую задачу, обсуждает ее напрямую с заказчиком, оценивает ее, например, через покер планирования [22]. Задача становится в очередь на выполнение в соответствии со своим приоритетом. Причем у нас было правило: брать первую из стопки задач. Таким образом происходит рандомизация категорий задач, и специализация сотрудников размывается.

В чем плюс такой схемы рандомизации? В том, что все сотрудники понимают, как функционирует система в целом, а значит, могут заменить друг друга в случае отпуска, болезни или увольнения. Это частично решает проблему фактора автобуса (сколько разработчиков вашей компании должен сбить автобус, чтобы компания все еще продолжала функционировать). До Retail Rocket я не заморачивался подобными вопросами. Если кто-то увольнялся – проект этого человека приостанавливался до найма сотрудника на его место. Но в той компании, соучредителем которой я являюсь сейчас, роль аналитики больше и ответственность выше.

У рандомизации задач есть минусы:

• У сотрудников есть сильные и слабые стороны: кто-то силен в инженерии, кто-то в построении моделей. Соответственно, у инженера будут проблемы с ML-моделями, а у аналитика – с инженерией.

• У сотрудников тоже есть профессиональный и личный интерес – брать задачи определенной категории. Рандомные задачи для них становятся деструктивными.

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

Поэтому сама схема рандомизации не является панацеей.

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