• в перспективе результат должен принести пользу;
• техническая поддержка задачи может работать без ее создателя.
Иначе исследователь слепит огромный космический корабль, который не полетит, а после увольнения исследователя на его место придет другой и будет строить корабль заново. В любом случае лучше относиться к таким проектам как к венчурной инвестиции. И обычно результат достигается только тогда, когда уже вся компания подключилась к проекту, – а это уже посерьезнее, чем просто исследование.
Приведу пример. Один из внутренних продуктов компании Retail Rocket в аналитике по NLP-анализу (анализ семантики текста) написан на глубоких нейронных сетях (Deep Learning). Проект, который начинался как «игрушечный», оказался довольно сложным и интересным с точки зрения развития. В процессе работы удалось доказать его эффективность, и сейчас он в строю. Бывали и проблемные проекты. Например, мы пытались сделать сопутствующие товары («С этим товаром часто покупают») для магазинов одежды, опираясь на стилевую сочетаемость [25]. Для проекта использовались сиамские нейронные сети, и у нас все получилось с точки зрения визуальных образов. Провели тестирование на коммерческих сайтах – улучшений не увидели. Пришлось признать гипотезу неудачной.
Глава 4
Делаем аналитические задачи
Глава состоит из двух частей: сначала я расскажу о самой организации анализа данных в виде задач, а потом непосредственно об анализе данных.
Как ставить задачи аналитикам
В прошлой главе я написал про доску статусов задачи. Сейчас мы подробно рассмотрим сами задачи. В идеале в тексте задачи перед ее планированием должны быть такие атрибуты:
• инициатор;
• причина возникновения задачи;
• ожидаемый результат;
• требуемые сроки и приоритет.
Инициатор – лицо, которому нужны результаты задачи для принятия решения. Очень важно, чтобы это не был посредник. Обычно руководители любят присылать такие задачи от лица своих сотрудников, в лучшем случае заместителей. Но лицом, принимающим решение, будет сам руководитель. Планирование исполнения задачи (трудоемкость, сроки и результат) – это переговоры, во время которых часто задача сильно меняется или даже отменяется, если появляются более простые пути ее решения. Часто у самого посредника не хватает власти, чтобы принять решение самостоятельно. Как вы думаете, можно ли договориться с посредником сразу? Нет, он пойдет к своему руководителю и потом вернется. Такой «футбол» отнимает много времени. Нужен ли инициатор задачи на таких переговорах при планировании? Да, потому что любая профессиональная коммуникация – это заключение контракта, а контракт подразумевает переговоры. Инициатор хочет получить от аналитиков обязательства по выполнению задачи, на которую они потратят много времени: часы и даже дни. Так почему же инициатор не может потратить 10 минут своего времени, чтобы договориться лично? Для меня это сигнал, что задача не так важна, и лучше заняться более приоритетными вещами.
Причину возникновения задачи необходимо обозначить. Она пригодится всем: инициатор осознает ее, аналитики понимают контекст, а значит, быстрее найдут способы решения. Есть еще один фактор – все могут попросту забыть эту причину. И когда через продолжительное время необходимо поднять результаты задачи, будет намного проще, если причина была описана в ней.
Ожидаемый результат – это форма ответа, которая устроит инициатора задачи. Результаты могут быть разными: просто текст причины с обоснованием, таблица с данными, графики, выгрузка данных для внешней системы. На встрече планирования инициатор должен объяснить, почему ему нужны результаты именно в таком виде и что он потом с ними сделает. Или хотя бы сообщить, что это его личное предпочтение для принятия решения. От формы результатов зависит трудоемкость задачи. Одно дело – написать короткое сообщение с парой цифр, другое – сделать большой отчет с графиками и выкладками. Обычно задачи для внутреннего пользования выглядят проще, чем, например, отчеты для клиентов.
Требуемые сроки и приоритет позволят тщательнее выстроить очередь исполнения задач. Никто не любит задачи, которые нужно было выполнить вчера, особенно если поставлены они были сегодня. Это и есть качество менеджмента: подумать и поставить задачу заранее. По соотношению таких задач можно судить об управленческих качествах менеджмента. На своей практике я часто видел, как такие задачи «перегорали» и были уже не интересны заказчику после их выполнения.
Давайте рассмотрим два примера задач: хорошая постановка и плохая. Начнем с хорошей. По электронной почте приходит письмо, текст задачи хорошо формализован: