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

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

Однако на практике гибкое управление данными не всегда работает так, как планировалось, поэтому важно применять реалистичный, адаптируемый подход к гибкому управлению. Agile — это отличная цель, к которой нужно стремиться, но это также и область, c которой команды часто не справляются.

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

Основы гибкого управления данными

Agile data management — это подход к сбору, обработке, анализу и представлению данных, в котором особое внимание уделяется гибкости и итеративным изменениям.

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

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

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

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

Проблемы гибкого управления данными

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

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

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

Вторая проблема особенно заметна, потому что она в корне отличает гибкое управление данными от гибкой разработки ПО. Когда вы создаете ПО, вы с самого начала знаете, с чем вам предстоит работать, и, как правило, можете контролировать все значимые переменные (например, какой язык кодирования вы используете и какие типы ИТ-инфраструктуры создаете).

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

Реалистичный подход к гибкому управлению данными

Эти проблемы не означают, что команды должны отказаться от agile-управления данными. Несмотря на свои недостатки, agile все же стоит использовать, поскольку этот подход может помочь сделать сложные проекты более эффективными и последовательными.

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

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

  • Условное отношение к дорожным картам. Мы создаем дорожные карты, чтобы структурировать наши проекты, но предполагаем, что они очень условны. Например, если мы запланировали две недели на создание инфраструктуры данных, это не значит, что мы предполагаем, что это займет именно две недели. Реализация может быть длиннее или короче.
  • Создание временных резервов. В связи с этим мы предпочитаем завышать оценку сроков выполнения задач, чтобы заложить дополнительный запас времени. Например, если мы ожидаем, что задача займет два с половиной дня, мы запланируем ее на три. Меньше времени, чем ожидалось, гораздо предпочтительнее, чем превышение графика.
  • Параллельная постановка задач. При планировании проектов мы стремимся выполнять как можно больше задач параллельно. Например, если мы можем создать инфраструктуру данных и одновременно оценить их качество, мы будем делать и то, и другое. Некоторые процессы, например BI-отчетность, не могут быть реализованы до тех пор, пока не будут выполнены другие сложные задачи, поэтому существуют ограничения по количеству параллельных задач. Но когда вы выполняете несколько задач одновременно, вы ускоряете весь проект, даже если в некоторых областях возникают задержки.
  • Четкая коммуникация с вовлеченными сторонами. При планировании проектов мы стараемся быть понятными и прозрачными для вовлеченных сторон. Мы подчеркиваем, что предварительные сроки являются лишь предварительными, и информируем их об изменениях в проекте по мере его реализации. Людям, от которых зависит управление данными и их анализ при принятии бизнес-решений, необходимо знать, когда будет завершен анализ, и оставлять их в неведении — или вводить в заблуждение обещаниями сроков, которые вы не можете гарантировать, — не в чьих интересах.

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

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