Бизнес-аналитик: роль, задачи и практический анализ

Кто такой бизнес-аналитик и какую ценность он создаёт

Зачем бизнесу нужен бизнес-аналитик

Бизнес-аналитик (BA, business analyst) помогает компании понять, какую проблему нужно решать, почему её нужно решать именно сейчас и как описать решение так, чтобы команда могла реализовать его без лишних догадок и переделок.

Если упростить: бизнес-аналитик переводит потребности бизнеса и пользователей на язык понятных требований, процессов и решений.

Один из широко используемых профессиональных ориентиров в профессии — руководство IIBA BABOK (Business Analysis Body of Knowledge): IIBA BABOK.

Определение роли простыми словами

Бизнес-аналитик — это специалист, который:

Выясняет цели и ограничения (что нужно получить и что мешает)

Находит истинную проблему, а не только её симптомы

Согласует ожидания разных заинтересованных сторон

Описывает требования к изменению: в продукте, процессе, сервисе или системе

Помогает проверить, что сделанное решение действительно принесло пользу

Важно: бизнес-аналитик не обязательно пишет код и не обязательно управляет проектом. Он отвечает за ясность потребности и качество формулировки решения.

Чем бизнес-аналитик отличается от смежных ролей

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

| Роль | Главный фокус | Типичные вопросы | |---|---|---| | Бизнес-аналитик | Ценность и требования к изменению | Что именно нужно изменить и зачем? Как поймём, что стало лучше? | | Продакт-менеджер | Продуктовая стратегия и приоритизация | Какая функция даст максимальный эффект? Что делать раньше, что позже? | | Проектный менеджер | Сроки, бюджет, ресурсы, координация | Как уложиться в план и довести до релиза? | | Системный аналитик | Техническая детализация решения | Как это реализовать в системе? Какие интеграции и данные нужны? | | UX-исследователь/дизайнер | Пользовательский опыт | Как пользователи действуют? Где им неудобно? |

В реальности роли могут пересекаться, особенно в небольших компаниях. Но ценность бизнес-аналитика проявляется именно в прояснении и согласовании потребности.

Какие задачи решает бизнес-аналитик

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

Сбор информации: интервью, наблюдение, анализ документов и данных

Формулирование проблем и целей: что хотим улучшить и почему

Моделирование текущего состояния: как процесс работает сейчас (as-is)

Проектирование целевого состояния: как процесс должен работать (to-be)

Описание требований: что должна уметь система/процесс, какие есть ограничения

Согласование требований со стейкхолдерами и командой

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

Оценка результата: достигли ли цели, какие метрики изменились

!Схема показывает типовой цикл работы бизнес-аналитика от цели до проверки результата

Какую ценность создаёт бизнес-аналитик

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

Снижение переделок и потерь времени

Когда требования расплывчаты, команда строит «то, что поняла», а не «то, что нужно». Бизнес-аналитик уменьшает риск переделок за счёт:

уточнения терминов и правил

фиксации границ решения (что входит, а что нет)

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

Повышение прозрачности и управляемости изменений

Бизнес-аналитик помогает компании видеть процесс и проблему:

где узкие места

кто влияет на результат

какие данные нужны для решения

какие есть зависимости и риски

Рост бизнес-эффекта

Хороший анализ помогает выбрать решение, которое даёт измеримый эффект, например:

уменьшение времени обработки заявки

снижение числа ошибок

рост конверсии

снижение стоимости операции

Здесь важно различать:

результат (например, «выпустили новую форму заказа»)

эффект (например, «конверсия выросла на 8%»)

Бизнес-аналитик фокусирует команду на эффекте.

Примеры из жизни: что делает бизнес-аналитик на практике

Ниже — несколько типичных ситуаций, где ценность анализа хорошо видна.

Пример: интернет-магазин и «падает конверсия»

Запрос бизнеса: «Сделайте кнопку Купить заметнее — у нас упала конверсия».

Что делает бизнес-аналитик:

Уточняет, где именно падает конверсия: карточка товара, корзина, оплата, доставка.

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

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

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

Согласует критерии успеха: например, «доля успешных оплат +5%» и «снижение отказов на шаге доставки на 10%».

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

Пример: банк и очередь в отделении

Запрос: «Нужно больше сотрудников в часы пик».

Что делает бизнес-аналитик:

Описывает процесс обслуживания клиентов.

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

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

Ценность: снижение нагрузки и времени ожидания без постоянного увеличения штата.

Что именно «производит» бизнес-аналитик (артефакты)

Артефакты зависят от компании и подхода (waterfall/agile), но чаще всего встречаются:

Описание проблемы, цели и границ (scope)

Карта стейкхолдеров

Модели процессов as-is и to-be

Требования (пользовательские, бизнес-правила, ограничения)

User stories и критерии приемки (в agile-командах)

Прототипы или схемы экранов (на уровне согласования логики)

Словарь терминов (единые определения)

Ключевая мысль: документы не самоцель. Самоцель — общее понимание и проверяемая ценность.

Кому и где особенно нужен бизнес-аналитик

Бизнес-аналитик особенно полезен, когда:

много заинтересованных сторон и у всех разные ожидания

процесс сложный и пересекает отделы

высокая цена ошибки (финансы, медицина, безопасность)

нужно менять систему, но «никто не может толком объяснить, что должно получиться»

компания растёт, и хаос договорённостей начинает мешать

Частые заблуждения о бизнес-аналитике

«Бизнес-аналитик просто пишет ТЗ». ТЗ — лишь возможная форма фиксации. Главная работа — выяснить потребность и согласовать решение.

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

«Это роль только для IT». Анализ нужен и вне IT: в операционке, логистике, сервисе, продажах.

Минимальная модель мышления бизнес-аналитика

Полезная опорная конструкция для старта — цепочка:

Проблема или возможность

Цель (что хотим улучшить)

Метрики успеха (как поймём, что улучшили)

Варианты решений (несколько)

Требования к выбранному варианту

Проверка результата после внедрения

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

Что будет дальше в курсе

Дальше мы разберём:

как выявлять и фиксировать потребности стейкхолдеров

как описывать процессы as-is и проектировать to-be

как формулировать требования и критерии приемки

как превращать анализ в решения, которые дают измеримый эффект

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

Зачем бизнес-аналитику бизнес-контекст

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

Бизнес-контекст — это связка:

цели (зачем бизнесу изменения)

процессы (как работа устроена сейчас и как должна быть устроена)

метрики (как измерим успех и побочные эффекты)

заинтересованные стороны (кто влияет на решение, кто пользуется, кто отвечает)

Если контекст не прояснён, команда часто:

решает не ту проблему (симптом вместо причины)

улучшает не то место в процессе

выбирает метрику, которую легко «нарисовать», но которая не отражает пользу

конфликтует из-за непонимания, кто принимает решение и чьи интересы важны

Цели: что именно хотим улучшить

Цель, проблема и результат

В работе часто путают три разных формулировки:

Проблема — что болит сейчас (например, «клиенты часто бросают оформление заказа на доставке»)

Цель — какое улучшение нужно получить (например, «снизить долю отказов на шаге доставки»)

Результат (output) — что будет сделано (например, «реализовать выбор интервалов доставки и показать стоимость раньше»)

Бизнес-аналитику важно удерживать логику:

цель отвечает на вопрос зачем

результат отвечает на вопрос что сделаем

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

Как формулировать цель без размытости

Практичная техника — критерии SMART (часто используются в бизнесе, хотя не являются «единственным стандартом»): SMART criteria.

Проверка цели по смыслу:

конкретность: что именно улучшаем

измеримость: чем измерим

реалистичность: достижимо ли с текущими ресурсами

срок: когда оценим результат

Пример плохой цели:

«Сделать оформление заказа удобнее»

Пример лучше:

«За 6 недель снизить долю отказов на шаге выбора доставки с 18% до 14%, не увеличив среднее время оформления более чем на 10 секунд»

Здесь сразу видно, что именно измеряем, и добавлено ограничение (не ухудшать скорость).

Цели разных уровней: от стратегии до задачи

Цели бывают на разных «высотах»:

стратегические (например, рост доли рынка)

тактические (например, увеличить повторные покупки)

операционные (например, сократить время обработки заявки)

