Бизнес анализ для специалистов практиков практическое руководство

5.1. Планирование управления содержанием

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

Рис. 5–2. Планирование управления содержанием: входы, инструменты и методы, выходы

Рис. 5–3. Планирование управления содержанием: диаграмма потоков данных

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

5.1.1. Планирование управления содержанием: входы5.1.1.1. Устав проекта

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

5.1.1.2. План управления проектом

Описан в разделе 4.2.3.1. Компоненты плана управления проектом включают в себя, среди прочего:

♦ План управления качеством. Описан в разделе 8.1.3.1. На порядок управления содержанием проекта и продукта оказывает влияние то, как реализуются в ходе осуществления проекта политика, методологии и стандарты организации в области контроля качества.

♦ Описание жизненного цикла проекта. Жизненный цикл проекта – это ряд фаз, через которые проходит проект с момента его начала до момента завершения.

♦ Подход к разработке. Подход к разработке определяет, какой тип подхода, а именно: водопадный, итеративный, адаптивный, гибкий или гибридный, – будет использоваться.

5.1.1.3. Факторы среды предприятия

Факторы среды предприятия, которые могут оказывать влияние на процесс планирования управления содержанием, включают в себя, среди прочего:

♦ организационную культуру,

♦ инфраструктуру,

♦ управление персоналом,

♦ ситуацию на рынке.

5.1.1.4. Активы процессов организации

Активы процессов организации, которые могут оказывать влияние на процесс планирования управления содержанием, включают в себя, среди прочего:

♦ политики и процедуры,

♦ репозитории исторической информации и извлеченных уроков.

5.1.2. Планирование управления содержанием: инструменты и методы5.1.2.1. Экспертная оценка

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

♦ предшествующие подобные проекты;

♦ информация об отрасли, дисциплине и прикладной области.

5.1.2.2. Анализ данных

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

5.1.2.3. Совещания

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

5.1.3. Планирование управления содержанием: выходы5.1.3.1. План управления содержанием

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

♦ процесс подготовки описания содержания проекта;

♦ процесс, который позволяет создавать ИСР из подробного описания содержания проекта;

♦ процесс, который устанавливает порядок одобрения и ведения базового плана по содержанию;

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

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

5.1.3.2. План управления требованиями

План управления требованиями – это компонент плана управления проектом, описывающий способы анализа, документирования требований по проекту и продукту и управления ими. Согласно документу Бизнес-анализ для специалистов-практиков: Практическое руководство (Analysis for Practitioners: A Practice Guide) [7], в некоторых организациях данный план называют еще «план бизнес-анализа». Компоненты плана управления требованиями могут включать в себя, среди прочего:

♦ порядок планирования, отслеживания и составления отчетов о действиях в отношении требований;

♦ действия по управлению конфигурацией, такие как порядок инициирования изменений, порядок анализа их воздействий, выявления, отслеживания и составления отчетов о них, а также уровни полномочий, необходимые для одобрения данных изменений;

♦ процесс приоритизации требований;

♦ используемые метрики и обоснование их использования;

♦ структуру отслеживания, которая отражает, какие параметры требований будут представлены в матрице отслеживания.

5.2. Сбор требований

Сбор требований – это процесс определения, документирования и управления потребностями и требованиями заинтересованных сторон для достижения поставленных целей. Ключевая выгода данного процесса состоит в том, что он предоставляет основу для определения содержания продукта и проекта. Этот процесс выполняется единожды или в предопределенные моменты в проекте. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 5–4. На рис. 5–5 показана диаграмма потоков данных процесса.

Рис. 5–4. Сбор требований: входы, инструменты и методы, выходы

Рис. 5–5. Сбор требований: диаграмма потоков данных

