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

Идеальный менеджер в моем представлении:

• идет напрямую к цели;

• относится человечно к людям;

• делает из любого хаоса, даже творческого, рутину;

• удовлетворяет страсть сотрудников к интересным и развивающим задачам.

На последнем пункте я бы хотел остановиться подробнее. В прошлой главе я описал конфликт исследователя и бизнеса: исследователь хочет сделать что-то значимое, используя самые последние разработки ML, бизнесу часто это не нужно. Как этим можно управлять? В нашей работе аналитиков и инженеров машинного обучения создание алгоритма занимает 5–10 % времени, а остальные 90 % уходят на то, чтобы заставить новый алгоритм приносить прибыль. Этот конфликт – основная причина, по которой я терял сотрудников.

Консервативный бизнес не хочет оплачивать дорогостоящие исследования с непонятным результатом. Чем крупнее компания, тем ей проще это делать; в больших компаниях есть даже такая должность – инженер по исследованиям (research scientist). Но с ними другая проблема – наука есть, а жизни нет: не видят исследователи реального применения, и это их демотивирует. Поэтому важно найти баланс. Обсудим роль менеджера аналитики в его достижении.

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

• в перспективе результат должен принести пользу;

• техническая поддержка задачи может работать без ее создателя.

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

Приведу пример. Один из внутренних продуктов компании Retail Rocket в аналитике по NLP-анализу (анализ семантики текста) написан на глубоких нейронных сетях (Deep Learning). Проект, который начинался как «игрушечный», оказался довольно сложным и интересным с точки зрения развития. В процессе работы удалось доказать его эффективность, и сейчас он в строю. Бывали и проблемные проекты. Например, мы пытались сделать сопутствующие товары («С этим товаром часто покупают») для магазинов одежды, опираясь на стилевую сочетаемость [25]. Для проекта использовались сиамские нейронные сети, и у нас все получилось с точки зрения визуальных образов. Провели тестирование на коммерческих сайтах – улучшений не увидели. Пришлось признать гипотезу неудачной.

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

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

• инициатор;

• причина возникновения задачи;

• ожидаемый результат;

• требуемые сроки и приоритет.

Инициатор – лицо, которому нужны результаты задачи для принятия решения. Очень важно, чтобы это не был посредник. Обычно руководители любят присылать такие задачи от лица своих сотрудников, в лучшем случае заместителей. Но лицом, принимающим решение, будет сам руководитель. Планирование исполнения задачи (трудоемкость, сроки и результат) – это переговоры, во время которых часто задача сильно меняется или даже отменяется, если появляются более простые пути ее решения. Часто у самого посредника не хватает власти, чтобы принять решение самостоятельно. Как вы думаете, можно ли договориться с посредником сразу? Нет, он пойдет к своему руководителю и потом вернется. Такой «футбол» отнимает много времени. Нужен ли инициатор задачи на таких переговорах при планировании? Да, потому что любая профессиональная коммуникация – это заключение контракта, а контракт подразумевает переговоры. Инициатор хочет получить от аналитиков обязательства по выполнению задачи, на которую они потратят много времени: часы и даже дни. Так почему же инициатор не может потратить 10 минут своего времени, чтобы договориться лично? Для меня это сигнал, что задача не так важна, и лучше заняться более приоритетными вещами.

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

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

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

Давайте рассмотрим два примера задач: хорошая постановка и плохая. Начнем с хорошей. По электронной почте приходит письмо, текст задачи хорошо формализован: