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

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

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

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

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

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

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

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

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

Как проверять задачи

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

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

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

• ML-модели;

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

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

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

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

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

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

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

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

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

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

• их очистка;

• анализ;

• выводы.