В Руководстве PMBOK® вопросы требований к продукту подробно не освещаются, поскольку эти требования разные в разных отраслях. Обратите внимание, что в документе Бизнес-анализ для специалистов-практиков: Практическое руководство (Analysis for Practitioners: Practice Guide) [7] можно найти более подробную информацию по требованиям к продукту. На успех проекта напрямую влияет активная вовлеченность заинтересованных сторон в выявление и декомпозицию потребностей в требования к проекту и продукту, а также тщательность определения, документирования и управления требованиями к продукту, услуге или результату проекта. Требования включают в себя условия или характеристики, которые должен, согласно требованиям, иметь продукт, услуга или результат, чтобы удовлетворить условиям соглашения или другим официально установленным спецификациям. Требования включают в себя количественно определенные и документированные потребности и ожидания спонсора, заказчика и прочих заинтересованных сторон. Данные требования должны быть выявлены, проанализированы и записаны со степенью детализации, достаточной для их включения в базовый план по содержанию и измерения после начала исполнения проекта. Требования становятся базой для ИСР. Планирование стоимости, расписания, качества и закупок основывается на данных требованиях.

5.2.1. Сбор требований: входы5.2.1.1. Устав проекта

Описан в разделе 4.1.3.1. В уставе проекта документируется высокоуровневое описание проекта и высокоуровневые требования, которые затем используются при детализации требований.

5.2.1.2. План управления проектом

Описан в разделе 4.2.3.1. Компоненты плана управления проектом включают в себя, среди прочего:

♦ План управления содержанием. Описан в разделе 5.1.3.1. План управления содержанием содержит информацию о порядке определения и разработки содержания проекта.

♦ План управления требованиями. Описан в разделе 5.1.3.2. План управления требованиями содержит информацию о порядке сбора, анализа и документального оформления требований по проекту.

♦ План вовлечения заинтересованных сторон. Описан в разделе 13.2.3.1. План вовлечения заинтересованных сторон используется для понимания требований заинтересованных сторон к коммуникациям и уровня их вовлеченности с целью оценки и адаптации к уровню участия заинтересованных сторон в действиях в отношении требований.

5.2.1.3. Документы проекта

В качестве примеров документов проекта, которые можно считать входами в данный процесс, можно назвать, среди прочего:

♦ Журнал допущений. Описан в разделе 4.1.3.2. В журнале допущений определены допущения в отношении продукта, проекта, среды, заинтересованных сторон и других факторов, которые влияют на требования.

♦ Реестр извлеченных уроков. Описан в разделе 4.4.3.1. Реестр извлеченных уроков используется для предоставления информации об результативных методах сбора требований, особенно для проектов, в которых применяется итеративная или адаптивная методология разработки продукта.

♦ Реестр заинтересованных сторон. Описан в разделе 13.1.3.1. Реестр заинтересованных сторон используется для определения заинтересованных сторон, которые могут предоставить информацию о требованиях. В нем также регистрируются требования и ожидания, которые есть у заинтересованных сторон по данному проекту.

5.2.1.4. Бизнес-документы

Описаны в разделе 1.2.6. Документом, который может оказать влияние на процесс сбора требований, является бизнес-кейс, который может содержать описание обязательных, желательных и необязательных критериев для удовлетворения бизнес-потребностей.

5.2.1.5. Соглашения

Описаны в разделе 12.2.3.2. Соглашения могут предусматривать требования к проекту и продукту.

5.2.1.6. Факторы среды предприятия

Факторы среды предприятия, которые могут оказывать влияние на процесс сбора информации, включают в себя, среди прочего:

♦ организационную культуру,

♦ инфраструктуру,

♦ управление персоналом,

♦ ситуацию на рынке.

5.2.1.7. Активы процессов организации

Активы процессов организации, которые могут оказывать влияние на процесс сбора требований, включают в себя, среди прочего:

♦ политики и процедуры,

♦ репозиторий исторической информации и извлеченных уроков, содержащий информацию о прошлых проектах.

5.2.2. Сбор требований: инструменты и методы5.2.2.1. Экспертная оценка

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