В продуктовых компаниях часто используют OKR (Objectives and Key Results): OKR. Для бизнес-аналитика полезна не сама методика, а принцип: у цели должны быть ключевые измеримые результаты.

Процессы: как создаётся результат

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

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

У процесса почти всегда есть:

триггер (что запускает процесс)

шаги (кто что делает)

роль/владелец (кто отвечает за результат)

входы и выходы

правила (например, «скидка доступна только при сумме заказа от…»)

исключения (что делаем, если что-то пошло не так)

Зачем описывать as-is и to-be

В анализе часто используют два состояния процесса:

as-is — как работает сейчас

to-be — как должно работать после изменений

Ценность разделения в том, что вы:

видите реальные узкие места (а не предположения)

понимаете, что именно меняется и где появятся новые риски

можете оценить влияние на разные роли и системы

!Сравнение процесса as-is и to-be на примере оформления доставки

Какую глубину процесса выбирать

Типичная ошибка — либо рисовать «слишком верхне» (ничего не понятно), либо «слишком глубоко» (тонете в деталях).

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

где появляется проблема

кто принимает решения на ключевых шагах

какие данные нужны

какие шаги нужно изменить

Для фиксации процессов используются разные нотации (способы рисования). Одна из распространённых — BPMN: BPMN. В курсе важнее не «идеальная нотация», а ясность логики.

Метрики: как понять, что стало лучше

Метрика, KPI и «сигнал»

Чтобы не путаться:

метрика — любой измеримый показатель (например, «время оформления заказа»)

KPI — метрика, по которой оценивают достижение цели (часто привязана к ответственности)

сигнал — вспомогательный показатель, который помогает понять причину (например, «сколько раз пользователи меняли способ доставки»)

Бизнес-аналитик помогает выбрать метрики так, чтобы они отражали цель, а не просто были «красивыми цифрами».

Хорошая метрика должна быть определена

Чтобы метрика была полезной, обычно фиксируют:

определение (что именно считаем)

формат расчёта словами (как считаем)

период (за день, неделю, месяц)

источник данных (аналитика, CRM, журнал обращений)

базовую линию (текущее значение)

целевое значение (к чему стремимся)

Пример: «Доля отказов на шаге доставки»

определение: процент пользователей, которые ушли со страницы доставки и не завершили заказ в течение 24 часов

период: неделя

источник: события веб-аналитики

базовая линия: 18%

цель: 14%

Ведущие и запаздывающие метрики

Полезно различать:

запаздывающие (показывают итог) — например, выручка, конверсия в покупку

ведущие (намекают на будущий итог) — например, доля пользователей, которые дошли до оплаты

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

Защитные метрики: чтобы улучшение не сломало другое

Иногда улучшая одну метрику, вы ухудшаете другую. Поэтому часто добавляют защитные метрики (их ещё называют guardrails): показатели, которые нельзя «провалить».

Пример:

цель: снизить отказы на шаге доставки

защитная метрика: «среднее время оформления заказа» не должно вырасти более чем на 10 секунд

Пример связки «цель → метрика → данные»

| Цель | Метрика | Как понимаем метрику | Источник | |---|---|---|---| | Уменьшить отказы на шаге доставки | Доля отказов на шаге доставки | Пользователь ушёл со страницы доставки и не оформил заказ за 24 часа | Веб-аналитика | | Ускорить обслуживание заявок | Среднее время обработки заявки | Время от «заявка зарегистрирована» до «решена» | Service desk/CRM | | Снизить ошибки в документах | Доля возвратов на исправление | Сколько документов вернули из-за ошибок / всего документов | Учётная система |

Заинтересованные стороны: кто влияет на решение

Кто такие заинтересованные стороны

Заинтересованные стороны (стейкхолдеры) — это люди или группы, которые:

получают пользу или ущерб от изменений

влияют на требования и приоритеты

принимают решения или дают согласования

будут пользоваться результатом

Важно: стейкхолдер — не только «заказчик». Например, в изменении процесса возврата товара стейкхолдерами будут:

клиент

поддержка

склад

финансы

доставка

юридическая функция

IT-команда

Зачем бизнес-аналитику карта стейкхолдеров

Она помогает:

не забыть важные роли

понять, у кого какая цель и боль

заранее увидеть конфликт интересов

выстроить коммуникации: кого интервьюировать, кого приглашать на воркшоп, с кем согласовывать

Как быстро оценить влияние: матрица «влияние/интерес»

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

влияние: насколько человек может продвинуть или заблокировать решение

интерес: насколько человеку важно изменение

!Матрица стейкхолдеров для выбора стратегии коммуникации

Роли и ответственность: RACI простыми словами

Чтобы не было «мы думали, это делает другой», применяют RACI — таблицу ответственности:

R (Responsible) — выполняет работу

A (Accountable) — несёт итоговую ответственность и принимает финальное решение

C (Consulted) — консультирует, даёт входные данные

I (Informed) — должен быть в курсе

Бизнес-аналитик не обязан «внедрять RACI в компании», но может использовать принцип, чтобы уточнить, кто:

владеет процессом

утверждает требования

принимает решение при конфликте

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

Удобная логика работы бизнес-аналитика выглядит так:

Сформулировать проблему и цель вместе со стейкхолдерами

Выбрать метрики успеха и защитные метрики

Описать процесс as-is, найти узкие места

Предложить варианты to-be (минимум 2–3), оценить влияние на стейкхолдеров и метрики

Зафиксировать выбранный вариант и требования к нему

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

Мини-шаблоны фиксации контекста

Эти шаблоны можно вести в Confluence/Google Docs/Notion — формат не важен, важна структура.

Карточка цели

| Поле | Пример | |---|---| | Проблема | Высокие отказы на шаге доставки | | Цель | Снизить отказы на шаге доставки | | Почему сейчас | Потери выручки растут, сезонный пик | | Ограничения | Не увеличивать время оформления > 10 секунд | | Срок проверки | Через 6 недель после релиза |

Карточка метрик

| Поле | Пример | |---|---| | Метрика успеха | Доля отказов на шаге доставки | | Определение | Ушёл со страницы доставки и не оформил заказ за 24 часа | | Источник | Веб-аналитика | | Базовая линия | 18% | | Цель | 14% | | Защитная метрика | Среднее время оформления заказа |

Карточка процесса

| Поле | Пример | |---|---| | Название процесса | Оформление заказа | | Триггер | Пользователь нажал «Оформить» | | Выход | Созданный заказ + успешная оплата | | Участники | Клиент, сайт, платёжный провайдер, склад | | Узкие места | Доставка: цена и сроки видны слишком поздно | | Исключения | Нет доставки по адресу, ошибка оплаты |

Карта стейкхолдеров

| Стейкхолдер | Интерес | Влияние | Что важно | Формат взаимодействия | |---|---|---|---|---| | Руководитель e-commerce | Высокий | Высокое | Выручка, конверсия | Еженедельное согласование | | Поддержка | Высокий | Среднее | Снижение обращений | Интервью + пилот | | Логистика | Средний | Высокое | Реалистичные интервалы | Воркшоп правил | | Клиенты | Высокий | Низкое | Понятные сроки/цены | Тестирование прототипов |

Типичные ошибки при работе с контекстом

Начинать с решения («давайте добавим кнопку/поле/интеграцию»), не зафиксировав цель и метрики.

Подменять цель результатом («сделать новый экран» вместо «снизить ошибки/ускорить процесс»).

Описать процесс без исключений: именно исключения часто создают нагрузку и ошибки.

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

Не выделить владельца процесса и финального решающего: требования «повисают».

Что дальше в курсе

Дальше мы будем углублять практику:

как выявлять потребности стейкхолдеров через интервью и наблюдение

как описывать процессы as-is так, чтобы находить узкие места

как превращать цели и контекст в требования и критерии приёмки, понятные команде

Сбор требований: интервью, воркшопы, наблюдение и анализ документов

Как эта тема связана с предыдущими статьями

В первых статьях курса мы закрепили две опоры:

бизнес-аналитик создаёт ценность, проясняя потребность и переводя её в требования и критерии результата

качественный анализ начинается с бизнес-контекста: цели, процессы, метрики и заинтересованные стороны

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

Сбор требований (часто говорят выявление требований или elicitation) — это управляемый процесс получения информации от людей и из источников (данные, документы, процессы), чтобы:

