Разберись в Data Science. Как освоить науку о данных и научиться думать как эксперт

Tekst
2
Recenzje
Przeczytaj fragment
Oznacz jako przeczytane
Czcionka:Mniejsze АаWiększe Aa
Почему эта проблема важна?

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

Вы можете задать этот вопрос по-разному:

– Что мешает вам (нам) спокойно спать по ночам?

– Почему это важно?

– Эта проблема новая или она уже была решена ранее?

– Какой приз на кону? (Какова отдача от инвестиций?)

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

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

– Фокус на методологии. Это когда компании кажется, будто использование какого-то нового метода анализа данных или технологии даст ей некое преимущество. Вы наверняка сталкивались с маркетинговыми уловками наподобие: «Если вы не используете искусственный интеллект (ИИ), то вы отстаете…» Или когда компания привязывается к какому-то понравившемуся ей модному термину (вроде «анализа настроений»).

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

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

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

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

Кого затрагивает эта проблема?

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

Вы должны подумать обо всех уровнях организации (а также о ее клиентах, если таковые имеются). Мы не имеем в виду дата-сайентиста, работающего над проблемой, или команду инженеров, которым придется поддерживать программное обеспечение. Речь идет об установлении конечных пользователей. Зачастую это не только те люди, которые участвуют в определении проблемы. Поэтому очень важно понять, чья повседневная работа будет затронута в случае реализации проекта, и привлечь этих людей к его обсуждению.

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

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

– Можем ли мы использовать полученный ответ?

– Чья работа от этого изменится?

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

Что, если у нас нет нужных данных?

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

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

Когда проект будет завершен?

Многим из нас доводилось участвовать в проектах, которые длились слишком долго. Если ожидания относительно длительности проекта неясны с самого начала, то со временем команды начинают посещать совещания просто по привычке и генерировать отчеты, которые никто не читает. Чтобы переломить подобные тенденции, следует ответить на вопрос: «Когда проект будет завершен?» еще до начала его реализации.

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

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

Не думайте, что знаете ответ на этот вопрос, пока не задали его.

Что, если нам не понравятся результаты?

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

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

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

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

 

Причины провала проектов по работе с данными

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

Давайте рассмотрим такой сценарий.

Клиентское восприятие

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

– менеджер проекта (вы);

– спонсор проекта (лицо, оплачивающее его реализацию);

– два специалиста по маркетингу (не имеющие опыта работы с данными);

– молодой дата-сайентист (только что окончивший колледж и стремящийся применить изученные методы на практике).

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

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

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

Спонсор проекта доволен. Неделю спустя эта информационная панель выводится на монитор в комнате отдыха на всеобщее обозрение.

Это успех.

Шесть месяцев спустя монитор убирается из комнаты отдыха в связи с ее ремонтом.

Никто этого не замечает.

Рис. 1.1. Тенденции, выявленные в результате анализа настроений


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

Обсуждение

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

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

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


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

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


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

Все было бы иначе, задай они те пять вопросов.

Работа над значимыми проблемами

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

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

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

В этих случаях многие специалисты по работе с данными разочаровываются в своей профессии. Работа над проблемами, которые чрезмерно сосредоточены на технологиях или имеют неоднозначные результаты, вызывает у них раздражение и неудовлетворенность. Сайт Kaggle.com, на котором дата-сайентисты со всего мира соревнуются друг с другом и изучают новые методы анализа данных, провел опрос относительно того, с какими препятствиями эти специалисты сталкиваются на работе[9]. Некоторые из перечисленных далее препятствий напрямую связаны с плохо сформулированными проблемами и неправильным планированием:


– Отсутствие четко поставленного вопроса, на который необходимо дать ответ (с этим столкнулись 30,4 % респондентов).

– Результаты не используются лицами, принимающими решения (24,3 %).

– Отсутствие вклада со стороны экспертов в предметной области (19,6 %).

– Ожидания относительно воздействия проекта (15,8 %).

– Интеграция результатов в решения (13,6 %).


Все это имеет очевидные последствия. Те, кто не удовлетворен своей работой, уходят.

Подведение итогов

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

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

Ответив на все эти вопросы, вы можете приступать к работе.

Глава 2
Что такое данные?

«Если у нас есть данные, давайте смотреть на данные.

Если все, что у нас есть, – это мнения, давайте придерживаться моего»

– Джим Барксдейл, бывший генеральный директор компании Netscape

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

Данные и информация

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

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

Пример набора данных

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

Таблица с данными, подобная табл. 2.1, называется набором данных.

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

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

Знайте свою аудиторию

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

Табл. 2.1. Пример набора данных о рекламных расходах и прибыли

 

Точка данных – это место пересечения наблюдения и признака. В данном случае примером точки данных является 150 единиц товара, проданного 01 февраля 2021 года.

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

92017 Kaggle Machine Learning & Data Science Survey. Результаты доступны по адресу: www.kaggle.com/kaggle/kaggle-survey-2017. Доступ получен 12 января 2021.