♦ бизнес-анализ,

♦ выяснение требований,

♦ анализ требований,

♦ документация по требованиям,

♦ требования к проекту в прошлых подобных проектах,

♦ методы диаграмм,

♦ фасилитация,

♦ управление конфликтами.

5.2.2.2. Сбор данных

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

♦ Мозговой штурм. Описан в разделе 4.1.2.2. Мозговой штурм – это метод, применяемый для генерации и сбора различных идей, связанных с требованиями к проекту и продукту.

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

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

♦ Анкеты и опросы. Анкеты и опросы представляют собой письменные наборы вопросов, разработанные с целью быстрого сбора информации у большого числа респондентов. Опросы и/или анкеты лучше всего подходят для работы с различными по составу аудиториями в ситуациях, когда требуется быстрый сбор информации, когда респонденты территориально распределены и когда статистический анализ мог бы быть целесообразным.

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

5.2.2.3. Анализ данных

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

♦ соглашения,

♦ бизнес-планы,

♦ документация по бизнес-процессам и интерфейсам,

♦ репозитории бизнес-правил,

♦ текущие блок-схемы процессов,

♦ маркетинговая литература,

♦ журналы проблем/трудностей,

♦ политики и процедуры,

♦ нормативно-правовые документы, такие как законы, кодексы, постановления и т. п.,

♦ запросы на предложения,

♦ сценарии использования.

5.2.2.4. Принятие решений

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

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

• Единогласие. Принятие решения посредством согласия каждого с единым курсом действий.

• Большинство. Решение, которое принимается при поддержке более чем 50 % участников группы. Наличие в группе нечетного количества участников может обеспечить принятие решения и исключить ситуацию равного количества голосов.

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

♦ Единоличное принятие решений. Данный метод предполагает, что одно лицо принимает на себя ответственность за решение, обязательное для целой группы.

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

5.2.2.5. Отображение данных

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

♦ Диаграммы сходства. Диаграммы сходства позволяют классифицировать большое количество идей по группам с целью обзора и анализа.

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

5.2.2.6. Навыки межличностных отношений и работы с командой

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

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

• постановка вопроса или проблемы перед группой; каждый человек молча обдумывает и записывает свои соображения;

• модератор выписывает идеи на лекционном плакате, пока не будут занесены все идеи;

• каждая выписанная идея обсуждается, пока у всех членов группы не сложится четкое понимание обсуждаемой идеи;

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

♦ Наблюдение/обсуждение. Наблюдение и обсуждение дают возможность непосредственно следить за отдельными лицами в окружающей их обстановке, а также за тем, как они исполняют свои обязанности или решают задачи и выполняют процессы. Наблюдения особенно полезны для детализированных процессов, когда люди, пользующиеся продуктом, не могут или не желают отчетливо изложить свои требования. Наблюдение также известно как «рабочая тень» (job shadowing). Оно обычно осуществляется внешним наблюдателем, следящим за тем, как бизнес-эксперт выполняет свою работу. Также наблюдения могут осуществляться «наблюдателем-участником», который фактически исполняет процесс или процедуру, чтобы узнать, как они выполняются, и выявить скрытые требования.

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

Навыки в области фасилитации используются, среди прочего, в следующих ситуациях:

• Совместное проектирование/разработка приложений (Joint application design/development, JAD). Сессии по JAD проводятся в отрасли разработки программного обеспечения. Данные сессии с участием модератора сконцентрированы на том, чтобы собрать вместе профильных бизнес-экспертов и команду разработчиков для сбора требований и улучшения процесса разработки программного продукта.

• Развертывание функции качества (Quality function deployment, QFD). В производственных отраслях QFD – это еще один метод фасилитации, который помогает определить критически важные характеристики для разработки нового продукта. QFD начинается со сбора потребностей заказчика, что также называется «мнением заказчика» (voice of the customer, VOC). Затем данные потребности объективно сортируются и приоритизируются, а также устанавливаются цели для их достижения.

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