понять проблему и причины

уточнить цели и ограничения

собрать бизнес-правила и исключения

описать, что должно измениться

Важно: бизнес-аналитик собирает не только «список хотелок», а проверяемые требования, привязанные к цели и метрикам.

Что такое требования простыми словами

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

Бизнес-требования: зачем нужно изменение (цель, ценность)

Пользовательские требования: что нужно пользователю для выполнения задачи

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

Нефункциональные требования: каким должно быть качество (скорость, безопасность, доступность)

Ограничения: что нельзя нарушать (закон, бюджет, сроки, технологии)

Бизнес-правила: условия и логика (скидки, проверки, маршрутизация заявок)

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

!Схема показывает, как контекст превращается в требования через методы сбора

Общий цикл сбора требований

Практичный цикл выглядит так:

Определить цель сбора: что нужно понять и для чего (привязка к бизнес-цели и метрикам).

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

Подготовить материалы: вопросы, гипотезы, текущие документы, данные.

Провести сессии (интервью/воркшоп/наблюдение) и собрать документы.

Зафиксировать результат в понятной структуре.

Проверить и согласовать: правильно ли поняли, нет ли противоречий.

Управлять изменениями требований: что поменялось и почему.

Ключевой принцип: сбор и согласование — разные шаги. На встрече вы добываете информацию, а после — структурируете и возвращаете её на проверку.

Интервью со стейкхолдерами

Когда интервью особенно подходит

Интервью полезно, когда:

нужно глубоко понять мотивацию, боли, исключения

есть конфликт интересов и важно выслушать стороны отдельно

процесс сложный и знания распределены по людям

требуется быстро собрать картину для первичного анализа

Подготовка к интервью

Сильное интервью начинается до встречи.

Сформулируйте цель: что вы должны узнать в результате.

Определите роль респондента: как он связан с процессом и решением.

Подготовьте контекст: цель изменения, границы, определения терминов.

Составьте сценарий вопросов (но оставьте место для уточнений).

Продумайте фиксацию: заметки, запись (только с явного согласия), шаблон.

Структура интервью

Удобная структура на 30–60 минут:

Вводная часть: цель встречи, как будете фиксировать, что будет результатом.

Контекст: чем человек занимается, какой участок процесса знает.

Основной блок: шаги процесса, проблемы, причины, правила, исключения.

Уточнения: термины, примеры кейсов, что считается «хорошо/плохо».

Завершение: резюме, следующие шаги, кому ещё стоит поговорить.

Типы вопросов, которые дают качество

Чтобы не получить набор общих фраз, используйте разные типы.

Открытые: «Расскажите, как вы оформляете возврат?»

Уточняющие: «Что означает “долго”? 2 часа или 2 дня?»

Процессные: «Что происходит после того, как заявка создана?»

Про исключения: «А что делаете, если клиент не отвечает?»

Про правила: «По каким условиям заявка уходит на ручную проверку?»

Про метрики: «Как вы понимаете, что стало лучше? Чем это измеряется?»

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

Как фиксировать результаты интервью

Надёжная фиксация обычно включает:

факты о процессе (шаги, входы/выходы)

проблемы и примеры конкретных случаев

бизнес-правила и исключения

термины (как люди называют одно и то же)

потребности и ожидания

риски и ограничения

вопросы, которые остались открыты

Чтобы не было эффекта «я говорил другое», отправляйте краткое резюме на подтверждение: что услышали, какие решения/вопросы.

Частые ошибки в интервью

Приходить без цели и задавать вопросы «в целом расскажите».

Спорить и доказывать вместо уточнения и проверки.

Записывать только «хотелки», игнорируя правила и исключения.

Пропускать определения терминов (потом выясняется, что все понимали по-разному).

Воркшопы (групповые сессии)

Зачем нужны воркшопы

Воркшоп — это управляемая групповая работа, где вы:

быстро выравниваете понимание между ролями

обнаруживаете противоречия требований на месте

совместно проектируете процесс to-be

договариваетесь о приоритетах и границах

Если интервью — это «глубина», то воркшоп — это «согласование и скорость».

Когда воркшоп лучше интервью

Воркшоп особенно эффективен, когда:

процесс пересекает несколько отделов

нужно согласовать правила и точки ответственности

требования противоречат друг другу

требуется совместно выбрать вариант решения

Роли на воркшопе

Фасилитатор (часто BA): ведёт процесс обсуждения, следит за временем и структурой

Эксперты процесса: знают реальную работу и исключения

Лицо, принимающее решение: закрывает спорные вопросы

Секретарь (может быть BA): фиксирует решения и открытые вопросы

Как подготовить воркшоп

Определите цель и ожидаемый результат: например, «согласовать процесс to-be обработки заявок и правила маршрутизации».

Подберите участников так, чтобы были покрыты ключевые участки процесса.

Подготовьте материалы: текущий процесс as-is, список спорных вопросов, данные, ограничения.

Сформируйте повестку с таймингом и отправьте заранее.

Подготовьте правила: как принимаются решения, где фиксируем договорённости.

Типовой сценарий воркшопа

Контекст: цель, границы, критерий успеха (метрика), правила работы.

Выравнивание по as-is: быстрый проход по текущему процессу и болям.

Генерация вариантов to-be: 2–3 альтернативы, без ранней критики.

Выбор: оценка влияния на метрики, риски, стоимость изменений.

Фиксация решений: правила, исключения, открытые вопросы, владелец каждого вопроса.

Полезные техники для воркшопов:

мозговой штурм для генерации вариантов

аффинити-диаграмма для группировки идей: Аффинити-диаграмма

приоритизация MoSCoW (Must/Should/Could/Won’t): MoSCoW

Как защищаться от хаоса на воркшопе

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

Разделяйте «обсуждаем» и «решили»: решения фиксируйте в явном виде.

Возвращайте к метрикам: «как это влияет на цель и на защитные метрики?»

Наблюдение (shadowing) и разбор реальных кейсов

Что такое наблюдение

Наблюдение — когда аналитик смотрит, как люди реально выполняют работу, а не как они её описывают. Часто это называют shadowing (вы как “тень” рядом с исполнителем).

Наблюдение особенно полезно, потому что в интервью люди:

пропускают «очевидные» шаги

забывают исключения

описывают «как должно быть», а не «как есть»

Когда наблюдение даёт максимальную пользу

Наблюдение стоит выбрать, если:

процесс операционный и повторяемый (колл-центр, бэк-офис, склад)

много ручных действий и переключений между системами

много ошибок, возвратов, дублирования данных

есть подозрение на «теневые» инструменты (таблички, заметки, мессенджеры)

Как проводить наблюдение корректно

Согласуйте цели и правила: что вы фиксируете, как защищаете данные.

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

Фиксируйте шаги, входы/выходы, решения и причины.

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

Сразу отмечайте проблемы и гипотезы причин.

Что именно фиксировать в наблюдении

Что является триггером (с чего начинается работа).

Какие системы и источники используются.

Где происходит ручной перенос данных.

Какие проверки и правила применяются.

Где исполнитель ждёт (согласование, ответ, зависимость).

Какие исключения встречаются и как их обходят.

Наблюдение хорошо связывается с описанием процесса as-is, о котором мы говорили ранее, и помогает точнее найти узкие места.

Анализ документов и существующих источников

Какие документы могут быть полезны

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

регламенты и инструкции

шаблоны договоров, заявлений, писем

политики безопасности и доступа

требования законодательства и внутреннего контроля

отчёты по инцидентам, обращения в поддержку

спецификации интеграций, описание полей, справочники

backlog, старые ТЗ, релиз-ноты

Риски документного анализа

Документы могут быть устаревшими.

Документы могут описывать «идеальный» процесс, который не совпадает с реальностью.

Документы часто не содержат исключений и неявных практик.

Поэтому документы лучше использовать как:

стартовую рамку для интервью

проверку полноты и соответствия требованиям (комплаенс)

источник терминов и правил

Быстрый чек-лист качества документа как источника требований

Дата актуальности и владелец документа

Связь с реальными системами и формами

Наличие исключений и альтернативных сценариев

Наличие определений терминов

Наличие критериев «сделано/не сделано»

Как выбирать метод: практичная логика

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

