Hi There!
Это перевод статьи "Norman Thuswaldner с сайта BA Times". Статья 2014-ого года, но мне показалась очень актуальной и в 2018-ом.
Начинаем!
Требования к данным — Должен ли бизнес-аналитик заботиться?
Однажды, директор ИТ-отдела сказал мне, чтобы я не думал о требованиях к данным и сосредоточился только на бизнес-требованиях. Система должна была быть разработана за 6-8 месяцев но потребовалось более двух лет, и немногие остались довольны конечным результатом. [читая этот текст, я не могу ни радоваться насколько у нас хорошо организованный проект, я работаю над созданием IT продукта, практически в каждом проекте у нас есть отдельный человек, который заботится только о данных]
Должны ли бизнес-аналитики заботиться о требованиях к данным? Что вы думаете?
К сожалению, бизнес-аналитики тратят гораздо больше времени на анализ бизнес-процессов, чем на анализ бизнес-информации. Это часто приводит к требованиям, которые рассказывают только половину истории. Когда дело доходит до построения IT систем, понимание данных не менее важно, чем понимание процессов. В современном мире немногие организации могут позволить себе перестраивать только построенную систему.
Существуют способы, который помогут собрать требования и позволят создать полную картину того, что необходимо (и только то, что необходимо), чтобы получить максимальную отдачу от проекта с первого раза. [заинтриговал]
Так что насчет данных?
Как бизнес-аналитики, мы являемся экспертами в нахождении корня проблемы или возможности, и у нас есть много методов для этого. Выбор методов, которые мы используем зависят от множества факторов, включая бизнес-среду, предпочтения заинтересованных сторон (stakeholders), наличие экспертов по тематике (SME), доступность систем, соответствующую документацию и др. Когда мы разрабатываем модели бизнес-процессов, мы часто моделируем текущие «as-is» и целевые «to-be» бизнес-процессы. Примеры использования, диаграммы потоков данных, функциональные разложения, диаграммы последовательности и диаграммы состояний — всего лишь несколько доступных методов. Когда дело доходит до моделирования бизнес-процессов, у нас есть полный арсенал методов в нашем наборе инструментов, но понятие документирования информации часто отсутствует.
Бизнес-аналитики иногда забывают или игнорируют требования к данным. Это может быть потому, что они думают, что это не их работа, или что кто-то другой позаботится об этом. Возможно, они запуганы видом тех диаграмм со всеми этими прямоугольниками и линиями. Независимо от причин, если вы являетесь частью команды, которая строит IT систему, и вы документируете бизнес-процессы без какого-либо представления о данных, вы делаете только половину своей работы.
Почему я должен заботиться?
Если вы понимаете требования к данным, у вас есть множество преимуществ. Когда бизнес-аналитик понимает бизнес-процессы и данные, есть отличная возможность перекрестно проверить обе области. Например, если есть бизнес-процесс, который не использует (или не производит) данных, скорее всего, это не бизнес-процесс. Аналогичным образом, если в модели данных есть элемент данных, который не используется каким-либо бизнес-процессом, возможно, мы упустили бизнес-процесс или элемент данных не входит в систему. В любом случае, эти знания могут быть использованы для полного завершения анализа бизнес-процессов и учета всех требований к данным.
Существуют четыре ключевых метода, которые я использую для документирования требований к данным. Выбранный вами метод будет зависеть от бизнес-среды, количества времени и денег и предпочтений Stakeholders и SMEs.
Требования к данным
1. Моделирование данных
Модель данных является одним из наиболее мощных инструментов, используемых для сбора требований к информации. Это отличный подход, потому что каждый элемент данных может быть тщательно задокументирован, включая его тип данных, длину поля и его связь с другими элементами данных. Как уже упоминалось ранее, модель данных является прекрасным средством проверки полноты модели бизнес-процесса.
Другим аспектом моделирования данных, который делает его мощным, является то, что, как только он будет установлен и проверен SME, бизнес-аналитик может работать с администратором базы данных, чтобы перепроектировать модель в физическую базу данных, особенно если модель была разработана с использованием инструмента моделирования данных.
Моделирование данных требует практики, и, если у вас нет опыта в этом методе, может потребоваться пройти курс обучения и работать с опытным коллегой или наставником, который может помочь вам учиться.
2. Словарь данных
Словарь данных является необходимой частью модели данных, но может быть разработан и отдельно. Словарем данных является письменное описание элементов данных системы, которое описывает сущности, атрибуты каждого объекта и отношения между ними. Для разработки словаря данных не требуется значительная подготовка, но это не тривиальное упражнение, и для этого потребуется усидчивость.
Проверка словаря данных может быть сложной задачей, поскольку бизнес-аналитик часто сталкивается с разногласиями между заинтересованными сторонами относительно определений. Согласование этих различий на раннем этапе жизненного цикла проекта является обязательным, и их игнорирование может быть катастрофическим на поздних стадиях.
3. Анализ отчетов и прототипов
Другим способом, который бизнес-аналитик может описать требованиями к данным, является разработка серии макетов отчетов. Предполагается, что все данные, поступающие в систему, выводятся в той или иной форме в отчете. В конце концов, если данные не будут отображаться в отчете, зачем вообще помещать их в базу данных? Теоретически, как только бизнес-аналитик имеет набор макетов отчетов, которые были проверены SME, у него есть все элементы данных, которые он не может упустить.
Обычно бизнес-аналитику не придется создавать макеты отчетов с нуля, потому что уже будут отчеты, которые использует организация. Могут быть новые или разные отчеты, которые приведут к дополнительным требованиям к данным, и могут быть изменения в некоторых существующих отчетах. Это один из наиболее простых методов разработки требований к данным, а также тот, который не требует значительного обучения.
4. Обратный инжиниринг
Многие проекты по разработке IT систем сосредоточены на коммерческих готовых решениях Сommercial Off-The-Shelf Solutions (COTS), поскольку большинство организаций осознают риск и затраты на разработку индивидуальных решений. При внедрении COTS, организации, которые не выполняют "домашнее задание", с точки зрения определения их бизнес-процессов и требований к данным, довольно легко рискуют провалиться. Недостаточно все просто доверить поставщику, вы сами полностью должны быть уверены в том, что получите на выходе.
Технология обратного проектирования включает в себя приобретение пробной версии рассматриваемого COTS и копирование БД программного обеспечения в инструмент моделирования данных для создания физической схемы БД. Затем схема сравнивается с моделью данных, представляющей требования к данным организации. Анализ различий между ними определит области, в которых должны быть приняты решения. Например, если решение не поддерживает определенные требования к данным, организация должна будет решить, может ли он жить без него, или добавить ручную работу или определить, можно ли настроить продукт. Существует множество причин, по которым не всегда возможно обратное проектирование базы данных поставщика, и даже если это возможно, требуется определенное техническое ноу-хау.
Да, ты можешь!
Вы не должны быть экспертом по моделированию данных для сбора требований к данным. Вам только нужно быть любопытным, иметь желание попробовать что-то новое и быть готовым работать с другими IТ-специалистами, которые могут знать что-то, чего не знаете вы. Это легко, выйти из зоны комфорта и вступить в зону, которая является бизнес-анализом
В следующей статье я расскажу, как мы используем некоторые из описанных инструментов для сбора требований к данным.
Cheers!