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

Инициатор : коммерческий директор Иванов И.И.

Причина : продажи направления «Игрушки» упали, эта категория сильно отстает от плана. Возможная проблема в недостаточных расходах на рекламу.

Ожидаемый результат : причина падения продаж – текстом с обоснованием причины цифрами.

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

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

Пример плохой задачи:

• Инициатор: Сидоров А. по поручению Иванова И.И.

• Пришлите мне распределение продаж категории «Игрушки» по рекламным каналам как можно быстрее.

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

Планирование задач [22] – важный процесс, который может выглядеть по-разному: планировать может руководитель аналитики или вся команда. Можно делать это в текущем режиме, планируя задачи по мере поступления, а можно и периодически, накапливая пул задач. Все эти способы я опробовал и теперь уверен, что лучше, когда в планировании участвуют все, как в Retail Rocket [22], и у этой встречи есть четкие календарные рамки. Мне лично бывает непросто спорить со своими же сотрудниками о вариантах и сроках исполнения. Часто хочется единолично принимать решения. Но есть формула – чем сильнее вы сами, тем лучших сотрудников вы нанимаете, тем больше свободы в принятии решений вы им даете. Так формируется команда профессионалов, у которых всегда будет возможность высказаться.

На встречах по планированию задач в Retail Rocket мы включаем диктофон. Аудиозаписи дисциплинируют и помогают решать спорные вопросы. Но еще лучше все договоренности прописывать прямо в тексте задачи – это гарантирует, что все всё поняли правильно, особенно если согласию предшествовали жаркие споры.

Чтобы проверить задачу, нужно вспомнить, какие артефакты мы можем получить:

• инсайт, ответ на вопрос почему;

• автоматизированный отчет (дашборд);

• ML-модели;

• код системы анализа данных.

Почти все эти задачи объединяет наличие программного кода. Исключением может быть разве что инсайт, для поиска которого порой достаточно обычного Excel, а программирование могло не потребоваться.

Для проверки программного кода проводится код-ревью (code review). На этом этапе какой-либо сотрудник (не исполнитель) изучает программный код, чтобы понять, насколько этот способ решения задачи корректен и соответствует стилистическому подходу, принятому в команде. Эта практика широко применяется в разработке ПО.

Когда пишете программу, всегда относитесь к ней как к тексту, который будет читать другой человек. Раньше, когда программу писал и поддерживал один человек, это было не так важно. Сейчас разработка ПО – это командная работа, в которой должно быть гарантировано качество. Компьютеру все равно, как выглядит ваша программа стилистически, а людям – нет. Те, кто будет работать с вашим кодом в дальнейшем – проверять его, оптимизировать скорость работы, переносить на другую платформу, – должны понимать его без лишних усилий. Если код вызывает вопросы, автора просят внести изменения так, чтобы текст стал читаемым и однозначным. Это одна из целей инспекции. Аналогичные стандарты работы действуют и в аналитике. Но есть несколько отличий от обычной разработки, расскажу о них далее.

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

• все изменения будут прозрачны;

• в случае ухода разработчика/аналитика весь код останется у вас;

• если возникнут проблемы – легко откатить изменения, вернувшись к прошлой версии.

Инспекцию кода относительно легко сделать для всех артефактов аналитики, кроме инсайтов. C инсайтами не все так однозначно. Для их поиска и выкладок используются разные инструменты: Excel или его аналоги, графический интерфейс аналитической системы, SQL, блокноты Python или другого языка (например, Jupyter Notebooks). В таких задачах обычно присутствует несколько этапов:

• получение данных;

• их очистка;

• анализ;

• выводы.

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

Есть одна проблема с блокнотами (jupyter notebooks) – скрытые ошибки. В блокнотах выполняются разовые задачи (ad-hoc), и поэтому аналитики пренебрегают стандартами разработки – инспекциями кода и тестами. Как с этим бороться? Есть несколько способов проверить код и выводы.

Во-первых, проверяющий может очень внимательно просмотреть все решение на предмет ошибок. Это трудоемко, ведь по сути ему придется построить решение чуть ли не с нуля в своей голове. Во-вторых, можно воспользоваться другими источниками данных, которые хотя бы косвенно могли бы подтвердить вывод. В-третьих, можно последовать совету Кэсси Козырьков, директора по принятию решений в Google, из ее статьи «Самая мощная идея в анализе данных» [26]: сделать случайное разделение данных на два датасета (набора данных). По первому набору аналитик будет искать причину, а по второму проверяющий проверит выводы аналитика. Такой подход всегда используется в машинном обучении и называется валидацией (validation).