Если цель — быстро понять картину и роли, начните с интервью.

Если цель — согласовать изменения между отделами, используйте воркшоп.

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

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

Таблица подсказка:

| Ситуация | Лучший метод | Почему | |---|---|---| | Нужно понять мотивацию и «боли» роли | Интервью | Глубина и детали | | Требования противоречат, нужно договориться | Воркшоп | Согласование в группе | | Процесс «как есть» неизвестен или искажён | Наблюдение | Видно реальную работу | | Много правил/комплаенса | Документы + интервью | Правила должны быть подтверждены |

Как превращать собранное в требования, понятные команде

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

Минимальные артефакты после сбора

Список стейкхолдеров и договорённости по коммуникациям.

Описание процесса as-is с болями и исключениями.

Черновик to-be или варианты решения (если уже обсуждали).

Список требований, сгруппированный по темам.

Словарь терминов (хотя бы 10–20 ключевых терминов).

Открытые вопросы и риски.

Пример: как фраза превращается в требование

Фраза стейкхолдера:

«Сделайте так, чтобы менеджеры быстрее обрабатывали заявки»

Уточнение аналитика:

Что значит «быстрее» (метрика, базовая линия, цель).

Где теряется время (шаги процесса, ожидания, ручной ввод).

Какие ограничения (проверки безопасности, обязательные поля).

Результат в виде требований:

Бизнес-цель: сократить среднее время обработки заявки с 2 дней до 1 дня.

Функциональное требование: система должна автоматически подставлять данные клиента из CRM при вводе ИНН.

Бизнес-правило: заявки от клиентов с определёнными признаками должны уходить на дополнительную проверку.

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

Этика, доверие и качество коммуникации

Сбор требований — это работа с людьми, поэтому важны базовые правила.

Не обещайте то, что не вы решаете (аналитик фиксирует потребности, но не всегда утверждает приоритет).

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

Не «вытаскивайте» информацию обманом: запись — только с согласия.

Разделяйте факты, мнения и предположения.

Что дальше в курсе

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

Для профессионального ориентира по терминологии и практикам бизнес-анализа полезно знать руководство IIBA BABOK: IIBA BABOK.

Моделирование и описание: user story, use case, BPMN и простые схемы

Зачем бизнес-аналитику моделирование и описание

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

Моделирование нужно, чтобы:

снизить неоднозначность: разные люди читают один текст по-разному

увидеть пробелы: какие шаги, роли, данные или исключения не учтены

согласовать ожидания: зафиксировать, что именно считаем решением

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

Связь с предыдущими темами курса выглядит так:

Вы выяснили зачем и что измеряем (цели и метрики).

Поняли кто вовлечён и где болит (стейкхолдеры и процесс as-is).

Собрали информацию (elicitation).

Теперь вы оформляете её в формы, которые позволяют команде строить решение и проверять, что оно ведёт к цели.

Принципы хорошего описания

Перед тем как выбирать формат (user story, use case, BPMN), полезно держать несколько принципов.

Один артефакт — одна цель: схема процесса для обсуждения шагов, таблица правил для логики, user story для планирования разработки.

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

Ясная граница: что входит в изменения, а что нет.

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

Проверяемость: у описания есть критерии, по которым можно принять результат.

User story

Что такое user story

User story — короткое описание потребности пользователя, которое удобно планировать и обсуждать в agile-командах. Классическая формулировка:

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

Ссылка для ориентира: User story.

Чем user story полезна бизнес-аналитику

User story помогает:

удерживать фокус на ценности, а не на интерфейсных деталях

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

связывать обсуждения с конкретными сценариями и критериями приёмки

Пример из жизни: доставка в интернет-магазине

Контекст (из предыдущей статьи про цели и метрики): цель — снизить отказы на шаге доставки.

Пример user story:

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

Но одной истории мало. Нужны критерии приёмки, иначе она останется «хотелкой».

Критерии приёмки

Критерии приёмки — проверяемые условия, при которых история считается выполненной.

Пример критериев приёмки к истории про доставку:

Если пользователь ввёл город и индекс, система показывает доступные способы доставки.

Для каждого способа доставки отображаются стоимость и ближайший интервал.

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

Отображение вариантов доставки происходит не дольше 2 секунд при нормальной нагрузке.

Критерии можно записывать обычным списком или в стиле Gherkin.

Типичные ошибки с user story

История описывает решение, а не потребность: «добавить выпадающий список».

Нет ценности: непонятно, зачем пользователю это нужно.

Нет критериев приёмки: разработка и тестирование интерпретируют по-разному.

История слишком крупная: её невозможно реализовать и проверить за разумный цикл.

Use case

Что такое use case и когда он лучше user story

Use case (сценарий использования) — более строгий формат описания взаимодействия акторов и системы, с основным сценарием и альтернативами.

Ссылка для ориентира: Use case.

Use case особенно полезен, когда:

много исключений и ветвлений

несколько акторов (пользователь, оператор, внешняя система)

высокая цена ошибки (финансы, безопасность, регуляторика)

важно формально договориться о предусловиях и результатах

Шаблон use case

Ниже — практичный минимальный шаблон.

| Поле | Что фиксируем | |---|---| | Название | Суть сценария в одном действии | | Цель | Какую задачу решает актор | | Акторы | Кто взаимодействует с системой | | Предусловия | Что должно быть истинно до начала | | Триггер | Что запускает сценарий | | Основной сценарий | Нумерованные шаги «счастливого пути» | | Альтернативы и исключения | Ветвления, ошибки, редкие случаи | | Постусловия | Что должно быть истинно после завершения |

Пример из жизни: возврат товара

Use case: Оформить возврат товара через личный кабинет.

| Поле | Пример | |---|---| | Цель | Клиент инициирует возврат и получает инструкции | | Акторы | Клиент, Система интернет-магазина, Служба доставки | | Предусловия | Заказ доставлен, срок возврата не истёк | | Триггер | Клиент нажал «Оформить возврат» |

Основной сценарий:

Клиент выбирает заказ и товар для возврата.

Система проверяет право возврата по правилам.

Клиент выбирает причину возврата и способ передачи товара.

Система формирует номер возврата и инструкции.

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

Альтернативы и исключения:

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

Если товар относится к невозвратным категориям, система показывает правила и альтернативный процесс.

Если выбран способ «курьер», но адрес недоступен, система предлагает пункты выдачи.

Постусловия:

В системе создана заявка на возврат с номером и статусом.

Диаграмма прецедентов как быстрый обзор

Иногда используют UML-диаграмму прецедентов как «карту» возможностей на верхнем уровне.

Ссылка для ориентира: Use case diagram.

!Пример верхнеуровневой карты сценариев возврата

BPMN

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

BPMN — распространённый стандарт для моделирования бизнес-процессов.

Ссылка для ориентира: BPMN.

BPMN особенно полезна, когда:

процесс пересекает отделы и роли

нужно договориться о границах ответственности

важно показать передачи работы, ожидания и разветвления

нужно связать изменения системы с изменениями процесса

Базовые элементы BPMN простыми словами

Для старта достаточно понимать несколько элементов.

Событие: что началось или закончилось (старт, завершение).

Задача: действие, которое выполняет роль или система.

Шлюз: точка ветвления по условию.

Пул и дорожки: участники процесса и разделение ответственности.

Пример: процесс обработки заявки as-is и to-be

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

!Пример BPMN-схемы процесса с узким местом ожидания

Практичные советы по BPMN, чтобы не утонуть

Начинайте с as-is, иначе вы не докажете, что именно улучшаете.

Рисуйте только то, что помогает ответить на вопросы цели и метрик.

Обязательно фиксируйте исключения, которые создают нагрузку.

Подписывайте условия на ветвлениях человеческим языком.

Простые схемы, которые часто эффективнее «больших нотаций»

Иногда вам не нужен полноценный BPMN или use case на страницу. Часто быстрее и понятнее работают простые схемы.

Контекстная схема (граница системы)

Контекстная схема отвечает на вопрос: что внутри изменения, а что снаружи.

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

!Контекстная схема: граница системы и внешние взаимодействия

Блок-схема (flowchart) для логики шага

Блок-схема удобна для описания логики одного фрагмента, например проверки данных или маршрутизации заявки.

плюс: быстро читается

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

