BABOK (Business Analysis Body of Knowledge)

BABOK (Business Analysis Body of Knowledge) — международный свод знаний по бизнес-анализу, который разрабатывает и поддерживает профессиональная ассоциация IIBA. Проще говоря, это описание того, как превратить смутные пожелания заказчиков и пользователей в понятные, проверяемые требования и убедиться, что реализованное решение действительно приносит пользу бизнесу. Стандарт используют бизнес-аналитики в ИТ-проектах, но его логика — от потребности к требованию, от требования к решению, от решения к оценке ценности — применима к любому проекту изменений: от внедрения CRM до перестройки процесса закупок. В этой статье BABOK разобран по первоисточникам: история стандарта, устройство версии 3, ключевые понятия, критика, метрики, план внедрения и работа с фреймом в OrgDevTools.

Что такое BABOK и зачем он нужен

Слово «BABOK» означает и сам документ — «A Guide to the Business Analysis Body of Knowledge» (BABOK Guide), и приблизительно всю профессиональную практику бизнес-анализа, которую этот документ описывает. Он отвечает на четыре вопроса: как спланировать работу аналитика, как выявить потребности заинтересованных сторон, как управлять требованиями на протяжении проекта и как оценить, что решение сработало. Главная ценность стандарта — единый язык: когда заказчик, аналитик, разработчик и тестировщик понимают одно и то же под словами «потребность», «требование», «решение» и «ценность», меньше тратится времени на споры о терминах и больше — на суть.

Стандарт полезен не только профессиональным аналитикам. Руководителю проекта он даёт чек-лист того, что должно быть сделано до начала разработки; собственнику — критерии, по которым можно проверять, что деньги тратятся на нужные изменения; команде разработки — общий шаблон формулировки требований. Смежные инструменты — PMBOK описывает управление проектом, а BABOK — то, что нужно построить и зачем; SIPOC помогает быстро очертить процесс, для которого собираются требования.

Происхождение и исследовательская база BABOK

IIBA (International Institute of Business Analysis) основан в 2003 году, чтобы решить проблему несогласованности практик бизнес-анализа: у профессии не было общего стандарта, и разные организации называли одинаковые вещи по-разному. Свод знаний развивался версиями: вторая версия BABOK Guide вышла в 2009 году, третья — в 2015 году (по данным IIBA, апрель 2015). Профессиональная сертификация CBAP (Certified Business Analysis Professional) введена в 2006 году, позднее ассоциация запустила сертификацию CCBA для практиков с двух-трёхлетним опытом. Стандарт систематизирует практики, накопленные в ИТ- и консалтинговых проектах по всему миру, и служит основой для профессионального экзамена.

Исследовательская база у метода прежде всего практическая: он возник как ответ на повторяющиеся провалы проектов из-за требований. Классическое наблюдение Фреда Брукса в статье «No Silver Bullet» (1987) состоит в том, что самая трудная часть построения программной системы — решить, что именно строить. Современные отраслевые данные говорят о том же: в углублённом отчёте PMI Pulse of the Profession по управлению требованиями (Requirements Management: A Core Competency for Project and Program Success) почти половина (47%) неуспешных проектов не достигает целей из-за неточного управления требованиями; при этом лишь 36% руководителей и спонсоров проектов полностью ценят управление требованиями как компетенцию, 55% ценят частично, а 9% не ценят вовсе. Исследование связывает требования и со многими другими причинами провалов — расползанием объёма, плохой коммуникацией, слабым участием заинтересованных сторон и недостаточной поддержкой спонсора — и рекомендует развивать три области: людей, процессы и культуру.

Большинство провалов проектов начинается не с плохого кода, а с неправильно понятой задачи: дешевле всего исправить ошибку, пока она ещё в виде слов на бумаге, а не в виде готовой системы.

Теория BABOK Guide v3: шесть областей знаний, модель понятий, компетенции и перспективы

Шесть областей знаний

BABOK v3 организует практику в шесть областей знаний, каждая из которых состоит из задач (всего около 30):