Ключевые слова: перевод BABOK v. 2.0. на русский язык (IIBA), бизнес-анализ, бизнес-аналитик, системный-аналитик, управление требованиями, бизнес-требования, бизнес-правила, функциональные требования, нефункциональные требования, области знаний бизнес-анализа, Свод знаний по бизнес-анализу, Business Analysis Body of Knowledge

Что такое свод знаний по бизнес-анализу (Business Analysis Body of Knowledge)?

Руководство свода знаний по бизнес-анализу (Руководство BABOK) — это всемирно признанный стандарт для практики бизнес-анализа. Руководство BABOK описывает области знаний бизнес-анализа, связанные с ними деятельности и задачи, а также навыки, необходимые для эффективного их исполнения.
Основной целью Руководства BABOK является установление границ профессии бизнес-анализа. Руководство BABOK служит основанием, с помощью которого практики могут договориться для того, чтобы обсудить работу, которую они делают, и с помощью которого могут убедиться, что они имеют навыки, позволяющие им эффективно исполнять роль, а также определяет навыки и знания, с которыми люди работают и которые используются бизнес-аналитиками. Руководство BABOK — это концепция, описывающая задачи бизнес-анализа, которые должны быть выполнены для того, чтобы понять как решение будет приносить пользу организации-спонсору. Форма этих задач, последовательность их выполнения, относительная значимость и другие аспекты могут различаться, но каждая задача способствует в некотором роде, прямо или косвенно, достижению общей цели.
В этой главе дается введение в ключевые понятия областей бизнес-анализа и описывает структуру оставшейся части Руководства BABOK. Главы со 2 по 7 определяют задачи, которые бизнес-аналитик должен быть способен выполнять. Глава 8 описывает компетенции, которые способствуют эффективному исполнению бизнес-анализа. Глава 9 описывает ряд общепринятых методов, которые поддерживают практику бизнес-анализа.

Что такое бизнес анализ?

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

Ключевые концепции

Домены

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

Решения

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

Требования

Требование — это:
1. Условие или возможность, необходимые заинтересованной стороне для решения проблемы или достижения цели.
2. Условие или возможность, которые должны быть выполнены или которыми должно обладать решение/компоненты решения для удовлетворения контракта, стандарта, спецификации или других официальных документов.
3. Документированное представление условий или возможностей, как в (1) или (2).

Как видно из этого определения, требование может быть скрытым, подразумеваемым или вытекающим из других требований, или же может быть напрямую указанным и управляемым. Одной из ключевых задач бизнес-анализа является обеспечение того, чтобы требования были видны и понятны для всех заинтересованных сторон.
Термин «требование» порождает множество дискуссий в рамках сообщества бизнес-анализа. Многие из этих дебатов сосредотачиваются на том, что следует или что не следует считать требованием, и каковы необходимые характеристики требования. Тем не менее, при изучении Руководства BABOK очень важно термин «требование» понимать в самом широком смысле. Требования включают, но не ограничиваются прошлыми, настоящими или будущими условиями и возможностями предприятия, а также описанием организационной структуры, ролей, процессов, политик, нормативов и информационных систем. Требование может характеризовать текущее или будущее состояние любого аспекта работы предприятия.
Большая часть существующей литературы по бизнес-анализу написана в предположении, что требования описывают только ИТ-систему, которую планируют внедрять. Другие определения могут также содержать в себе бизнес-функции будущего состояния организации или могут ограничивать смысл термина целями, которые стремятся достичь заинтересованные лица, а не средствами, с помощью которых эти цели достигаются. Хотя все эти различные использования термина являются разумными и оправданными, и термин, используемый руководством BABOK, включает все эти значения, они значительно уже, чем употребляемый здесь термин.
Точно так же мы не считаем, что требования анализируются на конкретном уровне детализации, а наоборот — они должны быть оценены независимо от уровня детализации с целью понимания и действий. В контексте инициативы управления бизнес-процессами, требования могут являться описанием текущих бизнес-процессов, используемых в организации. На других проектах, бизнес-аналитик может решить разрабатывать требования, описывающие текущее состояние предприятия (которое само по себе является решением текущих или прошлых потребностей бизнеса) перед тем, как рассматривать внесение в решение изменений, необходимых для удовлетворения меняющихся условий бизнеса.