Таблица решений (decision table) для бизнес-правил

Когда много условий и комбинаций, текст становится опасным. Таблица решений делает правила проверяемыми.

Пример: правила «нужна ли ручная проверка заявки».

| Условие | Вариант A | Вариант B | Вариант C | |---|---|---|---| | Клиент новый | Да | Нет | Нет | | Сумма заказа > 50 000 | Нет | Да | Нет | | Есть подозрение на риск | Нет | Нет | Да | | Решение | Ручная проверка | Ручная проверка | Ручная проверка |

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

Словарь терминов и модель данных на минимальном уровне

Даже простой список терминов часто спасает проект от разночтений.

«Заявка» и «Обращение» — это одно и то же или разные сущности?

«Доставка» — это метод, тариф или конкретная отгрузка?

Минимальный артефакт:

термин

определение

источник истины (где хранится)

Как выбрать формат: user story, use case, BPMN или простая схема

Выбор зависит от цели коммуникации и сложности.

| Ситуация | Что выбрать | Почему | |---|---|---| | Нужно планировать разработку по небольшим ценностям | User story + критерии приёмки | Удобно для backlog и тестирования | | Много исключений, акторов, высокая цена ошибки | Use case | Структурирует сценарии и альтернативы | | Процесс пересекает отделы, важны передачи работы и ожидания | BPMN | Хорошо показывает поток и ответственность | | Нужно быстро согласовать границу и интеграции | Контекстная схема | Сразу видно, что внутри и с кем связываемся | | Нужно формализовать сложные правила | Таблица решений | Убирает двусмысленность условий |

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

контекстная схема для границы

BPMN для процесса end-to-end

use case для критичных сценариев

user stories для разработки по итерациям

таблицы решений для правил

Как бизнес-аналитик работает с моделями на практике

Типовой рабочий цикл:

Собрать исходные факты (интервью, воркшоп, наблюдение, документы).

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

Пройтись по модели со стейкхолдерами и найти пробелы.

Зафиксировать решения и открытые вопросы.

Превратить согласованное в требования, критерии приёмки и задачи.

Поддерживать актуальность модели при изменении требований.

Частые ошибки моделирования

Модель делается «для галочки», без связи с целью и метриками.

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

Нет явных исключений: потом они «всплывают» на тестировании.

Смешивают as-is и to-be, и участники спорят, «как сейчас».

Нет определений терминов: разные отделы читают одно слово по-разному.

Итог

Моделирование для бизнес-аналитика — это способ превратить контекст и собранные требования в общее понимание, которое можно реализовать и проверить.

User story удерживает фокус на ценности и удобно ложится в планирование.

Use case дисциплинирует сценарии, альтернативы и предусловия.

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

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

Дальше по курсу логичный шаг — научиться превращать модели в структурированные требования, критерии приёмки и управление изменениями, чтобы цель и метрики не «размывались» при реализации.

Анализ данных для BA: гипотезы, сегментация, воронки и A/B-тесты

Зачем бизнес-аналитику анализ данных

В предыдущих статьях мы разобрали, как бизнес-аналитик:

проясняет цель и метрики

понимает процесс as-is и проектирует to-be

собирает требования у стейкхолдеров

фиксирует их в виде user story, use case, BPMN и простых схем

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

Для BA данные чаще всего нужны, чтобы:

уточнить проблему: где именно и у кого именно она проявляется

выбрать, что менять: какие причины вероятнее и где эффект больше

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

оценить результат после внедрения: достигли ли цели и не сломали ли что-то рядом

Важно: бизнес-аналитик не обязан быть дата-сайентистом. Но он должен уметь формулировать вопросы к данным, определять метрики и проверять, что выводы корректны.

Минимальный словарь: данные, события, метрики

События и сущности

В продуктовых и цифровых процессах данные часто устроены так:

сущности: заказ, клиент, заявка, обращение

события: «добавил в корзину», «перешёл к оплате», «заявка создана», «заявка решена»

атрибуты: город, канал, тариф, сумма, тип клиента

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

Метрика и её определение

Метрика должна быть определена так, чтобы её можно было посчитать одинаково разными людьми. Частая минимальная карточка метрики:

название

определение простыми словами

формула расчёта

период

источник данных

Пример простой формулы конверсии:

Где:

— конверсия (conversion rate)

число попыток — сколько пользователей дошли до шага

число успешных действий — сколько пользователей выполнили целевое действие

Если на шаг оплаты дошли 1000 пользователей, а оплатили 820, то , то есть 82%.

Гипотезы: как формулировать и проверять

Что такое гипотеза

Гипотеза — это проверяемое предположение о причине проблемы или о том, какое изменение улучшит метрику.

Сильная гипотеза отвечает на вопросы:

что меняем

для кого (сегмент)

какой эффект ожидаем

почему ожидаем этот эффект

как измерим результат (метрика успеха и защитные метрики)

Практичный шаблон гипотезы для BA

Удобная формулировка:

Если мы сделаем изменение X для сегмента Y, то метрика Z улучшится, потому что причина/механизм.

Пример из жизни (интернет-магазин):

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

Гипотезы «про продукт» и «про процесс»

Для BA важно различать два частых типа:

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

процессная гипотеза: изменение маршрутизации, ролей, правил, SLA

Пример процессной гипотезы (служба поддержки):

Если мы автоматически маршрутизируем обращения с темой «не проходит оплата» на линию L2, то среднее время решения снизится, потому что L1 всё равно эскалирует эти кейсы, теряя время на лишнюю переписку.

Что делает BA, чтобы гипотеза была проверяемой

BA обычно уточняет:

текущую базовую линию метрики (baseline)

целевое изменение (target)

срок измерения

защитные метрики (чтобы улучшение не ухудшило другое)

ограничения (закон, безопасность, бюджет)

Результат полезно фиксировать в карточке гипотезы.

| Поле | Пример | |---|---| | Проблема | Высокие отказы на шаге доставки | | Гипотеза | Ранний показ сроков/стоимости снизит отказы | | Сегмент | Пользователи из регионов | | Метрика успеха | Доля отказов на шаге доставки | | Защитные метрики | Среднее время оформления, число обращений в поддержку | | Ожидаемый эффект | Отказы −10% относительно базовой | | Как проверяем | Воронка + A/B тест |

Сегментация: как понять, у кого болит

Что такое сегментация

Сегментация — это разделение пользователей, заказов или операций на группы, чтобы увидеть, что общий показатель «в среднем» скрывает разные картины.

Без сегментации вы часто получаете ложный вывод:

«конверсия упала»

С сегментацией вы можете увидеть реальную причину:

«конверсия упала только у новых пользователей на мобильных в регионах после изменения условий доставки»

Типовые оси сегментации

Практичные варианты (выбирайте те, что связаны с вашей целью):

канал: SEO, реклама, партнёры

устройство: mobile/desktop/app

география: город/регион

тип клиента: новый/повторный/VIP

продукт/категория: электроника, одежда

тариф/условия: доставка, оплата, подписка

поведение: дошёл до шага N, пользовался функцией X

Сегментация и стейкхолдеры

Сегменты часто соответствуют «зонам ответственности» стейкхолдеров. Например:

логистика отвечает за регионы и сроки

маркетинг отвечает за каналы

поддержка отвечает за обращения и причины

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

Когортный взгляд: сегментация во времени

Когорта — группа, объединённая моментом начала (например, «зарегистрировались в январе» или «первый заказ в неделю 12»).

Когортный анализ полезен, когда нужно отличать:

эффект изменений (релиз, новая политика)

сезонность

«созревание» пользователей (новичок ведёт себя иначе, чем опытный)

!Пример когортного графика: сравнение поведения групп во времени

Воронки: где именно пользователи/операции «падают»

Что такое воронка

Воронка — это последовательность шагов, через которые должен пройти пользователь или операция до целевого результата.

В цифровом продукте это может быть:

просмотр товара → корзина → оформление → оплата → подтверждение

В операционном процессе это может быть:

заявка создана → взята в работу → решена → подтверждена клиентом

Смысл воронки: найти шаг с наибольшими потерями и разбирать причины именно там.

Связь с предыдущими темами курса:

шаги воронки часто напрямую соответствуют шагам процесса as-is (который вы моделировали)