• Планирование и мониторинг бизнес-анализа (Business Analysis Planning and Monitoring). Как спланировать саму работу аналитика: кто заинтересованные стороны, какой подход к анализу, как будут управляться информация и результаты.

• Выявление и сотрудничество (Elicitation and Collaboration). Как получить настоящую информацию от людей: подготовка и проведение интервью, воркшопов, наблюдений, а затем подтверждение результатов и совместная работа со стейкхолдерами.

• Управление жизненным циклом требований (Requirements Life Cycle Management). Как ничего не потерять и не забыть: отслеживание связей между требованиями, поддержание актуальности, приоритизация, утверждение и управление изменениями.

• Анализ стратегии (Strategy Analysis). Проверка, что решается правильная задача: текущее и будущее состояние, риски и стратегия изменения.

• Анализ требований и определение дизайна (Requirements Analysis and Design Definition). Как превратить требования в то, с чем может работать команда: спецификация и моделирование, проверка и валидация, определение архитектуры и опций решения, оценка потенциальной ценности.

• Оценка решения (Solution Evaluation). Проверка, что решение реально сработало и принесло ожидаемую ценность, и анализ причин расхождений.

Модель основных понятий бизнес-анализа (BACCM)

Впервые в третьей версии стандарта введена модель Business Analysis Core Concept Model (BACCM): шесть понятий, общих для любых областей знаний. Изменение (Change) — переход из текущего состояния в желаемое; потребность (Need) — проблема или возможность, которую нужно закрыть; решение (Solution) — конкретный способ ответить на потребность; заинтересованная сторона (Stakeholder) — группа или человек, связанные с изменением; ценность (Value) — польза, которую изменение приносит; контекст (Context) — обстоятельства, влияющие на изменение. Смысл модели практический: любое решение аналитика можно проверить вопросом «как оно связано с этими шестью понятиями», а спор о терминах — снять ссылкой на общую модель.

Классификация требований

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

Базовые компетенции аналитика и перспективы

Стандарт описывает и то, чем должен обладать сам аналитик: шесть категорий базовых компетенций — аналитическое мышление и решение проблем, поведенческие характеристики, знание бизнеса, коммуникация, взаимодействие с людьми, инструменты и технологии. Кроме того, v3 вводит пять «перспектив» — контекстов, в которых применяется практика: Agile, бизнес-аналитика данных (Business Intelligence), информационные технологии, бизнес-архитектура и управление бизнес-процессами. Всего в стандарте описано около 50 техник (от интервью и воркшопов до моделирования процессов и данных). Согласно материалам о стандарте, техники выявления и сотрудничества напрямую применимы к работе с бэклогом, написанию пользовательских историй и планированию спринтов, поэтому BABOK не противопоставляется гибким подходам — см. Agile-манифест и Scrum.

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

Ключевые идеи и принципы BABOK

1. Принцип: сначала потребность, потом требование, потом решение

   Самая частая ошибка проектов — начинать с решения («нам нужна CRM»), не проверив потребность («мы теряем заявки при передаче между отделами»). BABOK строит последовательность: сначала выясняется потребность и её ценность, затем формулируются требования, и только потом обсуждаются варианты решения. Это защищает от покупки дорогой системы, которая решает не ту проблему.

2. Принцип: требование должно быть проверяемым

   Формулировка «система должна быть удобной» ничего не говорит о том, когда работа выполнена. Хорошее требование содержит критерий приёмки: какое наблюдаемое условие покажет, что оно выполнено. В международном стандарте ISO/IEC/IEEE 29148 (инженерия требований) хорошее требование описывают набором характеристик — необходимость, однозначность, полнота, единичность, осуществимость, проверяемость, корректность и другие; практическое правило то же: если тестировщик не может проверить требование, его нужно переписать.

3. Принцип: каждое требование прослеживается до бизнес-цели

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

4. Принцип: разные представления снимают разночтения

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

5. Принцип: анализ — не разовая фаза, а непрерывная работа

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

Как проводить бизнес-анализ по BABOK: практическая последовательность

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

Такая последовательность не обязана быть «водопадом»: в гибкой работе те же действия повторяются короткими циклами, а требования оформляются в виде пользовательских историй и критериев приёмки, но вопросы остаются теми же — какая потребность, кто заинтересованные стороны, как проверить результат, какая ценность.

