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

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 фокусируется на определении роли бизнес-анализа в широком диапазоне подходов бизнес-анализа и поэтому лишь вкратце затрагивает большую часть информации, разработанную практиками, которые работают в этих областях. Бизнес-аналитики обнаружат, что изучение любой из этих областей будет награждено более глубоким пониманием профессии бизнес-анализа, умением сотрудничать с другими профессионалами, а также пониманием ряда различных способов, с помощью которых бизнес-аналитики могут принести организации, которые их нанимают.

Предисловие

Я, Артём Кагукин, Lead BA в компании *Instinctools и тренер курса по бизнес-анализу в IT-Academy.

Мой первый пост на Хабр является рецензией-сравнением двух книг: BABOK (Business Analysis Body of Knowledge) от института IIBA и REF (Requirements Engineering Fundamentals) от некоммерческой организации IREB.

Книги содержат свод знаний по выявлению потребностей бизнеса, рекомендации возможных решений и проектирования информационных системе в ИТ-сфере. Знание обеих книг помогает мне в преподавании курса «Бизнес-анализ в области разработки ПО».

 Данная статья будет полезна всем, кто связан с ИТ и работает с требованиями и потребностями клиентов и заказчиков не зависимо от вашего уровня подготовки и опыта.

Цели данной статьи:

• Помочь читателю понять, какая книга может быть полезна для него.

• Помочь читателю выбрать, какую из книг стоит читать первой и когда.

Методы достижения целей:

• Сравнительный анализ контента книг.

• Экспертная оценка:

Кагукин Артем, Lead BA, специалист с 14-ти летним стажем, сертифицированный бизнес-аналитик (CBAP от IIBA, 12/2019) и системный аналитик (CPRE -FL IREB, 05/2021).

Кондратьев Павел, Lead BA, специалист с 15-ти летним стажем, сертифицированный бизнес-аналитик (CBAP от IIBA, 06/2020).

Уманец Николай, Head of BA, специалист с 7-ти летним стажем, сертифицированный бизнес-аналитик (CBAP от IIBA, 05/2018, ААС от IIBA, 01/2020).

Сазановец Степан, Middle+ BA/SA, специалист с 6-и летним стажем, сертифицированный системный аналитик (CPRE -FL IREB, 05/2022).

Основная часть

Для начала заглянем во введение книг:

• «В Руководстве BABOK® описываются области знаний бизнес-анализа, задачи, базовые компетенции, методы и ракурсы подхода к бизнес-анализу… Главная цель Руководства BABOK® — определить бизнес-анализ как профессию и предложить набор его общепринятых практик.» (выдержки из BABOK от IIBA официальной русской версии).

• «Влияние инженерии требований на успешную и ориентированную на клиента разработку систем больше нельзя игнорировать … растет понимание того, что роль инженера по требованиям, по сути, самодостаточна и включает в себя ряд сложных действий… Цель этой книги — помочь вам в подготовке к сертификационному экзамену» (мой вольный перевод из REF от IREB).

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

• одна о бизнес-анализе, а другая об инженерии требований;

• одна о бизнес-аналитике, а другая об инженере по требованиям.

Так ли это? Давайте сперва посмотрим на основные отличия данных книг

А теперь детальнее на отличия по основным темам.

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

BABOK от IIBA написана более сложно, это как справочник или энциклопедия. Информация в книге полезна опытным специалистам как контрольный список с указанием нужных действий и техник, необходимых для работы над определенными задачами в рамках определенных этапов работы. Структура BABOK от IIBA сложна для восприятия неподготовленным читателям без необходимых теоретических и практических навыков.

На диаграмме показано, кому необходимо и желательно прочитать данные книги. Также можно оценить значимость контента книг для разных специалистов. Распределение по осям сделано на основании метода приоритезации «MoSCoW»: must, should, could, would. Список специалистов не является полным и может быть дополнен в дальнейшем.

Заключение

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

