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

Кому подчиняются аналитики

В идеале аналитики должны быть независимы от менеджеров, которых они оценивают. Тут принцип – кто платит, тот и музыку заказывает. Не может сотрудник менеджера объективно оценить его работу. Решать задачи отдела может (помните про децентрализацию из прошлой главы?), но оценивать – нет. Здесь нужна независимость от операций. Я бы рекомендовал, чтобы центральный аналитический отдел подчинялся генеральному директору, финансам или IT. Список дан в порядке приоритета. У меня был опыт подчинения генеральному директору, директору по маркетингу и IT. Первый вариант был самым лучшим опытом – внешнее давление минимально. Но в этом есть и проблема: как правило, менеджеры не знают, как управлять аналитикой, а генеральному директору еще и времени не хватает. Руководителю аналитики придется проявить недюжинную самостоятельность. Я лично получал задания в духе: «найди что-нибудь интересненькое». Эту книгу я начал писать в том числе и для того, чтобы ее прочитали топ-менеджеры, которым подчиняется аналитика. Мне бы этого очень хотелось!

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

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

Я попал на собеседование в Quora на должность менеджера. Послушав, чем я занимаюсь, директор по аналитике Шавье Аматриан (Xavier Amatriain) мне прямо сказал: ты ни то ни сё – не менеджер и не разработчик. И не принял меня на работу. Этот сигнал заставил меня задуматься: за двумя зайцами погонишься – ни одного не поймаешь. Что на самом деле очень сложно совмещать работу сотрудника и менеджера и при этом быть эффективным во всем.

Однажды мне на глаза попался ответ Эрика Колсона (который тогда руководил аналитикой Netfliх) на Quora [20]:

«…главная задача менеджера – наем (это действительно непросто – найти отличного аналитика данных). Далее организация команд – не только аналитиков, но и работа с другими командами в организации (Продукт, Инженеры, Маркетинг и т. д.). Затем коммуникация, координация, наставничество и т. д. Для менеджера не остается времени для решения аналитических задач, и, следовательно, это делегируется. Технические навыки лидера команды атрофируются».

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

Важный аспект – мотивация менеджера. Я люблю цитировать конспект лекций «You and your research» [21] Ричарда Хэмминга. Ричард работал в лаборатории Bell Labs, в том числе с Клодом Шенноном (основателем теории информации). Как и многие знаменитые ученые того времени, Хэмминг работал над проектом первой атомной бомбы США. Сама лаборатория была очень мощной: там изобрели первый транзистор, ученые лаборатории получили семь Нобелевских премий в разных областях. Его попросили сравнить исследовательскую работу и менеджмент, и вот что он ответил:

«Если вы хотите быть великим исследователем, вы не станете им, будучи президентом компании. Другое дело, если вы хотите быть президентом компании. Я не против того, чтобы быть президентом компании. Я просто не хочу. Я думаю, Иан Росс делает хорошую работу в качестве президента Bell Labs. Я не против этого; но вы должны четко понимать, чего хотите. Еще, когда вы молоды, вы можете захотеть быть великим ученым, но пожив больше, вы можете изменить мнение. Например, я пошел однажды к своему боссу, Боду, и спросил: “Почему ты вообще стал главой департамента? Почему ты не остался просто хорошим ученым?” Он ответил: “Хэмминг, у меня было видение того, какой должна быть математика в Bell Laboratories. И я понимал, что, чтобы это видение воплотилось, это должен был сделать я; я должен был быть главой департамента”. Когда вы можете в одиночку воплотить то, что хотите, тогда вам следует этим заниматься. Как только ваше видение того, что, как вы считаете, должно быть сделано, больше того, что вы можете сделать в одиночку, вам надо двигаться в менеджмент. И чем больше видение, тем дальше в менеджмент вам надо идти. Если у вас есть видение того, какой должна быть вся лаборатория или вся Bell System, вам надо идти туда, чтобы это осуществить. Вы не можете это осуществить легко снизу.

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

Есть один минус полного перехода в менеджмент – атрофия технических навыков. Менеджеру будет сложно вернуться в работу руками, а такое иногда бывает, например, когда создают стартап. По этому поводу Колсон написал [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), увеличить средний чек покупки, среднее количество заказов в товаре и даже визуальную привлекательность рекомендуемых товаров. Рационализаторские предложения могут быть разными: от исправления ошибки в алгоритме до внедрения алгоритма машинного обучения на нейронных сетях. Мы старались все изменения алгоритмов прогонять через гипотезы. Потому что даже исправление несложной ошибки в реальной жизни может привести к ухудшению метрики.

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

Интересно, что на Западе такие проблемы тоже актуальны. В 2016 году я подал заявку на доклад «Тестирование гипотез: как уничтожить идею как можно быстрее» [23] на международную конференцию RecSys по рекомендательным системам. Туда очень сложно попасть, все доклады проходят инспекцию несколькими учеными. Предыдущую нашу заявку на доклад [24] отклонили, но в этот раз моя тема оказалась достаточно актуальной, чтобы доклад приняли в программу. Я выступил в концертном зале MIT в Бостоне. В докладе был рассказ о том, как мы проверяем гипотезы. Помню, что страшно волновался, текст учил чуть ли не наизусть. Но все прошло хорошо, я даже получил лично положительный отзыв от Шавье Аматриана, экс-руководителя аналитики Netflix, он был одним из организаторов конференции. Тогда Аматриан пригласил меня на собеседование в офис компании Quora, топ-менеджером которой он был в то время – видимо, мой рассказ о тестировании гипотез произвел впечатление.

Как управлять романтиками

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

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

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

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

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

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

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

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

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

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

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

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

Глава 4
Делаем аналитические задачи

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

Как ставить задачи аналитикам

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

• инициатор;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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