события в данных должны быть согласованы с терминами и требованиями (которые вы собирали)

Как BA специфицирует воронку (чтобы её считали правильно)

Чтобы избежать споров «а вы не так посчитали», BA фиксирует:

названия шагов и их смысл

событие или условие попадания на шаг

окно времени: сколько времени даётся на переход к следующему шагу

правила дедупликации: что делать, если событие произошло несколько раз

сегменты, по которым смотреть воронку

Мини-шаблон:

| Шаг | Определение шага | Окно времени | |---|---|---| | Корзина | событие add_to_cart | 7 дней до покупки | | Оформление | событие checkout_start | 24 часа | | Оплата | событие payment_success | 1 час |

Пример: диагностика проблемы через воронку

Ситуация: «упала выручка». Декомпозиция через воронку помогает локализовать:

трафик не изменился

конверсия в корзину не изменилась

падение на шаге оплаты

Дальше BA добавляет сегментацию:

падение только у оплат картой конкретного банка

И это уже превращается в конкретные требования:

обработка ошибки платёжного провайдера

понятное сообщение пользователю

ретраи платежа

!Иллюстрация воронки с проблемным шагом

Типичные ошибки при работе с воронками

шаги не соответствуют реальному процессу (нет исключений и альтернатив)

шаги определены неоднозначно (разные события, разное окно времени)

смешали разные цели в одну воронку (например, «оплата» и «регистрация»)

смотрят только «среднюю» воронку без сегментации

A/B-тесты: как проверять изменения без споров

Что такое A/B-тест простыми словами

A/B-тест — это эксперимент, где пользователей (или операции) случайно делят на группы и показывают им разные варианты, чтобы сравнить влияние на метрики.

Ориентир по понятию: A/B тестирование.

группа A: контроль (как сейчас)

группа B: вариант с изменением

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

Когда A/B-тест уместен, а когда нет

A/B-тест уместен, когда:

можно разделить поток пользователей или операций

метрика измерима и доступна в данных

риск ограничен (есть защитные метрики и возможность отката)

A/B-тест хуже подходит, когда:

изменения касаются всех (например, новая юридическая оферта)

слишком малый поток (набор данных будет очень долгим)

эффект нельзя измерить корректно (нет событий, нет источника)

В таких случаях используют альтернативы:

сравнение до/после (но осторожно с сезонностью)

пилот на одном филиале/регионе

экспертная оценка + мониторинг метрик после релиза

Что именно должен зафиксировать BA для A/B-теста

BA часто выступает «сшивателем» между бизнесом, продуктом, разработкой и аналитиками данных. Минимум, который важно согласовать:

гипотеза и ожидаемый эффект

первичная метрика успеха (primary metric)

защитные метрики (guardrails)

сегменты (где эффект ожидается сильнее)

критерии остановки: сколько времени идём и при каких условиях заканчиваем

риски и план отката

Пример структуры брифа эксперимента:

| Поле | Пример | |---|---| | Изменение | Показ стоимости доставки на карточке товара | | Гипотеза | Снизит отказы на доставке | | Primary metric | Конверсия из корзины в оплату | | Guardrails | Время загрузки страницы, обращения в поддержку | | Сегменты | Регионы, мобильные устройства | | Длительность | Не меньше 2 недель (чтобы покрыть цикл покупок) | | Риски | Нагрузка на сервис расчёта доставки | | Откат | Фича-флаг: мгновенно выключить показ |

Как интерпретировать результат без глубокой статистики

Чтобы не перегружаться математикой, важно понимать 3 идеи.

Разница метрик между A и B должна быть не только «в цифрах», но и достаточно надёжной, чтобы не быть случайностью.

Надёжность обычно оценивают через понятия статистической значимости и p-value.

p-value — это величина, которая показывает, насколько наблюдаемая разница согласуется с предположением «на самом деле разницы нет».

Справочные понятия:

Статистическая значимость

p-value

Практический вывод для BA: не требуйте «дайте p-value» как самоцель. Требуйте прозрачного ответа:

какая метрика выросла/упала

насколько

в каких сегментах

не ухудшились ли защитные метрики

можно ли раскатить на 100% и какие риски

!Схема устройства A/B-теста и сравнения метрик

Частые ловушки A/B-тестов, о которых BA должен предупреждать

Подмена метрики: улучшили клики, но ухудшили оплату.

Эффект новизны: первые дни пользователи реагируют иначе.

Слишком ранняя остановка: посмотрели результат через 2 дня и сделали вывод.

Множественные проверки: тестируют 20 метрик и «находят» случайные улучшения.

Неучтённая сегментация: общий эффект нулевой, но в важном сегменте сильный минус.

Как связать данные с требованиями и моделями

Хороший BA использует анализ данных не отдельно, а как часть единого контура.

Цель и метрики задают, что именно измерять.

Процесс as-is подсказывает, какие события и шаги должны быть в данных.

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

A/B-тест или мониторинг после релиза проверяет, достигли ли цели.

Пример: требование к аналитическим событиям

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

Пример формулировки:

система должна отправлять событие delivery_options_shown с параметрами city, delivery_type, cost, eta_days

система должна отправлять событие delivery_option_selected с параметрами delivery_type

Это не «хотелка аналитиков». Это часть способности бизнеса проверить, что изменение сработало.

Артефакты BA по теме анализа данных

После работы с гипотезами, сегментацией, воронками и A/B-тестами у BA обычно появляются такие полезные результаты:

карточки гипотез с метриками и ожиданиями

спецификация воронки (шаги, события, окна времени)

список сегментов для регулярного мониторинга

бриф эксперимента A/B с primary и guardrails

требования к событиям и качеству данных

Итог

Анализ данных для бизнес-аналитика — это инструмент, который делает обсуждение изменений проверяемым.

Гипотезы помогают перейти от «кажется» к «проверим».

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

Воронки локализуют потери по шагам процесса.

A/B-тесты позволяют доказательно сравнивать варианты изменений и защищать решение перед стейкхолдерами.

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

Управление требованиями: приоритизация, backlog, изменения и риски

Зачем управлять требованиями

В прошлых статьях курса мы разобрали, как бизнес-аналитик:

понимает контекст (цели, метрики, стейкхолдеры)

собирает требования (интервью, воркшопы, наблюдение, документы)

описывает их (user story, use case, BPMN, простые схемы)

использует данные для проверки гипотез (сегментация, воронки, A/B)

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

> "Responding to change over following a plan." — Agile Manifesto

Управление требованиями нужно, чтобы:

не потерять связь требований с целью и метриками

принять решения о том, что делать сначала, а что позже

контролировать изменения, не превращая проект в хаос

заранее видеть риски и стоимость переделок

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

Требование

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

Backlog

Backlog — упорядоченный список работ (обычно user story, задачи, улучшения, технические элементы), который команда постепенно уточняет и реализует.

Ориентир по термину: Product backlog#Product_backlog).

Приоритизация

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

Изменение требований

Изменение требования — любая правка смысла, объёма или критериев приёмки: добавили сценарий, поменяли правило, уточнили метрику, изменили интеграцию.

Трассируемость

Трассируемость — возможность связать:

цель и метрики

требования

сценарии и тесты

релизы и фактически внедрённые изменения

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

Приоритизация требований: что делать первым

Почему "срочно" и "важно" — недостаточно

Без явного подхода к приоритизации происходит типичный сценарий:

каждый стейкхолдер продавливает своё

команда берёт самые громкие запросы

критичные зависимости и риски всплывают поздно

метрики успеха не улучшаются, потому что делали не то

Задача BA — сделать приоритизацию прозрачной: по каким критериям решили и кто это утвердил.

Критерии, которые чаще всего реально работают

На практике требования обычно сравнивают по набору критериев:

ценность для бизнеса или пользователя (влияние на цель и метрики)

срочность (дедлайны, сезонность, штрафы)

стоимость/сложность реализации

риски (технические, юридические, операционные)

зависимости (нельзя сделать B, пока не сделан A)

обратимость (насколько легко откатить)

Важно: критерии должны быть одинаковыми для всех кандидатов в backlog, иначе сравнение превращается в спор.

MoSCoW: быстрый способ договориться о составе релиза

Метод MoSCoW делит элементы на 4 группы:

Must: без этого релиз не имеет смысла или нарушит обязательства

