Почему решил написать статью: всё просто, не нашел аналогичной статьи и решил восполнить пробел! К тому же, эти знания сильно помогают мне в работе.
Итак, сразу к делу. Начнем, разумеется, с определения бизнес-анализа — возьмем классическое определение из BABOK:
Бизнес-анализ — это деятельность, которая делает возможным проведение изменений в организации, приносящих пользу заинтересованным сторонам в определенном контексте, путём выявления потребностей и обоснования решений, описывающих возможные пути реализации этих изменений.
Бизнес-аналитик, в свою очередь, — это любой человек, который занимается бизнес-анализом :-)
Зачем вообще говорить о модели базовых понятий бизнес-анализа? Да просто потому что это база! На основании этой модели можно строить практически всю работу бизнес-аналитика в любом проекте. Более того, умение смотреть через призму базовых понятий сильно упрощает работу.
Как видно на рисунке, все понятия тесно связаны между собой, давайте разбираться как именно они связаны!
Если упростить до сути, то зачастую цикл начинается с того, что изменения в контексте приводят к неудовлетворению какой-то потребности. Эта потребность выражается в требованиях, которые фокусируются на ожидаемой ценности. Для получения этой ценности разрабатывается решение, которое внедряется через преднамеренные изменения, приносящие пользу заинтересованным сторонам. После реализации, решение само становится частью контекста, который, в свою очередь, постоянно изменяется, создавая новые потребности и запуская цикл заново и так до бесконечности.
Рассмотрим связь основных понятий между собой подробнее
1. Контекст (Context) – это совокупность фактов и обстоятельств, в окружении которых происходит какое-то событие или существует явление/объект; это то, что нас окружает.
Связь с Потребностями: Потребности зачастую дают о себе знать, когда они перестают удовлетворяться в результате непреднамеренных изменений, чаще всего происходящих во внешнем контексте. Осознание потребности очень сильно зависит от контекста.
Связь с Решениями: Решения по удовлетворению потребностей очень контекстно-зависимы. Одно и то же решение в разных контекстах работает совершенно по-разному. Контекст сильно влияет на выбор решения, часто накладывая ограничения. После реализации, решение само становится частью контекста.
Связь с Ценностью: Польза/ценность решения не абсолютна и сильно зависит от контекста; изменение контекста может сильно изменить или даже обнулить ценность.
Связь с Заинтересованными сторонами: Люди (заинтересованные стороны) являются неотъемлемой частью контекста и оказывают на него непосредственное влияние.
2. Потребности (Needs). Потребность может существовать объективно, независимо от того, выявлена ли она или осознана. Чаще всего потребность дает о себе знать, когда она перестает удовлетворяться. Например потребность в дыхании.
Как определяются: Неудовлетворение потребности происходит, как правило, в результате изменений, происходящих во внешнем контексте.
Переход к Требованиям и Ценности: Осознанная потребность формулируется в виде требования. Требование – это высказанная потребность, которая фокусируется на пользе/ценности, которую человек получит при её реализации.
Связь с Решением: Решение – это то, что позволяет удовлетворить потребность, указанную в требовании.
3. Изменение (Change) – ключевое слово в бизнес-анализе. Главная цель реализации решения — удовлетворение потребности, которое осуществляется через проведение изменения.
◦ Типы и их связь с Контекстом:
▪ Непреднамеренные изменения: Происходят независимо от нашего желания, чаще всего вопреки ему, и происходят во внешнем контексте. Именно эти изменения часто приводят к тому, что существующие потребности перестают удовлетворяться, вызывая их осознание.
▪ Преднамеренные изменения: Это изменения, которые осознанно инициируются для реализации выбранного решения.
◦ Связь с Решением и Ценностью: Преднамеренные изменения позволяют получить пользу/ценность и помогают внедряемому решению реализовать его ценность, максимально удовлетворяя потребность. Изменения, как и решения, должны проводиться с учетом контекста.
4. Решение (Solution) – это то, что позволяет удовлетворить потребность, указанную в требовании.
Как определяются/выбираются: Для удовлетворения одной потребности может существовать множество решений. Выбор решения очень сильно зависит от контекста, который часто накладывает ограничения.
Связь с Изменением: Удовлетворение потребности через решение осуществляется посредством проведения преднамеренных изменений.
Связь с Контекстом: После реализации, решение становится частью повседневной работы организации и переходит в контекст для новых изменений или решений.
Связь с Ценностью: Решение позволяет получить пользу/ценность, ради которой оно было реализовано.
5. Ценность (Value)
Определение: Это значимость, важность или полезность чего-либо для кого-либо (человека, группы людей, компании) в конкретном контексте.
Как определяются: Наиболее стандартным критерием определения ценности решения является то, насколько решение максимально удовлетворяет потребность, ради которой оно было реализовано.
Связь с Требованием: Требование сфокусировано на той пользе/ценности, которую человек получит, когда оно будет реализовано.
Связь с Решением и Изменением: Решение позволяет получить эту ценность. Проведение изменений должно приносить пользу, помогая решению реализовать его ценность.
Связь с Контекстом: Ценность не является абсолютной величиной и сильно зависит от контекста.
6. Заинтересованные стороны (Stakeholders) - те, кому приносятся польза/ценность от изменений, осуществляемых бизнес-анализом.
Как определяются: В определении профессии бизнес-анализа указано, что его деятельность приносит пользу заинтересованным сторонам. Они выражают свои потребности (например, через user story).
Связь с Контекстом: Заинтересованные стороны (люди) являются неотъемлемой частью контекста и оказывают на него непосредственное влияние. Их потребности необходимо учитывать при разработке или выборе решения, так как их неучет может привести к негативным отзывам.
Помимо этого есть «Ключевые понятия» и множество других, но они второстепенны, с ними можно ознакомится самостоятельно.
Рассмотрим использование на практике
Представим что вы работаете БА и к вам прилетает таска на решение какой-то проблемы или реализацию какой-то инициативы, вводных данных мало, приоритет стоит высокий, таска не маленькая и рушит планы спринта
Дальше предлагаю мой вариант простого и понятного чеклиста из уточняющих вопросов на основе базовых понятий БА:
Шаг 0. Собрать больше информации - поставить встречу с автором таски, но к встрече стоит подготовится
Перед тем, как пойти дальше, еще раз вспомним базовые понятия и цепочку из взаимосвязей:
Происходят изменения в контексте - появляется потребность. Для определения потребности разрабатывается требования с фокусом на ценности. Для получения ценности разрабатывается решение. Чтобы решение внедрить надо провести изменения которое должно принести пользу заинтересованным сторонам.
Шаг 1. Выясняем контекст и проблему и заинтересованных сторон:
В чем проблема/потребность?
Проблема/потребность реально есть?
Какие масштабы у проблемы/потребности?
Кто поставил задачу? Инициировал решение проблемы?
Какая потребность у того, кто поставил проблему?
Кого еще затрагивает данная проблема?
Шаг 2. Выяснив потребность/проблему, стоит уточнить какие уже есть предлагаемые варианты решений, если они есть и как они повлияют на скоуп (само решение) и заинтересованных сторон:
Какие есть варианты решений?
На что повлияют изменения?(ПО, бэклог, стейкхолдеры, метрики и т.д..)?
На что мы хотим повлиять решением? (решить инцидент, разработать фичу и увеличить конкретную метрику на №%)
Решение несет измеримую бизнес пользу/ценность?
Шаг 3. Анализ информации и принятие решения
1. Выделить и ценить реальную проблему, убедится что инициатор/стейкхолдер понимает что ему надо. Разработать верхнеуровневые сценарии решения проблем и прийти к ЛПРам (в моей работе это обычно Продакт и Проджект у вас может быть ваш Шеф), с описанием задачи, потребностями и возможными решениями.
2. Собрать общую встречку — описать ситуацию — принять решение (Либо на встрече либой уйти на доработку).
Если очень сильно упростить, то можно ограничится 4 вопросами:
Какую проблему мы решаем? (Что не так?)
Проблема реально есть? (Что-то реально не так?)
На какую метрику мы хотим повлиять решением? (Что хотим получить?)
Мы изменим ситуацию предлагаемым решением? (Мы получим это существующим решением?)
Кейс
Представьте, что вы продакт интернет-магазина косметики. Однажды открываете дашборд и видите, что количество посетителей сайта упало на 17%.
Шаг 1. Понять что за проблема, есть ли она действительно и в чем конкретно заключается! (Контекст, потребности,)
1: Проверить все ли хорошо технически:
- Проверка логов аналитики и пайплайнов, которые формируют дашборд
- Что на фронте и бэке, мб что-то не так
2: Разобраться что происходит с продуктом:
- Пользователь: какой сегмент или когорта проседает
- Сущность продукта: локализация на каком экране, типе баннеров наблюдается проблема
- Что запускали другие команды, что могло вызвать изменение трафика
3: Оценить влияние внешней среды:
- Праздники, события, новости
- Период промо-кампаний
Этапы можно параллелить разумеется
Шаг 2. Какие есть предполагаемые решения, повлияют ли они на достижение целевого показателя посетителей сайта?
Представим, что мы все проанализировали, и поняли что просел сегмент посетителей мужчин, потому что сейчас 9 марта и они уже подарили своим дамам косметику;
В таком случае это надо аргументировать циферками, и доказать сезонность - прийти к боссу, и указать что это не проблема, а сезонность - решение не нужно, ресурсы сэкономлены, вы молодец!)
На этом все, надеюсь было интересно и полезно, если есть комментарии или замечаний велком, буду рад услышать все мнения!)
Что еще рекомендую почитать и посмотреть на тему самостоятельно:
BABOK v3 - куда же без этой рекомендации)