«Требования редко лежат на поверхности»

Большинство проектов Data Science терпят неудачу. Я даже не буду приводить никаких ссылок в подтверждение этого утверждения - в Интернете полно примеров. Причины высокого процента отказов многочисленны и разнообразны. Однако, как это ни удивительно, одной из основных причин является отсутствие четко определенных целей проекта и связанных с ними требований.

Понимание проблемы и сбор требований составляют начальную фазу практически в любой структуре управления проектами, включая широко используемый Межотраслевой стандартный процесс интеллектуального анализа данных (CRISP-DM). Это означает, что цели и требования проекта уже там и ждут, чтобы их собрали. Однако, как говорят Эндрю Хант и Дэвид Томас в своей знаменитой книге Программист-прагматик:

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

Совет, который затем дают авторы, прост:

«Не собирайте требования - копайте их».

Действительно мудрые слова. Но что именно означает этот совет в контексте проектов Data Science? Необходимо рассмотреть несколько важных аспектов, и я расскажу о некоторых из них в этой статье. Чтобы сделать вещи более конкретными, предположим, что перед командой Data Science стоит задача создать систему рекомендаций для продуктов, продаваемых в интернет-магазине.

Изучите своих заинтересованных сторон

Определение целей проекта Data Science объективно сложно из-за количества вовлеченных заинтересованных сторон и различных целей, которые они преследуют (Hulten 2018). Маркетинговая группа может захотеть иметь систему рекомендаций, чтобы удерживать клиентов и продавать им как можно больше продуктов. Тем не менее, команда взаимодействия с пользователем может захотеть использовать его, чтобы максимально упростить переход клиентов на веб-сайт. Наконец, Data Scientists в основном заботятся о точности прогнозов модели машинного обучения, используемой в их рекомендательной системе.

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

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

Вести глоссарий проекта

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

Собирайте требования с помощью «пользовательских историй»

Разработчики программного обеспечения используют несколько методов для сбора требований, и я считаю, что эти методы напрямую применимы и к проектам Data Science. В моей консультационной работе я нашел пользовательские истории особенно полезными.

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

"As a <role> I want to <capability>, so that <receive benefit>"

Пользовательские истории хороши по следующим причинам:

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

В контексте нашего текущего примера пользовательские истории могут выглядеть так:

"As a marketer, I want our website visitors to see products that they are likely to buy, so that I can increase our overall cross-sell rate."
"As a UX specialist, I want our website visitors to quickly find the products they are interested in, so that they spend minimal time to complete a purchase."

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

Документируйте требования

Как только вы закончите определение целей и требований проекта, задокументируйте их. Это можно сделать разными способами (мне нравится формат плакат проекта, разработанный Atlassian). Независимо от формата, который имеет смысл для вашей организации, постарайтесь избегать ненужных деталей. Требования не описывают дизайн или архитектуру системы, они только фиксируют то, что необходимо выполнить. Никогда не тратьте время на написание подробных уставов проекта, потому что 1) они устаревают в момент сохранения файла и 2) их все равно никто никогда не прочитает из-за их раздутого размера.

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

Выводы

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

Перед тем, как ты уйдешь

Оказываю консультационные услуги в области Data Science. "Связаться"!