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

• Задача проходит проверку на правильность реализации (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, топ-менеджером которой он был в то время – видимо, мой рассказ о тестировании гипотез произвел впечатление.