• Области знаний, в которых у вас нет практического опыта.

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

Необходимость или желательность прочтения данных книг зависит от вашей специальности и рода выполняемых вами задач (смотрите Диаграмму 1 выше).

Я рекомендую REF от IREB читать до прочтения BABOK IIBA и при наличии 1-2 лет опыта работы в ИТ. Данный срок является достаточным для подготовки к освоению материала книги. Для лучшего понимания вам необходимо пройти общие курсы по выявлению и спецификации требований, а также получить практический опыт в ИТ сфере. На прочтение и проработку материала REF от IREB вам может понадобиться от 1 до 3 месяцев. В изучении вам поможет знание UML, дополнительное чтение Handbook от IREB, консультации с опытными коллегами.

BABOK от IIBA стоит читать подготовленным специалистом, с практическим опытом работы в ИТ 3-6 лет. Данный срок необходим для подготовки к лучшему восприятию и пониманию материала книги. На проработку вам может понадобиться от 3 до 6 месяцев. При этом сократить скорость изучения и лучше понять структуру книги вам помогут специализированные курсы по главам BABOK от IIBA, специализированные тренажеры с вопросами, ответами и пояснениями, а также общение с сертифицированными коллегами.

Спасибо всем за уделенное время. Открыт для конструктивной критики в комментариях.

Библиографическая запись Библиотеки Конгресса США

Названия: Институт управления проектами (Project Management Institute, PMI), издатель.