Should: очень важно, но можно перенести при необходимости

Could: хорошо бы иметь, но без сильного эффекта

Won’t: точно не делаем в этом релизе

Ориентир: MoSCoW method.

Практический совет для BA: фиксируйте не только категорию, но и почему элемент попал в неё (привязка к цели, риску или обязательству).

Kano: понять, что даст рост удовлетворённости

Модель Kano помогает разделять улучшения на типы:

базовые ожидания (без них продукт считают плохим)

линейные (чем лучше, тем выше удовлетворённость)

вау-эффекты (приятные неожиданности)

Ориентир: Kano model.

BA использует Kano как язык для разговора с бизнесом: мы сейчас закрываем базовые провалы или пытаемся добавить вау?

WSJF: когда нужно сравнивать "ценность в единицу времени"

Если организация использует подход SAFe, встречается WSJF (Weighted Shortest Job First) — приоритизация по идее "делаем то, что даст больше эффекта быстрее".

Ориентир: WSJF.

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

Пример из жизни: приоритизация улучшений доставки

Контекст: интернет-магазин, цель — снизить отказы на шаге доставки.

В backlog попали кандидаты:

ранний показ стоимости и сроков

добавление нового перевозчика

редизайн страницы доставки

новый фильтр по пунктам выдачи

BA помогает приоритизировать так:

Проверяем воронку: где максимум потерь и у каких сегментов.

Смотрим ограничения: подключение перевозчика займёт 2 месяца и требует договора.

Выбираем итерацию: ранний показ стоимости и сроков даёт быстрый эффект и проверяется A/B.

Фиксируем: что Must (без чего цель не достижима) и что Should/Could.

Итог: приоритет формируется не по вкусу, а по метрикам, срокам и реализуемости.

Backlog и работа с ним: как не утонуть

Что должно быть в хорошем backlog

Backlog полезен, если он:

упорядочен (есть понятный приоритет)

разбит на небольшие элементы (можно реализовать и проверить)

содержит критерии приёмки для проверяемости

привязан к цели и метрикам (зачем это делаем)

имеет владельцев решений по спорным вопросам

Уровни детализации backlog

В реальности удобно держать несколько уровней:

инициатива/эпик: крупная цель изменения (например, "Сократить отказы на доставке")

фича: значимая часть решения (например, "Ранний расчёт доставки")

user story: маленькая ценность (например, "Показать стоимость доставки в корзине")

задачи: технические шаги реализации

BA часто отвечает за качество описания на уровне фича и user story, чтобы разработка и тестирование не додумывали смысл.

Refinement: уточнение требований по мере приближения к реализации

Refinement (уточнение backlog) — регулярная работа, где команда и стейкхолдеры:

уточняют сценарии и исключения

дописывают критерии приёмки

разделяют крупные элементы на меньшие

поднимают зависимости и риски

Ценность для BA: refinement — главный механизм, чтобы требования не устаревали и не расходились с тем, что реально строит команда.

!Поток прохождения требований от идеи до релиза

Definition of Ready и Definition of Done

В командах часто используют договорённости:

Definition of Ready: что должно быть в элементе backlog, чтобы взять его в работу (например, есть критерии приёмки, понятны данные, согласованы правила)

Definition of Done: что значит "сделано" (например, пройдены тесты, обновлена документация, включены события аналитики)

BA помогает сделать эти определения конкретными, чтобы уменьшить переделки.

Управление изменениями: как принимать правки без хаоса

Почему изменения опасны не сами по себе

Изменения нормальны. Опасно, когда:

изменения не фиксируются

нет оценки влияния

нет согласования с владельцами цели

старые требования продолжают жить в документах и тестах

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

Минимальный процесс управления изменениями

Для большинства команд достаточно простого контура.

Инициировать изменение: что меняем и почему.

Описать влияние:

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

Оценить стоимость: грубо, но честно (время, ресурсы, сложность).

Принять решение: утвердить, перенести, отклонить.

Обновить артефакты: backlog, схемы, критерии приёмки, словарь терминов.

Сообщить изменениям адресатам: кому важно знать (RACI-логика из темы про стейкхолдеров).

Это можно делать формально (через change request) или легко (комментарием в задаче и записью решения), но шаги по смыслу должны быть.

Оценка влияния: быстрый чек-лист BA

Когда приходит правка, BA полезно пройтись по вопросам:

Цель не изменилась? Если изменилась, пересматриваем метрики и приоритеты.

Какие бизнес-правила затрагиваем? Часто именно там скрыты риски.

Какие исключения появятся? Новые ветки почти всегда дают дефекты.

Какие данные и события нужны, чтобы проверить эффект?

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

Версионность требований

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

версия требования или документа

дата

что изменилось

кто утвердил

Так снижается риск споров "мы договаривались по-другому".

Пример: изменение требования в банке

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

BA делает следующее:

Фиксирует изменение и причину: комплаенс.

Оценивает влияние:

- изменение экранов - изменение логики хранения согласий - влияние на конверсию (защитная метрика)

Предлагает варианты:

- добавить согласие как отдельный шаг - встроить в существующий шаг с короткой формулировкой

Согласует решение с владельцем цели и юристами.

Обновляет критерии приёмки и события аналитики.

Идея: не "просто добавили поле", а управляем влиянием на метрики и риски.

Риски в требованиях: как находить и снижать

Что такое риск в контексте требований

Риск — вероятность того, что требование или изменение приведёт к негативному эффекту: срыв срока, рост стоимости, падение метрики, нарушение закона, ухудшение процесса.

Ориентир по базовому понятию управления рисками: Risk management.

Типовые категории рисков для BA

Полезно классифицировать риски, чтобы не забыть важное:

бизнес-риски: метрика не улучшится, эффект меньше ожидаемого

технические: интеграции, производительность, качество данных

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

операционные: новый процесс не принят, нет обучения, вырастет нагрузка

коммуникационные: нет владельца решения, конфликт интересов стейкхолдеров

Риск-ориентированная детализация требований

Не все требования нужно детализировать одинаково. Детализация должна соответствовать риску:

низкий риск: достаточно user story и критериев приёмки

высокий риск: нужен use case с исключениями, таблица решений для правил, требования к аудит-логам

Матрица рисков: простой инструмент

Риск часто оценивают по двум осям:

вероятность (низкая/средняя/высокая)

влияние (низкое/среднее/высокое)

!Простая матрица для приоритизации рисков

Реестр рисков: минимальный шаблон

| Поле | Пример | |---|---| | Риск | Падение конверсии из-за нового обязательного шага | | Причина | Добавляем согласие/проверку | | Вероятность | Средняя | | Влияние | Высокое | | План снижения | A/B тест, альтернативный текст, сокращение шага | | Владелец | Продакт/бизнес-владелец | | Статус | В работе |

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

Артефакты BA для управления требованиями

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

упорядоченный backlog (с приоритетом и причинами)

критерии приёмки для элементов, которые берутся в разработку

журнал решений (что решили, почему, кто утвердил)

список зависимостей и ограничений

реестр рисков и планов снижения

связи "цель → метрика → требование → тест" (хотя бы на уровне ссылок)

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

Real cases: from a business problem to a solution and a measurable result

Why this article matters

So far in the course we built a full toolkit:

business context: goals, processes, metrics, stakeholders

requirements elicitation: interviews, workshops, observation, document review

description and modeling: user stories, use cases, BPMN and simple diagrams

data analysis for BA: hypotheses, segmentation, funnels, A/B tests

requirements management: prioritization, backlog, change control, risks

This article connects everything through real-life style cases. The goal is to show how a business analyst turns a vague request into a clear goal, a shared understanding, a deliverable backlog, and finally a measured impact.

!The end-to-end BA loop from problem to measurable outcome

Case format used in this article

Each case is described using the same structure so you can reuse it as a working template:

Problem statement and the risk of jumping to a solution

Goal, success metrics, and guardrails

Stakeholders and process scope

What data to check first

Elicitation plan and key questions

Models and requirement artifacts

Prioritization, changes, and risks

Result measurement and what “done” means

Case: E-commerce checkout drop at delivery step

Problem statement

Business request: “Make the Buy button bigger. Conversion dropped.”

A BA challenge: the request is a proposed solution, not the problem.

Goal, success metrics, guardrails