Схема классификации требований
Для целей Руководства BABOK используется следующая схема классификации для описания требований:
Бизнес-требования — это высокоуровневые формулировки целей, задач и потребностей предприятия. Они описывают причины, по которым был инициирован проект, задачи, которые будут достигнуты в ходе проекта, а также метрики, которые будут использоваться для измерения его успешности. Бизнес-требования описывают потребности организации в целом, а не группы или заинтересованных в нем сторон. Они разработаны и определены на основе анализа предприятия.
Требования заинтересованных сторон — это формулирование нужд конкретного заинтересованного лица или класса заинтересованных лиц. Эти требования описывают потребности, которые описывают что заинтересованная сторона имеет и как эта заинтересованная сторона будет взаимодействовать с решением. Требования заинтересованных сторон служит в качестве моста между бизнес-требованиями и другими классами требований к решению. Они разработаны и определены на основе анализа требований.
Требования к решению описывают характеристики к решению, которые соответствуют бизнес-требованиям и требованиям заинтересованных сторон. Они разработаны и определены на основе анализа требований. Их часто делят на подкатегории, особенно в случаях, когда требования описывают программное решение:
Функциональные требования описывают поведение решения и информацию о том, чем оно будет управлять. Эти требования описывают возможности системы, которые доступны к выполнению, в части режимов работы или операций — действия или реакции конкретного ИТ-приложения.
Нефункциональные требования фиксируют условия, которые напрямую не относятся к поведению или функциональности решения, а скорее описывают условия окружающей (внешней) среды, в условиях которой решение должно сохранять эффективность и качества, которыми система должна обладать. Они также известны как требования качества или дополнительные требования. Они могут включать в себя требования, связанные с мощностью (емкостью), скоростью, безопасностью, доступностью, информационной архитектурой и пользовательским интерфейсом.
Переходные требования описывают возможности, которыми решения должно обладать для осуществления перехода из текущего состояния предприятия к желаемому (требуемому) состоянию в будущем. Эти требования статут ненужными, как только этот переход завершится. Они отличаются от других типов требований, потому что они всегда носят временный характер и потому, что они не могут быть разработаны, пока оба решения, существующее и новое, не будут определены. Как правило, они охватывают преобразование данных из существующих систем, пробелы в знаниях и квалификации, которые должны быть решены, а также другие соответствующие изменения, необходимые для достижения желаемого будущего состояния. Их разрабатывают и определяют посредством проведения оценки и валидации (проверки) решения.

Области знаний