Заголовок: Руководство к своду знаний по управлению проектом (Руководство PMBOK) (A guide to the project management body of knowledge (PMBOK guide) / Институт управления проектами.

Другие заголовки: Руководство PMBOK

Описание: Шестое издание | Newtown Square, PA: Project Management Institute, 2017. | Серия: Руководство PMBOK |

Включает библиографические ссылки и указатель

Идентификаторы: LCCN 2017032505 (print) | LCCN 2017035597 (ebook) | ISBN 9781628253900 (ePUP) |

ISBN 9781628253917 (kindle) | ISBN 9781628253924 (Web PDF) | ISBN 9781628251845 (paperback)

Тематика: LCSH: Управление проектом (Project management). | BISAC: БИЗНЕС И ЭКОНОМИКА / Управление проектом (BUSINESS & ECONOMICS / Project Management).

Классификация: LCC HD69.P75 (ebook) | LCC HD69.P75 G845 2017 (print) | DDC 658.4/04-dc23

Запись LC доступна на веб-сайте https://lccn.loc.gov/2017032505

ISBN: 978-1-62825-193-7

Опубликовано:

Project Management Institute, Inc.

14 Campus Boulevard

Newtown Square, Pennsylvania 19073-3299 США

Телефон: +1 610-356-4600

Факс: +1 610-356-4647

Эл. почта: customercare@pmi.org

Веб-сайт: https://www.PMI.org

Материалы Project Management Institute, Inc. охраняются авторским правом в соответствии с законом США об интеллектуальной собственности, который признан в большинстве стран. Для переиздания или воспроизведения материалов PMI вам необходимо получить наше разрешение. Для получения более подробной информации посетите http://www.pmi.org/permissions_for_details.

Для размещения торгового заказа или получения информации о расценках обратитесь в Independent Publishers Group:

Independent Publishers Group

Order Department

814 North Franklin Street

Chicago, IL 60610 США

Телефон: +1 800-888-4741

Факс: +1 312-337-5985

Эл. почта: orders@ipgbook.com (только для заказов)

По всем остальным вопросам обращайтесь в PMI Book Service Center.

PMI Book Service Center

P.O. Box 932683, Atlanta, GA 31193-2683 USA

Телефон: 1-866-276-4764 (в США или Канаде) или +1-770-280-4129 (по всему миру)

Факс: +1-770-280-4113

Эл. почта: info@bookorders.pmi.org

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

PMI, логотип PMI, PMBOK, OPM3, PMP, CAPM, PgMP, PfMP, PMI-RMP, PMI-SP, PMI-ACP, PMI-PBA, PROJECT MANAGEMENT JOURNAL, PM NETWORK, PMI TODAY, PULSE OF THE PROFESSION и девиз MAKING PROJECT MANAGEMENT INDISPENSABLE FOR BUSINESS RESULTS. являются товарными знаками Project Management Institute, Inc. Для получения полного списка товарных знаков PMI обратитесь в юридический отдел PMI. Все остальные товарные марки, знаки обслуживания, торговые наименования, торговое оформление, названия продуктов и логотипы, появляющиеся в данном документе, являются собственностью их соответствующих владельцев. Любые права, не переданные в явной форме в настоящем документе, принадлежат владельцу авторского права.

Все права защищены. Воспроизведение всей книги или ее части в любом виде воспрещается без письменного разрешения издателя.

ISBN 9781628251845

© Copyright 2017 Project Management Institute, Inc. Все права защищены.

© Перевод на русский язык, издание, оформление издательство «Олимп–Бизнес», 2018

Руководство к Своду знаний по управлению проектами (Руководство PMBOK)

Уведомление

Публикуемые Институтом управления проектами (Project Management Institute, Inc., сокращенно PMI) стандарты и руководства, к числу которых принадлежит и данный документ, разработаны согласно процессу разработки стандартов на основе добровольного участия и общего консенсуса. В ходе такого процесса объединяются усилия волонтеров и/или сводятся воедино замечания и мнения лиц, заинтересованных в предмете, которому посвящено данное издание. Хотя PMI администрирует этот процесс и устанавливает правила, гарантирующие непредвзятость при достижении консенсуса, PMI не занимается написанием документа, а также независимым тестированием, оценкой и проверкой точности или полноты материала, содержащегося в издаваемых PMI стандартах и руководствах. Подобным же образом, PMI не занимается проверкой обоснованности мнений, высказанных в этих документах.

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

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

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

Часть 1. Руководство к Своду Знаний по Управлению Проектом (Руководство PMBOK®)

1. Введение

1.1. Обзор и назначение настоящего руководства

Управление проектами не является чем-то новым. Люди пользуются им на протяжении многих веков. Среди примеров осуществленных проектов можно назвать:

♦ пирамиды в Гизе,

♦ Олимпийские игры,

♦ Великую китайскую стену,

♦ Тадж-Махал,

♦ издание книги для детей,

♦ Панамский канал,

♦ создание коммерческих реактивных самолетов,

♦ вакцину от полиомиелита,

♦ высадку человека на Луне,

♦ коммерческие компьютерные прикладные программы,

♦ портативные устройства для использования глобальной системы позиционирования (GPS),

♦ выведение международной космической станции на околоземную орбиту.

Практические достижения этих проектов стали результатом применения руководителями и управленцами в своей работе практик, принципов, процессов, инструментов и методов управления проектами. Руководители этих проектов использовали ряд ключевых навыков и применяли знания, необходимые для удовлетворения своих клиентов и других людей, занятых в осуществлении или испытывающих влияние проекта. К середине XX века руководители проектов начали работу с целью добиться признания управления проектами в качестве профессии. Одним из аспектов этой работы стало достижение соглашения в отношении содержания свода знаний (body of knowledge, BOK) под названием «управление проектом» (project management). ВОК становится известным как «Свод знаний по управлению проектом» (Project Management Body of Knowledge, PMBOK). Институт управления проектами (Project Management Institute, PMI) создал базовые схемы и глоссарии для PMBOK. Руководители проектов скоро пришли к пониманию, что PMBOK невозможно полностью уместить в одной книге. Поэтому PMI разработал и опубликовал «Руководство к Своду знаний по управлению проектом» (PMBOK® Guide).

Согласно данному институтом PMI определению, «свод знаний по управлению проектом» (PMBOK) – это понятие, которое описывает знания в области профессии управления проектом. Свод знаний по управлению проектом включает в себя зарекомендовавшие себя и широко используемые традиционные практики, а также недавно появившиеся инновационные практики.

Свод знаний (ВОК) включает как опубликованные, так и неопубликованные материалы. Этот свод знаний постоянно развивается. Настоящее Руководство PMBOK® выделяет ту часть Свода знаний по управлению проектом, которая является общепризнанной хорошей практикой.

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

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

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

Настоящее Руководство PMBOK® не является методологией. Методология – это система практик, методов, процедур и правил, используемых в определенной сфере деятельности. Настоящее Руководство PMBOK® является основой, на которой организация может разработать свои методологии, политики, процедуры, правила, инструменты и методы, а также фазы жизненного цикла, необходимые в практике управления проектом.

1.1.1. Стандарт управления проектом

В основу настоящего Руководства положен Стандарт управления проектом [1]. Стандарт – это документ, установленный уполномоченным органом, обычаем или по общему согласию в качестве модели или образца. Стандарт управления проектом был разработан как стандарт Американского национального института стандартов (American National Standards Institute, ANSI) с использованием процесса, основанного на принципах консенсуса, открытости, соблюдения процессуальных норм и сбалансированности. Стандарт управления проектом является основополагающим справочным материалом для программ PMI по профессиональному развитию и в практике управления проектом. Поскольку существует необходимость адаптации управления проектом с целью обеспечить соответствие потребностям конкретного проекта, в основу как Стандарта, так и Руководства положены описательные, а не директивные практики. В силу этого настоящий Стандарт определяет процессы, которые являются хорошими практиками при осуществлении большинства проектов в большинстве случаев. Данный Стандарт также определяет входы и выходы, которые обычно связаны с этими процессами. Стандарт не содержит требований об обязательном исполнении тех или иных конкретных процессов или практик. Стандарт управления проектом входит в состав части II Руководства к Своду знаний по управлению проектом (Руководство PMBOK®).

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

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

♦ Стандарт управления портфелем [2], и

♦ Стандарт управления программой [3].

1.1.2. Общий словарь

Общий словарь является существенным элементом любой профессиональной дисциплины. Лексикон терминов управления проектами PMI (PMI Lexicon of Project Management Terms)^[1] представляет собой основной словарь профессиональной терминологии, который могут единообразно использовать организации, руководители проектов, программ и портфелей и другие заинтересованные стороны проектов. Лексикон с течением времени будет развиваться. Глоссарий настоящего Руководства включает в себя словарь входящих в Лексикон (Lexicon) терминов, а также дополнительные определения. В проектах могут использоваться другие принятые в конкретных отраслях термины, определение которых дано в отраслевой литературе.

1.1.3. Кодекс профессиональной этики и поведения

PMI публикует Кодекс профессиональной этики и поведения [5] с целью укрепить доверие к профессии управления проектами и помочь человеку в принятии разумных решений, особенно в трудных ситуациях, когда ему (ей) может быть предложено совершить нечестный поступок или поступиться своими ценностями. Ценности, которые мировое сообщество специалистов по управлению проектами определило как наиболее важные, – это ответственность, уважение, справедливость и честность. В основе Кодекса профессиональной этики и поведения лежат эти четыре ценности.

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

1.2. Основополагающие элементы

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

1.2.1. Проекты

Проект – это временное предприятие, направленное на создание уникального продукта, услуги или результата.

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

Достижение целей проекта может произвести один или несколько из перечисленных ниже поставляемых результатов:

• уникальный продукт, который может быть либо компонентом другого продукта, либо улучшением или исправлением какого-то продукта, либо сам по себе новым конечным продуктом (например, устранением дефекта в конечном продукте);

• уникальная услуга или способность предоставлять услугу (например, бизнес-подразделение, поддерживающее производство или дистрибуцию);

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

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

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

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

В качестве примеров проекта можно привести, среди прочего:

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

• расширение экскурсионных туристических услуг;

• слияние двух организаций;

• совершенствование бизнес-процесса в организации;

• приобретение и установка нового компьютерного аппаратного обеспечения для использования в организации;

• разведка нефтяных месторождений в регионе;

• модификация компьютерной программы, используемой в организации;

• проведение исследований для разработки нового производственного процесса;

• строительство здания.

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

• достигнуты цели проекта;

• цели не будут или не могут быть достигнуты;

• финансирование на осуществление проекта исчерпано или больше не может быть выделено;

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

• исчерпаны человеческие или материальные ресурсы;

• проект прекращается по юридическим причинам или соображениям целесообразности.

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

♦ Проекты служат движущей силой изменений. Проекты служат движущей силой изменений в организациях. С точки зрения бизнеса, цель проекта состоит в переходе организации из одного состояния в другое для достижения конкретной цели (см. рис. 1–1). Обычно считается, что до начала проекта организация находится в исходном состоянии. А желаемый результат изменения в ходе осуществления проекта описывается как будущее состояние.

Некоторые проекты могут предполагать создание переходного состояния, когда выполняется несколько вытекающих один из другого шагов для достижения будущего состояния. Результатом успешного завершения проекта является переход организации к будущему состоянию и достижение конкретной цели. Дополнительную информацию по управлению проектом и изменениями смотрите в документе «Управление изменениями в организациях: практическое руководство» (Governance of Portfolios, Programs, and Projects: A Practice Guide) [6].

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

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

В качестве примеров материальных элементов можно назвать:

• денежные средства,

• акционерный капитал,

• инженерные сети,

• основные средства,

• инструменты,

• долю рынка.

В качестве примеров нематериальных элементов можно назвать:

• гудвилл (деловая репутация и коммерческий опыт),

• узнаваемость марки,

• общественное благо,

• товарные знаки,

• соответствие стратегии,

• репутацию.

♦ Контекст инициации проекта. Руководители организаций инициируют проекты в ответ на факторы, влияющие на состояние дел в их организациях. Существует четыре основных категории данных факторов, которые позволяют лучше понять контекст проекта (см. рис. 1–2):

• обеспечение соответствия нормативно-правовым, юридическим или социальным требованиям;

• удовлетворение запросов или потребностей заинтересованных сторон;

• реализация или изменение бизнес- или технологических стратегий;

• создание, совершенствование или исправление продуктов, процессов или услуг.

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

В таблице 1–1 показано, как взятые для примера конкретные факторы можно сопоставить с одной или несколькими основными категориями факторов.

Таблица 1–1. Примеры факторов, которые вызывают необходимость в создании проекта.

Часть 1 — Руководство

1.2.4.7 ДАННЫЕ И ИНФОРМАЦИЯ УПРАВЛЕНИЯ ПРОЕКТОМ

На протяжении жизненного цикла проекта производится сбор, анализ и преобразование значительного количества 

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

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

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

форматах в виде отчетов. Более подробную информацию по этой теме см. в разделе 4.3.

Сбор и анализ данных проекта производится регулярно на всем протяжении жизненного цикла проекта. Ниже приводятся 

определения основных терминов, относящихся к данным и информации проекта.

u

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

выполненной работе, показатели качества и показатели технического исполнения, даты старта и финиша операций 

по расписанию, количество запросов на изменения, количество дефектов, фактическая стоимость, фактическая 

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

(Project Management Information System, PMIS; см. раздел 4.3.2.2) и в документах проекта.

u

u

Информация об исполнении работ. Данные об исполнении, собранные в рамках различных процессов контроля, 

проанализированные в контексте и обобщенные на основе связей в различных областях. Примеры информации 

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

прогнозы до завершения работ.

u

информации об исполнении работ, которая предназначена для принятия решений или формулирования проблем, 

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

обоснования, информационные бюллетени, электронные информационные панели, рекомендации и обновления.

На рис. 1-7 показан поток информации проекта в рамках различных процессов, используемых для управления проектом.