BABOK и PMBOK: чем отличаются и как дополняют друг друга

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

Сертификации на основе BABOK: CBAP и CCBA

IIBA предлагает профессиональные сертификации, основанные на стандарте: CBAP (Certified Business Analysis Professional), введённая в 2006 году, и CCBA (Certification of Capability in Business Analysis) для практиков с двух-трёхлетним опытом. Сертификация подтверждает знание стандарта и опыт, но не является гарантией качества конкретного анализа; для организации она полезна как общий ориентир при найме и развитии аналитиков.

Ограничения, слепые зоны и критика BABOK

Типовые ошибки при внедрении BABOK

1. Ошибка 1: начинают с решения, а не с потребности.

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

   Как избежать

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

2. Ошибка 2: формулируют требования без критериев приёмки.

   Формулировки вроде «быстро», «удобно», «надёжно» допускают любое прочтение, и по завершении работы стороны расходятся в оценке результата.

   Как избежать

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

3. Ошибка 3: собирают требования у одной группы стейкхолдеров.

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

   Как избежать

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

4. Ошибка 4: не связывают требования с бизнес-целью.

   В проект попадают «хотелки», реализация которых не приближает результат; бюджет и сроки растут без ценности.

   Как избежать

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

5. Ошибка 5: пропускают модели и остаются на тексте.

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

   Как избежать

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

6. Ошибка 6: считают анализ разовой фазой и не управляют изменениями.

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

   Как избежать

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

7. Ошибка 7: применяют стандарт «по букве» вместо адаптации.

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

   Как избежать

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

Метрики качества бизнес-анализа

Универсальных нормативов нет — значения зависят от отрасли, размера проекта и подхода. Сначала снимите базовые показатели по прошлым проектам, затем отслеживайте динамику:

• Стабильность требований: доля требований, изменённых после утверждения, и доля изменений, вызванных ошибками анализа, а не изменением бизнеса.

• Полнота трассировки: доля требований, связанных с потребностью, целью и элементом решения.

• Проверяемость: доля требований с критериями приёмки.

• Дефекты требований: число ошибок и пропусков, найденных на этапе разработки и после запуска, отнесённых к причинам в требованиях.

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

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

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

План внедрения BABOK в проекте изменений

1. Неделя 1: карта заинтересованных сторон и план анализа

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

2. Неделя 2: выявление потребностей

   Проведите интервью и воркшопы, понаблюдайте за реальной работой пользователей, соберите документы. Зафиксируйте потребности (проблемы и возможности) и подтвердите их с участниками.

3. Неделя 3: требования и критерии приёмки

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

4. Неделя 4: модели и проверка

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

   Далее: на протяжении проекта поддерживайте трассировку и управляйте изменениями; после запуска оцените решение по согласованным показателям и вернитесь к потребностям.

Как реализовать этот план с помощью фрейма «BABOK» в OrgDevTools

Фрейм BABOK в OrgDevTools — бесплатный тренажёр, который проводит путь от бизнес-целей и потребностей к проверяемым требованиям. Требования связываются с потребностью и целью, а фрейм сам ищет разрывы в прослеживаемости. В нём пять вкладок: три рабочие, визуализация и итоги. Готовых примеров нет, все списки и таблица изначально пустые. Подсказки в полях — только образцы формулировок.

Книги и материалы по теме BABOK

IIBA — «A Guide to the Business Analysis Body of Knowledge (BABOK Guide)», версия 3 (2015). Первоисточник стандарта: области знаний, основные понятия, техники, компетенции и перспективы.

Фредерик Брукс — «No Silver Bullet — Essence and Accident in Software Engineering» (IEEE Computer, 1987). Классическое рассуждение о том, что самая трудная часть создания ПО — определить, что строить.

PMI — «Requirements Management: A Core Competency for Project and Program Success» (Pulse of the Profession In-Depth Report). Данные о влиянии управления требованиями на успех проектов.

ISO/IEC/IEEE 29148 — международный стандарт по инженерии требований: процессы и характеристики хороших требований.