A workable goal:

reduce checkout abandonment on the delivery step

Define metrics:

success metric: abandonment rate on delivery step

guardrail metrics: checkout time, customer support contacts about delivery

Stakeholders and process scope

Typical stakeholders:

e-commerce manager: revenue and conversion

logistics team: delivery options, cutoffs, capacity

customer support: complaints, reasons for drop

engineering: performance, integrations

analytics: event tracking and reporting

Scope boundary example:

in scope: delivery options display, pricing logic, error messages, performance

out of scope (for first iteration): adding a new carrier contract

What data to check first

Key checks that often reveal the real issue:

Funnel from cart to payment, segmented by device and region

Error rates and response time for delivery calculation API

Sessions where users changed address multiple times

Support tickets tagged as “delivery price” or “delivery not available”

!A funnel that localizes the drop and suggests segmentation

Elicitation plan and key questions

Interviews:

logistics: “When is delivery unavailable and why?” “What cutoffs exist?”

support: “Top 5 delivery-related complaints, with examples?”

product owner: “Which metric matters most and when do we evaluate?”

Workshop goal:

align on delivery rules and a realistic to-be flow

Observation:

watch how support resolves delivery complaints to find missing information in the UI

Models and requirement artifacts

A practical artifact set:

BPMN or a simple flow for the delivery step, including exceptions: unavailable regions, oversized items, holiday cutoffs

decision table for delivery availability rules

user stories with acceptance criteria

Example user story:

As a customer, I want to see delivery cost and estimated time before payment, so that I can decide without wasting time.

Example acceptance criteria:

When the user enters city and postal code, the system shows available delivery methods with cost and ETA.

If no methods are available, the system shows a human-readable reason and at least one alternative action.

Delivery options load within an agreed performance threshold in normal load.

Prioritization, changes, and risks

Prioritization logic:

fastest testable impact first: early display of delivery cost and ETA

defer heavy dependencies: new carrier integration

Common risks and mitigations:

risk: increased load on delivery calculation service

mitigation: caching, rate limits, feature flag rollout

Change control example:

mid-sprint logistics adds a new cutoff rule

BA impact analysis: rules table update, acceptance criteria update, analytics event update

Result measurement

Definition of done includes measurement:

analytics events exist for delivery options shown and selected

success metric tracked for at least one full buying cycle

decision documented: roll out, iterate, or revert

Case: Bank loan application delays due to manual checks

Problem statement

Business request: “We need more staff to process applications. SLA is failing.”

BA risk: staffing may be a symptom, while the root cause is routing logic, missing data, or policy ambiguity.

Goal, metrics, guardrails

Goal example:

reduce average application processing time while keeping risk controls intact

Metrics:

success metric: average processing time from submission to decision

guardrails: fraud rate, compliance violations, customer complaints

Stakeholders and process scope

Typical stakeholders:

underwriting team: risk decisions and checks

operations: queue management and SLA

compliance and legal: mandatory data and consent

IT: workflow system, integrations

What data to check first

Operational analytics usually answers “where we wait”:

time spent in each status

top reasons for rework and returns to customer

volume by channel and time of day

percentage of applications routed to manual review and why

Elicitation plan

Use interview questions that force specifics:

“What exact conditions trigger manual review?”

“What is the minimal data required to make a decision?”

“Which checks are legally mandatory versus internal policy?”

Documents to review:

internal underwriting policy

regulatory requirements and consent text

audit logging requirements

Models and artifacts

Recommended artifacts because risk and exceptions are high:

use case: Submit loan application with alternative flows for missing consent, failed identity check, high-risk signals

decision table: manual review routing rules

BPMN: end-to-end application process across roles and systems

Prioritization, changes, and risks

Typical “quick wins” that are still safe:

auto-populate data from CRM for existing customers

validate missing fields earlier to reduce returns

routing improvements: send specialized cases directly to the right queue

Risk-focused detail:

if the change affects compliance, require explicit approval and versioning of requirements

Result measurement

A good BA closes the loop:

compare baseline vs after-release processing time

verify guardrails did not degrade

validate audit logs meet compliance expectations

Reference on compliance mindset and security controls: NIST Cybersecurity Framework

Case: Customer support backlog grows and SLA is missed

Problem statement

Business request: “Support is overloaded. We need a new ticketing tool.”

BA risk: a tool switch may not address routing, knowledge base quality, or category definitions.

Goal, metrics, guardrails

Goal:

improve time-to-resolution and first-contact resolution

Metrics:

success metric: average time to resolution

secondary metric: first-contact resolution rate

guardrails: customer satisfaction, agent workload fairness

Stakeholders and scope

Stakeholders:

L1 support: handles common issues

L2 specialists: handle complex issues

product and engineering: need actionable defect reports

customer success: escalations and VIP accounts

Scope example:

focus on categorization, routing rules, and knowledge base integration before changing the core platform

Data analysis first

Support data is often rich:

top categories by volume

top categories by time-to-resolve

reassignments per ticket and their reasons

escalation rate and back-and-forth loops

Elicitation plan

Observation is especially valuable:

watch agents handle 10 real tickets and note copy-paste, context switching, and missing information

Workshop target:

redefine categories and routing rules, agree who owns knowledge articles

Models and artifacts

Useful “simple but powerful” artifacts:

flowchart for routing by category and customer type

decision table for escalation rules

user stories for agent UX improvements with acceptance criteria

Example requirement that enables measurement:

every ticket must have a single primary category and resolution code from an agreed list

Prioritization, changes, risks

Typical risk:

if you change categories, historical reporting breaks

Mitigation:

maintain mapping table from old categories to new ones and document the rules

Result measurement

After rollout, BA checks:

reduction in reassignments

reduction in time-to-resolve for top 3 categories

no drop in customer satisfaction

Case: Manufacturing inventory mismatch causes production stops

Problem statement

Business request: “Inventory in the system is wrong. We need a new ERP.”

BA risk: replacing ERP is expensive and slow, while the real issue may be process discipline, scanning gaps, or conflicting definitions of “available stock”.

Goal, metrics, guardrails

Goal:

reduce inventory mismatch and prevent line stoppages

Metrics:

success metric: inventory accuracy for critical materials

operational metric: number of production stops caused by missing materials

guardrails: receiving and picking time, audit workload

Stakeholders and scope

Stakeholders:

warehouse staff: receiving, put-away, picking

production planners: material availability

procurement: lead times and reorder points

finance: valuation and shrinkage

Scope example:

start with one warehouse and one material group as a pilot

Data analysis first

Look for patterns:

mismatch rate by warehouse zone

mismatch rate by material type

time between receiving and system posting

frequency of manual adjustments and who performs them

Elicitation plan

Observation is critical here:

shadow receiving and picking for several shifts

record where scanning is skipped and why

Document review:

standard operating procedures, safety constraints, audit requirements

Models and artifacts

Artifacts that prevent ambiguity:

BPMN for receiving and picking as-is and to-be

glossary: definitions for on hand, available, reserved, in transit

requirements for scanning checkpoints and exception handling

Prioritization, changes, risks

Prioritize by impact:

enforce scanning at the most error-prone step first

add exception workflow for damaged goods to avoid silent “inventory loss”

Risk:

throughput reduction due to more scanning

Mitigation:

measure scanning time, improve UX, and set guardrails for cycle time

Result measurement

“Done” includes operational outcomes:

inventory accuracy improved for pilot materials

fewer production stops

process adopted by warehouse staff with training completed

Patterns across all cases: what good BAs consistently do

Across domains, the best BA work looks similar:

Separate problem from suggested solution.

Define a goal and how success will be measured.

Identify stakeholders and process boundaries to avoid hidden blockers.

Use data to localize where the issue happens and for whom.

Elicit exceptions and business rules, not just “desired features”.

Model just enough to remove ambiguity and reveal gaps.

Prioritize for fastest measurable impact while controlling risks.

Close the loop with measurement and documented learning.

What to do next

To practice, take one case above and rewrite it as a mini BA package:

goal card with success metrics and guardrails

stakeholder map with the decision-maker identified

as-is process sketch with top 3 pain points

3 to 5 user stories with acceptance criteria

1 decision table for business rules

a measurement plan for after release

This is the smallest realistic set of artifacts that connects business intent to delivery and results.