Тег: Согласно правилу 1-10-100, $1 тратится на проверку новых данных, $10 — на их очистку в системе и $100 — на устранение ущерба от использования некачественных данных. Сами по себе данные часто бесполезны: чтобы получить ценность, из них нужно извлечь знания.
Традиционные подходы к работе с данными
Метод Waterfall, или каскадный подход к проектному управлению, подразумевает поэтапное прохождение ряда фаз: концепция, инициация, коммуникация, планирование, анализ, конструирование, разработка, тестирование, развертывание. Некоторые каскадные модели включают вариации этих фаз.
Подходит ли Waterfall для науки о данных? Короткий ответ: «Нет».
Каскадная модель эффективна, когда технология хорошо изучена, рынок продукта стабилен, а требования неизменны. Проекты в области науки о данных редко соответствуют хотя бы одному из этих критериев, поэтому каскадная модель редко подходит для них.
Однако структурированный каскадный подход хорошо подходит для некоторых этапов проекта по науке о данных — планирования или валидации. Он имеет следующие преимущества:
- четко определенная и понятная структура проекта;
- облегчение коммуникации и возможность выявлять отставания во времени от плана при помощи диаграмм Ганта;
- точность сроков и деталей каждого шага благодаря тщательному планированию и предварительному документированию;
- отсутствие перегрузки проекта из-за «расползания объема работ» благодаря раннему фиксированию требований;
- отсутствие конфликтов и возможность объективной оценки хода выполнения проекта благодаря детально разработанному плану.
Слабые стороны и проблемы Waterfall
Недостаток методологии Waterfall — неспособность соотнести планы с реалиями постоянно меняющихся бизнес-потребностей. План может быть хорош, но когда он сталкивается с реальностью, то разваливается. В проектах, связанных с наукой о данных, применение Waterfall приводит к ряду проблем:
- Ложное чувство четких бизнес-требований. Бизнес редко когда может сформулировать все свои потребности до начала проекта.
- Ложное утешение от понимания проблемной области. Даже если бизнес-требования ясны, специалистам по данным необходимо исследовать проблемную область. Только после этого они определят, разрешима ли проблема, и если да, то как это сделать.
- Отсроченная реализация ценности. Обширное предварительное планирование откладывает начало этапа реализации, и весь проект сдается в конце. Следовательно, заинтересованные стороны не могут получить ценность до завершения проекта.
- Низкокачественная обратная связь. Без доступа к работающим частям продукта пользователи не могут дать эффективную обратную связь.
- Неточные сроки. В науке о данных невозможно обозначить точное время выполнения некоторых задач, что делает сроки проекта неточными.
- Увеличение стоимости ошибок. Проведение проверки и валидации после этапа разработки приводит к тому, что некачественное проектирование функций и ошибки дороже и сложнее устранять.
- Более высокие накладные расходы. Обширная документация отнимает много времени и не добавляет прямой ценности.
Недостатки традиционного подхода для проектов бизнес-аналитики
В традиционных BI-проектах каждый уровень инфраструктуры строится отдельно. Это требует значительных инвестиций в сложные внутренние системы для ИТ-среды и хранилищ данных. Системы, которые взаимодействуют с пользователями, появляются на поздних этапах проекта. Тестирование — часто заключительный этап.
Такой тщательно спланированный, пошаговый подход приводит к множеству проблем:
- Неизвестные потребности. Конечные пользователи часто не знают, чего хотят. Если просить их заранее определить каждый фильтр и диаграмму, то составленный план не будет отвечать реальным потребностям.
- Трудности изменения. Даже если конечные пользователи понимают свои текущие потребности, они могут не знать, какие показатели будут важны в следующем году.
- Ошибки тестирования. Стоимость дефектов растет по мере развития проекта. Одна и та же ошибка запроса может многократно повторяться. Если отложить тестирование до конца проекта, то можно столкнуться с ошибками, которые будет сложно исправить.
- Отложенная ценность. Согласно правилу 80/20 80% ценности достигается за счет 20% решений. Нет смысла откладывать реализацию ценности до тех пор, пока не будет завершен весь проект.
- Отложенная обратная связь. Вы не знаете, как люди будут использовать вашу панель инструментов, пока они ею не воспользуются. Традиционные подходы основаны на представлениях продукта, таких как диаграммы потоков данных или каркасы. Они полезны для обратной связи, но менее содержательны, чем инкрементальная версия готовой к использованию BI-системы.
Что такое Agile Business Intelligence
Гибкая бизнес-аналитика — это применение гибких практик для создания BI-продуктов. Agile — это образ мышления, который подчеркивает:
- открытое сотрудничество внутри членов команды и со стейкхолдерами;
- быструю итерацию и частое создание небольших дополнительных ценностей;
- постоянный контроль и совершенствование, которые со временем повышают скорость работы команды;
- самостоятельное управление проектом командой по продукту;
- возможность гибкой корректировки планов по мере необходимости.
Agile BI разбивает проект на несколько небольших полезных этапов, которые постепенно приближают его к завершению. Это имеет следующие преимущества:
- Высокая вовлеченность. Распространенная ошибка BI-проектов — недостаточное внедрение. Когда конечные пользователи вовлечены в проект с самого начала, то берут на себя большую ответственность. Они понимают ценность системы и с большей вероятностью будут ее использовать.
- Гибкость. Планировали ли вы COVID, последствия внезапной инфляции или любое другое серьезное потрясение, которое может произойти в вашем бизнесе или мире? Скорее всего, нет. Но имея краткие гибкие планы, изложенные в дорожной карте, вы сможете быстро адаптироваться к ситуации.
- Быстрое получение ценности. Вертикальные срезы сквозной ценности приносят пользователям пользу еще до завершения проекта. Например, вы можете сперва предоставить таблицу с удобной панелью управления на ее основе, и только потом — полноценное хранилище данных.
- Высокая мотивация. В BI-проектах вся команда видит результаты своей работы. Вид работающей панели управления с частичной функциональностью мотивирует больше, чем полноценный каркас где-то в глубинах общего диска.
Гибкая бизнес-аналитика с Kanban
Что такое Kanban
Методология Kanban — это последовательность процессов, которая делает работу наглядной и направлена на сокращение времени поставки ценности. Ее цель — минимизировать объемы незавершенного производства и привести предложение в соответствие со спросом.
Методология Kanban фокусируется на двух принципах:
- визуализировать рабочий процесс;
- сократить объем незавершенной работы.
Визуализация рабочего процесса
В основе методологии лежит Kanban-доска — наглядное отображение рабочего процесса. В самом простом варианте она состоит из трех столбцов: «В ожидании», «В процессе» и «Готово». Задачи проекта помещаются между столбцами по мере готовности.
Kanban-доски часто содержат дополнительные столбцы. Например, команды разработчиков ПО могут разделить столбец «В процессе» на разделы «В разработке» и «Тестирование». Раздел «Тестирование» можно дополнительно разделить на подразделы «Верификация» и «Валидация».
Минимизация незавершенной работы
Незавершенная работа — это инвестиции, ценность которых еще предстоит оценить. Чтобы сократить объем незавершенной работы, команды Kanban устанавливают ее лимиты. Они определяют максимальное число задач, которые можно выполнять одновременно. Чтобы дополнить столбец, нужно переместить задачу из него в следующий.
Алгоритм внедрения Kanban для BI-команды
- Настройте доску Kanban. Столбцы доски — это этапы работы. Команды бизнес-аналитики могут использовать столбцы «В ожидании», «Анализ», «Разработка», «Тестирование» и «Развертывание».
- Определите лимиты незавершенной работы. Укажите лимит задач в каждом столбце — максимальное количество элементов, которые могут находиться на данной фазе в любой момент.
- Определите рабочие элементы. Оцените, какой объем работы требуется выполнить, и разбейте его на небольшие рабочие элементы. Каждый элемент — это задача в первом столбце Kanban-доски.
- Определите приоритеты рабочих элементов. Учитывайте ценность, усилия и зависимости.
- Отслеживайте выполнение работы. Члены команды каждый раз сосредотачиваются на небольшом количестве рабочих элементов и при возможности берут в работу новые задачи.
- Оценивайте прогресс. Команда проверяет доску минимум раз в день. Анализируйте ее поток, чтобы выявить и внедрить методы повышения производительности и минимизации времени цикла.
Когда Kanban работает для бизнес-аналитики
Благодаря легкой и гибкой структуре методика Kanban полезна любой команде бизнес-аналитики. Она подходит, когда:
- нужно обработать входящий поток запросов на выполнение рабочих заданий от стейкхолдеров;
- сложно оценить, сколько времени необходимо, чтобы выполнить конкретные рабочие задачи;
- нужен минималистский подход к управлению проектами;
- в фокусе — минимизация времени выполнения конкретного запроса;
- преемственность команды нестабильна — члены команды могут быть вовлечены в различные инициативы.
{{cta}}
Гибкая бизнес-аналитика со Scrum
Что такое Scrum
Scrum — наиболее популярный гибкий подход. Его используют не только команды разработчиков ПО, но и другие компании: John Deere для создания нового оборудования, National Public Radio — новых программ, Saab — истребителей, а CH Robinson — для управления персоналом. По сравнению с Kanban, этот метод всеобъемлющ, поскольку определяет ряд сущностей.
Три основы
- прозрачность: сделайте текущую работу видимой;
- проверка: обратите внимание на отклонения;
- адаптация: адаптируйте свои процессы, чтобы свести к минимуму отклонения и максимально использовать полезные возможности.
Пять ценностей
- преданность делу;
- сосредоточенность;
- открытость;
- уважение;
- смелость.
Три роли в команде
Scrum рекомендует создавать полнофункциональные команды численностью до десяти человек. Существуют три роли:
- владелец продукта: устанавливает видение продукта;
- скрам-мастер: содействует процессу Scrum в качестве лидера-слуги;
- разработчик: обеспечивает выпуск новых версий продукта.
В Scrum-команде, специализирующейся на анализе данных, в команду разработчиков могут входить специалисты по анализу данных, инженеры по данным, аналитики данных, системные аналитики и инженеры-программисты. Один человек может совмещать несколько ролей.
Пять событий
Agile Scrum определяет пять событий, первое из которых — контейнер для остальных:
- Спринт. Scrum делит крупный проект на серию мини-проектов с фиксированной продолжительность не более месяца. Каждый цикл мини-проекта называется спринтом.
- Планирование. Спринт начинается с составления стурктуры. Сперва владелец продукта объясняет основные элементы бэклога — функции. Затем команда разработчиков прогнозирует, что они могут предоставить к концу спринта, и составляет план.
- Ежедневный скрам — стендап. Во время спринта команда тесно координирует и разрабатывает планы на день на ежедневных встречах.
- Обзор спринта. В конце спринта команда демонстрирует заинтересованным сторонам инкременты — выполненную работу — и запрашивает обратную связь в ходе обзора. Эти инкременты должны быть потенциально готовы к выпуску и соответствовать заранее заданному критерию готовности.
- Ретроспектива спринта. Чтобы закрыть спринт, во время ретроспективы команда анализирует и планирует, как она может улучшить результаты в следующем спринте.
Три артефакта
- продуктовый бэклог — упорядоченный набор идей, которые можно реализовать для создания продукта;
- журнал невыполненных работ — содержит цель спринта, выборку элементов для ее достижения и план реализации;
- приращение — набор элементов, поставляемых в спринте.
Как BI-команда может использовать Scrum
Спринт начинается с планирования, когда разработчики переносят наиболее приоритетные элементы из продуктового бэклога в бэклог спринта. Последний отражает их обязательства к концу спринта. В период реализации спринта команда встречается не реже одного раза в день для разработки краткосрочных планов.
Разработчики тесно сотрудничают, чтобы достигнуть цели спринта. После его завершения команда запрашивает обратную связь по своему инкременту во время обзора и оценивает, как она может работать лучше во время ретроспективы.
Когда Scrum подходит для бизнес-аналитики
Метод может подойти не всем командам:
- Scrum требует предсказуемой преемственности состава команды. Проекты короче пары месяцев могут не достигать критической массы времени, необходимой для полноценной работы команды. Члены команды должны быть полностью преданы продукту, не отвлекаться на другие инициативы.
- Scrum разрушает традиционную философию управления «сверху вниз». Поэтому он подходит только для компаний, которые наделяют свои команды полномочиями нести ответственность за процессы и результаты.
Scrum обладает рядом преимуществ по сравнению с Kanban. Команда фокусируется на ценности каждого спринта. Например, в ходе первого спринта может быть создан набор фильтров, визуализаций или модуль панели мониторинга. Следующий спринт улучшает этот набор результатов, третий — добавляет функции. Слаженность каждого набора функций демонстрирует прогресс и приближает весь проект к завершению.
Гибкая бизнес-аналитика с использованием Data Driven Scrum
Что такое Scrum, основанный на данных
Data Driven Scrum (DDS) — это новая гибкая методология, разработанная для команд, работающих на основе данных, чтобы улучшить взаимодействие и совместную работу. Это модифицированная версия Scrum с аналогичными встречами, ролями и артефактами.
DDS изменяет некоторые из ограничивающих аспектов Scrum, делая его более гибким для научно-исследовательской природы проектов, основанных на данных. Основное изменение — концепция итерации DDS.
Итерация — это цикл экспериментирования и адаптации. Цель каждого цикла — формирование идеи или эксперимента, их реализация, наблюдение и анализ наблюдений для создания следующей идеи.
Основа итерации — переход от изначальной идеи к ее воплощению и анализу результатов. Конец итерации — это окончание эмпирического процесса, а не заранее определенное количество часов.
Сравнение Scrum и DDS
Как BI-команда может использовать DDS
Команда Scrum BI постоянно сталкивается с дилеммой при подготовке спринтов: слишком много обязательств не позволит достигнуть цели спринта, недостаточное количество — приведет к простою. Это не проблема для команд DDS: им не нужно разрабатывать детальные оценки для каждого рабочего элемента, чтобы понять, что «вписывается» в предстоящий спринт.
Команда Scrum BI планирует заранее определенный ритм для каждого спринта в соответствии с календарем, команда DDS BI — начинает итерацию при первой возможности. Например, когда инженер по данным начинает настройку для следующей панели мониторинга в «Итерации 2», разработчики BI завершают работу над текущей панелью мониторинга в «Итерации 1».
Итерации основаны на возможностях. Они различаются по продолжительности, чтобы за одну итерацию можно было выполнить логический фрагмент работы. Команды DDS BI проводят наблюдение и анализ коллективно, встраивая их в основной рабочий процесс.
Когда DDS подходит для бизнес-аналитики
DDS имеет более четкую структуру, чем Kanban, но более гибок, чем Scrum. Метод хорошо подходит командам, которые хотят:
- визуализировать рабочий процесс на доске с карточками;
- сосредоточиться на постепенном наборе результатов, определенных в итерации;
- быть гибкими без ограничений временных рамок спринтов.
Переход к гибкой бизнес-аналитике позволяет быстрее преобразовывать данные в осмысленные решения. Agile-методологии помогают получать первые результаты еще до завершения проекта, сокращают время обратной связи и уменьшают стоимость ошибок. Правильно выбранная методология повышает эффективность команды, скорость принятия решений и дает конкурентное преимущество.
{{cta}}
