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

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

Иллюстрации Владимира Вышванюка

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

© ООО Издательство «Питер», 2021

© Серия «IT для бизнеса», 2021

© Роман Зыков, 2021

Об авторе

Роман Владимирович Зыков, 1981 года рождения, в 2004 году получил степень бакалавра, а затем магистра прикладной физики и математики в МФТИ (Московском физико-техническом институте).

В 2002 году начал свой карьерный путь в аналитике данных (Data Science) в качестве технического консультанта в компании StatSoft Russia, российского офиса одноименной американской компании-разработчика пакета статистического анализа данных STATISTICA. В 2004 году был принят на должность руководителя аналитического отдела интернет-магазина Ozon.ru, где создавал аналитические системы с нуля, в том числе веб-аналитику, аналитику баз данных, управленческую отчетность, внес вклад в систему рекомендаций.

В 2009 году консультировал ряд проектов инвестиционного фонда Fast Lane Ventures и гейм-индустрии.

В 2010 году возглавил отдел аналитики в интернет-ритейлере Wikimart.ru.

В конце 2012 года стал сооснователем и совладельцем маркетинговой платформы для интернет-магазинов RetailRocket.ru. На текущий момент компания является безусловным лидером на рынке в России и успешно работает на рынках Чили, Голландии, Испании и других.

С 2007-го вел блог «Аналитика на практике» (KPIs.ru – ныне не существует), где евангелизировал анализ данных в применении к бизнес-задачам в электронной коммерции. Выступал на отраслевых конференциях, таких как РИФ, iMetrics, Gec 2014 вместе с Аркадием Воложем (Yandex), бизнес-конференциях в Дублине и Лондоне, в посольстве США (AMC Center), университете Сбербанка. Печатался в технологическом прогнозе PwC, ToWave, «Ведомостях», «Секрете фирмы».

В 2016 году прочитал мини-лекцию в концертном зале MIT в Бостоне о процессах тестирования гипотез.

В 2020 году был номинирован на премию CDO Award.

Благодарности

Я посвящаю эту книгу своей жене Екатерине и моим детям – Аделле и Альберту. Катя придала мне решимости написать книгу и приняла большое участие в редактировании текстов. За что я ей очень благодарен.

Также я благодарен своим родителям, которые вырастили и воспитали меня в очень непростое время. Отдельная благодарность моему отцу Владимиру Юрьевичу за то, что привил мне любовь к физике.

Я благодарен всем на моем долгом пути в аналитику данных. Илье Полежаеву, Большакову Павлу и Владимиру Боровикову за грамотное руководство, когда я только пришел в StatSoft. Бернару Люке, тогда генеральному директору Ozon.ru, а также коллегам в Ozon.ru: Александру Перчикову, Александру Алехину, Валерию Дьяченко – за совместное написание рекомендательной системы. Марине Туркиной и Ирине Коткиной – с вами было замечательно сотрудничать. Основателям проекта Wikimart.ru Камилю Курмакаеву и Максиму Фалдину – те знакомства в Калифорнии очень сильно повлияли на меня. Александру Аникину – ты очень крутой был тогда, а сейчас вообще звезда. Основателям проекта Ostrovok.ru – Кириллу Махаринскому и Сержу Фаге, а также Жене Курышеву, Роману Богатову, Феликсу Шпильману – с вами очень интересно было работать, я узнал много нового о разработке.

Я благодарен сооснователям Retail Rocket – Николаю Хлебинскому и Андрею Чижу. Отдельная благодарность венчурному фонду Impulse VC (Кириллу Белову, Григорию Фирсову, Евгению Пошибалову) – за то, что поверили в нас. Всем сотрудникам Retail Rocket, особенно моим ребятам Александру Анохину и Артему Носкову – вы лучшие.

Я благодарен психологу Елене Клюстер, с которой работаю уже несколько лет, за осознание своих собственных границ и своих истинных желаний. Благодарен Андрею Гузю, моему тренеру по плаванию, за аналитический подход к тренировкам. Оказывается, так можно, и не только профессионалам, но и любителям.

Выражаю благодарность всем моим виртуальным рецензентам, особенно Артему Аствацатурову, Александру Дмитриеву, Аркадию Итенбергу, Алексею Писарцову. Роману Нестеру – за рецензию на главу по этике данных.

Благодарен всем, кто способствовал изданию этой книги. Прежде всего Алексею Кузменко, который помог мне быстро найти издательство, минуя бюрократические препоны. Отдельная благодарность Владимиру Вышванюку за ироничные иллюстрации кота Вилли. Юлии Сергиенко и Наталье Римицан, которые делали все, чтобы эта книга вышла в свет.

От издательства

