Гипотезы, как и задачи, имеют свой жизненный цикл. Во-первых, все гипотезы нужно очень четко приоритизировать, поскольку трудоемкость огромная и результат на практике появится далеко не сразу. Ошибка в приоритизации будет дорого стоить. Я считаю, что приоритизация гипотез должна быть извне: цели должен определять бизнес. Обычно в интернет-компаниях это делает отдел продукта. Они общаются с клиентами и знают, что будет лучше для них. Моя персональная ошибка в Retail Rocket была в том, что я первые годы приоритизировал гипотезы сам. Аналитики варились в собственном соку, придумывали гипотезы, приоритизировали их, экспериментировали. Да, мы неплохо оптимизировали алгоритмы, этот задел нам пригодился в конкурентной борьбе. Но если бы мы тогда больше думали о том, чего хочет клиент, то добились бы большего. Я списываю это на то, что аналитики в какой-то момент стали слишком квалифицированны (overqualified) и бизнес за нами не поспевал. Оценить гипотезу, понять ее потенциальную пользу, найти баланс между трудоемкостью и ее эффектом – это искусство.
Интересно, что на Западе такие проблемы тоже актуальны. В 2016 году я подал заявку на доклад «Тестирование гипотез: как уничтожить идею как можно быстрее» [23] на международную конференцию RecSys по рекомендательным системам. Туда очень сложно попасть, все доклады проходят инспекцию несколькими учеными. Предыдущую нашу заявку на доклад [24] отклонили, но в этот раз моя тема оказалась достаточно актуальной, чтобы доклад приняли в программу. Я выступил в концертном зале MIT в Бостоне. В докладе был рассказ о том, как мы проверяем гипотезы. Помню, что страшно волновался, текст учил чуть ли не наизусть. Но все прошло хорошо, я даже получил лично положительный отзыв от Шавье Аматриана, экс-руководителя аналитики Netflix, он был одним из организаторов конференции. Тогда Аматриан пригласил меня на собеседование в офис компании Quora, топ-менеджером которой он был в то время – видимо, мой рассказ о тестировании гипотез произвел впечатление.
Как управлять романтиками
Идеальный менеджер в моем представлении:
• идет напрямую к цели;
• относится человечно к людям;
• делает из любого хаоса, даже творческого, рутину;
• удовлетворяет страсть сотрудников к интересным и развивающим задачам.
На последнем пункте я бы хотел остановиться подробнее. В прошлой главе я описал конфликт исследователя и бизнеса: исследователь хочет сделать что-то значимое, используя самые последние разработки ML, бизнесу часто это не нужно. Как этим можно управлять? В нашей работе аналитиков и инженеров машинного обучения создание алгоритма занимает 5–10 % времени, а остальные 90 % уходят на то, чтобы заставить новый алгоритм приносить прибыль. Этот конфликт – основная причина, по которой я терял сотрудников.
Консервативный бизнес не хочет оплачивать дорогостоящие исследования с непонятным результатом. Чем крупнее компания, тем ей проще это делать; в больших компаниях есть даже такая должность – инженер по исследованиям (research scientist). Но с ними другая проблема – наука есть, а жизни нет: не видят исследователи реального применения, и это их демотивирует. Поэтому важно найти баланс. Обсудим роль менеджера аналитики в его достижении.
Как известно, бизнес должен быть устойчивым по отношению к персоналу. Эта устойчивость достигается автоматизацией, «автобусным» числом, построенными процессами – когда все творческое, хаотическое оборачивается в процессы и становится рутиной. Когда я пишу эти строки, представляю сборочный конвейер, у которого нет души, а люди подходят и на разных этапах крутят разные гайки. Все задачи максимально приземленные. И вот когда все отлажено до состояния идеально смазанной машины, нужно впускать в поток интересные для ваших сотрудников задачи. Мне лично всегда очень непросто их найти. Требования к ним я бы предъявил следующие:
• в перспективе результат должен принести пользу;
• техническая поддержка задачи может работать без ее создателя.
Иначе исследователь слепит огромный космический корабль, который не полетит, а после увольнения исследователя на его место придет другой и будет строить корабль заново. В любом случае лучше относиться к таким проектам как к венчурной инвестиции. И обычно результат достигается только тогда, когда уже вся компания подключилась к проекту, – а это уже посерьезнее, чем просто исследование.
Приведу пример. Один из внутренних продуктов компании Retail Rocket в аналитике по NLP-анализу (анализ семантики текста) написан на глубоких нейронных сетях (Deep Learning). Проект, который начинался как «игрушечный», оказался довольно сложным и интересным с точки зрения развития. В процессе работы удалось доказать его эффективность, и сейчас он в строю. Бывали и проблемные проекты. Например, мы пытались сделать сопутствующие товары («С этим товаром часто покупают») для магазинов одежды, опираясь на стилевую сочетаемость [25]. Для проекта использовались сиамские нейронные сети, и у нас все получилось с точки зрения визуальных образов. Провели тестирование на коммерческих сайтах – улучшений не увидели. Пришлось признать гипотезу неудачной.
Глава 4
Делаем аналитические задачи
Глава состоит из двух частей: сначала я расскажу о самой организации анализа данных в виде задач, а потом непосредственно об анализе данных.
Как ставить задачи аналитикам
В прошлой главе я написал про доску статусов задачи. Сейчас мы подробно рассмотрим сами задачи. В идеале в тексте задачи перед ее планированием должны быть такие атрибуты:
• инициатор;
• причина возникновения задачи;
• ожидаемый результат;
• требуемые сроки и приоритет.
Инициатор – лицо, которому нужны результаты задачи для принятия решения. Очень важно, чтобы это не был посредник. Обычно руководители любят присылать такие задачи от лица своих сотрудников, в лучшем случае заместителей. Но лицом, принимающим решение, будет сам руководитель. Планирование исполнения задачи (трудоемкость, сроки и результат) – это переговоры, во время которых часто задача сильно меняется или даже отменяется, если появляются более простые пути ее решения. Часто у самого посредника не хватает власти, чтобы принять решение самостоятельно. Как вы думаете, можно ли договориться с посредником сразу? Нет, он пойдет к своему руководителю и потом вернется. Такой «футбол» отнимает много времени. Нужен ли инициатор задачи на таких переговорах при планировании? Да, потому что любая профессиональная коммуникация – это заключение контракта, а контракт подразумевает переговоры. Инициатор хочет получить от аналитиков обязательства по выполнению задачи, на которую они потратят много времени: часы и даже дни. Так почему же инициатор не может потратить 10 минут своего времени, чтобы договориться лично? Для меня это сигнал, что задача не так важна, и лучше заняться более приоритетными вещами.
