Рис. 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]:
«Широкое распространение компьютерных технологий привело к тому, что сейчас за минуты можно сделать то, на что раньше требовались часы кропотливой работы, и слайды пекутся как пирожки пресные и невкусные».
Я делал довольно много докладов: со слайдами и без, короткие, на 510 минут, и длинные на час. Смею вас заверить, что мне намного сложнее сделать убедительный текст для короткого доклада без слайдов, чем презентацию в PowerPoint. Посмотрите на политиков, которые выступают: их задача убеждать, много ли из них показывают слайды на выступлениях? Слово убеждает сильнее, слайды это всего лишь наглядный материал. И чтобы ваше слово было понятно и убедительно, требуется больше труда, чем для накидывания слайдов. Я себя поймал на том, что при составлении слайдов я думаю о том, как презентация выглядит. А при составлении устного доклада насколько убедительны мои аргументы, как работать с интонацией, насколько понятна моя мысль. Пожалуйста, подумайте, действительно ли вам нужна презентация? Хотите ли вы превратить совещание в просмотр скучных слайдов вместо принятия решений?
«Совещания должны фокусироваться на кратких письменных отчетах на бумаге, а не на тезисах или обрывочных пунктах списка, проецируемых на стену», утверждает Эдвард Тафти, видный представитель школы визуализации данных, в своей работе «Когнитивный стиль PowerPoint» [29].
Парный анализ данных
О парном программировании я узнал от разработчиков [30] Retail Rocket. Это техника программирования, при которой исходный код создается парами людей, программирующих одну задачу и сидящих за одним рабочим местом. Один программист сидит за клавиатурой, другой работает головой, сосредоточен на картине в целом и непрерывно просматривает код, производимый первым программистом. Время от времени они могут меняться местами.
И нам удалось ее адаптировать для нужд аналитики! Аналитика, как и программирование, творческий процесс. Представьте, что вам нужно построить стену. У вас есть один рабочий. Если вы добавите еще одного скорость вырастет примерно в два раза. В творческом процессе так не получится. Скорость создания проекта не вырастет в два раза. Да, можно проект декомпозировать, но я сейчас обсуждаю задачу, которая не декомпозируется, и ее должен делать один человек. Парный же подход позволяет многократно ускорить этот процесс. Один человек за клавиатурой, второй сидит рядом. Две головы работают над одной проблемой. Когда я решаю сложные проблемы, я разговариваю сам с собой. Когда разговаривают две головы друг с другом они ищут причину лучше. Мы используем схему парной работы для следующих задач.
Когда нужно передать знания одного проекта от одного сотрудника другому, например, был нанят новичок. «Головой» будет сотрудник, который передает знания, «руками» за клавиатурой кому передают.
Когда проблема сложная и непонятная. Тогда два опытных сотрудника в паре решат ее намного эффективней одного. Будет сложнее сделать задачу анализа однобоко.
Обычно на планировании мы переносим задачу в категорию парных, если понятно, что она подходит под критерии таковой.
Плюсы парного подхода время используется намного эффективней, оба человека очень сфокусированы, они друг друга дисциплинируют. Сложные задачи решаются более творчески и на порядок быстрей. Минус в таком режиме невозможно работать больше нескольких часов, очень сильно устаешь.
Технический долг
Еще одна важная вещь, которой я научился у инженеров Retail Rocket [31], работа с техническим долгом (technical debt). Технический долг это работа со старыми проектами, оптимизация скорости работы, переход на новые версии библиотек, удаление старого программного кода от тестирования гипотез, инженерное упрощение проектов. Все эти задачи занимают добрую треть времени разработки аналитики. Приведу цитату технического директора Retail Rocket Андрея Чижа [31]:
«Я еще не встречал компаний за свою практику (а это более 10 компаний, в которых работал сам, и примерно столько же, с которыми хорошо знаком изнутри), кроме нашей, у которых в бэклоге были бы задачи на удаление функционала, хотя, наверное, такие существуют».
Я тоже не встречал. Видел «болота» программных проектов, где старье мешает создавать новое. Суть технического долга все, что вы сделали ранее, нужно обслуживать. Это как с ТО автомобиля его нужно делать регулярно, иначе машина сломается в самый неожиданный момент. Программный код, в который давно не вносились изменения или обновления, плохой код. Обычно он уже работает по принципу «работает не трогай». Четыре года назад я общался с разработчиком Bing. Он рассказал, что в архитектуре этого поискового движка есть скомпилированная библиотека, код которой потерян. И никто не знает, как это восстановить. Чем дольше это тянется, тем хуже будут последствия.
Как аналитики Retail Rocket обслуживают технический долг:
После каждого проекта тестирования гипотез мы удаляем программный код этой гипотезы везде, где только можно. Это избавляет нас от ненужного и неработающего хлама.
Если происходит обновление каких-либо версий библиотек мы делаем это с некоторым запозданием, но делаем регулярно. Например, платформу Spark мы апгрейдим регулярно, начиная с версии 1.0.0.
Если какие-либо компоненты обработки данных работают медленно ставим задачу и занимаемся ею.
Если есть какие-то потенциально опасные риски например, переполнение дисков кластера, тоже ставится соответствующая задача.