Ваши замечания, предложения, вопросы отправляйте по адресу [email protected] (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.

Введение

Дайте мне точку опоры, и я переверну Землю.

Архимед

Дайте мне данные, и я переверну всю вашу жизнь.

Data Scientist Архимед

Данные повсюду – начиная от алгоритмов «Тиндера», который «матчит» вас с далеко не случайными людьми, и заканчивая информационными войнами, которые ведут политики. Никого уже не удивляет, что за каждым нашим шагом пристально следят: будь то история запросов в браузере телефона или ваши действия в офлайне. Задержитесь на секунду у витрины спортивного магазина – и ждите его таргетированную рекламу в соцсетях с минуты на минуту. Расскажите коллеге, что натворил ваш кот, – и вот сухие корма и наполнители уже тут как тут в вашей ленте.

Особо впечатлительные могут впасть в паранойю – но данные в этом не виноваты. Все зависит от того, в чьи руки они попадут. С анализом данных связано очень много мифов, а data scientist – одна из самых перспективных и «сексуальных» профессий будущего. В своей книге я намерен развенчать мифы и рассказать, как все обстоит на самом деле. Надеюсь, читатель, ты, как и я, окажешься на «светлой» стороне силы.

Я окончил МФТИ в начале нулевых и тогда же возглавил аналитический отдел интернет-магазина Ozon.ru, где создавал аналитические системы с нуля. Я консультировал инвестиционные фонды, гигантов ритейла и гейм-индустрии, а восемь лет назад стал сооснователем и совладельцем маркетинговой платформы для интернет-магазинов RetailRocket.ru. Сейчас компания не просто является безусловным лидером на рынке в России, но и успешно работает на рынках Чили, Голландии, Испании и Германии. В 2016 году я прочитал лекцию в концертном зале MIT в Бостоне про процессы тестирования гипотез. В 2020 году номинировался на премию CDO Award.

Считается, что нужно потратить 10 000 часов для того, чтобы стать очень хорошим специалистом в своей области. Анализом данных я занимаюсь с 2002 года, когда это не было так популярно и хайпово. Так вот, чтобы получить эти заветные 10 000 часов, нужно проработать 10 000 часов / 4 часа в день / 200 дней в году = 12.5 лет. Я в полтора раза превысил эту цифру, поэтому, надеюсь, получилось написать книгу, которая будет очень полезна для вас, дорогие читатели.

Эта книга о том, как превращать данные в продукты и решения. Она основывается не на академических знаниях, а на моем личном опыте анализа данных длиной почти в двадцать лет. Сейчас существует очень много курсов по анализу данных (data science) и машинному обучению (machine learning, ML). Как правило, они узкоспециализированы. Отличие этой книги в том, что она, не утомляя частностями, дает цельную картину и рассказывает о том:

• как принимать решения на основе данных;

• как должна функционировать система;

• как тестировать ваш сервис;

• как соединить все в единое целое, чтобы на выходе получить «конвейер» для ваших данных.

Для кого эта книга

Эта книга предназначена для думающих читателей, которые хотят попробовать свои силы в области анализа данных и создавать сервисы на их основе.

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

Как читать эту книгу

Я писал эту книгу так, чтобы ее можно было читать непоследовательно. Краткое содержание каждой главы:

Глава 1 «Как мы принимаем решения» описывает общие принципы принятия решения, как данные влияют на них.

Глава 2 «Делаем анализ данных» вводит общие понятия – с какими артефактами мы имеем дело, когда анализируем данные. Кроме того, с этой главы я начинаю поднимать организационные вопросы анализа данных.

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

Глава 4 «Делаем аналитические задачи» – полностью о задачах. Что такое хорошая аналитическая задача, как ее проверить. Технические атрибуты таких задач – датасеты, описательные статистики, графики, парный анализ, технический долг.

Глава 5 «Данные» о том, что говорят о данных – объемы, доступы, качество и форматы.

Глава 6 «Хранилища данных» рассказывает, зачем нужны хранилища, какие они бывают, также затрагиваются популярные системы для Big Data – Hadoop и Spark.

Глава 7 «Инструменты анализа данных», полностью посвящена наиболее популярным способам анализа от электронных таблиц в Excel до облачных систем.

Глава 8 «Алгоритмы машинного обучения» является базовым введением в машинное обучение.

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

Глава 10 «Внедрение ML в жизнь: гипотезы и эксперименты» рассказывает о трех видах статистического анализа экспериментов (статистика Фишера, байесовская статистика и бутстрэп) и об использовании А/Б-тестов на практике.

Глава 11 «Этика данных». Я не смог пройти мимо этой темы, наша область начинает все больше и больше регулироваться со стороны государства. Здесь поговорим о причинах этих ограничений.

Глава 12 «Задачи и стартапы» рассказывает об основных задачах, которые я решал в e-commerce, а также о моем опыте сооснователя проекта Retail Rocket.

Глава 13 «Строим карьеру» больше предназначена для начинающих специалистов – как искать работу, развиваться и даже когда уходить дальше.

Глава 1
Как мы принимаем решения

«Итак, главный принцип – не дурачить самого себя. А себя как раз легче всего одурачить. Здесь надо быть очень внимательным. А если вы не дурачите сами себя, вам легко будет не дурачить других ученых. Тут нужна просто обычная честность.

Я хочу пожелать вам одной удачи – попасть в такое место, где вы сможете свободно исповедовать ту честность, о которой я говорил, и где ни необходимость упрочить свое положение в организации, ни соображения финансовой поддержки – ничто не заставит вас поступиться этой честностью. Да будет у вас эта свобода».

Нобелевский лауреат Ричард Фейнман, из выступления перед выпускниками Калтеха в 1974 году

Монетизация данных возможна лишь тогда, когда мы принимаем на основе этих данных правильные решения. Однако делать выбор, руководствуясь только статистикой, – плохая идея: как минимум нужно уметь читать их между строк и слушать свою интуицию (gut feeling). Поэтому в первой главе я расскажу про принципы, которыми я пользуюсь, принимая решения на основе данных. Я проверял на своем опыте – они работают.

Решения принимать непросто, ученые даже придумали новый термин «усталость от решений» (decision fatigue) [7]. Мы накапливаем стресс, совершая выбор каждый день сотни раз: и в какой-то момент, когда уже полностью вымотаны необходимостью принимать решения, можем махнуть рукой и начать действовать наугад. Я не зря привел в начале этой книги цитату выдающегося физика, нобелевского лауреата Ричарда Фейнмана. Она напрямую касается как аналитики данных, так и вообще нашей жизни.

Как принимать верные решения, оставаясь честным с собой?

В книге «Биология добра и зла. Как наука объясняет наши поступки» профессор Стэнфордского университета, нейробиолог Роберт Сапольски [1] пишет, что на наши поступки, а значит и решения, влияет множество факторов: cреда, в которой мы выросли, детские травмы, травмы головы, гормональный фон, чувства и эмоции. На нас всегда влияет множество факторов, которые мы даже не осознаем. Мы необъективны!

Лично я принял как данность, что гораздо легче принять необъективное и срезать углы, чем объективное, потому что для второго нужны серьезные усилия.

Вспомните об этом, когда будете предоставлять цифры кому-либо для принятия решения. И даже мои сотрудники указывали мне на то, что я сам нарушаю принципы объективности при утверждении результатов некоторых А/Б-тестов. Тогда я возвращался к реальности и соглашался с ними – объективность важнее моих априорных решений до проведения эксперимента.

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

Четыреста сравнительно честных способов

Остап Бендер знал четыреста сравнительно честных способов отъема денег у населения. Профессиональный аналитик знает примерно столько же способов «повернуть» цифры в сторону «нужного» решения. К сожалению, это очень распространено в политике: вспомните, как государства рапортовали о количестве зараженных во время пандемии вируса COVID-19. Показатели смертности в России были занижены [6]. Оказалось, что если человек болел коронавирусом и умер от сопутствующего заболевания, то в соответствующую статистику не попадет. В большинстве же западных стран одной положительной пробы на коронавирус было достаточно, чтобы попасть в статистику. Если копнуть глубже, мы видим, что у всех разная методика и разные цели. Существуют объективные и субъективные причины неточности таких цифр.

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

Вторая причина тоже объективная – нет денег на массовое тестирование населения.

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

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

Чему можно научиться у Amazon?

Мне всегда нравились письма Джеффа Безоса (основателя Amazon.com) акционерам. Например, еще в 1999 году он писал про важность систем персональных рекомендаций на сайте, которые сейчас стали стандартом в современной электронной коммерции. Меня заинтересовали два его письма: 2015 [2] и 2016 [3] годов.

В первом из них Безос писал про «Фабрику изобретений» (Invention Machine). Он точно знает, о чем говорит, – само провидение вело Amazon через тернии электронной коммерции. Попутно в компании изобретали много вещей, абсолютно новых для рынка: система рекомендаций, А/Б-тесты (да-да, именно они были пионерами тестирования гипотез для веба), AWS (Amazon Web Services), роботизация склада, кнопки на холодильник для мгновенного заказа порошка и многое другое.

Так вот, в первом письме он рассуждает о том, как в больших компаниях принимаются решения об изобретении новых продуктов. Часто процесс утверждения выглядит так: все участники процесса (как правило, руководители департаментов компании) проставляют свои «визы». Если решение положительное, идея или гипотеза отправляются на реализацию. Здесь Безос предупреждает, что есть два типа решений и они не должны проходить один и тот же процесс утверждения.

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

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

В письме 2016 года Безос противопоставляет компанию Дня 1 (Day 1), где сохраняется живая атмосфера создания компании и новых продуктов, компании Дня 2 (Day 2), которая статична и, как следствие, приходит к своей ненужности и смерти. Он выделяет 4 фактора, которые определяют компанию Дня 1:

• истинная одержимость покупателем (customer obsession);

• скепсис относительно моделей (a skeptical view of proxies);

• стремительное освоение внешних трендов (the eager adoption of external trends);

• стремительное принятие решений (the eager adoption of external trends).

Последний пункт мне кажется особенно важным в контексте этой книги. Для поддержания атмосферы компании Дня 1 требуется принимать быстрые и качественные решения. Мой шестилетний сын в таких случаях восклицает: «Но как?» Вот правила Безоса:

1. Никогда не использовать один-единственный процесс принятия решений (есть два типа решений, про которые я написал выше). Не дожидаться получения 90 % всей информации, нужной для принятия решения, – 70 % уже достаточно. Ошибаться не так страшно, если вы умеете быстро исправляться. А вот промедление, скорее всего, влетит вам в копеечку.

2. Не соглашайся, но позволяй. Когда руководителю предлагают идею талантливые и успешные сотрудники, а он не согласен с ней – ему стоит просто позволить им ее реализовать, а не тратить их усилия на то, чтобы убедить. Безос рассказал, как дали зеленый свет одному из сериалов Amazon Studios. Он считал, что запускать этот проект рискованно: Безосу эта история казалась сложной в производстве и не слишком интересной. Но команда с ним не соглашалась. Тогда он сказал – хорошо, давайте пробовать. Им не пришлось убеждать Безоса в своей правоте, и они сэкономили уйму времени. Сам он подумал так: эти ребята уже привезли домой одиннадцать премий «Эмми», шесть «Золотых Глобусов» и три «Оскара» – они знают, что делают, просто у нас разные мнения.

3. Быстро находите причины несогласия и эскалируйте их наверх вашим руководителям. Разные команды могут иметь разные взгляды на решение. Вместо того чтобы тратить время на изматывающих совещаниях в попытках договориться – лучше эскалировать проблему наверх.

Аналитический паралич

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

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

Яркий пример – книга «Проект Рози» Грэма Симсиона (кстати, одна из любимых книг Билла Гейтса и его жены). Молодой успешный ученый-генетик Дон ищет жену, но ни разу еще не продвинулся дальше первого свидания. Сочтя традиционный способ поиска второй половинки неэффективным, Дон решает применить научный подход. Его проект «Жена» начинается с подробнейшего 30-страничного вопросника, призванного отсеять всех неподходящих и выявить одну – идеальную. Понятно, что человека, который соответствовал бы такому списку требований, просто не существует. А потом он знакомится с девушкой, у которой нет ничего общего с его идеалом. Что из этого вышло – догадайтесь сами.

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

Третий пример из моей профессиональной практики связан с гипотезами, точнее с тестами. Представьте себе, что вы вместо старого алгоритма рекомендаций разработали новый и хотите его протестировать. У вас есть 10 сайтов, где можно выполнить сравнение. В итоге вы получили: 4 выигрыша, 4 ничьи и 2 проигрыша. Стоит ли заменить старый алгоритм на новый? Все зависит от критериев решения, которые сформулировали перед тестом. Новый алгоритм должен победить на всех сайтах? Или вероятность выигрыша должна быть больше вероятности проигрыша? В первом случае очень высока вероятность того, что вы закопаетесь в бесконечных итерациях, «полируя» свой алгоритм до совершенства, особенно учитывая то, что тесты займут не одну неделю. Это типичная ситуация «аналитического паралича». Во втором – условие кажется легким. Хотя из практики скажу, что даже его выполнить бывает очень непросто.

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

Погрешности – правило штангенциркуля

Следующая вещь, с которой я столкнулся, – это точность цифр. Я много занимался анализом маркетинговой деятельности, в том числе маркетинговых акций. Моя задача заключалась в том, чтобы как можно более точно оценить их влияние на бизнес. Вообще реакция менеджеров на цифры разная – все радуются положительным результатам, не проверяя их; но когда видят отрицательные – сразу ищут ошибку. И скорее всего, «найдут». Видите ли, все метрики содержат ошибку. Вспомните лабораторные работы по физике в школе или институте, сколько мы мучились и считали погрешности. Системные, случайные… Сколько времени мы тогда тратили на то, чтобы подогнать результат под нужную закономерность?

В бизнесе и науке так делать нельзя, особенно если вы хотите быть хорошим аналитиком и не пользоваться вышеупомянутыми «сравнительно честными способами» повернуть цифры туда, куда нужно. Сейчас погрешность измерений веб-аналитики (системы измеряют посещаемость веб-сайтов) составляет около 5 %. Когда я еще работал в Ozon.ru, погрешность всей аналитической системы тоже была около 5 % (расхождение с данными бухгалтерии). У меня был серьезный случай – я обнаружил ошибку в коммерческой системе веб-аналитики Omniture Sitecatalyst (ныне Adobe Analytics): она не считала пользователей с браузером Opera. В результате погрешность измерений была очень большой – около 10 % всех совершенных заказов система, за которую мы платили более 100 тысяч долларов в год, безнадежно потеряла. С такой погрешностью ей тяжело было доверять – но, к счастью, когда я обнаружил ошибку системы и сообщил о ней в Omniture, их разработчики ее устранили.

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

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

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

Принцип Парето

Итальянский экономист и социолог Вильфредо Парето в 1897 году, исследуя структуру доходов итальянских домохозяйств, выяснил, что 80 % процентов всех их доходов приходится на 20 % из них.

Универсальный принцип, названный в его честь, был предложен в 1951 году, и сейчас принцип Парето звучит так: «20 % усилий дают 80 % результата».

Опираясь на свой опыт, я бы так сформулировал его на языке данных:

• 20 % данных дают 80 % информации (data science);

• 20 % фич или переменных дают 80 % точности модели (machine learning);

• 20 % из числа успешных гипотез дают 80 % совокупного положительного эффекта (тестирование гипотез).

Я почти 20 лет работаю с данными и каждый день убеждаюсь в том, что эта закономерность работает. Это правило лентяя? Только на первый взгляд. Ведь чтобы понять, какие именно 20 % позволят добиться результата, нужно потратить 100 % усилий. Стив Джобс в интервью Business Week в 98-м году сказал: «Простое сделать труднее, чем сложное: вам придется усердно поработать, чтобы внести ясность в ваши мысли, и тогда станет понятно, как сделать проще. Но это стоит того: как только вы достигнете этого, вы сможете свернуть горы».

Приведу пример того, как применяется правило Парето в машинном обучении. Для проекта обычно готовится ряд фич (входных параметров модели), на которых будет тренироваться модель. Фич может получиться очень много. Если выводить такую модель в бой, она будет тяжелой, требовать для своего поддержания много строк программного кода. Для такой ситуации есть лайфхак – посчитать вклад каждой фичи (feature importance) в результирующую модель и выбросить из модели фичи с минимальным вкладом. Это прямое использование правила Парето – 20 % фич дают 80 % результата модели. В большинстве случаев лучше модель упростить, пожертвовав небольшой долей ее точности, при этом проект будет в разы меньше исходного. На практике можно экономить время, подсмотрев фичи в решениях какой-нибудь схожей задачи на kaggle.com. Взять оттуда самые сильные из них и реализовать в первой версии собственного проекта.

Можно ли принимать решения только на основе данных?

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

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

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

Ошибку выжившего допустить очень легко. Чему нас учит пример Вальда? Тому, что нужно думать о всей генеральной совокупности. Ошибка выжившего является одной из форм когнитивных искажений.

В анализе данных ошибка выжившего – это учет известного и пренебрежение неизвестным, но существующим. С этой ошибкой очень легко столкнуться, когда у нас есть какие-то данные, на основе которых нужно сделать вывод. Любые данные – это выборка, ограниченное число. Сама выборка сделана из генеральной совокупности. Если выборка сделана случайно и она достаточно большая, то все хорошо – большая часть закономерностей будет зафиксирована в выборке, и выводы будут объективными. Если же выборка была не случайной, как в нашем случае с самолетами, где в ней отсутствовали сбитые машины, – то, скорее всего, выводы будут ошибочными.

Например, в среднем только 1 из 100 посетителей сайта интернет-магазина совершает покупку. Если мы захотим улучшить свой сайт, чтобы больше покупателей покупали, то с какими посетителями нужно работать? Обычно дизайнеры и продуктологи обращают внимание на существующих покупателей из-за того, что с ними можно пообщаться, есть контактная информация из заказов, по ним есть хорошая статистика. Но эта выборка составляет всего лишь 1 % от всей генеральной совокупности посетителей; с остальными почти невозможно связаться – это «сбитые самолеты». В итоге будет смещение выводов в сторону «выживших», а значит, выводы анализа не будут работать для всех посетителей.

Еще одно когнитивное искажение – предвзятость результата (outcome bias). Представьте себе – вам предлагают два варианта на выбор:

• Сыграть в «Орла или решку» – если выпадет орел, получите 10 000 рублей.

• Сыграть игральной костью с шестью гранями – если выпадет 6, получите 10 000 рублей.

Какой вариант выберете? Естественно первый, в котором шанс выиграть 1 к 2, во втором варианте значительно хуже – 1 к 6. Монету подбросили – выпала решка, вы ничего не получили. Тут же бросили кость, выпала шестерка. Будет ли обидно? Да, будет. Но было ли наше решение правильным?

Этот пример я взял из поста «Фокусируйтесь на решениях, а не на результате» [5] Кэсси Козырьков (Cassie Kozyrkov), которая работает директором по принятию решений [4] (Decision Intelligence) в Google. Она советует всегда оценивать верность решения, учитывая, какой именно информацией вы обладали в момент его принятия. Многие люди жалеют, что они не уволились с работы раньше и только потеряли время, откладывая это решение, – я и сам в свое время так думал. И это отличный пример предвзятости результата – мы понимаем, что нужно было уволиться раньше, только обладая той информацией, которая у нас есть на данный момент. Например, что с тех пор зарплата так и не выросла, а интересный проект, который мы предвкушали, так и не был запущен. Оценивая последствия своего решения (особенно неудачного), в приступе самокопания мы не должны забывать, что принимали решение в условиях неопределенности.

Глава 2
Делаем анализ данных

Когда я работал в компании Wikimart.ru, основатели этого проекта познакомили меня с Ди Джеем Патилом (DJ Patil). Ди Джей был тогда одним из ангелов-инвесторов проекта, он руководил аналитикой в LinkedIn, затем был ведущим аналитиком данных (Chief data scientist) Белого дома в Вашингтоне при администрации Барака Обамы, тогдашнего президента США. Встречался я с Ди Джеем несколько раз в Москве и в Кремниевой долине в Калифорнии. В Москву он приезжал для презентации своей мини-книги «Building Data Science Teams» («Построение команд аналитиков данных») [9], выпущенной издательством O’Reilly. В книге он обобщил опыт ведущих компаний Кремниевой долины. Очень рекомендую вам эту книгу, так как ее мысли мне близки, и их я проверил на практике. Вот как автор определяет организацию, управляемую данными:

«A data-driven organization acquires, processes, and leverages data in a timely fashion to create efficiencies, iterate on and develop new products, and navigate the competitive landscape».

«Организация, управляемая данными, своевременно получает, обрабатывает и использует данные для повышения эффективности, итераций и разработки новых продуктов, а также навигации в конкурентной среде».

Далее Ди Джей указывает на принцип «Если ты не можешь измерить, ты не можешь это исправить» («if you can’t measure it, you can’t fix it»), который объединяет самые сильные организации, эффективно использующие свои данные. Вот рекомендации Патила, которые следуют из этого принципа:

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

• Продумывайте заранее и делайте вовремя измерение метрик проектов.

• Позвольте как можно большему количеству сотрудников знакомиться с данными. Множество глаз поможет быстрее выявить очевидную проблему.

• Стимулируйте интерес сотрудников задавать вопросы относительно данных и искать на них ответы.

Эти мысли я еще озвучу в главе про данные. А теперь самое время поговорить о том, что мы получаем на выходе анализа данных.

Артефакты анализа данных

Здесь и далее под артефактами я буду понимать осязаемый результат, физический или виртуальный объект.

Рис. 2.1. Артефакты аналитики

Их можно разделить на три вида (рис. 2.1):

• артефакты бизнес-анализа данных (business intelligence);

• артефакты машинного обучения (machine learning);

• артефакты инженерии данных (data engineering).

Поговорим о них подробнее.

Бизнес-анализ данных

Бизнес-анализ данных (Business Intelligence, BI) – термин уже устоявшийся. Вот какое определение дает Википедия:

«Business Intelligence – это обозначение компьютерных методов и инструментов для организаций, обеспечивающих перевод транзакционной деловой информации в человекочитаемую форму, пригодную для бизнес-анализа, а также средства для работы с такой обработанной информацией».

Под бизнес-анализом я подразумеваю объединение контекста бизнеса и данных, когда становится возможным бизнесу задавать вопросы к данным и искать ответы Первыми артефактами являются так называемые инсайты и гипотезы, вторыми – отчеты или дашборды, метрики и ключевые показатели (Key Performance Indicator). Поговорим подробнее об инсайтах и гипотезах.

Гипотезы и инсайты

Инсайт (insight) в переводе с английского – понимание причин. Именно за этим обращаются к аналитикам. В поиске инсайтов помогают аналитика и статистика:

• Цель аналитики заключается [10] в помощи формулирования гипотезы.

• Цель статистики [10] в том, чтобы эту гипотезу проверить и подтвердить.

Это требует пояснений. В бизнесе, да и в жизни тоже, мы ищем причину проблемы, задавая вопрос «почему?». Не зная причины, мы не можем принять решение. В игру вступает аналитика – мы формулируем список возможных причин: это и есть гипотезы. Чтобы это сделать, нужно задать несколько вопросов:

• Не происходило ли что-нибудь подобное раньше? Если да, то какие тому были причины? Тогда у нас будет самая первая и самая вероятная гипотеза.

• Обращаемся к бизнес-контексту: не происходило ли каких-либо неординарных событий? Часто как раз параллельные события влияют на возникновение проблемы. Еще плюс пара гипотез.

• Описательный анализ данных (exploratory data analysis): смотрим данные в аналитической системе (например, кубах OLAP), не видно ли каких-либо аномалий на глаз? Например, какие-либо распределения изменились во времени (типы клиентов, структура продаж и т. д.). Если что-то показалось подозрительным – дополняем список гипотез.

• Использование более сложных методов поиска аномалий или изменений, например, как описано здесь [11].

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

Когда я был директором по аналитике Retail Rocket (сервис рекомендаций для интернет-магазинов), мне и аналитикам часто приходилось заниматься расследованиями, ведь бизнес довольно большой – больше 1000 клиентов, и странности, с которыми приходится разбираться, случаются часто. Много приходится работать с так называемыми А/Б-тестами: это тесты, где аудитория сайта делится на две части случайным образом – первой части пользователей показывается одна версия сайта, второй – другая. Такие тесты обычно используют, чтобы оценить влияние изменений на бизнес-метрики сайта, когда первая версия – это старая версия или контрольная группа, а вторая – новая версия. Если это интернет-магазин – это, скорее всего, будут продажи. Далее к результатам теста применяются статистические критерии, которые подскажут достоверность изменений.

Такие тесты хорошо выявляют проблемы: например, версия сайта с обновленными рекомендациями Retail Rocket проиграла старой версии рекомендаций. Как только это становится известным, начинается расследование. Проверка начинается с интеграции, и это первая гипотеза: правильно ли передаются нам данные от интернет-магазина. Обычно на этом этапе решается 60–70 % проблем. Далее мы пытаемся найти отличие этого магазина от остальных в такой же тематике, например магазины одежды. Это вторая гипотеза. Третья гипотеза – возможно, мы изменили дизайн сайта таким образом, что полезная информация опустилась ниже на странице сайта. Четвертая гипотеза – тест мог отрицательно повлиять на определенные категории товаров. Собрав набор таких гипотез, мы начинаем их проверять примерно в такой последовательности, как я описал. Довольно часто мы находим причину проблем, но иногда это не удается, его величество случай играет с нами в кошки-мышки, и эту мышку очень сложно найти.

Однажды клиент – магазин «Дочки-Cыночки» – тестировал наш сервис и сервис одного из наших российских конкурентов, чтобы выбрать лучший, и это превратилось в настоящий детектив [12]. Чтобы точно не проиграть в тесте, конкурент перемещал некоторое число пользователей, которые были близки к покупке, (например, добавили товар в корзину) из конкурентных (наших) сегментов в свой – причем делалось это не на постоянной основе, а в отдельные дни и часы. Основной метрикой сравнения была конверсия: процент пользователей, совершивших покупку. Ясно, что в той «мошеннической схеме» такой процент будет выше там, куда перетянули пользователей. Здесь компания Retail Rocket пошла на принцип! Мы стали копать. Через два месяца были обнаружены и опубликованы [12] факты подтасовки результатов. В итоге прошел ряд судебных процессов, и справедливость восторжествовала.

Отчеты, дашборды и метрики

Понятие самого отчета очень широкое, здесь я подразумеваю под ним табличное или иное графическое представление данных. Отчеты могут быть разными:

• Просто таблица с «сырыми» данными или так называемые «выгрузки», например, таблица с заказами клиентов.

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

• Дашборды (dashboards) содержат ключевые показатели и метрики.

Первые два относительно просты и делаются через специальные системы, которые могут генерировать отчеты по запросу. Я стараюсь максимально оставить эту задачу на откуп пользователям. Почему? Потому, что тратить на это время высококвалифицированных сотрудников – значит стрелять из пушки по воробьям. Кстати, этим могут заняться стажеры-аналитики – отличный способ наработать опыт и понять бизнес-контекст. Как мотивировать пользователей стараться самостоятельно? Во-первых, они сэкономят время, которое обычно тратят на постановку задачи и ожидание результата. Во-вторых, получат возможность самим вносить правки и изменения – а значит творить. По моему опыту, обычно этим занимаются очень перспективные сотрудники, которые не бояться освоить новый инструмент, чтобы делать свою работу лучше. Остальным придется пройти через стандартный цикл планирования задач: а это время (дни, а иногда недели) и очень четкая формулировка технического задания. И кстати, все генеральные директора (Ozon.ru, Wikimart.ru, Ostrovok), с которыми я работал, пользовались OLAP-кубами со своих компьютеров. С их помощью они всегда могли ответить на простые вопросы, а если не получалось – обращались к аналитикам.

Теперь взглянем на дашборды и начнем с определения из Википедии:

«Дашборд – это тип графического интерфейса, который делает возможным быструю оценку ключевых показателей для конкретной цели или бизнес-процесса. Часто подразумевается, что это просто другое название отчета о прогрессе или просто отчета».

Как правило, дашборд состоит из ключевых показателей и метрик, выраженных с помощью графических инструментов (графики, диаграммы и т. д.):

• Ключевой показатель (key performance indicator, KPI) – это индикатор, который показывает, насколько далеко мы находимся от цели, например отставание/опережение плана.

• Метрика – это цифра, которая характеризует процесс, обычно используется как справочная информация.

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

Обычно дашборды характеризуют какой-то бизнес-процесс (далее слово «процесс» без «бизнес»), например эффективность рекламы, складские остатки, продажи и т. д. Есть еще важные характеристики дашбордов:

• не является «простыней цифр»;

• показывает, где возникла проблема, но не дает ответа на вопрос почему.

Часто велико искушение сделать огромную простыню цифр, закрывающую все аспекты бизнеса. И я понимаю владельцев/менеджеров компаний – на старте проекта по построению внутренней аналитической системы всегда хочется большего. Я наблюдал это и в Ozon.ru, и в Ostrovok.ru. К слову, эти строки написаны по мотивам письма, которое я писал восемь лет назад операционному директору Ostrovok.ru, – он хотел получить от аналитиков ту самую «простыню». А я считаю такое цифровым «микроменеджментом», в нем легко запутаться, самые важные показатели похоронены среди второстепенных. С первого взгляда будет сложно понять, где возникла проблема, а это основная функция дашбордов. Бороться с этим можно, например, через внедрение OKR – цели и ключевые результаты (Objectives and Key Results) [13] – или системы сбалансированных показателей (Balanced Scorecard). В этой книге я не буду подробно останавливаться на этих методиках, но рекомендую вам с ними ознакомиться. Также можно чаще пользоваться графическими элементами, например, добавив на график линию тренда (с помощью семиточечного скользящего среднего, чтобы убрать недельную сезонность), будет легче заметить восходящий или нисходящий тренд.

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

Никакой дашборд не заменит интерактивный анализ, для которого нужны соответствующая аналитическая система (SQL, OLAP, Google Data Studio, Tableau) и знание контекста. Мы никогда не сможем придумать ограниченный набор отчетов, которые будут отвечать на вопрос «почему». Максимум, что мы можем сделать, – наращивать (но не слишком) объем правильных метрик, исходя из инцидентов, за которыми будем следить.

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

Разработка дашбордов – это одна из самых нелюбимых работ у тех, кто занимается анализом данных. Когда я обсуждал этот вопрос с Ди Джеем Патилом, отметив, что 50 % времени аналитического отдела занимает работа над отчетностью, он сказал, что у них в LinkedIn тоже периодически накапливался пул таких задач и приходилось их закрывать. И взгрустнул. Но дашборды очень нужны – они помогают контролировать общее здоровье вашей системы – вверенных вам серверов и сетей, если вы системный администратор, или всей компании, если вы генеральный директор.

Артефакты машинного обучения

Раньше компьютером можно было управлять только с помощью прямых команд или инструкций: поверни сюда, дай назад, сложи и т. д. Это обычное, так называемое детерминированное программирование – для нас понятен алгоритм в виде инструкций, мы его описали, и компьютер подчиняется ему. Машинное обучение предполагает совершенно другой подход к программированию – обучение на примерах. Здесь мы показываем системе что-то с помощью примеров, тем самым избавляем себя от самостоятельного написания инструкций, что бывает совсем не просто. Это становится работой по обучению алгоритма ML.

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

• Функция обучения (train), в которую можно отправить данные для обучения признаки (они же фичи, независимые предикторы, независимые переменные) и правильный ответ (output). Сам результат обучения сохраняется внутри модели.

• Функция предсказания (predict), которая предсказывает результат для новых примеров.

Поясню на примере одной задачи. У нас есть много фотографий собак и кошек, и нам нужно их разделить: в одну папку сложить файлы с фотографиями кошек, в другую – фото собак. Фотографий очень много – миллионы, вручную не сделать. У вас есть размеченный набор данных для обучения – тысяча фотографий, для каждой указано, кошка там или собака. Вы берете нужную модель, «скармливаете» ей в функцию train набор с размеченными данными, и она учится на них. Сама модель выглядит для нас как черный ящик. Конечно, в него можно заглянуть, что мы и сделаем в главе про машинное обучение. Как только модель обучится, мы уже начинаем одна за другой скармливать ей фотографии, которые нужно разделить. Для каждой фотографии модель вернет нам вероятность того, кошка там или собака. Используя эти цифры, уже несложно разделить фотографии.

Этот пример я видел вживую, когда глубокое обучение нейронных сетей (Deep Learning) только набирало оборот. На одном из конкурсов Kaggle.com была точно такая же задача [14]. Чтобы поиграть с этой задачей, я нашел код в интернете, который не использовал нейронные сети. Естественно, ничего не получилось, мой алгоритм был настолько плох, что проще было бросить монетку и получить такой же результат. Первые места заняли исследователи, у которых результат был близок в 99 % (точность угадывания). Их модель была основана на сверточных нейронных сетях. Меня тогда поразил результат. Глубокое обучение нейронных сетей еще не было популярным, а ведь это было всего лишь в 2013 году. Вот так быстро меняются технологии!

Следующий постулат: данные, на которых обучена модель, – это часть кода. Это еще одно серьезное отличие от классического программирования. Чтобы сделать «тиражирование» программного кода, его текст можно опубликовать в Сети. Эта программа будет работать везде одинаково. Если вы захотите «поделиться» своей обученный моделью, то вам придется отправить не только код, но и весь получившийся черный ящик. Именно так исследователи и делятся своими обученными моделями. Например, модель нейронной сети Resnet 50 [15] была обучена на миллионах изображений. Она уже полностью готова к работе; просто показывая ей разные фотографии, вы получите названия предметов, которые там изображены.

Артефакты инженерии

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

• Откуда и с какой периодичностью брать данные и как туда получить доступ?

• Какова нагрузочная способность источников данных, чтобы и бизнес работал без сбоев, и данные как можно быстрее были доступны для анализа?

• Какую архитектуру хранилища сделать? Или, может, не делать его вовсе?

• Какую аналитическую систему выбрать?

• Как использовать в процессах обученную модель машинного обучения (далее ML-модель)?

Таких вопросов может быть очень много. Эти вопросы должны решаться и автоматизироваться. Артефактами инженерии будут:

• Архитектура аналитической системы.

• Программный код, который обеспечивает работу системы.

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

Архитектура аналитической системы состоит из нескольких уровней:

• Физический – серверы и каналы связи между ними.

• Данные – хранилища данных.

• Приложения – программы, с помощью которых пользователи получают доступ к данным, а также публикуют модели ML.

За физический уровень отвечают системные администраторы. Они занимаются «железом», чтобы система была отказоустойчивой. Также администраторы постоянно мониторят здоровье системы. Знаете, как определить, что у вас хорошая система и администраторы? Вы о работе администраторов ничего не слышите, а система работает без серьезных сбоев.

За уровень данных отвечают инженеры данных (Data Engineers или ETL Engineers): их основная задача – сделать так, чтобы данные доставлялись от источников данных и сохранялись в хранилищах данных. Часто они же отвечают за предобработку данных и развертывание BI-систем (OLAP-кубы и отчетные системы).

За уровень приложений отвечают инженеры машинного обучения (ML engineers) и аналитики данных (data scientists). ML-инженеры занимаются созданием ML-моделей и иногда – их развертыванием, чтобы они работали на благо вашего бизнеса (хотя в больших компаниях развертыванием моделей «в бою» часто занимаются другие инженеры). Аналитики данных занимаются тестированием моделей и их оценкой. В небольших компаниях эти две роли часто совмещаются. Однажды я проходил собеседование в офисе компании Quora.com (социальная сеть) в Пало-Альто (Калифорния, США) и там выяснил, что местные ML-инженеры как раз и занимаются разработкой ML-моделей, а аналитики данных занимаются метриками, анализом данных и прочим, но не ML-моделями.

Кто анализирует данные

Чем ближе анализ данных к точке принятия решений – тем лучше. Если вопрос возник у руководителя и у него есть полное понимание бизнес-контекста (какие события были и т. д.), а аналитическая система обладает хорошей интерактивностью, то большинство вопросов решаются на раз-два-три. До 80 % вопросов (вспомните правило Парето), если быть точным. В чем плюсы такого решения? Нет посредников – выше скорость! Пользователь даже может не иметь четко сформулированного вопроса, который точно понадобится, если ставить задачу аналитикам. Для этого очень важно внутри компании «продавать» аналитический подход и регулярно обучать пользователей.

Если бизнес-контекст размытый, находится вне компетенций или вопрос заказчика слишком сложный, то тут подключают в работу аналитика. Обычно я рекомендую в отделах, департаментах держать собственного «децентрализованного» аналитика, который в курсе дел этого департамента, то есть владеет бизнес-контекстом и при этом обладает развитыми аналитическими и техническими навыками. Это вторая линия обороны. Такой «карманный» аналитик сможет решать вопросы внутри отдела/департамента быстрее центрального просто потому, что у него нет других задач.

Третий уровень – передаем задачу условному центральному отделу аналитиков данных, если:

• задача требует изменения ядра системы;

• задача технически сложна для аналитика какого-то отдела;

• требуется большая коллаборация между отделами для ее решения.

В Ozon.ru я не полностью ее реализовал, но уже в Wikimart.ru была сделана такая система: интерактивный анализ данных в OLAP-кубах дал возможность пользователям быстро решать свои вопросы, аналитики отделов решали проблемы анализа данных отделов, а центральный отдел создавал ядро всей аналитической системы. Кстати, многие бывшие пользователи OLAP-кубов в Ozon.ru потом писали мне, что им очень не хватает этих аналитических решений в других компаниях. К хорошему быстро привыкаешь.

Идеальная кнопка

До Физтеха я вообще не знал английского – в школе у меня был немецкий, о чем я очень жалел. На Физтехе принято учить английский язык, поэтому сразу на первом курсе была сформирована группа начинающих, в которую попали всего 4 человека. На протяжении трех курсов у нас проходило 2 занятия в неделю. Это был один из самых моих любимых предметов, и он здорово мне пригодился. На четвертом курсе я устроился подрабатывать переводчиком книги с английского языка на русский. Это была книга о программе анализа данных STATISTICA компании StatSoft. Я устроился туда стажером, переводил книгу, помню норматив – 15 000 знаков в день, от которого к вечеру пухла голова. Постепенно я втянулся и стал заниматься более интересными вещами: преподавал клиентам компании, проводил презентации для продаж, ездил в командировки и т. д. Тогда я постоянно консультировал клиентов и понял одну важную вещь: многие клиенты хотят получить кнопку и желательно на стуле – садишься на нее, а она делает всю твою работу.

Кроме того, заказчику чаще всего лень вдаваться в детали, и он готов платить огромные деньги просто за яркую обертку. Этот феномен очень хорошо эксплуатируется продавцами IT-решений, консультантами всех мастей. Я наблюдал его, когда Ozon.ru выбирал решение для веб-аналитики между Omniture SiteCatalyst и Webtrends. Обе команды продавцов активно рассказывали о «светлом» будущем. Так как никто из принимающих решения не был особенно в теме (я, кстати, тоже), то выбрали тех, кто «поет» лучше. Презентация Omniture выглядела эффектней, они нам подарили радиоуправляемые машинки и всякие подарки. Поэтому выбор был сделан в их пользу, хотя я нахожу системы равнозначными, и стоили они почти одинаково. В продолжение истории – когда я пришел в Wikimart.ru, мне уже было понятно, что нужно пользователям от веб-аналитики. Я быстро накатал техническое задание, его реализовали разработчики, и через два месяца после моего прихода в компании была своя система веб-аналитики, ничуть не хуже Omniture. И экономия составляла порядка 100 тысяч долларов в год.

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

Продать аналитику внутри компании

Для меня это очень непростой вопрос. В разделе «Кто анализирует данные» я упоминал, что аналитическую систему мне удалось поднять за два месяца (причем я работал тогда два дня в неделю). «Продажа» ее пользователям заняла гораздо больше времени, и только спустя 4 месяца системой начали более-менее пользоваться. Причем kick-off-презентацию я делал сразу после запуска: пригласил туда всех значимых сотрудников компании, включая основателей.

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

В Retail Rocket мы так внедряли аналитику на базе ClickHouse. Ранее данные были доступны только в SQL-интерфейсе к вычислительному кластеру на базе Spark/Hadoop (эти технологии мы обсудим в главе о хранилищах), Hive. Подобная схема используется в компании Facebook, они так дают доступ к данным внутри своей компании. Проблема этой технологии заключается в том, что она медленно считает, запросы выполнялись до 30 минут, а данные доступны только до вчерашних суток. Пользовались этой системой только сотрудники технической поддержки. В одном из проектов мы попробовали аналитическую базу данных ClickHouse от Яндекса. Нам она понравилась: быстро считала, большая часть запросов – это секунды, можно было сделать систему, близкую к реальному времени. Вначале пересадили на нее техническую поддержку, а в Retail Rocket это одно из самых сильных подразделений. Они очень быстро полюбили эту технологию за скорость и отказались от использования медленного Hive. Далее мы начали предлагать новую систему пользователям внутри компании. После обучающих презентаций многие сотрудники зарегистрировались в системе, но не стали ею пользоваться. Тогда мы пошли другим путем: все входящие задачи от сотрудников, которые можно было решить с помощью этой системы, начали раз за разом «отфутболивать» – возвращать под соусом «сделай сам», демонстрируя возможности системы. И часть пользователей стала работать с системой самостоятельно! Там многое еще можно сделать, но то, что уже сделано, я считаю успехом.

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

Конфликт исследователя и бизнеса

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

Я много раз проводил собеседования и с новичками, и с опытными людьми, и знаю, что поиск интересной работы – главный тренд на рынке труда. Действующие специалисты говорят: «Надоело заниматься рутиной и всякой ерундой, хочу заниматься моделями машинного обучения». Новички: «Хочу заниматься компьютерным зрением и NLP (машинное обучение в лингвистике)». В целом людей объединяет любовь к машинному обучению, но для меня это звучит как любовь строителя к молотку, который пытается построить дом лишь с его помощью.

Эндрю Ын (Andrew Ng), которого я считаю одним из главных исследователей и популяризаторов машинного обучения, автор моего любимого курса на Coursera, в своей рассылке deeplearning.ai писал:

«Существует огромная разница между построением модели в блокноте Python (Jupyter Notebook) на компьютере в лаборатории и созданием реально работающих систем, которые создают ценность. Кажется, что сфера AI переполнена людьми, но по факту она широко открыта для профессионалов, которые знают, что делают».

Курсы по анализу данных и машинному обучению делают полезное дело, но их можно сравнить с игрушечными моделями кораблей – они далеки от настоящих примерно так же, так курсы – от реального применения ML в жизни.

Ноа Лоранг, аналитик данных из компании Basecamp, в своем блоге [16] пишет:

«Маленькая грязная тайна продолжающегося бума data science в том, что то, что обычно подразумевается под этим на самом деле, не нужно бизнесу. Бизнесу нужна точная и полезная информация для принятия решений: как тратить время и ресурсы компании. Очень небольшое подмножество задач в бизнесе может быть лучшим образом решено машинным обучением; большинство же из них нуждается в хороших данных и понимании их смысла, что может быть достигнуто простыми методами».

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

Недостатки статистического подхода в аналитике

Аналитика данных «усредняет» человека. На вопрос «Би-би-си» про индивидуальность человека Карл Юнг, основатель аналитической психологии, сказал [17]:

«Что тут скажешь: это – одно из следствий современной науки, которая основывается на статистическом усреднении. А для статистического усреднения человек как таковой совершенно не важен. Это – абстракция, а не конкретная личность.

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

Если вы рассматриваете жизнь с позиций среднего арифметического, то у вас есть только некое представление о том, что такое “нормальный человек”. Но на самом деле такой “нормальный человек” просто не существует, и в жизни нам приходится иметь дело с конкретными людьми. И конкретному человеку, а не бесчисленным массам, приходится иметь дело с последствиями принятых решений».

Статистический подход, данные для которого по сути представляют «агрегаты» (суммы, количества, средние), убирает «слабые» сигналы индивидуальности. Для алгоритма человек – всего лишь строчка с несколькими цифрами и ID. Все остальное не нужно, эти «фичи» не важны, потому что конкретная модель не смогла извлечь из них выгоду. Я размышлял над моделями машинного обучения, они все слишком обобщают и упрощают, часто видят лишь черное и белое, не различая оттенков. В итоге все сводится к банальности, к скору (score), к баллам на выходе модели, на основании которых принимают решение – дать кредит или не дать и т. д. Это касается моделей машинного обучения.

Еще один недостаток статистического подхода – измерение, которое лежит в его основе. Об этом пишет в своей книге «Тирания показателей» [18] Джерри Миллер, ученый, автор многочисленных статей для New York Times и Wall Street Journal:

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

Бездумное внедрение количественных показателей везде, где только можно, – зло. Я помню, как в школе на уроках физкультуры нас гоняли по нормативам. Вы тоже бегали на скорость стометровку и прыгали в длину? Но при этом никто не прививал культуру тренировок и привычку к ежедневной физической активности. Соответствие абстрактным нормативам оказалось важнее не только твоего личного прогресса (все мы разные – усреднять нельзя!), но и любви к спорту – а это в корне неправильно. Помню, читал пост выпускника Физтеха в соцсети: «1987 год. Мы уже поступили… А потом была какая-то контрольная по физкультуре. Надо было на время переплыть физтеховский 25-метровый бассейн. Заставили всех, а потом вывесили результаты. Помню, как я их изучал: 30 сек, 35 сек, 1 мин, 2 мин, 5 мин… Последней строкой значилось: “сошел с дистанции”. Куда сошел?»

Все мы знаем про «палочную» систему в силовых органах, которая доводит до абсурда. Саша Сулим, автор книги «Безлюдное место. Как ловят маньяков в России» [8], посвященной знаменитому делу ангарского маньяка, пишет в ней о том, как их на самом деле не ловят – милиция много лет не связывала убийства женщин в серию, игнорируя очевидные факты, чтобы избежать в отчетах «висяка» и непойманный маньяк не портил статистику раскрываемости.

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

Глава 3
Строим аналитику с нуля

В этой главе я изложу свой подход к построению аналитики в компании с нуля. За всю мою карьеру в найме я делал это дважды – в Ozon.ru, Wikimart.ru и один раз как сооснователь – в компании Retail Rocket. И еще помог сделать это нескольким компаниям в режиме консультирования, заодно поучаствовав в найме сотрудников.

Первый шаг

Когда передо мной стоит задача сделать аналитическую систему или существенно расширить ее возможности, я всегда использую двусторонний подход: определяю, какие задачи и вопросы перед нами стоят, и выясняю, какие данные есть в источниках.

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

• Какие метрики понадобится считать?

• Какие дашборды собрать?

• Какую информацию отправить в интерактивные системы?

• Будут ли тут задачи ML (машинное обучение)?

Сложность этого шага в том, что потребители (заказчики) не всегда представляют, какая именно информация им понадобится. И для того чтобы выстроить эффективную систему, аналитику необходимо самому обладать хотя бы минимальной экспертизой в том бизнесе, который он анализирует. После работы в интернет-магазинах мне поначалу было непросто в Ostrovok.ru (система бронирования отелей) – да, продажи идут тоже через интернет, но тут понадобились очень специфические знания отельного бизнеса. Ваша собственная экспертиза помогает вам во время интервью с заказчиком задавать правильные вопросы и на основе ответов формировать структуру данных, которые понадобятся для решения задач клиента.

Затем я иду к разработчикам и начинаю узнавать, а что же, собственно, у них есть – какие данные они собирают и где эти данные находятся. Во-первых, меня интересуют данные, которые помогут решать задачи клиента (мне важно увидеть не только схемы, но и живые примеры таких данных – строки таблиц и файлов). Во-вторых, для меня важны те данные, которые есть, а применения им пока нет – какие задачи они могли бы решить? К финалу этого этапа у меня уже есть:

• Список вопросов, которые покрываются текущими данными.

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

• Данные, которые пока не решают никаких актуальных задач.

• Источники данных и их примерные объемы.

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

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

Выбираем технологии

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

• Собственное хранилище или облачное?

• Использовать ли open-source-технологии?

• Какой язык программирования использовать для артефактов инженерии?

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

• Какую отчетную систему выбрать?

• Требуется ли где-нибудь скорость анализа, близкая к real-time?

Это самые базовые вопросы, но от них зависит многое. В том числе каких сотрудников нанимать, сколько придется инвестировать, как быстро запустится проект.

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

Цель работы коммерческой компании – прибыль. Прибыль является разностью выручки и затрат, куда входит и себестоимость хранилища. И может быть довольно большой, если данные хранятся в облаке. Ее можно оптимизировать, создав собственное хранилище. Да, тут будут затраты на администрирование. Внимания такая система будет требовать больше. Но и способов снизить затраты у вас будет явно больше, система будет намного гибче. Если же аналитическая система не имеет такого прямого влияния на P&L (прибыли и убытки), то гораздо проще будет работать с облачным хранилищем. Тогда вам не придется думать об отказавших серверах – «облака» сделают за вас свою работу сами.

Технологии open-source (свободно распространяемое ПО с открытым исходным кодом) имеют очень большой вес в аналитике. Впервые я столкнулся с ними, когда учился на Физтехе. На втором курсе у меня появился компьютер, он имел очень слабую производительность даже по тем временам, поэтому я установил туда Linux. Часами компилировал ядро под свои нужды, учился работать в консоли. И это пригодилось мне ровно через десять лет. Именно тогда я посетил офис компании Netflix в Лос-Гатосе (Калифорния) и познакомился с директором по аналитике Эриком Колсоном. Он рассказал тогда об инструментах, которые используют его сотрудники в работе, и даже нарисовал маркерами на доске их названия. И как раз он много говорил об открытом ПО для анализа данных, таком как Python, Hadoop и R. До этого я пользовался только коммерческим софтом, но несколько месяцев спустя по следам этой встречи, летом, в пустом офисе, когда все сотрудники офиса Wikimart.ru отправились на корпоратив, я написал первые 9 строчек кода на языке Pig для платформы Hadoop (тут мне пригодилось знание Linux). На это ушло 4 часа. Тогда я еще не знал, что через несколько лет именно на этом языке и на этой платформе будет написан «мозг» рекомендательной системы Retail Rocket. К слову сказать, вся аналитическая система RR, как внутренняя для принятия решений, так и вычислительная для расчета рекомендаций, написана с использованием только open-source-технологий.

Сейчас, оборачиваясь в прошлое, я могу сказать, что Retail Rocket – это самое крутое, что я сделал в своей карьере: компания быстро вышла в прибыльность, успешно конкурирует с западными аналогами, и сейчас там работает больше сотни сотрудников по всему миру с основными офисами в Москве, Тольятти, Гааге, Сантьяго, Мадриде и Барселоне. Российская компания развивается и создает рабочие места за рубежом! Сейчас вектор развития изменился: RR продает не только рекомендательную систему, но и много сопутствующих услуг для интернет-магазинов. Технологии анализа больших данных и машинного обучения, которые мы создали в далеком 2013 году, актуальны до сих пор, и я очень горд, что мы были на голову выше наших конкурентов в технологическом плане.

Когда стоит связываться с коммерческим ПО? Ответ: когда на это есть деньги. Практически у любого коммерческого ПО есть open-source-аналог. Да, как правило, они хуже, особенно в каких-то деталях. Например, я так и не нашел достойный open-source-аналог для OLAP-кубов. Отчетные системы тоже выглядят недоделанными. Но что касается инженерных технологий, таких как Hadoop, Spark, Kafka, – то это очень надежные и мощные инструменты разработчиков. Они очень хорошо зарекомендовали себя в коммерческом применении.

Обсудим языки программирования, которые будут использоваться при разработке системы. Мой принцип – чем их меньше, тем лучше. До Retail Rocket мне удавалось обходиться одним SQL. Правда, для перекачивания данных (ETL) из источника в хранилище приходилось использовать специальные коммерческие инструменты от Microsoft. В Retail Rocket в свое время использовалось аж четыре языка программирования для создания рекомендаций: Pig, Hive, Java, Python. Потом мы заменили их все на Scala, так как он относится к семейству JVM, на котором написана Hadoop. Поэтому на нем очень легко программировать на платформе Hadoop/Spark, для последней он еще является родным. Но пару лет назад мы стали использовать Python и SQL. Здесь пришлось отойти от Scala – некоторые вещи на нем делать было неудобно.

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

• для какой системы он будет использоваться (например, SQL идеально подходит для баз данных);

• есть ли специалисты по этому языку в вашей компании и на рынке.

Например, заставлять пользователей вашей системы учить сложные в освоении языки программирования для доступа к данным – плохая идея. Для пользователей это вспомогательный инструмент, и много времени на его изучение они тратить не захотят.

Специалисты на рынке – моя головная боль. Scala – очень редкий язык, довольно непростой в изучении. Специалистов на рынке очень мало, а имеющиеся стоят дорого. Вот на Python работают очень многие. Хотя за одного Scala-разработчика я бы дал трех на Python. Здесь мы приняли сознательное решение: качество нашей работы для нас важнее, поэтому выбрали Scala. Нанимать готовых Scala-людей почти не получалось, поэтому мы сделали свой курс молодого бойца [19], когда новичок в течение полугода обучается программировать на нем.

Поговорим об аутсорсе

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

• создание и поддержка технической части системы;

• аналитическая часть;

• выделенные задачи.

Когда требуется сократить время развертывания технической части проекта и получить качественный результат – нужен хороший подрядчик. Но попробуй его еще найди! Мало того что редкий подрядчик достаточно глубоко знает предмет – ситуация часто усугубляется тем, что заказчик не знает, чего хочет.

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

Риск уменьшится, если привлечь очень опытного аналитика, который не раз лично реализовывал подобные проекты. На вашем проекте он будет выступать в качестве независимого советника или даже арбитра. Это нужно, чтобы, с одной стороны, «приземлить» заказчика, с другой – ограничить подрядчика. Я считаю, что проект на старте лучше сильно урезать по «хотелкам», чтобы получить на выходе работающую версию как можно быстрее. На то есть несколько причин. Во-первых, после того как вы, заказчик, вживую поработаете с ней, вам гораздо легче будет сформулировать, что вы действительно хотите. Это тяжело делать абстрактно на бумаге, конструируя сферического коня в вакууме. Вторая причина – драйв, лично для меня это очень важно. Когда время течет медленно, у команды, да и у заказчиков, постепенно угасает интерес. И на выходе мы уже получаем вымученный проект, которым уже не так сильно хочется заниматься.

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

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

Еще один вариант аутсорса – отдать какую-то часть проекта целиком: вы отдаете данные, а на выходе получаете готовый продукт. Пример такого сотрудничества – компания Retail Rocket. Начали мы бизнес с товарных рекомендаций. Интернет-магазины отдавали нам данные и товарную базу, на выходе они получали готовые рекомендации. Лично у меня идея такого бизнеса зародилась во время работы в компании Wikimart.ru. Я сделал рекомендации для сайта компании и подумал: почему бы не запустить тиражируемое решение. Это бы сняло необходимость интернет-магазину нанимать инженеров машинного обучения и изобретать велосипед. Результат получался гораздо быстрее, буквально за неделю. Среднее качество рекомендаций нашего сервиса гораздо лучше внутренней разработки. Если бы меня наняли сейчас в интернет-магазин, то, скорее всего, я бы привлек внешний сервис рекомендаций вместо того, чтобы делать собственную разработку.

Немного расскажу о своем личном опыте работы на аутсорсе. В 2009 году я ушел из Ozon.ru. В то время у меня был достаточно популярный блог по аналитике KPIs.ru, созданный за пару лет до этого. И оттуда ко мне стали приходить запросы на консалтинг по аналитике из самых разных сфер: разработчики игр, e-commerce, венчурный фонд и т. д. Потихоньку я стал наращивать темп консультаций, одновременно работая на три компании. Первой я помог выбрать нужную технологию и нанять людей в команду, проводил собеседования. Второй – помогал растить стартапы. В третьей компании я поработал руками, подняв аналитическую систему. Мне этот опыт много дал – прежде всего я помогал компаниям, не отвлекаясь на корпоративные детали и бюрократию, как было бы, работай я в штате. Ну а компаниям моя работа позволила осуществлять быстрый старт проектов. Кстати, в третьей компании я в результате остался работать (это был Wikimart.ru): ее основатель предложил мне возглавить отдел аналитики – и я согласился, потому что в тот момент хотел быть ближе к данным и работать руками. На этом тогда закончился мой аутсорс.

Наем и увольнения

Допустим, технологии выбраны, задачи понятны, есть информация по имеющимся данным. Возможно, даже «поднята» аналитическая система – бери и пользуйся. Поговорим о найме сотрудников.

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

Будем считать, что вы определились со списком необходимых сотрудников. Теперь поделюсь своим опытом найма – за свою карьеру я собеседовал сотни специалистов, и у меня в голове есть некоторая картинка без лишних подробностей (оставим их HR-отделу). При найме любого сотрудника для меня прежде всего важно, чтобы кандидат был здравомыслящий, ищущий развитие и разделяющий мои ценности. Младших аналитиков, джуниоров, стажеров на неполный рабочий день иногда получалось найти через групповое интервью. Делается это следующим образом. Даются объявления, в том числе в вузах, через вакансии. Рекрутер обзванивает кандидатов и приглашает всех собраться в одно время в один день. Сама встреча делится на несколько частей:

1. Вводное слово – рассказ о компании, работе и т. д. Пятнадцати минут достаточно.

2. Групповая работа – ребят и девушек разбиваем случайным образом на группы по 3–4 человека. Им дается простое аналитическое задание. Они обсуждают его группой в течение 30 минут – в это время рекомендую подходить к ним, слушать, как они рассуждают. Далее кто-то из группы озвучивает свое решение.

3. Индивидуальное задание – нужно предложить подход или решение к какой-либо задаче, можно письменно. На задание – полчаса.

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

Со специалистами сложнее. В такую группу их не собрать, требования к их квалификации выше. А еще на рынке труда существует серьезный перекос. Совсем недавно мне нужно было нанять двух человек: инженера по данным и аналитика данных. Как вы думаете, на какую вакансию откликнулось больше кандидатов? Задам еще один вопрос: кого у нас в стране больше – гитаристов или барабанщиков? Я трижды играл на шоу #ROCKNMOB – это такой масштабный флешмоб для музыкантов-любителей: собирается толпа вокалистов, басистов, гитаристов и ударников, и банда из трех сотен человек пилит рок-хиты, от Queen до Rammstein. На одно из шоу было заявлено 27 ударников и 151 гитарист. Эта статистика более-менее отражает распределение сил в природе: парень с гитарой – это сексуальный архетип (я уже написал, что играю на электрогитаре?), и выглядит он всегда круче барабанщика. А еще гитару купить проще, чем барабанную установку. Инженеры по данным проигрывают аналитикам в еще более грустной пропорции: 95 % откликов приходит на вакансию data scientist. Они прямо как гитаристы! При этом большинство имеют крайне низкую квалификацию и очень скромный послужной список, но чувствуют себя опытными «сержантами». В этом тоже виноват хайп!

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

Тема увольнения обычно стыдливо замалчивается, но оно даже важнее найма. Популистские высказывания в духе «нанимай медленно, увольняй быстро» я не поддерживаю. К сотрудникам нужно относиться по-человечески. Расставаться тоже нужно по-человечески, это важная часть корпоративной культуры. Увольнения происходят с двух сторон: по инициативе сотрудника и по инициативе работодателя. В моей практике первых было больше. Главная причина – мало машинного обучения, а ведь на курсах рассказывали, что этого будет много. Наука сильно расходится здесь с жизнью. Не устаю повторять, что реального машинного обучения в проектах машинного обучения 5–10 % времени. После такого опыта я стал целенаправленно отсеивать таких кандидатов-мечтателей на этапе собеседования. Вторая причина – сотрудник сильно вырос или устал долго работать на одном проекте. В таких случаях я обычно помогаю ему найти новое место работы, используя свои связи.

Причины уволить сотрудника могут быть разными – откровенно лажает, не вписывается в нашу аналитическую культуру. Но я никогда не тороплю события, ведь я также могу ошибаться. Для начала советуюсь с командой, с каждым отдельно. Если получаю негативные отзывы – это практически всегда означает, что нужно расставаться. Можно попробовать поговорить, подкинуть проекты, но обычно это не работает. Я наблюдал за карьерой уволенных и обратил внимание, что часто эти сотрудники находят нормальную работу и приживаются там. То есть они не были плохими – просто они не подошли нам, и это нормально.

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

В идеале аналитики должны быть независимы от менеджеров, которых они оценивают. Тут принцип – кто платит, тот и музыку заказывает. Не может сотрудник менеджера объективно оценить его работу. Решать задачи отдела может (помните про децентрализацию из прошлой главы?), но оценивать – нет. Здесь нужна независимость от операций. Я бы рекомендовал, чтобы центральный аналитический отдел подчинялся генеральному директору, финансам или 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 мы включаем диктофон. Аудиозаписи дисциплинируют и помогают решать спорные вопросы. Но еще лучше все договоренности прописывать прямо в тексте задачи – это гарантирует, что все всё поняли правильно, особенно если согласию предшествовали жаркие споры.

Как проверять задачи

Чтобы проверить задачу, нужно вспомнить, какие артефакты мы можем получить:

• инсайт, ответ на вопрос почему;

• автоматизированный отчет (дашборд);

• ML-модели;

• код системы анализа данных.

Почти все эти задачи объединяет наличие программного кода. Исключением может быть разве что инсайт, для поиска которого порой достаточно обычного Excel, а программирование могло не потребоваться.

Для проверки программного кода проводится код-ревью (code review). На этом этапе какой-либо сотрудник (не исполнитель) изучает программный код, чтобы понять, насколько этот способ решения задачи корректен и соответствует стилистическому подходу, принятому в команде. Эта практика широко применяется в разработке ПО.

Когда пишете программу, всегда относитесь к ней как к тексту, который будет читать другой человек. Раньше, когда программу писал и поддерживал один человек, это было не так важно. Сейчас разработка ПО – это командная работа, в которой должно быть гарантировано качество. Компьютеру все равно, как выглядит ваша программа стилистически, а людям – нет. Те, кто будет работать с вашим кодом в дальнейшем – проверять его, оптимизировать скорость работы, переносить на другую платформу, – должны понимать его без лишних усилий. Если код вызывает вопросы, автора просят внести изменения так, чтобы текст стал читаемым и однозначным. Это одна из целей инспекции. Аналогичные стандарты работы действуют и в аналитике. Но есть несколько отличий от обычной разработки, расскажу о них далее.

В разработке используется система контроля версий, например Git. Через нее разработчики вносят изменения в аналитическую систему компании и проводят инспекцию. Я рекомендую весь код держать в системе контроля версий. Плюсы такого решения:

• все изменения будут прозрачны;

• в случае ухода разработчика/аналитика весь код останется у вас;

• если возникнут проблемы – легко откатить изменения, вернувшись к прошлой версии.

Инспекцию кода относительно легко сделать для всех артефактов аналитики, кроме инсайтов. C инсайтами не все так однозначно. Для их поиска и выкладок используются разные инструменты: Excel или его аналоги, графический интерфейс аналитической системы, SQL, блокноты Python или другого языка (например, Jupyter Notebooks). В таких задачах обычно присутствует несколько этапов:

• получение данных;

• их очистка;

• анализ;

• выводы.

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

Есть одна проблема с блокнотами (jupyter notebooks) – скрытые ошибки. В блокнотах выполняются разовые задачи (ad-hoc), и поэтому аналитики пренебрегают стандартами разработки – инспекциями кода и тестами. Как с этим бороться? Есть несколько способов проверить код и выводы.

Во-первых, проверяющий может очень внимательно просмотреть все решение на предмет ошибок. Это трудоемко, ведь по сути ему придется построить решение чуть ли не с нуля в своей голове. Во-вторых, можно воспользоваться другими источниками данных, которые хотя бы косвенно могли бы подтвердить вывод. В-третьих, можно последовать совету Кэсси Козырьков, директора по принятию решений в Google, из ее статьи «Самая мощная идея в анализе данных» [26]: сделать случайное разделение данных на два датасета (набора данных). По первому набору аналитик будет искать причину, а по второму проверяющий проверит выводы аналитика. Такой подход всегда используется в машинном обучении и называется валидацией (validation).

Хочу сделать важное замечание относительно решений, которые не используют код. В чем сложность их проверки? Представьте, что вы работаете в Excel и уже получили данные в виде файла. Вы должны загрузить его в Excel, проверить, почистить, написать формулы, построить таблицу или сводную таблицу (что удобнее для проверки). Теперь поставьте себя на место проверяющего. Часть операций в Excel делается мышью, данные можно копировать и вставлять блоками, протокола всех действий нигде нет. Чтобы посмотреть формулу – нужно кликнуть, а если таких формул много? И вы их «протягивали», а если ошиблись, исправили и не обновили все формулы? Чуть лучше с интерфейсами, где блоки выстраиваются графически и соединяются стрелками. Приходится щелкать по каждому блоку, проверять, все ли корректно. С кодом проверить все намного проще – все операции с данными написаны текстом! Не нужно никуда щелкать, все видно сразу. Еще один плюс кода – можно очень быстро пересчитать задачу – просто запустить код. В безкодовых решениях аналитику придется писать протокол – что и как он делал по шагам. Это облегчит проверку и даст возможность безболезненно повторить задачу в будущем. Конечно, Excel и другие визуальные инструменты очень ускоряют работу, я сам пользуюсь ими и не отговариваю вас. Моя задача обозначить плюсы и минусы этих подходов – что вам ближе, решать только вам.

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

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

Если задача вносит изменения в рабочую систему, то следующий шаг проверки – выкладка (deploy) изменений. Здесь все выглядит стандартно для разработки, и вы можете использовать практики, принятые у ваших разработчиков. В аналитике Retail Rocket мы использовали CI/CD на основе GitLab, когда все изменения выкладываются нажатием одной кнопки. Мы думали, кто это должен делать, и после различных экспериментов сошлись на том, что это должен делать исполнитель задачи. Как таковых инженеров тестирования у нас нет, поэтому исполнитель переводит задачу в статус тестирования (Testing). Далее делает выкладку, следит за тем, чтобы тесты были выполнены и изменения отразились на работе системы. Например, проверяет, что нужные отчеты работают и предоставляют информацию в требуемом виде. Цели выкладки: отразить изменения в рабочей системе, проверить, что все работает так, как этого требует задача.

Как защищать задачу перед инициатором

У задачи есть инициатор, который ее поставил, и только этот человек может дать разрешение перевести ее в статус выполненной. В статусе тестирования, после выполнения всех расчетов, исполнитель задачи обращается к инициатору с просьбой проверить результат. Это может быть инсайт, отчет или какое-то программное изменение системы. Тут инициатор должен либо согласиться с результатами задачи, либо нет. В случае отказа я рекомендую сравнить то, что требует инициатор по результатам проверки, с постановкой задачи. Разница между тем, чего хотят от вас сейчас, и тем, чего хотели на этапе планирования задачи, может быть большой. Встречается такая ситуация довольно часто. Как с этим бороться, особенно если инициатор находится выше исполнителя в иерархии? Во-первых, правила игры должны быть известны всем и быть явно обозначены. Во-вторых, как я уже писал, нужно вести аудиозапись на встречах планирования. В-третьих, если условия задачи изменились существенно, то нужно признать, что результаты ее оказались ненужными и время было потрачено зря. А затем завести новую задачу, трудоемкость которой будет оценена отдельно.

Отдельная проблема – инициатор не выходит на связь и ничего не делает с полученными результатами. Это может свидетельствовать о том, что задача «перегорела» и больше не интересна, если, конечно, не было каких-либо форс-мажоров. Неплохо было бы узнавать такие новости до того, как на задачу были потрачены ресурсы. Что делать? Я боролся с этим пессимизацией приоритета последующих задач от таких инициаторов, но, откровенно говоря, смог позволить себе это только заняв позицию сооснователя компании.

Нужно ли уметь программировать?

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

Я научился программировать самостоятельно в детстве. Отец купил компьютер «Партнер 01.01» в конце 80-х, когда мне было примерно одиннадцать лет, и я начал погружаться в программирование. Вначале освоил язык BASIC, потом уже добрался до ассемблера. Изучал все по книгам – спросить тогда было не у кого. Задел, который был сделан в детстве, мне очень пригодился в жизни. В то время моим главным инструментом был белый мигающий курсор на черном экране, программы приходилось записывать на магнитофон – все это не идет ни в какое сравнение с теми возможностями, которые есть сейчас. Азам программирования научиться не так сложно. Когда моей дочери было пять с половиной лет, я посадил ее за несложный курс по программированию на языке Scratch. С моими небольшими подсказками она прошла этот курс и даже получила сертификат MIT начального уровня.

Прикладное программирование – это то, что позволяет автоматизировать часть функций сотрудника. Первые кандидаты на автоматизацию – повторяющиеся действия.

В аналитике есть два пути. Первый – пользоваться готовыми инструментами (Excel, Tableau, SAS, SPSS и т. д.), где все действия совершаются мышкой, а максимум программирования – написать формулу. Второй – писать на Python, R или SQL. Это два фундаментально разных подхода, но хороший специалист должен владеть обоими. При работе с любой задачей нужно искать баланс между скоростью и качеством. Особенно это актуально для поиска инсайтов. Я встречал и ярых приверженцев программирования, и упрямцев, которые могли пользоваться только мышкой и от силы одной программой. Хороший специалист для каждой задачи подберет свой инструмент. В каком-то случае он напишет программу, в другом сделает все в Excel. А в третьем – совместит оба подхода: на SQL выгрузит данные, обработает датасет в Python, а анализ сделает в сводной (pivot) таблице Excel или Google Docs. Скорость работы такого продвинутого специалиста может быть на порядок больше, чем одностаночника. Знания дают свободу.

Еще будучи студентом, я владел несколькими языками программирования и даже успел поработать полтора года разработчиком ПО. Времена тогда были сложными – я поступил в МФТИ в июне 1998 года, а в августе случился дефолт. Жить на стипендию было невозможно, денег у родителей я брать не хотел. На втором курсе мне повезло, меня взяли разработчиком в одну из компаний при МФТИ – там я углубил знание ассемблера и Си. Через какое-то время я устроился в техническую поддержку компании StatSoft Russia – здесь я прокачал статистический анализ. В Ozon.ru прошел обучение и получил сертификат SAS, а еще очень много писал на SQL. Опыт программирования мне здорово помог – я не боялся чего-то нового, просто брал и делал. Если бы у меня не было такого опыта программирования, в моей жизни не было бы многих интересных вещей, в том числе компании Retail Rocket, которую мы основали с моими партнерами.

Датасет

Датасет – это набор данных, чаще всего в виде таблицы, который был выгружен из хранилища (например, через SQL) или получен иным способом. Таблица состоит из столбцов и строк, обычно именуемых как записи. В машинном обучении сами столбцы бывают независимыми переменными (independent variables), или предикторами (predictors), или чаще фичами (features), и зависимыми переменными (dependent variables, outcome). Такое разделение вы встретите в литературе. Задачей машинного обучения является обучение модели, которая, используя независимые переменные (фичи), сможет правильно предсказать значение зависимой переменной (как правило, в датасете она одна).

Основные два вида переменных – категориальные и количественные. Категориальная (categorical) переменная содержит текст или цифровое кодирование «категории». В свою очередь, она может быть:

• Бинарной (binary) – может принимать только два значения (примеры: да/нет, 0/1).

• Номинальной (nominal) – может принимать больше двух значений (пример: да/нет/не знаю).

• Порядковой (ordinal) – когда порядок имеет значение (пример, ранг спортсмена, номер строки в поисковой выдаче).

Количественная (quantitative) переменная может быть:

• Дискретной (discrete) – значение подсчитано счетом, например, число человек в комнате.

• Непрерывной (continuous) – любое значение из интервала, например, вес коробки, цена товара.

Рассмотрим пример. Есть таблица с ценами на квартиры (зависимая переменная), одна строка (запись) на квартиру, у каждой квартиры есть набор атрибутов (независимы) со следующими столбцами:

• Цена квартиры – непрерывная, зависимая.

• Площадь квартиры – непрерывная.

• Число комнат – дискретная (1, 2, 3…).

• Санузел совмещен (да/нет) – бинарная.

• Номер этажа – порядковая или номинальная (зависит от задачи).

• Расстояние до центра – непрерывная.

Описательная статистика

Самое первое действие после выгрузки данных из хранилища – сделать разведочный анализ (exploratory data analysis), куда входит описательная статистика (descriptive statistics) и визуализация данных, возможно, очистка данных через удаление выбросов (outliers).

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

• Количество непустых значений (non missing values).

• Количество уникальных значений.

• Минимум/максимум.

• Среднее значение.

• Медиана.

• Стандартное отклонение.

• Перцентили (percentiles) – 25 %, 50 % (медиана), 75 %, 95 %.

Не для всех типов переменных их можно посчитать – например, среднее значение можно рассчитать только для количественных переменных. В статистистических пакетах и библиотеках статистического анализа уже есть готовые функции, которые считают описательные статистики. Например, в библиотеке pandas для Python есть функция describe, которая сразу выведет несколько статистик для одной или всех переменных датасета:

s = pd.Series([4–1, 2, 3])

s.describe()

count 3.0

mean 2.0

std 1.0

min 1.0

25 % 1.5

50 % 2.0

75 % 2.5

max 3.0

Хотя эта книга не является учебником по статистике, дам вам несколько полезных советов. Часто в теории подразумевается, что мы работаем с нормально распределенными данными, гистограмма которых выглядит как колокол (рис. 4.1).

Очень рекомендую проверять это предположение хотя бы на глаз. Медиана – значение, которое делит выборку пополам. Например, если 25-й и 75-й перцентиль находятся на разном расстоянии от медианы, это уже говорит о смещенном распределении. Еще один фактор – сильное различие между средним и медианой; в нормальном распределении они практически совпадают. Вы будете часто иметь дело с экспоненциальным распределением, если анализируете поведение клиентов, – например, в Ozon.ru время между последовательными заказами клиента будет иметь экспоненциальное распределение.

Рис. 4.1. Нормальное распределение и Шесть Сигм

Среднее и медиана для него отличаются в разы. Поэтому правильная цифра – медиана, значение, которое делит выборку пополам. В примере с Ozon.ru это время, в течение которого 50 % пользователей делают следующий заказ после первого. Медиана также более устойчива к выбросам в данных. Если же вы хотите работать со средними, например, из-за ограничений статистического пакета, да и технически среднее считается быстрее, чем медиана, то в случае экспоненциального распределения можно его обработать натуральным логарифмом. Чтобы вернуться в исходную шкалу данных, нужно полученное среднее обработать обычной экспонентой.

Перцентиль – значение, которое заданная случайная величина не превышает с фиксированной вероятностью. Например, фраза «25-й перцентиль цены товаров равен 150 рублям» означает, что 25 % товаров имеют цену меньше или равную 150 рублям, остальные 75 % товаров дороже 150 рублей.

Для нормального распределения, если известно среднее и стандартное отклонение, есть полезные теоретически выведенные закономерности – 95 % всех значений попадает в интервал на расстоянии двух стандартных отклонений от среднего в обе стороны, то есть ширина интервала составляет четыре сигмы. Возможно, вы слышали такой термин, как Шесть сигм (six sigma, рис. 4.1), – эта цифра характеризует производство без брака. Так вот, этот эмпирический закон следует из нормального распределения: в интервал шести стандартных отклонений вокруг среднего (по три в каждую сторону) укладывается 99.99966 % значений – идеальное качество. Перцентили очень полезны для поиска и удаления выбросов из данных. Например, при анализе экспериментальных данных вы можете принять то, что все данные вне 99-го перцентиля – выбросы, и удалять их.

Графики

Хороший график стоит тысячи слов. Основные виды графиков, которыми пользуюсь я:

• гистограммы;

• диаграмма рассеяния (scatter chart);

• график временного ряда (time series) с линией тренда;

• график «ящики с усами» (box plot, box and whiskers plot).

Гистограмма (рис. 4.2) – наиболее полезный инструмент анализа. Она позволяет визуализировать распределение по частотам появления какого-то значения (для категориальной переменной) или разбить непрерывную переменную на диапазоны (bins). Второе используется чаще, и если к такому графику дополнительно предоставить описательные статистики, то у вас будет полная картина, описывающая интересующую вас переменную. Гистограмма – это простой и интуитивно понятный инструмент.

График диаграммы рассеяния (scatterplot, рис. 4.3) позволяет увидеть зависимость двух переменных друг от друга. Строится он просто: на горизонтальной оси – шкала независимой переменной, на вертикальной оси – шкала зависимой. Значения (записи) отмечаются в виде точек. Также может добавляться линия тренда. В продвинутых статистических пакетах можно интерактивно пометить выбросы.

Рис. 4.2. Гистограмма

Рис. 4.3. Диаграмма рассеяния

Графики временных рядов (time series, рис. 4.4) – это почти то же самое, что и диаграмма рассеяния, в которой независимая переменная (на горизонтальной оси) – это время. Обычно из временного ряда можно выделить две компоненты – циклическую и трендовую. Тренд можно построить, зная длину цикла, например, семидневный – это стандартный цикл продаж в продуктовых магазинах, на графике можно увидеть повторяющуюся картинку каждые 7 дней. Далее на график накладывается скользящее среднее с длиной окна, равной циклу, – и вы получаете линию тренда. Практически все статистические пакеты, Excel, Google Sheets умеют это делать. Если нужно получить циклическую компоненту, это делается вычитанием из временного ряда линии тренда. На основе таких простых вычислений строятся простейшие алгоритмы прогнозирования временных рядов.

Рис. 4.4. Временные ряды

График «Ящик с усами» (box plot, рис. 4.5) очень интересен; в некоторой степени он дублирует гистограммы, так как тоже показывает оценку распределения.

Рис. 4.5. Ящик с усами

Рис. 4.6. Ящики с усами для разных экспериментов

Он состоит из нескольких элементов: усов, которые обозначают минимум и максимум, ящика, верхний край которого 75-й перцентиль, нижний – 25-й перцентиль. В ящике линия – это медиана, значение «посередине», которая делит выборку пополам. Этот тип графика удобен для сравнения результатов экспериментов или переменных между собой. Пример такого графика ниже (рис. 4.6). Считаю это лучшим способом визуализации результатов тестирования гипотез.

Общий подход к визуализации данных

Визуализация данных нужна для двух вещей: для исследования данных и для того, чтобы объяснить выводы заказчику. Часто для представления результатов используется несколько способов: простой комментарий с парой цифр, Excel или другой формат электронных таблиц, презентация со слайдами. Все эти три способа объединяют вывод и доказательство – то есть объяснение, как к этому выводу пришли. Доказательство бывает удобно выражать в графиках. В 90 % случаев для этого достаточно тех графиков, типы которых были описаны выше. Исследовательские графики и презентационные отличаются друг от друга. Цель исследовательских – найти закономерность или причину, их, как правило, много, и бывает, что они строятся наугад. Целью презентационных графиков является подведение ЛПР (лица, принимающего решения) к выводам в задаче. Тут важно все – и заголовок слайда, и их простая последовательность, которая ведет к нужному выводу. Важный критерий схемы доказательства вывода – как быстро заказчик поймет и согласится с вами. Необязательно это должна быть презентация. Лично я предпочитаю простой текст – пара предложений с выводами, пара графиков и несколько цифр, доказывающих эти выводы, ничего лишнего.

Джин Желязны, который работает директором по визуальным коммуникациям в McKinsey & Company, в своей книге «Говори на языке диаграмм» утверждает [28]:

«Тип диаграммы определяют вовсе не данные (доллары или проценты) и не те или иные параметры (прибыль, рентабельность или зарплата), а ваша идея – то, что вы хотите в диаграмму вложить».

Рекомендую вам обращать внимание на графики в презентациях и статьях – доказывают ли они выводы автора? Все ли вам нравится в них? Могли бы они быть более убедительными?

А вот что пишет Джин Желязны про слайды в презентациях [28]:

«Широкое распространение компьютерных технологий привело к тому, что сейчас за минуты можно сделать то, на что раньше требовались часы кропотливой работы, – и слайды пекутся как пирожки… пресные и невкусные».

Я делал довольно много докладов: со слайдами и без, короткие, на 5–10 минут, и длинные – на час. Смею вас заверить, что мне намного сложнее сделать убедительный текст для короткого доклада без слайдов, чем презентацию в PowerPoint. Посмотрите на политиков, которые выступают: их задача убеждать, много ли из них показывают слайды на выступлениях? Слово убеждает сильнее, слайды – это всего лишь наглядный материал. И чтобы ваше слово было понятно и убедительно, требуется больше труда, чем для накидывания слайдов. Я себя поймал на том, что при составлении слайдов я думаю о том, как презентация выглядит. А при составлении устного доклада – насколько убедительны мои аргументы, как работать с интонацией, насколько понятна моя мысль. Пожалуйста, подумайте, действительно ли вам нужна презентация? Хотите ли вы превратить совещание в просмотр скучных слайдов вместо принятия решений?

«Совещания должны фокусироваться на кратких письменных отчетах на бумаге, а не на тезисах или обрывочных пунктах списка, проецируемых на стену», – утверждает Эдвард Тафти, видный представитель школы визуализации данных, в своей работе «Когнитивный стиль PowerPoint» [29].

Парный анализ данных

О парном программировании я узнал от разработчиков [30] Retail Rocket. Это техника программирования, при которой исходный код создается парами людей, программирующих одну задачу и сидящих за одним рабочим местом. Один программист сидит за клавиатурой, другой – работает головой, сосредоточен на картине в целом и непрерывно просматривает код, производимый первым программистом. Время от времени они могут меняться местами.

И нам удалось ее адаптировать для нужд аналитики! Аналитика, как и программирование, – творческий процесс. Представьте, что вам нужно построить стену. У вас есть один рабочий. Если вы добавите еще одного – скорость вырастет примерно в два раза. В творческом процессе так не получится. Скорость создания проекта не вырастет в два раза. Да, можно проект декомпозировать, но я сейчас обсуждаю задачу, которая не декомпозируется, и ее должен делать один человек. Парный же подход позволяет многократно ускорить этот процесс. Один человек за клавиатурой, второй сидит рядом. Две головы работают над одной проблемой. Когда я решаю сложные проблемы, я разговариваю сам с собой. Когда разговаривают две головы друг с другом – они ищут причину лучше. Мы используем схему парной работы для следующих задач.

• Когда нужно передать знания одного проекта от одного сотрудника другому, например, был нанят новичок. «Головой» будет сотрудник, который передает знания, «руками» за клавиатурой – кому передают.

• Когда проблема сложная и непонятная. Тогда два опытных сотрудника в паре решат ее намного эффективней одного. Будет сложнее сделать задачу анализа однобоко.

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

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

Технический долг

Еще одна важная вещь, которой я научился у инженеров Retail Rocket [31], – работа с техническим долгом (technical debt). Технический долг – это работа со старыми проектами, оптимизация скорости работы, переход на новые версии библиотек, удаление старого программного кода от тестирования гипотез, инженерное упрощение проектов. Все эти задачи занимают добрую треть времени разработки аналитики. Приведу цитату технического директора Retail Rocket Андрея Чижа [31]:

«Я еще не встречал компаний за свою практику (а это более 10 компаний, в которых работал сам, и примерно столько же, с которыми хорошо знаком изнутри), кроме нашей, у которых в бэклоге были бы задачи на удаление функционала, хотя, наверное, такие существуют».

Я тоже не встречал. Видел «болота» программных проектов, где старье мешает создавать новое. Суть технического долга – все, что вы сделали ранее, нужно обслуживать. Это как с ТО автомобиля – его нужно делать регулярно, иначе машина сломается в самый неожиданный момент. Программный код, в который давно не вносились изменения или обновления, – плохой код. Обычно он уже работает по принципу «работает – не трогай». Четыре года назад я общался с разработчиком Bing. Он рассказал, что в архитектуре этого поискового движка есть скомпилированная библиотека, код которой потерян. И никто не знает, как это восстановить. Чем дольше это тянется, тем хуже будут последствия.

Как аналитики Retail Rocket обслуживают технический долг:

• После каждого проекта тестирования гипотез мы удаляем программный код этой гипотезы везде, где только можно. Это избавляет нас от ненужного и неработающего хлама.

• Если происходит обновление каких-либо версий библиотек – мы делаем это с некоторым запозданием, но делаем регулярно. Например, платформу Spark мы апгрейдим регулярно, начиная с версии 1.0.0.

• Если какие-либо компоненты обработки данных работают медленно – ставим задачу и занимаемся ею.

• Если есть какие-то потенциально опасные риски – например, переполнение дисков кластера, тоже ставится соответствующая задача.

Работа с техническим долгом – это путь к качеству. Меня убедила в этом работа в проекте Retail Rocket. С инженерной точки зрения проект сделан как в «лучших домах Калифорнии».

Глава 5
Данные

Данные – представление фактов, понятий или инструкций в форме, приемлемой для общения, интерпретации или обработки человеком или с помощью автоматических средств.

Википедия

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

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

• Медицинские анализы – помощь в постановке диагноза, принятие решений о выводе лекарства на рынок.

• Фотографии – поиск предметов, распознавание лиц.

• Товары – закупки нужных товаров на склад.

• История посещений сайта – рекомендательная система интересных страниц.

• Список клиентов – разбить их на группы, чтобы предложить разные скидки.

• Географические карты – навигация с учетом автомобильных пробок.

Как собираются данные

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

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

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

Big Data

Очень хайповый термин, который сейчас звучит из каждого утюга. Мне посчастливилось поработать в этой теме последние 8 лет и накопить достаточно большую экспертизу. Попробую дать собственное определение: большие данные (Big Data) – это такой объем данных, который невозможно обработать в требуемое время на одной машине (сервере).

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

Большой объем данных на самом деле получить очень несложно. Дам простой пример. Если каждую миллисекунду сохранять вашу геопозицию, например GPS координаты, то за сутки мы получим: 1000 миллисекунд в секунде × 60 секунд × 60 минут × 24 часа = 86 400 000 событий. Цифра очень впечатляет, особенно если масштабировать ее на всех людей на Земле. Более подробно о больших данных я расскажу в главе про хранилища данных.

Связность данных

Одна из важнейших характеристик данных – возможность связать разные источники данных. Например, если удается связать затраты на интернет-рекламу и продажи через нее, то вы получаете инструмент эффективности. Далее добавляем данные по реально доставленным заказам, так как в некоторых e-commerce-бизнесах процент отказов очень высок. И на выходе мы получаем эффективность с поправкой на отказы. Фантазируем дальше, добавляем к данным категории товаров – получаем возможность видеть эффективность рекламы в разрезе категорий товаров. Продолжать можно до бесконечности. Кстати, именно этот пример иллюстрирует то, что называется «сквозной аналитикой».

Вышеприведенный пример показывает, что, добавляя новый источник данных, мы можем улучшить точность и увеличить число «степеней свободы», что можно делать с самими данными. Лично для меня это увеличивает ценность данных на порядок. Вот только есть одна заминка с тем, как эти данные связать. Для этого нужен «ключ», который должен быть в обоих источниках, и этот ключ не всегда бывает настолько точным, насколько требуется нам. Поясню на примере. Чтобы идеально связать затраты на интернет-рекламу и покупки, нужен ключ – id пользователя. Но проблема в том, что, скорее всего, от рекламных систем вы не получите информации о том, сколько вы потратили денег на конкретного пользователя. Из-за этого приходится использовать набор ключей из ссылок, которые однозначно характеризуют рекламное объявление. Точность из-за этого страдает, но это реальная жизнь данных – лучше получить что-то, чем ничего.

Много данных не бывает

Эту фразу я повторял, когда работал в Ostrovok.ru. Я точно не помню, с чем она была связана, возможно, требовалось расширить парк серверов. Считаю, что в эпоху облачных вычислений, дешевого хранения данных и хороших алгоритмов их сжатия нужно сохранять максимально много и подробно. Поверьте, когда понадобится найти ответ на какой-то вопрос и вы будете понимать, что данных нет, а могли бы быть, будет очень обидно. Рано или поздно собирать их все равно придется, почему бы не начать прямо сейчас?

ВАЖНО! Здесь хочу поднять одну проблему: в какой бы компании я ни работал – везде разработчики игнорируют аналитиков. При разработке какого-либо функционала или продукта анализ его функциональности через данные ставится на последнее место. В лучшем случае будет сделан сбор простейших метрик по усмотрению разработчика. Дальнейший сценарий такой – менеджеры проекта или продукта, владельцы бизнеса начинают активно интересоваться его судьбой. Что там с цифрами? Бегут к аналитикам, просят нарыть хоть что-нибудь. А что может сделать аналитик, если данных для статистических тестов не хватает и точность страдает? Только высосать информацию из пальца. С таким положением вещей я лично сталкивался десятки раз, а случаи, когда все было сделано как надо, могу по пальцам пересчитать.

Я предлагаю активно бороться с этим. Разработку можно понять – им нужно как можно быстрее выкатить новую «фичу» с очень хорошим качеством. Анализ метрик их не волнует, это лишние строчки кода, это работа аналитиков. Что делать? Это сфера ответственности менеджера проекта/продукта, лица, от имени которого ставится задача разработке. Необходимо в процессе постановки подобных задач предусмотреть «визу» от аналитиков. Что в нее входит:

1. Отправка технического задания и примерного списка вопросов к эффективности новой разработки аналитикам.

2. Аналитики со своей стороны отдают вам список метрик, а также встречное техническое задание для логирования (сбора метрик) данных проекта: что собирать и в каком формате.

Этот процесс не так прост, как кажется. Часто приходится в итеративном формате договариваться обо всех нюансах и ограничениях, в том числе с разработчиками. Происходит своеобразный торг, но он стоит того. Заранее хорошо продуманный результат не будет идеальным на 100 %, но если менеджмент получит ответы на 80 % своих вопросов в течение нескольких дней с момента запуска «фичи» – это успех. Ничто не играет против нас так, как время! И лучше его потратить до запуска, а не после, теряя деньги на неэффективном продукте.

Доступ к данным

Теперь коснемся доступа к данным внутри компании. Кто может получить его?

Отвлечемся на компанию Netflix, один из крупнейших поставщиков сериалов (мой любимый – «Карточный домик»). У компании очень интересная корпоративная культура [32]. Один из ее принципов звучит так: «Share information openly, broadly, and deliberately» (обмениваемся информацией открыто, широко и сознательно).

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

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

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

Качество данных

Данные бывают грязными, очень грязными. Если вам встретятся «чистые» данные, то это, скорее всего, неправда. Но бывает, что в жизни сказочно везет. Аналитики данных тратят львиную долю своего времени на очистку данных от выбросов и прочих артефактов, которые могут помешать получить правильное решение. Мы все работаем в условиях неопределенности, и увеличивать ошибку из-за грязи в данных совсем не хочется.

Для меня качественные данные – это данные, которые могут быть использованы для решения конкретной задачи без каких-либо предварительных очисток. Я намеренно написал «конкретной задачи», потому что считаю: разные задачи требуют разной степени точности, так как последствия и уровень риска для компании разные. И мы движемся по лезвию бритвы, стараясь решить задачу как можно быстрее наименьшими усилиями, балансируем между трудоемкостью и ценой ошибки. Если это бухгалтерская задача, то она требует очень высокой степени точности, так как санкции налоговой службы могут быть весьма болезненными. Если управленческая и последствия не столь значимы, то некоторой степенью точности можно пренебречь. Решение здесь за руководителем аналитики.

Основные причины плохого качества данных:

• человеческий фактор;

• техническая потеря данных;

• ошибка интеграции и выгрузки данных в хранилище;

• отставание в обновлении данных в хранилище.

Рассмотрим более подробно.

Часть данных приходит от людей напрямую: по разным каналам связи они отдают нам цифры. Для простоты будем считать, что периодически они заполняют какую-то форму и отправляют нам. Из школьного курса физики мы знаем про погрешность отсчета по шкале – при любых измерениях принимается погрешность отсчета, равная половине цены деления. Для линейки с миллиметровой шкалой это полмиллиметра. То есть просто из-за того, что мы можем посмотреть не под тем углом, чуть сдвинуть линейку, – мы уже ошибаемся. Чего же ждать от людей, которые используют инструменты посложнее линейки?

Кроме того, не стоит забывать про намеренную фальсификацию данных. Давайте будем называть вещи своими именами: изменения, которые внесены в данные человеком, пусть даже из лучших побуждений, – это намеренная фальсификация. За примерами ходить далеко не нужно – выборы! Спасибо независимым исследователям, которые анализируют данные участков, ищут аномалии, выбросы и прочие «неслучайные» закономерности. В промышленности тоже есть методики поиска аномалий, например, с помощью статистических карт контроля качества.

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

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

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

Как проверяется и контролируется качество данных

Для меня это сродни искусству, но существует несколько полезных практик, из тех, которые по принципу Парето дают 80 % результата при затраченных 20 % усилий:

• мониторинг выгрузки данных в хранилище;

• здоровый скептицизм к полученным результатам анализа;

• статистический анализ выбросов;

• особое внимание к недублированным источникам данным.

Первый шаг для любой аналитической системы – ее мониторинг, а именно мониторинг обновления данных в хранилище. Это несложно, зато очень эффективно с точки зрения максимально быстрого поиска проблем. Такой мониторинг можно разделить на две части: одна отслеживает, что данные поступают в систему вовремя, вторая убеждается, что они корректны. Первая часть очень проста, как правило она реализована на специально программе или системе-планировщике (scheduler). Главное – правильно подписаться на уведомления об ошибках и вовремя на них реагировать. Лучше это делать, как в армии: лампочка загорелась – бежим исправлять; стоит составить инструкции для персонала, как действовать в случае аварии.

Вторая часть значительно сложнее. Хорошие тесты на корректность данных дорогого стоят. Если есть доступ к источнику и способ запускать на нем несложные запросы, то можно сравнивать простые статистики данных в хранилище и источнике. Также можно проверять целостность данных, сравнивая их уже в хранилище, – действительно ли во всех справочниках есть информация и т. д.

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

Выбросы – это данные, которые не укладываются в нашу картину мира, а точнее в распределение, которое мы обычно наблюдаем: кто-то совершил очень крупную покупку в магазине, поступили странные данные от одного из избирательных участков, зачислена аномально большая сумма на счет. Все это выбросы, но удалять их из анализа просто так нельзя. Часто удаление выброса может привести к изменению выводов и решений на полностью противоположные. Считаю, что работа с выбросами данных является искусством. Более подробно это рассмотрим в главе 10.

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

Типы данных

Вот основные типы данных, с которыми приходится работать:

1. Состояние на определенный момент времени.

2. Лог изменений данных.

3. Справочники.

Разберем каждый тип отдельно на примере с банковским счетом. Итак, у вас есть счет, туда приходит зарплата, скажем, первого числа каждого месяца. Вы пользуетесь картой, привязанной к этому счету, для оплаты покупок. Так вот, остаток средств на вашем счете прямо сейчас – это состояние счета на определенный момент времени. Движение средств по счету – это так называемый лог изменений состояния счета (лог изменения данных). А справочником могут выступать категории покупок, которые банк проставляет в онлайн-приложении для каждой покупки, например: продукты, авиабилеты, кинотеатр, ресторан. А теперь подробнее о каждом типе данных.

Состояние на определенный момент времени. Все мы имеем дело с разными объектами, как физическими, так и виртуальными. Эти объекты имеют свойства или атрибуты, которые могут изменяться во времени. Например, координаты вашего местонахождения на карте, остаток средств на счете, цвет волос, который может измениться после посещения парикмахерской, рост и вес, которые меняются со в�

Иллюстрации Владимира Вышванюка

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

© ООО Издательство «Питер», 2021

© Серия «IT для бизнеса», 2021

© Роман Зыков, 2021

Об авторе

Роман Владимирович Зыков, 1981 года рождения, в 2004 году получил степень бакалавра, а затем магистра прикладной физики и математики в МФТИ (Московском физико-техническом институте).

В 2002 году начал свой карьерный путь в аналитике данных (Data Science) в качестве технического консультанта в компании StatSoft Russia, российского офиса одноименной американской компании-разработчика пакета статистического анализа данных STATISTICA. В 2004 году был принят на должность руководителя аналитического отдела интернет-магазина Ozon.ru, где создавал аналитические системы с нуля, в том числе веб-аналитику, аналитику баз данных, управленческую отчетность, внес вклад в систему рекомендаций.

В 2009 году консультировал ряд проектов инвестиционного фонда Fast Lane Ventures и гейм-индустрии.

В 2010 году возглавил отдел аналитики в интернет-ритейлере Wikimart.ru.

В конце 2012 года стал сооснователем и совладельцем маркетинговой платформы для интернет-магазинов RetailRocket.ru. На текущий момент компания является безусловным лидером на рынке в России и успешно работает на рынках Чили, Голландии, Испании и других.

С 2007-го вел блог «Аналитика на практике» (KPIs.ru – ныне не существует), где евангелизировал анализ данных в применении к бизнес-задачам в электронной коммерции. Выступал на отраслевых конференциях, таких как РИФ, iMetrics, Gec 2014 вместе с Аркадием Воложем (Yandex), бизнес-конференциях в Дублине и Лондоне, в посольстве США (AMC Center), университете Сбербанка. Печатался в технологическом прогнозе PwC, ToWave, «Ведомостях», «Секрете фирмы».

В 2016 году прочитал мини-лекцию в концертном зале MIT в Бостоне о процессах тестирования гипотез.

В 2020 году был номинирован на премию CDO Award.

Благодарности

Я посвящаю эту книгу своей жене Екатерине и моим детям – Аделле и Альберту. Катя придала мне решимости написать книгу и приняла большое участие в редактировании текстов. За что я ей очень благодарен.

Также я благодарен своим родителям, которые вырастили и воспитали меня в очень непростое время. Отдельная благодарность моему отцу Владимиру Юрьевичу за то, что привил мне любовь к физике.

Я благодарен всем на моем долгом пути в аналитику данных. Илье Полежаеву, Большакову Павлу и Владимиру Боровикову за грамотное руководство, когда я только пришел в StatSoft. Бернару Люке, тогда генеральному директору Ozon.ru, а также коллегам в Ozon.ru: Александру Перчикову, Александру Алехину, Валерию Дьяченко – за совместное написание рекомендательной системы. Марине Туркиной и Ирине Коткиной – с вами было замечательно сотрудничать. Основателям проекта Wikimart.ru Камилю Курмакаеву и Максиму Фалдину – те знакомства в Калифорнии очень сильно повлияли на меня. Александру Аникину – ты очень крутой был тогда, а сейчас вообще звезда. Основателям проекта Ostrovok.ru – Кириллу Махаринскому и Сержу Фаге, а также Жене Курышеву, Роману Богатову, Феликсу Шпильману – с вами очень интересно было работать, я узнал много нового о разработке.

Я благодарен сооснователям Retail Rocket – Николаю Хлебинскому и Андрею Чижу. Отдельная благодарность венчурному фонду Impulse VC (Кириллу Белову, Григорию Фирсову, Евгению Пошибалову) – за то, что поверили в нас. Всем сотрудникам Retail Rocket, особенно моим ребятам Александру Анохину и Артему Носкову – вы лучшие.

Я благодарен психологу Елене Клюстер, с которой работаю уже несколько лет, за осознание своих собственных границ и своих истинных желаний. Благодарен Андрею Гузю, моему тренеру по плаванию, за аналитический подход к тренировкам. Оказывается, так можно, и не только профессионалам, но и любителям.

Выражаю благодарность всем моим виртуальным рецензентам, особенно Артему Аствацатурову, Александру Дмитриеву, Аркадию Итенбергу, Алексею Писарцову. Роману Нестеру – за рецензию на главу по этике данных.

Благодарен всем, кто способствовал изданию этой книги. Прежде всего Алексею Кузменко, который помог мне быстро найти издательство, минуя бюрократические препоны. Отдельная благодарность Владимиру Вышванюку за ироничные иллюстрации кота Вилли. Юлии Сергиенко и Наталье Римицан, которые делали все, чтобы эта книга вышла в свет.

От издательства

Ваши замечания, предложения, вопросы отправляйте по адресу [email protected] (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.

Введение

Дайте мне точку опоры, и я переверну Землю.

Архимед

Дайте мне данные, и я переверну всю вашу жизнь.

Data Scientist Архимед

Данные повсюду – начиная от алгоритмов «Тиндера», который «матчит» вас с далеко не случайными людьми, и заканчивая информационными войнами, которые ведут политики. Никого уже не удивляет, что за каждым нашим шагом пристально следят: будь то история запросов в браузере телефона или ваши действия в офлайне. Задержитесь на секунду у витрины спортивного магазина – и ждите его таргетированную рекламу в соцсетях с минуты на минуту. Расскажите коллеге, что натворил ваш кот, – и вот сухие корма и наполнители уже тут как тут в вашей ленте.

Особо впечатлительные могут впасть в паранойю – но данные в этом не виноваты. Все зависит от того, в чьи руки они попадут. С анализом данных связано очень много мифов, а data scientist – одна из самых перспективных и «сексуальных» профессий будущего. В своей книге я намерен развенчать мифы и рассказать, как все обстоит на самом деле. Надеюсь, читатель, ты, как и я, окажешься на «светлой» стороне силы.

Я окончил МФТИ в начале нулевых и тогда же возглавил аналитический отдел интернет-магазина Ozon.ru, где создавал аналитические системы с нуля. Я консультировал инвестиционные фонды, гигантов ритейла и гейм-индустрии, а восемь лет назад стал сооснователем и совладельцем маркетинговой платформы для интернет-магазинов RetailRocket.ru. Сейчас компания не просто является безусловным лидером на рынке в России, но и успешно работает на рынках Чили, Голландии, Испании и Германии. В 2016 году я прочитал лекцию в концертном зале MIT в Бостоне про процессы тестирования гипотез. В 2020 году номинировался на премию CDO Award.

Считается, что нужно потратить 10 000 часов для того, чтобы стать очень хорошим специалистом в своей области. Анализом данных я занимаюсь с 2002 года, когда это не было так популярно и хайпово. Так вот, чтобы получить эти заветные 10 000 часов, нужно проработать 10 000 часов / 4 часа в день / 200 дней в году = 12.5 лет. Я в полтора раза превысил эту цифру, поэтому, надеюсь, получилось написать книгу, которая будет очень полезна для вас, дорогие читатели.

Эта книга о том, как превращать данные в продукты и решения. Она основывается не на академических знаниях, а на моем личном опыте анализа данных длиной почти в двадцать лет. Сейчас существует очень много курсов по анализу данных (data science) и машинному обучению (machine learning, ML). Как правило, они узкоспециализированы. Отличие этой книги в том, что она, не утомляя частностями, дает цельную картину и рассказывает о том:

• как принимать решения на основе данных;

• как должна функционировать система;

• как тестировать ваш сервис;

• как соединить все в единое целое, чтобы на выходе получить «конвейер» для ваших данных.

Для кого эта книга

Эта книга предназначена для думающих читателей, которые хотят попробовать свои силы в области анализа данных и создавать сервисы на их основе.

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

Как читать эту книгу

Я писал эту книгу так, чтобы ее можно было читать непоследовательно. Краткое содержание каждой главы:

Глава 1 «Как мы принимаем решения» описывает общие принципы принятия решения, как данные влияют на них.

Глава 2 «Делаем анализ данных» вводит общие понятия – с какими артефактами мы имеем дело, когда анализируем данные. Кроме того, с этой главы я начинаю поднимать организационные вопросы анализа данных.

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

Глава 4 «Делаем аналитические задачи» – полностью о задачах. Что такое хорошая аналитическая задача, как ее проверить. Технические атрибуты таких задач – датасеты, описательные статистики, графики, парный анализ, технический долг.

Глава 5 «Данные» о том, что говорят о данных – объемы, доступы, качество и форматы.

Глава 6 «Хранилища данных» рассказывает, зачем нужны хранилища, какие они бывают, также затрагиваются популярные системы для Big Data – Hadoop и Spark.

Глава 7 «Инструменты анализа данных», полностью посвящена наиболее популярным способам анализа от электронных таблиц в Excel до облачных систем.

Глава 8 «Алгоритмы машинного обучения» является базовым введением в машинное обучение.

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

Глава 10 «Внедрение ML в жизнь: гипотезы и эксперименты» рассказывает о трех видах статистического анализа экспериментов (статистика Фишера, байесовская статистика и бутстрэп) и об использовании А/Б-тестов на практике.

Глава 11 «Этика данных». Я не смог пройти мимо этой темы, наша область начинает все больше и больше регулироваться со стороны государства. Здесь поговорим о причинах этих ограничений.

Глава 12 «Задачи и стартапы» рассказывает об основных задачах, которые я решал в e-commerce, а также о моем опыте сооснователя проекта Retail Rocket.

Глава 13 «Строим карьеру» больше предназначена для начинающих специалистов – как искать работу, развиваться и даже когда уходить дальше.

Глава 1

Как мы принимаем решения

«Итак, главный принцип – не дурачить самого себя. А себя как раз легче всего одурачить. Здесь надо быть очень внимательным. А если вы не дурачите сами себя, вам легко будет не дурачить других ученых. Тут нужна просто обычная честность.

Я хочу пожелать вам одной удачи – попасть в такое место, где вы сможете свободно исповедовать ту честность, о которой я говорил, и где ни необходимость упрочить свое положение в организации, ни соображения финансовой поддержки – ничто не заставит вас поступиться этой честностью. Да будет у вас эта свобода».

Нобелевский лауреат Ричард Фейнман, из выступления перед выпускниками Калтеха в 1974 году

Монетизация данных возможна лишь тогда, когда мы принимаем на основе этих данных правильные решения. Однако делать выбор, руководствуясь только статистикой, – плохая идея: как минимум нужно уметь читать их между строк и слушать свою интуицию (gut feeling). Поэтому в первой главе я расскажу про принципы, которыми я пользуюсь, принимая решения на основе данных. Я проверял на своем опыте – они работают.

Решения принимать непросто, ученые даже придумали новый термин «усталость от решений» (decision fatigue) [7]. Мы накапливаем стресс, совершая выбор каждый день сотни раз: и в какой-то момент, когда уже полностью вымотаны необходимостью принимать решения, можем махнуть рукой и начать действовать наугад. Я не зря привел в начале этой книги цитату выдающегося физика, нобелевского лауреата Ричарда Фейнмана. Она напрямую касается как аналитики данных, так и вообще нашей жизни.

Как принимать верные решения, оставаясь честным с собой?

В книге «Биология добра и зла. Как наука объясняет наши поступки» профессор Стэнфордского университета, нейробиолог Роберт Сапольски [1] пишет, что на наши поступки, а значит и решения, влияет множество факторов: cреда, в которой мы выросли, детские травмы, травмы головы, гормональный фон, чувства и эмоции. На нас всегда влияет множество факторов, которые мы даже не осознаем. Мы необъективны!

Лично я принял как данность, что гораздо легче принять необъективное и срезать углы, чем объективное, потому что для второго нужны серьезные усилия.

Вспомните об этом, когда будете предоставлять цифры кому-либо для принятия решения. И даже мои сотрудники указывали мне на то, что я сам нарушаю принципы объективности при утверждении результатов некоторых А/Б-тестов. Тогда я возвращался к реальности и соглашался с ними – объективность важнее моих априорных решений до проведения эксперимента.

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

Четыреста сравнительно честных способов

Остап Бендер знал четыреста сравнительно честных способов отъема денег у населения. Профессиональный аналитик знает примерно столько же способов «повернуть» цифры в сторону «нужного» решения. К сожалению, это очень распространено в политике: вспомните, как государства рапортовали о количестве зараженных во время пандемии вируса COVID-19. Показатели смертности в России были занижены [6]. Оказалось, что если человек болел коронавирусом и умер от сопутствующего заболевания, то в соответствующую статистику не попадет. В большинстве же западных стран одной положительной пробы на коронавирус было достаточно, чтобы попасть в статистику. Если копнуть глубже, мы видим, что у всех разная методика и разные цели. Существуют объективные и субъективные причины неточности таких цифр.

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

Вторая причина тоже объективная – нет денег на массовое тестирование населения.

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

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

Чему можно научиться у Amazon?

Мне всегда нравились письма Джеффа Безоса (основателя Amazon.com) акционерам. Например, еще в 1999 году он писал про важность систем персональных рекомендаций на сайте, которые сейчас стали стандартом в современной электронной коммерции. Меня заинтересовали два его письма: 2015 [2] и 2016 [3] годов.

В первом из них Безос писал про «Фабрику изобретений» (Invention Machine). Он точно знает, о чем говорит, – само провидение вело Amazon через тернии электронной коммерции. Попутно в компании изобретали много вещей, абсолютно новых для рынка: система рекомендаций, А/Б-тесты (да-да, именно они были пионерами тестирования гипотез для веба), AWS (Amazon Web Services), роботизация склада, кнопки на холодильник для мгновенного заказа порошка и многое другое.

Так вот, в первом письме он рассуждает о том, как в больших компаниях принимаются решения об изобретении новых продуктов. Часто процесс утверждения выглядит так: все участники процесса (как правило, руководители департаментов компании) проставляют свои «визы». Если решение положительное, идея или гипотеза отправляются на реализацию. Здесь Безос предупреждает, что есть два типа решений и они не должны проходить один и тот же процесс утверждения.

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

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

В письме 2016 года Безос противопоставляет компанию Дня 1 (Day 1), где сохраняется живая атмосфера создания компании и новых продуктов, компании Дня 2 (Day 2), которая статична и, как следствие, приходит к своей ненужности и смерти. Он выделяет 4 фактора, которые определяют компанию Дня 1:

• истинная одержимость покупателем (customer obsession);

• скепсис относительно моделей (a skeptical view of proxies);

• стремительное освоение внешних трендов (the eager adoption of external trends);

• стремительное принятие решений (the eager adoption of external trends).

Последний пункт мне кажется особенно важным в контексте этой книги. Для поддержания атмосферы компании Дня 1 требуется принимать быстрые и качественные решения. Мой шестилетний сын в таких случаях восклицает: «Но как?» Вот правила Безоса:

1. Никогда не использовать один-единственный процесс принятия решений (есть два типа решений, про которые я написал выше). Не дожидаться получения 90 % всей информации, нужной для принятия решения, – 70 % уже достаточно. Ошибаться не так страшно, если вы умеете быстро исправляться. А вот промедление, скорее всего, влетит вам в копеечку.

2. Не соглашайся, но позволяй. Когда руководителю предлагают идею талантливые и успешные сотрудники, а он не согласен с ней – ему стоит просто позволить им ее реализовать, а не тратить их усилия на то, чтобы убедить. Безос рассказал, как дали зеленый свет одному из сериалов Amazon Studios. Он считал, что запускать этот проект рискованно: Безосу эта история казалась сложной в производстве и не слишком интересной. Но команда с ним не соглашалась. Тогда он сказал – хорошо, давайте пробовать. Им не пришлось убеждать Безоса в своей правоте, и они сэкономили уйму времени. Сам он подумал так: эти ребята уже привезли домой одиннадцать премий «Эмми», шесть «Золотых Глобусов» и три «Оскара» – они знают, что делают, просто у нас разные мнения.

3. Быстро находите причины несогласия и эскалируйте их наверх вашим руководителям. Разные команды могут иметь разные взгляды на решение. Вместо того чтобы тратить время на изматывающих совещаниях в попытках договориться – лучше эскалировать проблему наверх.

Аналитический паралич

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

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

Яркий пример – книга «Проект Рози» Грэма Симсиона (кстати, одна из любимых книг Билла Гейтса и его жены). Молодой успешный ученый-генетик Дон ищет жену, но ни разу еще не продвинулся дальше первого свидания. Сочтя традиционный способ поиска второй половинки неэффективным, Дон решает применить научный подход. Его проект «Жена» начинается с подробнейшего 30-страничного вопросника, призванного отсеять всех неподходящих и выявить одну – идеальную. Понятно, что человека, который соответствовал бы такому списку требований, просто не существует. А потом он знакомится с девушкой, у которой нет ничего общего с его идеалом. Что из этого вышло – догадайтесь сами.

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

Третий пример из моей профессиональной практики связан с гипотезами, точнее с тестами. Представьте себе, что вы вместо старого алгоритма рекомендаций разработали новый и хотите его протестировать. У вас есть 10 сайтов, где можно выполнить сравнение. В итоге вы получили: 4 выигрыша, 4 ничьи и 2 проигрыша. Стоит ли заменить старый алгоритм на новый? Все зависит от критериев решения, которые сформулировали перед тестом. Новый алгоритм должен победить на всех сайтах? Или вероятность выигрыша должна быть больше вероятности проигрыша? В первом случае очень высока вероятность того, что вы закопаетесь в бесконечных итерациях, «полируя» свой алгоритм до совершенства, особенно учитывая то, что тесты займут не одну неделю. Это типичная ситуация «аналитического паралича». Во втором – условие кажется легким. Хотя из практики скажу, что даже его выполнить бывает очень непросто.

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

Погрешности – правило штангенциркуля

Следующая вещь, с которой я столкнулся, – это точность цифр. Я много занимался анализом маркетинговой деятельности, в том числе маркетинговых акций. Моя задача заключалась в том, чтобы как можно более точно оценить их влияние на бизнес. Вообще реакция менеджеров на цифры разная – все радуются положительным результатам, не проверяя их; но когда видят отрицательные – сразу ищут ошибку. И скорее всего, «найдут». Видите ли, все метрики содержат ошибку. Вспомните лабораторные работы по физике в школе или институте, сколько мы мучились и считали погрешности. Системные, случайные… Сколько времени мы тогда тратили на то, чтобы подогнать результат под нужную закономерность?

В бизнесе и науке так делать нельзя, особенно если вы хотите быть хорошим аналитиком и не пользоваться вышеупомянутыми «сравнительно честными способами» повернуть цифры туда, куда нужно. Сейчас погрешность измерений веб-аналитики (системы измеряют посещаемость веб-сайтов) составляет около 5 %. Когда я еще работал в Ozon.ru, погрешность всей аналитической системы тоже была около 5 % (расхождение с данными бухгалтерии). У меня был серьезный случай – я обнаружил ошибку в коммерческой системе веб-аналитики Omniture Sitecatalyst (ныне Adobe Analytics): она не считала пользователей с браузером Opera. В результате погрешность измерений была очень большой – около 10 % всех совершенных заказов система, за которую мы платили более 100 тысяч долларов в год, безнадежно потеряла. С такой погрешностью ей тяжело было доверять – но, к счастью, когда я обнаружил ошибку системы и сообщил о ней в Omniture, их разработчики ее устранили.

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

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

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

Принцип Парето

Итальянский экономист и социолог Вильфредо Парето в 1897 году, исследуя структуру доходов итальянских домохозяйств, выяснил, что 80 % процентов всех их доходов приходится на 20 % из них.

Универсальный принцип, названный в его честь, был предложен в 1951 году, и сейчас принцип Парето звучит так: «20 % усилий дают 80 % результата».

Опираясь на свой опыт, я бы так сформулировал его на языке данных:

• 20 % данных дают 80 % информации (data science);

• 20 % фич или переменных дают 80 % точности модели (machine learning);

• 20 % из числа успешных гипотез дают 80 % совокупного положительного эффекта (тестирование гипотез).

Я почти 20 лет работаю с данными и каждый день убеждаюсь в том, что эта закономерность работает. Это правило лентяя? Только на первый взгляд. Ведь чтобы понять, какие именно 20 % позволят добиться результата, нужно потратить 100 % усилий. Стив Джобс в интервью Business Week в 98-м году сказал: «Простое сделать труднее, чем сложное: вам придется усердно поработать, чтобы внести ясность в ваши мысли, и тогда станет понятно, как сделать проще. Но это стоит того: как только вы достигнете этого, вы сможете свернуть горы».

Приведу пример того, как применяется правило Парето в машинном обучении. Для проекта обычно готовится ряд фич (входных параметров модели), на которых будет тренироваться модель. Фич может получиться очень много. Если выводить такую модель в бой, она будет тяжелой, требовать для своего поддержания много строк программного кода. Для такой ситуации есть лайфхак – посчитать вклад каждой фичи (feature importance) в результирующую модель и выбросить из модели фичи с минимальным вкладом. Это прямое использование правила Парето – 20 % фич дают 80 % результата модели. В большинстве случаев лучше модель упростить, пожертвовав небольшой долей ее точности, при этом проект будет в разы меньше исходного. На практике можно экономить время, подсмотрев фичи в решениях какой-нибудь схожей задачи на kaggle.com. Взять оттуда самые сильные из них и реализовать в первой версии собственного проекта.

Можно ли принимать решения только на основе данных?

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

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

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

Ошибку выжившего допустить очень легко. Чему нас учит пример Вальда? Тому, что нужно думать о всей генеральной совокупности. Ошибка выжившего является одной из форм когнитивных искажений.

В анализе данных ошибка выжившего – это учет известного и пренебрежение неизвестным, но существующим. С этой ошибкой очень легко столкнуться, когда у нас есть какие-то данные, на основе которых нужно сделать вывод. Любые данные – это выборка, ограниченное число. Сама выборка сделана из генеральной совокупности. Если выборка сделана случайно и она достаточно большая, то все хорошо – большая часть закономерностей будет зафиксирована в выборке, и выводы будут объективными. Если же выборка была не случайной, как в нашем случае с самолетами, где в ней отсутствовали сбитые машины, – то, скорее всего, выводы будут ошибочными.

Например, в среднем только 1 из 100 посетителей сайта интернет-магазина совершает покупку. Если мы захотим улучшить свой сайт, чтобы больше покупателей покупали, то с какими посетителями нужно работать? Обычно дизайнеры и продуктологи обращают внимание на существующих покупателей из-за того, что с ними можно пообщаться, есть контактная информация из заказов, по ним есть хорошая статистика. Но эта выборка составляет всего лишь 1 % от всей генеральной совокупности посетителей; с остальными почти невозможно связаться – это «сбитые самолеты». В итоге будет смещение выводов в сторону «выживших», а значит, выводы анализа не будут работать для всех посетителей.

Еще одно когнитивное искажение – предвзятость результата (outcome bias). Представьте себе – вам предлагают два варианта на выбор:

• Сыграть в «Орла или решку» – если выпадет орел, получите 10 000 рублей.

• Сыграть игральной костью с шестью гранями – если выпадет 6, получите 10 000 рублей.

Какой вариант выберете? Естественно первый, в котором шанс выиграть 1 к 2, во втором варианте значительно хуже – 1 к 6. Монету подбросили – выпала решка, вы ничего не получили. Тут же бросили кость, выпала шестерка. Будет ли обидно? Да, будет. Но было ли наше решение правильным?

Этот пример я взял из поста «Фокусируйтесь на решениях, а не на результате» [5] Кэсси Козырьков (Cassie Kozyrkov), которая работает директором по принятию решений [4] (Decision Intelligence) в Google. Она советует всегда оценивать верность решения, учитывая, какой именно информацией вы обладали в момент его принятия. Многие люди жалеют, что они не уволились с работы раньше и только потеряли время, откладывая это решение, – я и сам в свое время так думал. И это отличный пример предвзятости результата – мы понимаем, что нужно было уволиться раньше, только обладая той информацией, которая у нас есть на данный момент. Например, что с тех пор зарплата так и не выросла, а интересный проект, который мы предвкушали, так и не был запущен. Оценивая последствия своего решения (особенно неудачного), в приступе самокопания мы не должны забывать, что принимали решение в условиях неопределенности.

Глава 2

Делаем анализ данных

Когда я работал в компании Wikimart.ru, основатели этого проекта познакомили меня с Ди Джеем Патилом (DJ Patil). Ди Джей был тогда одним из ангелов-инвесторов проекта, он руководил аналитикой в LinkedIn, затем был ведущим аналитиком данных (Chief data scientist) Белого дома в Вашингтоне при администрации Барака Обамы, тогдашнего президента США. Встречался я с Ди Джеем несколько раз в Москве и в Кремниевой долине в Калифорнии. В Москву он приезжал для презентации своей мини-книги «Building Data Science Teams» («Построение команд аналитиков данных») [9], выпущенной издательством O’Reilly. В книге он обобщил опыт ведущих компаний Кремниевой долины. Очень рекомендую вам эту книгу, так как ее мысли мне близки, и их я проверил на практике. Вот как автор определяет организацию, управляемую данными:

«A data-driven organization acquires, processes, and leverages data in a timely fashion to create efficiencies, iterate on and develop new products, and navigate the competitive landscape».

«Организация, управляемая данными, своевременно получает, обрабатывает и использует данные для повышения эффективности, итераций и разработки новых продуктов, а также навигации в конкурентной среде».

Далее Ди Джей указывает на принцип «Если ты не можешь измерить, ты не можешь это исправить» («if you can’t measure it, you can’t fix it»), который объединяет самые сильные организации, эффективно использующие свои данные. Вот рекомендации Патила, которые следуют из этого принципа:

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

• Продумывайте заранее и делайте вовремя измерение метрик проектов.

• Позвольте как можно большему количеству сотрудников знакомиться с данными. Множество глаз поможет быстрее выявить очевидную проблему.

• Стимулируйте интерес сотрудников задавать вопросы относительно данных и искать на них ответы.

Эти мысли я еще озвучу в главе про данные. А теперь самое время поговорить о том, что мы получаем на выходе анализа данных.

Артефакты анализа данных

Здесь и далее под артефактами я буду понимать осязаемый результат, физический или виртуальный объект.

Рис. 2.1. Артефакты аналитики

Их можно разделить на три вида (рис. 2.1):

• артефакты бизнес-анализа данных (business intelligence);

• артефакты машинного обучения (machine learning);

• артефакты инженерии данных (data engineering).

Поговорим о них подробнее.

Бизнес-анализ данных

Бизнес-анализ данных (Business Intelligence, BI) – термин уже устоявшийся. Вот какое определение дает Википедия:

«Business Intelligence – это обозначение компьютерных методов и инструментов для организаций, обеспечивающих перевод транзакционной деловой информации в человекочитаемую форму, пригодную для бизнес-анализа, а также средства для работы с такой обработанной информацией».

Под бизнес-анализом я подразумеваю объединение контекста бизнеса и данных, когда становится возможным бизнесу задавать вопросы к данным и искать ответы Первыми артефактами являются так называемые инсайты и гипотезы, вторыми – отчеты или дашборды, метрики и ключевые показатели (Key Performance Indicator). Поговорим подробнее об инсайтах и гипотезах.

Гипотезы и инсайты

Инсайт (insight) в переводе с английского – понимание причин. Именно за этим обращаются к аналитикам. В поиске инсайтов помогают аналитика и статистика:

• Цель аналитики заключается [10] в помощи формулирования гипотезы.

• Цель статистики [10] в том, чтобы эту гипотезу проверить и подтвердить.

Это требует пояснений. В бизнесе, да и в жизни тоже, мы ищем причину проблемы, задавая вопрос «почему?». Не зная причины, мы не можем принять решение. В игру вступает аналитика – мы формулируем список возможных причин: это и есть гипотезы. Чтобы это сделать, нужно задать несколько вопросов:

• Не происходило ли что-нибудь подобное раньше? Если да, то какие тому были причины? Тогда у нас будет самая первая и самая вероятная гипотеза.

• Обращаемся к бизнес-контексту: не происходило ли каких-либо неординарных событий? Часто как раз параллельные события влияют на возникновение проблемы. Еще плюс пара гипотез.

• Описательный анализ данных (exploratory data analysis): смотрим данные в аналитической системе (например, кубах OLAP), не видно ли каких-либо аномалий на глаз? Например, какие-либо распределения изменились во времени (типы клиентов, структура продаж и т. д.). Если что-то показалось подозрительным – дополняем список гипотез.

• Использование более сложных методов поиска аномалий или изменений, например, как описано здесь [11].

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

Когда я был директором по аналитике Retail Rocket (сервис рекомендаций для интернет-магазинов), мне и аналитикам часто приходилось заниматься расследованиями, ведь бизнес довольно большой – больше 1000 клиентов, и странности, с которыми приходится разбираться, случаются часто. Много приходится работать с так называемыми А/Б-тестами: это тесты, где аудитория сайта делится на две части случайным образом – первой части пользователей показывается одна версия сайта, второй – другая. Такие тесты обычно используют, чтобы оценить влияние изменений на бизнес-метрики сайта, когда первая версия – это старая версия или контрольная группа, а вторая – новая версия. Если это интернет-магазин – это, скорее всего, будут продажи. Далее к результатам теста применяются статистические критерии, которые подскажут достоверность изменений.

Такие тесты хорошо выявляют проблемы: например, версия сайта с обновленными рекомендациями Retail Rocket проиграла старой версии рекомендаций. Как только это становится известным, начинается расследование. Проверка начинается с интеграции, и это первая гипотеза: правильно ли передаются нам данные от интернет-магазина. Обычно на этом этапе решается 60–70 % проблем. Далее мы пытаемся найти отличие этого магазина от остальных в такой же тематике, например магазины одежды. Это вторая гипотеза. Третья гипотеза – возможно, мы изменили дизайн сайта таким образом, что полезная информация опустилась ниже на странице сайта. Четвертая гипотеза – тест мог отрицательно повлиять на определенные категории товаров. Собрав набор таких гипотез, мы начинаем их проверять примерно в такой последовательности, как я описал. Довольно часто мы находим причину проблем, но иногда это не удается, его величество случай играет с нами в кошки-мышки, и эту мышку очень сложно найти.

Однажды клиент – магазин «Дочки-Cыночки» – тестировал наш сервис и сервис одного из наших российских конкурентов, чтобы выбрать лучший, и это превратилось в настоящий детектив [12]. Чтобы точно не проиграть в тесте, конкурент перемещал некоторое число пользователей, которые были близки к покупке, (например, добавили товар в корзину) из конкурентных (наших) сегментов в свой – причем делалось это не на постоянной основе, а в отдельные дни и часы. Основной метрикой сравнения была конверсия: процент пользователей, совершивших покупку. Ясно, что в той «мошеннической схеме» такой процент будет выше там, куда перетянули пользователей. Здесь компания Retail Rocket пошла на принцип! Мы стали копать. Через два месяца были обнаружены и опубликованы [12] факты подтасовки результатов. В итоге прошел ряд судебных процессов, и справедливость восторжествовала.

Отчеты, дашборды и метрики

Понятие самого отчета очень широкое, здесь я подразумеваю под ним табличное или иное графическое представление данных. Отчеты могут быть разными:

• Просто таблица с «сырыми» данными или так называемые «выгрузки», например, таблица с заказами клиентов.

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

• Дашборды (dashboards) содержат ключевые показатели и метрики.

Первые два относительно просты и делаются через специальные системы, которые могут генерировать отчеты по запросу. Я стараюсь максимально оставить эту задачу на откуп пользователям. Почему? Потому, что тратить на это время высококвалифицированных сотрудников – значит стрелять из пушки по воробьям. Кстати, этим могут заняться стажеры-аналитики – отличный способ наработать опыт и понять бизнес-контекст. Как мотивировать пользователей стараться самостоятельно? Во-первых, они сэкономят время, которое обычно тратят на постановку задачи и ожидание результата. Во-вторых, получат возможность самим вносить правки и изменения – а значит творить. По моему опыту, обычно этим занимаются очень перспективные сотрудники, которые не бояться освоить новый инструмент, чтобы делать свою работу лучше. Остальным придется пройти через стандартный цикл планирования задач: а это время (дни, а иногда недели) и очень четкая формулировка технического задания. И кстати, все генеральные директора (Ozon.ru, Wikimart.ru, Ostrovok), с которыми я работал, пользовались OLAP-кубами со своих компьютеров. С их помощью они всегда могли ответить на простые вопросы, а если не получалось – обращались к аналитикам.

Теперь взглянем на дашборды и начнем с определения из Википедии:

«Дашборд – это тип графического интерфейса, который делает возможным быструю оценку ключевых показателей для конкретной цели или бизнес-процесса. Часто подразумевается, что это просто другое название отчета о прогрессе или просто отчета».

Как правило, дашборд состоит из ключевых показателей и метрик, выраженных с помощью графических инструментов (графики, диаграммы и т. д.):

• Ключевой показатель (key performance indicator, KPI) – это индикатор, который показывает, насколько далеко мы находимся от цели, например отставание/опережение плана.

• Метрика – это цифра, которая характеризует процесс, обычно используется как справочная информация.

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

Обычно дашборды характеризуют какой-то бизнес-процесс (далее слово «процесс» без «бизнес»), например эффективность рекламы, складские остатки, продажи и т. д. Есть еще важные характеристики дашбордов:

• не является «простыней цифр»;

• показывает, где возникла проблема, но не дает ответа на вопрос почему.

Часто велико искушение сделать огромную простыню цифр, закрывающую все аспекты бизнеса. И я понимаю владельцев/менеджеров компаний – на старте проекта по построению внутренней аналитической системы всегда хочется большего. Я наблюдал это и в Ozon.ru, и в Ostrovok.ru. К слову, эти строки написаны по мотивам письма, которое я писал восемь лет назад операционному директору Ostrovok.ru, – он хотел получить от аналитиков ту самую «простыню». А я считаю такое цифровым «микроменеджментом», в нем легко запутаться, самые важные показатели похоронены среди второстепенных. С первого взгляда будет сложно понять, где возникла проблема, а это основная функция дашбордов. Бороться с этим можно, например, через внедрение OKR – цели и ключевые результаты (Objectives and Key Results) [13] – или системы сбалансированных показателей (Balanced Scorecard). В этой книге я не буду подробно останавливаться на этих методиках, но рекомендую вам с ними ознакомиться. Также можно чаще пользоваться графическими элементами, например, добавив на график линию тренда (с помощью семиточечного скользящего среднего, чтобы убрать недельную сезонность), будет легче заметить восходящий или нисходящий тренд.

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

Никакой дашборд не заменит интерактивный анализ, для которого нужны соответствующая аналитическая система (SQL, OLAP, Google Data Studio, Tableau) и знание контекста. Мы никогда не сможем придумать ограниченный набор отчетов, которые будут отвечать на вопрос «почему». Максимум, что мы можем сделать, – наращивать (но не слишком) объем правильных метрик, исходя из инцидентов, за которыми будем следить.

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

Разработка дашбордов – это одна из самых нелюбимых работ у тех, кто занимается анализом данных. Когда я обсуждал этот вопрос с Ди Джеем Патилом, отметив, что 50 % времени аналитического отдела занимает работа над отчетностью, он сказал, что у них в LinkedIn тоже периодически накапливался пул таких задач и приходилось их закрывать. И взгрустнул. Но дашборды очень нужны – они помогают контролировать общее здоровье вашей системы – вверенных вам серверов и сетей, если вы системный администратор, или всей компании, если вы генеральный директор.

Артефакты машинного обучения

Раньше компьютером можно было управлять только с помощью прямых команд или инструкций: поверни сюда, дай назад, сложи и т. д. Это обычное, так называемое детерминированное программирование – для нас понятен алгоритм в виде инструкций, мы его описали, и компьютер подчиняется ему. Машинное обучение предполагает совершенно другой подход к программированию – обучение на примерах. Здесь мы показываем системе что-то с помощью примеров, тем самым избавляем себя от самостоятельного написания инструкций, что бывает совсем не просто. Это становится работой по обучению алгоритма ML.