Роман с Data Science. Как монетизировать большие данные - читать онлайн книгу. Автор: Роман Зыков cтр.№ 14

Cтраница 14

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Именно такой подход к выполнению задач мы практикуем в Retail Rocket, правда, в реальности деталей и правил у нас гораздо больше. В нашем случае получилась смесь методологий Scrum и Kanban. Но не стоит создавать из них карго-культ. Они зависят от размера команд, специфики задач и самое главное – степени готовности команды. Я начинал с самых простых столбцов со статусами попроще для ведения задач в Trello, потом пришел к схеме выше, но и ее не считаю совершенной. Не существует единой методологии, внедрив которую вы станете полностью счастливыми, главное – придерживаться здравого смысла.

Следующий класс задач – уже из области анализа данных: поиск инсайтов. Обычно это задачи от менеджеров или клиентов. В тексте таких задач описывается какая-либо проблема, и необходимо найти ее причину. Мы пропускали такие задачи через те же самые статусы, что и инженерные. Но у них есть одно отличие – неизвестно, найдем мы причину или нет. Конечный результат неизвестен, значит, теоретически мы можем потратить бесконечно большое время на поиск причины. Поэтому при планировании такой задачи мы указываем максимальное время, которое готовы на нее потратить.

Третий класс задач – исследовательские, куда включена проверка гипотез и проведение экспериментов. Это самые сложные (но интересные) задачи с непредсказуемым результатом. Их обожают люди, которые любят постоянно учиться и экспериментировать, это их основной мотиватор. У таких задач следующие характеристики: непредсказуемый результат и очень долгое время его ожидания.

Управление гипотезами совсем непростая штука, как кажется на первый взгляд. Например, у нас в Retail Rocket только три из 10 гипотез по улучшению рекомендаций дают положительный результат. Чтобы провести эксперимент с одной гипотезой, требуется минимум полтора месяца. Это очень дорогое удовольствие. Что обычно понимается под гипотезой? Какое-либо изменение, которое приведет к улучшению чего-либо. Обычно это рационализаторское предложение, направленное на улучшение определенной метрики. Метрика – обязательный атрибут. На старте работы компании это была конверсия сайта (процент посетителей, которые сделали покупку). Потом мы пошли дальше: захотели повысить заработок в расчете на одного посетителя сайта (Revenue Per Visitor), увеличить средний чек покупки, среднее количество заказов в товаре и даже визуальную привлекательность рекомендуемых товаров. Рационализаторские предложения могут быть разными: от исправления ошибки в алгоритме до внедрения алгоритма машинного обучения на нейронных сетях. Мы старались все изменения алгоритмов прогонять через гипотезы. Потому что даже исправление несложной ошибки в реальной жизни может привести к ухудшению метрики.