Области знаний определяют то, что практикующему специалисту бизнес-анализа нужно понимать и какие задачи он должен быть в состоянии выполнять.
Бизнес-аналитикам, скорее всего, необходимо выполнять задачи из всех областей знаний подряд, многократно или одновременно. Задачи могут выполняться в любой последовательности при условии наличия необходимых входных данных. В принципе, работа бизнес-аналитика может начаться с любой задачи, хотя наиболее вероятными задачами будут «Определение потребностей бизнеса» (5.1) или «Оценка эффективности решения» (7.6).
Области знаний не предназначены для представления фаз в проекте. Это, конечно, возможно и допустимо переходить от выполнения анализа деятельности предприятия к анализу требований, к оценке решения и валидации деятельности, и относиться к каждому из этих мероприятий как к отдельному этапу проекта. Однако руководство BABOK этого не требует, поэтому указанные шаги не следует рассматривать в качестве готовой методологии для выполнения бизнес-анализа.
Планирование и контроль бизнес-анализа (Глава 2) — это область знаний, которая освещает как бизнес-аналитика определить какие виды деятельности необходимы для осуществления бизнес-анализа. Она охватывает идентификацию заинтересованных сторон, выбор методов бизнес-анализа, процесса, который будет использоваться для управления требованиями и оценки хода работы. Задачи в этой области знаний регулируют производительность всех других задач бизнес-анализа.
Сбор информации (Глава 3) описывает как бизнес-аналитики работают с заинтересованными сторонами для определения и понимания их потребности и опасения, а также понять условия, в которых они работают. Целью сбора информации состоит в том, чтобы были поняты истинные, лежащие в основе потребности, а не их высказанные или поверхностные пожелания.
Управление требованиями и коммуникации (Глава 4) описывает, как бизнес-аналитики управляют конфликтами, проблемами и изменениями для того, чтобы гарантировать, что заинтересованные стороны и команда проекта находятся в согласии по рамкам решения, а также как требования доводятся до заинтересованных сторон и как знания полученные бизнес-аналитиком сохраняются для использования в будущем.
Анализ предприятия (глава 5) описывает как бизнес-аналитики идентифицируют потребности бизнеса, улучшают и проясняют определение этой потребности, а также определяют границы решения, которые могут быть реально реализованы для бизнеса. Эта область знаний описывает постановку пролемы и ее анализ, разработку бизнес-кейсов, техникоэкономические обоснования и определения границ решений.
Анализ требований (Глава 6) описывает, как бизнес аналитики расставляют приоритеты и последовательно уточняют требования заинтересованных сторон и требования по решению с тем, чтобы позволить проектной команде реализовать решение, которое будте соответствовать потребностям организации-спонсору и заинтересованным сторонам. Анализ требований включает в себя анализ потребностей заинтересованных сторон для определения решений, которые отвечают этим потребностям, оценку текущего состояния бизнеса для выявления и подготовки рекомендаций по улучшению, а также верификацию и валидацию требований.
Оценка и проверка решения (Глава 7) описывает, как бизнес-аналитики оценивают предлагаемые решения, чтобы определить какое решение лучше всего подходит для подребности бизнеса, выявляют пробелы и недостатки в решениях, а также определяют определяют необходимые доработки и изменения в решении. Оценка и проверка решения также описывает, как бизнес-аналитики оценивают развернутые решения, чтобы увидеть насколько хорошо они соответствуют потребностям, дабы организация-спонсор могла оценить производительность и эффективность решения.
Базовые компетенции (Глава описывает поведение, знания и другие характеристики, которые поддерживают эффективное выполенние бизнес-анализа.

Задачи

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

• Назначение задачи
• Описание задачи
• Входные данные
• Диаграмма входных/выходных данных задачи
• Требования входных данных для задачи
• Элементы задачи
• Методы выполнения задачи
• Заинтересованные лица
• Выходные данные задачи

Назначение задачи (цель)

Каждая задача имеет назначение. Назначение — это краткое описание причины для выполнения этой задачи бизнес-аналитиком и ее ценности, которая создается посредством выполнения задачи.

Описание задачи

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

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

Входные данные для задачи

Входные данные представляют информацию и предпосылки необходимые для начала выполнения задачи. Входные данные могут быть:
— Явно генерируемые за рамками бизнес-анализа (например, конструкция программного приложения).
Создаваться с помощью задачи бизнес-анализа.

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

Диаграммы входных и выходных данных задачи:

Требования для входных данных задач

Требования являются частным случаем как входных или выходных данных, что не должно быть неожиданно, учитывая их важность для бизнес-анализа. Они являются только входом или выходом, которые не производятся одной задачей. Требования могут быть классифицированы в несколько различных способов и могут существовать в любом из множества состояний. Когда указан в качестве входа или выхода в этом разделе задачи, следующий формат будет использоваться для обозначения классификации и состояния требования или набора требований:
Классификация требований [состояние или состояния]. Если не перечислены классификация или состояния, все или только некоторые требования могут быть использованы в качестве входа или выхода. Например, Требования [Заявленные] — означает что требования могут иметь любую классификацию, тогда как бизнес-требования — будет означать, могут быть в любом возможном состоянии (например, проверены, приоритезированы, заявлены или комбинации этих состояний).
Требования могут быть также объединены в некоторых случаях. Например, Требования [Приоритезированы и Проверены] — должны быть прочитаны, чтобы указать, что требования были приоритезированы и проверены. Требования [Приоритезированы или Проверены] — означает, что требования могут быть либо приоритезированы, либо проверены, либо одновременно приоритезированы и проверены.

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

Элементы задачи

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

Методики

Каждая задача содержит перечень соответствующих методов. Некоторые методы характерны для выполнения одной задачи, в то время как другие относятся к выполнению большого числа задач (и перечислены в Главе 9: Методы). Если конкретная задача может использовать оба вида техник, те, что описаны в Главе 9 будут перечислены в подразделе «Общие методы». Если нет подраздела, то все методы можно найти в Главе 9. Для получения дополнительной информации см. Методы (1.6).

Заинтересованные стороны

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

Техники (методы или методики)

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

• Определение критериев приемки и оценки (9.1)
• Мозговой штурм (9.3)
• Анализ бизнес-правил (9.4)
• Словарь данных и Глоссарий (9.5)
• Диаграммы потоков данных (9.6)
• Моделирование данных (9.7)
• Анализ решений (9.8)
• Анализ документов (9.9)
• Интервью (9.14)
• Метрики и Ключевые показатели эффективности (9.16)
• Анализ нефункциональных требований (9.17)
• Организационное моделирование (9.19)
• Отслеживание проблемы (9.20)
• Моделирование процессов (9.21)
• Семинары требований (9.23)
• Сценарии и варианты использования (9.26)

Руководство BABOK может в некоторых случаях группировать схожие методы, или методы, которые разделяют одну цель, под одним заголовком. Например, техника Моделирования данных (9.7) охватывает модели классов и диаграммы «сущность-связь» и в принципе может охватывать концепт-карты, модели терминов и факт-модели, модели ролей объекта, и другие, менее широко распространенные методы анализа.
Каждый метод в Руководстве BABOK представлен в следующем формате:

Цель
Определяет для чего эта техника используется и при каких обстоятельствах скорее всего, она будет применима.

Описание
Описание того, что это за техника и как она используется.

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

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

Основные компетенции (Базовые компетенции)

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

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

Другие ресурсы информации по бизнес анализу

Руководство BABOK является обобщением информации о роли бизнес-анализа, заимствованные из разнообразных подходов к совершенствованию и изменению бизнеса. Полный список работ, на которые ссылается Руководство BABOK можно найти в Приложении B: Библиография. Бизнес-аналитиков, которые стремятся расширить свое понимание бизнес-анализа, возможно, пожелают ознакомиться с работами в других областях, получить профессиональную подготовку от специалистов из этих областей или осуществить другие возможности для обучения и профессионального развития.

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

• Гибкая разработка (Agile)
• Бизнес-аналитика (BI)
• Управление бизнес-процессами
• Бизнес-правила
• Управление ИТ-услугами (включая ITIL)
• Lean и Six Sigma
• Управление организационными изменениями
• Управление проектами
• Управление качеством
• Сервис-ориентированная архитектура
• Разработка программного обеспечения (в частности, разработка требований)
• Совершенствование процессов разработки (в том числе CMMI)
• Контроль качества программного обеспечения
• Стратегическое планирование
• Проектирование пользовательского интерфейса

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

Новости

Комментариев нет.

RSS-лента комментариев к этой записи.