Бизнес-аналитика с нуля: база, практика и реальные кейсы (15 минут в день)

Role of the Business Analyst and Value-Oriented Thinking

Why business analysis exists

Business analysis exists to make sure that time, money, and effort spent on change (a project, a product update, a process redesign) actually creates value.

In many organizations, teams build things fast—but still miss the mark because:

The real problem was misunderstood

Stakeholders wanted different outcomes

Requirements were unclear or conflicted

Solutions shipped, but adoption was low

Results were never measured

A business analyst (BA) reduces these risks by clarifying what to build, why it matters, and how we’ll know it worked.

Who is a business analyst

A business analyst is a professional who helps people and teams:

Understand a business problem or opportunity

Define the desired outcomes

Align stakeholders on priorities and trade-offs

Translate needs into clear requirements or user stories

Validate that the delivered solution solves the right problem

A BA is not “just a note-taker” and not “just a documentation person.” The BA’s core contribution is decision quality.

!The BA connects business needs to delivery decisions and keeps focus on value.

BA vs other roles (so you don’t get confused)

Titles vary across companies. Sometimes one person combines several roles. Still, it helps to separate responsibilities.

| Role | Main focus | Typical outputs | |---|---|---| | Business Analyst | Value, problem clarity, stakeholder alignment, requirements | Problem statement, scope, requirements, acceptance criteria, process models | | Product Manager / Product Owner | Product vision and prioritization | Roadmap, backlog priorities, product goals | | Project Manager | Delivery plan, time, cost, coordination | Schedule, risk log, project status | | UX Designer/Researcher | User experience and usability | Prototypes, user research findings, UI flows | | Data Analyst | Insights from data | Dashboards, analyses, statistical findings |

A BA often partners closely with Product, UX, Engineering, and Operations—but the BA’s unique strength is structured problem-solving + alignment.

The value mindset: outputs vs outcomes

A value-oriented BA constantly separates outputs from outcomes.

Output: what you deliver (a feature, a report, a new process)

Outcome: what changes in the real world (fewer errors, faster onboarding, higher conversion)

Value: why the outcome matters (revenue growth, cost reduction, risk reduction, better customer experience)

A common trap is celebrating outputs (“we shipped the feature”) while ignoring outcomes (“did anything improve?”).

!Value thinking links what you build to measurable real-world change.

A practical definition of value (without complicated math)

In business analysis, value is the benefit you get relative to what you give up.

Benefits can include revenue, saved time, fewer mistakes, reduced risk, or happier customers.

Costs can include development effort, operational complexity, support load, and opportunity cost (what you didn’t build because you built this).

A value-oriented BA makes trade-offs explicit so stakeholders can decide consciously.

What a BA actually does (end-to-end)

Below is a typical flow. In real life, you iterate.

Clarify the problem

A BA asks:

What is happening today, and why is it a problem?

Who experiences the pain?

What is the desired future state?

What constraints exist (time, budget, regulation, technology)?

Useful artifact: problem statement (short and specific).

Identify stakeholders (the people who can affect or are affected)

A stakeholder is anyone who:

Uses the solution

Pays for it

Operates/supports it

Is impacted by it

Approves or blocks decisions

Value mindset tip: if you miss a key stakeholder, you often miss a key definition of “value.”

Elicit needs (get the real information)

Elicitation means drawing out information from people and sources. Common techniques:

Interviews and workshops

Observation (shadowing how work is done)

Document analysis (policies, reports)

Data review (tickets, funnel metrics)

Define scope and requirements

Scope is what is included and excluded.

Requirements are what the solution must do or be.

Functional requirements: what the system/process does (e.g., “user can reset password”)

Non-functional requirements: quality constraints (e.g., performance, security, accessibility)

A BA also helps define acceptance criteria: clear conditions for when work is “done” and acceptable.

Validate and manage change

Requirements change. Context changes. A BA keeps alignment by:

Confirming shared understanding

Managing impacts of changes (cost, timeline, risk)

Keeping documentation lightweight but reliable

Measure results

A value-oriented BA supports measurement by defining:

What metric will change

What baseline is today

What target is success

When we will measure (immediately, after 2 weeks, after 2 months)

A real-life mini case: “Checkout is underperforming”

Imagine an e-commerce company says: “We need a new checkout page.”

A value-oriented BA would slow down (briefly) and reframe:

Business goal: increase revenue without increasing marketing spend

Observed issue: checkout completion is low

Hypotheses: too many fields, unclear shipping cost, payment errors, slow page

Next, the BA would:

Map the current checkout steps (where users drop off)

Segment by device (mobile vs desktop)

Gather stakeholder views (support hears complaints; finance cares about fraud; ops cares about shipping rules)

Propose options with trade-offs (e.g., guest checkout vs fraud risk)

Instead of “build a new page,” the team gets a value-focused direction like:

Outcome: reduce checkout abandonment

Measurement: increase completion rate, reduce payment errors, reduce support tickets

Delivery plan: test the smallest changes first (remove optional fields, clarify total cost)

The BA’s core communication skill: aligning definitions

Many conflicts are not about facts—they’re about meanings.

A BA frequently aligns definitions like:

“Customer” (payer vs end user)

“Done” (coded vs tested vs adopted)

“Priority” (urgent vs important vs high ROI)

“Success” (output delivered vs outcome achieved)

This is value work because unclear definitions create expensive rework.

Principles that keep you value-oriented

These principles will show up throughout the course.

Start with why before what

Prefer outcomes over outputs

Make assumptions visible and testable

Keep documentation as simple as possible, but not simpler

Treat requirements as a tool for alignment, not bureaucracy

This mindset is strongly aligned with the Agile focus on customer value:

> “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” (Agile Manifesto)

What you should be able to do after this lesson

After this article, you should be able to:

Explain what a BA does in one clear paragraph

Distinguish output, outcome, and value using a real example

Name key BA activities from problem discovery to measurement

Describe how a BA differs from Product, Project, UX, and Data roles

Further reading (optional, reliable)

IIBA — A Guide to the Business Analysis Body of Knowledge (BABOK)

PMI — Business Analysis resources

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

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

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

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

Зачем мы это делаем (цели)

Как поймём, что стало лучше (KPI/метрики)

Для кого мы это делаем (пользователи)

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

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

Цели: что бизнес хочет изменить

Цель — это желаемое состояние, к которому стремится компания или команда.

Важно отличать цель от задачи:

Цель отвечает на вопрос какой эффект нужен

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

Примеры:

Цель: снизить стоимость поддержки клиентов

Задача: внедрить FAQ и чат-бота

Цели бывают разных уровней:

Стратегические (на уровне компании): рост доли рынка, выход в новый сегмент

Тактические (на уровне направления/продукта): повысить конверсию, снизить отток

Операционные (на уровне процесса/команды): сократить время обработки, снизить ошибки

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

Практичный набор уточняющих вопросов:

Что именно должно измениться в поведении клиентов/сотрудников?

Почему это важно именно сейчас?

Что будет считаться успехом через 1–3 месяца?

Что точно не является целью (чтобы не раздувать ожидания)?

KPI и метрики: как измерять успех

Метрика — любой измеряемый показатель.

KPI (Key Performance Indicator) — ключевая метрика, по которой принимают решения и оценивают успех.

Разница важна: метрик может быть десятки, KPI — обычно несколько, и они привязаны к целям.

Виды метрик, которые часто путают

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

Бизнес-результат: выручка, маржинальность, удержание

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

Операционная эффективность: время цикла, стоимость операции, % ошибок

Качество/надёжность: доступность, число инцидентов, время восстановления

И ещё одно важное различие:

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

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

Хорошая практика: держать рядом 1–2 запаздывающих KPI (результат) и 2–4 ведущих метрики (рычаги влияния).

Что делает KPI плохим

KPI начинает вредить, когда:

Он не связан с целью (измеряем «что угодно», лишь бы измерять)

Им легко манипулировать (люди оптимизируют число, а не ценность)

Он не управляем командой (нет рычагов влияния)

Он без контекста (нет базовой линии и целевого значения)

Мини-шаблон KPI, который удобно фиксировать

Чтобы KPI был пригоден для работы, бизнес-аналитик обычно фиксирует:

Название метрики (что именно измеряем)

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

Источник данных (система, отчёт, владелец данных)

Базовое значение (сейчас)

Целевое значение (какой уровень считаем успехом)

Период измерения (когда и как часто)

Ограничения (например, сезонность, неполные данные)

!Дерево метрик помогает связать цель с измеримыми рычагами

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

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

В бизнес-анализе часто встречаются разные типы пользователей:

Конечный пользователь (делает действие)

Плательщик (оплачивает)

Администратор/оператор (обслуживает и настраивает)

Поддержка (разбирается с проблемами)

Одна из самых частых ошибок — считать, что «клиент» всегда один. Например, в B2B:

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

Покупатель: руководитель, который выбирает поставщика

Плательщик: финансовый отдел

Что важно зафиксировать про пользователей

Минимум, который помогает не потерять смысл:

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

Цель пользователя (что он пытается сделать)

Болевые точки (что мешает)

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

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

Стейкхолдеры: кто влияет на решение и кого оно затронет

Стейкхолдер — человек или группа, которые:

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

Пострадают или выиграют от изменений

Будут поддерживать решение после внедрения

Важно: пользователь — это частный случай стейкхолдера, но не каждый стейкхолдер — пользователь.

Примеры стейкхолдеров в типичном кейсе «улучшаем оформление заказа»:

E-commerce команда и владелец продукта

Поддержка (рост/падение обращений)

Финансы (возвраты, платежи)

Безопасность/антифрод (мошенничество)

Логистика (правила доставки)

Юристы (согласия, оферта)

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

Один из удобных инструментов — матрица влияние/интерес:

Высокое влияние + высокий интерес: ключевые участники, с ними нужно регулярно синхронизироваться

Высокое влияние + низкий интерес: держать в курсе по ключевым решениям

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

Низкое влияние + низкий интерес: мониторить, но не тратить много времени

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

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

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

Сформулировать цель в терминах эффекта (что должно измениться и зачем).

Выбрать KPI, которые докажут, что эффект достигнут.

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

Определить стейкхолдеров, кто влияет на решение и внедрение.

Проверить согласованность:

- KPI действительно отражают цель? - Пользователи могут повлиять на KPI своим поведением? - Стейкхолдеры согласны с определениями и не держат «скрытые» цели?

Мини-кейс из жизни: «Сократить время ответа поддержки»

Ситуация: руководство говорит: «Нужно внедрить новый сервис тикетов».

Бизнес-аналитик возвращает фокус на контекст:

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

Пользователи: агенты поддержки, тимлид поддержки, клиенты (косвенно)

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

KPI:

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

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

Результат урока

После этого урока вы должны уметь:

Формулировать цель как ожидаемый эффект, а не как список работ

Отличать метрику от KPI и понимать, зачем нужны ведущие и запаздывающие метрики

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

Собрать контекст в связную картину, чтобы держать фокус на ценности

Дополнительные источники (по желанию)

IIBA — BABOK (Business Analysis Body of Knowledge)

Google re:Work — OKRs

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

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

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

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

понять текущую ситуацию as is;

уточнить цели и критерии успеха (KPI);

выявить реальные потребности пользователей;

согласовать ожидания стейкхолдеров;

снизить риск построить “правильное решение не той проблемы”.

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

!Цикл работы с информацией: от цели до проверенных выводов

Принципы хорошего сбора информации

Начинайте с цели разговора: что вы хотите прояснить и как это связано с KPI.

Отделяйте факты от мнений и помечайте предположения.

Сравнивайте источники: расхождения — это не “ошибка”, а важный сигнал.

Фиксируйте определения (термины, статусы, “что такое успех”).

Уважайте людей и данные: конфиденциальность, разрешение на записи, минимум “политики”.

Как выбрать метод

Ниже — практичная карта выбора. Часто лучший вариант — комбинация.

| Метод | Когда полезен | Ограничения | Типичный результат | |---|---|---|---| | Интервью | Понять мотивы, боли, причины решений, правила “в голове” | Субъективность, эффект “как надо”, а не “как есть” | Список потребностей, проблем, правил, гипотез | | Воркшоп | Быстро выровнять понимание у группы, договориться о приоритетах, карте процесса | Нужна фасилитация, возможна доминация сильных ролей | Согласованные решения, карта процесса, список вопросов/рисков | | Наблюдение | Узнать реальную работу, обходные пути, исключения, потери времени | Требует доступа и такта, эффект наблюдателя | Шаги процесса as is, реальные боли, источники ошибок | | Анализ документов | Понять правила, ограничения, историю изменений, ответственность | Документы часто устаревшие или “идеальные” | Набор бизнес-правил, ограничений, пробелов и противоречий |

Интервью

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

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

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

Выберите респондентов: пользователи, поддержка, финансы, операции, безопасность — зависит от контекста.

Подготовьте структуру вопросов: от общего к частному.

Согласуйте формат: длительность 30–45 минут, можно ли записывать.

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

Как задавать вопросы, чтобы получать полезные ответы

Начинайте с реальности: “Расскажите про последний раз, когда…”.

Просите примеры и артефакты: “Можете показать, где это видно в системе/письме/тикете?”.

Уточняйте термины: “Что вы называете ‘успешной оплатой’?”.

Отделяйте “что происходит” от “как должно быть”.

Проверяйте причинность осторожно: не “почему вы так делаете?”, а “что обычно приводит к этому решению?”.

Мини-скрипт интервью (универсальный)

Контекст: роль человека и цель его работы.

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

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

Исключения: нестандартные случаи, ручные обходы.

Метрики: что считают успехом и что измеряют.

Идеи: что бы человек изменил в первую очередь.

Подтверждение: “Правильно ли я понял, что…?”.

Мини-кейс: интервью по проблеме “падает оформление заказа”

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

С поддержкой: какие жалобы чаще всего в последний месяц.

С финансовыми/платёжными: где больше отказов и возвратов.

С логистикой: какие правила доставки создают ошибки.

С пользователями (или UX-исследователем): что непонятно на шаге оплаты и почему уходят.

Важно: интервью дадут версии причин, но подтвердить их лучше данными и наблюдением.

Воркшопы

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

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

Нужно быстро синхронизировать 5–12 человек вокруг цели, KPI и определения “успеха”.

Есть конфликт приоритетов или разные версии “как работает процесс”.

Нужно принять решения: что в scope, что out of scope, какие риски блокируют.

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

Фасилитатор: ведёт процесс, следит за временем и правилами.

Доменные эксперты: дают содержание.

Решающее лицо: может подтвердить финальные договорённости.

Секретарь (опционально): фиксирует решения и открытые вопросы.

Шаблон повестки на 60 минут

Цель сессии и ожидаемый результат (5 минут).

Контекст: цель, KPI, пользователи, ограничения (10 минут).

Совместная фиксация текущего процесса или проблемы (20 минут).

Список болей и причин (10 минут).

Приоритизация и следующие шаги (10 минут).

Подтверждение решений и владельцев действий (5 минут).

Практика фасилитации: как не дать встрече “утонуть”

Явно фиксируйте парковку (parking lot) для тем “не по цели”.

Прерывайте обсуждение мнений просьбой о фактах: “На чём это основано?”.

Завершайте каждый блок артефактом: список правил, карта процесса, 3 решения.

!Пример структуры воркшопа: от контекста к решениям

Наблюдение

Наблюдение (shadowing, field study) показывает то, что люди часто не упоминают в интервью:

обходные пути;

реальные “узкие места” по времени;

ручные операции;

причины ошибок (копипаст, переключение систем, недостающие поля);

несоответствие регламента и реальности.

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

Объясните цель: “Мы улучшаем процесс, не оцениваем вашу работу”.

Получите согласие: на присутствие, записи экрана, заметки.

Наблюдайте реальный кейс от начала до конца.

Задавайте короткие вопросы по ходу: “Что вы сейчас проверяете?”

Фиксируйте:

- шаги процесса; - используемые системы и документы; - точки ожидания; - места, где человек “останавливается подумать”; - ошибки и возвраты назад.

Что особенно искать при наблюдении

Триггеры: что запускает процесс.

Решения: где человек выбирает один из вариантов.

Исключения: что ломает стандартный сценарий.

Передачи: где работа переходит другому человеку/отделу.

Анализ документов

Документы — это быстрый способ понять формальные правила и ограничения. Но важно помнить: документ описывает “как должно быть”, а не всегда “как есть”.

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

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

SLA, политики, требования безопасности.

ТЗ, описания интеграций, схемы данных.

Отчёты, дашборды, определения метрик.

История инцидентов, обращения в поддержку, FAQ.

Коммерческие условия, договорные ограничения.

Как извлекать пользу из документов

Выпишите бизнес-правила простыми фразами: “Если X, то Y”.

Отдельно отметьте обязательные ограничения: закон, безопасность, финансы.

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

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

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

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

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

Минимальный набор артефактов

Конспекты интервью с отмеченными цитатами и фактами.

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

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

Карта процесса as is (хотя бы текстом).

Журнал решений: что решили, когда, кто подтвердил.

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

Техника “подтверждение понимания”

После синтеза отправьте стейкхолдерам короткое резюме:

Что мы узнали (факты).

В чём проблема (формулировка).

Какие гипотезы причин.

Какие вопросы открыты.

Что будет считаться успехом (KPI и определения).

Это снижает риск, что команда начнёт проектировать решение на неверной картине мира.

Типичные ошибки и как их избежать

Ошибка: задавать вопросы про “идеальное будущее” вместо реальных случаев.

Ошибка: собирать мнения только у одного отдела.

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

Ошибка: путать жалобы (симптомы) с причинами.

Ошибка: превращать воркшоп в статус-встречу без результатов.

Результат урока

После этого урока вы должны уметь:

выбрать подходящий метод сбора информации под задачу и ограничения;

подготовить и провести базовое интервью и зафиксировать результаты;

организовать воркшоп так, чтобы получить согласованный артефакт и решения;

провести наблюдение и выделить реальные проблемы процесса;

извлечь из документов правила и ограничения и проверить их на практике.

Надёжные источники (по желанию)

IIBA BABOK (официальный сайт)

Nielsen Norman Group: User Interviews

Требования: user stories, use cases, критерии приемки и приоритизация

Зачем нужны требования и почему это продолжение предыдущих уроков

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

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

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

не спорила о трактовках в конце разработки

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

делала в первую очередь то, что даёт больше ценности при ограниченных ресурсах

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

!Как контекст и сбор информации превращаются в требования и приоритеты

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

Требование — это согласованное утверждение о том, что должно быть в решении или процессе, чтобы достичь цели.

Практически полезно держать три слоя:

Зачем: цель и KPI (что должно улучшиться)

Что: требования (какие изменения нужны)

Как проверить: критерии приемки (по каким условиям считаем, что сделали правильно)

Если пропущен слой “как проверить”, то “готово” превращается в спор мнений.

User story: компактный формат “потребность + ценность”

Когда user stories подходят лучше всего

User stories удобны, когда:

вы работаете итеративно (Agile, продуктовая разработка)

нужно быстро договориться о ценности и поведении

команда готова уточнять детали через диалог, а не через большой документ

Шаблон user story

Классический шаблон:

Как [роль пользователя]

Я хочу [действие/возможность]

Чтобы [ценность/результат]

Пример (e-commerce):

Как покупатель

Я хочу видеть итоговую стоимость с доставкой до оплаты

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

Что обязательно добавить к user story, чтобы она стала рабочей

Одна фраза редко достаточно. Минимальный комплект уточнений рядом с историей:

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

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

Критерии приемки: как проверим (раздел ниже)

Примечания: ссылки на источники (интервью, тикеты, метрики)

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

| Ошибка | Почему плохо | Как исправить | |---|---|---| | “Как система, я хочу…” | Система не получает ценность; теряется пользователь | Назвать реальную роль: клиент, оператор, бухгалтер | | “Чтобы было удобно” | Не проверяется | Перевести в наблюдаемое поведение: “сократить время оформления”, “уменьшить ошибки” | | Слишком крупная история | Нельзя оценить и быстро проверить | Разбить на тонкие вертикальные срезы ценности |

Use case: сценарий взаимодействия шаг за шагом

Когда use cases особенно полезны

Use case удобнее, чем user story, когда:

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

важны интеграции и строгая последовательность действий

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

много участников процесса (например, клиент + оператор + внешняя система)

Структура use case (практичный минимум)

Один use case обычно фиксируют так:

Название (глагол + объект): “Оплатить заказ картой”

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

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

Триггер: что запускает сценарий

Основной сценарий: шаги “счастливого пути”

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

Постусловия: что должно быть истинно после завершения (например, “создан оплаченный заказ”)

Мини-пример use case

Use case: “Сбросить пароль”

Акторы: пользователь, система аутентификации, почтовый сервис

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

Триггер: пользователь нажимает “Забыли пароль?”

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

1. пользователь вводит email 2. система отправляет письмо со ссылкой 3. пользователь открывает ссылку и задаёт новый пароль 4. система подтверждает смену пароля и предлагает войти

Исключения:

1. email не найден — показываем нейтральное сообщение (без утечки данных) 2. ссылка просрочена — предлагаем запросить новую

Постусловия: пароль обновлён; событие записано в журнал безопасности

Как связать user story и use case, а не выбирать “что-то одно”

На практике часто работает связка:

User story объясняет зачем и для кого

Use case описывает как это работает в деталях и исключениях

Один use case может покрывать несколько user stories, и наоборот.

Критерии приемки: как превратить “сделайте нормально” в проверяемое

Что такое критерии приемки

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

Они помогают:

разработчикам понять границы задачи

тестированию проверить без догадок

стейкхолдерам принять результат без “ещё чуть-чуть”

Важно различать:

Критерии приемки: проверяемые условия для конкретной истории/функции

Определение готовности (Definition of Done): общий стандарт команды (код-ревью, тесты, документация и т.д.)

Признаки хороших критериев приемки

Хорошие критерии:

однозначные (разные люди поймут одинаково)

проверяемые (можно протестировать или наблюдать)

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

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

Удобный формат: Given-When-Then

Часто критерии пишут в стиле BDD:

Given (дано): контекст

When (когда): действие

Then (тогда): ожидаемый результат

Пример критериев приемки для истории “показать итоговую стоимость с доставкой до оплаты”:

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

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

Given стоимость доставки не может быть рассчитана (ошибка сервиса), When пользователь открывает подтверждение заказа, Then пользователь видит сообщение об ошибке и не может перейти к оплате до успешного расчёта.

Как избежать “неправильных” критериев приемки

Частые проблемы:

Критерий описывает дизайн (“кнопка зелёная”) вместо поведения (“кнопка активна только если…”)

Критерий не учитывает исключения (ошибки интеграции, пустые поля, отмену)

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

Нефункциональные требования: качество и ограничения

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

Типовые категории:

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

Надёжность: доступность, восстановление после сбоев

Безопасность: доступы, аудит, защита данных

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

Совместимость: браузеры, устройства, интеграции

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

Пример: “Форма оплаты должна загружаться не дольше 2 секунд при 95-м перцентиле” — это ограничение, которое меняет подход к реализации и тестированию.

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

Почему приоритизация — обязанность бизнес-аналитика как “хранителя ценности”

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

максимизировать ценность относительно целей и KPI

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

выстроить реалистичный план поставки

Важно: бизнес-аналитик не всегда “назначает” приоритет, но он обеспечивает прозрачную логику выбора.

Входные данные для приоритизации

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

вклад в цель и KPI

охват пользователей и сила боли

риски (юридические, финансовые, репутационные)

зависимости (что блокирует другое)

стоимость и сложность (оценка команды)

срочность (дедлайн, сезонность)

Метод MoSCoW: простой и быстрый

MoSCoW делит требования на группы:

Must: без этого нельзя запускать или это критично

Should: важно, но можно перенести

Could: хорошо иметь, если останутся ресурсы

Won’t: не делаем сейчас (фиксируем явно)

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

Метод “ценность против усилий”: чтобы не спорить бесконечно

Ещё один практичный способ — разложить инициативы по двум осям:

ценность (насколько влияет на цель/KPI)

усилия (сколько нужно времени/ресурсов)

Результат — понятная логика:

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

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

низкая ценность + низкие усилия: делать только если не мешает важному

низкая ценность + высокие усилия: обычно исключать

!Матрица ценность/усилия для выбора приоритетов

Как связывать приоритеты с KPI, а не с “громкостью” стейкхолдера

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

какой KPI оно должно сдвинуть

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

как мы увидим эффект (события, отчёт, замер)

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

Мини-кейс: требования для проблемы “падает конверсия оплаты”

Исходные данные (из прошлых уроков):

цель: увеличить выручку без роста маркетинговых затрат

KPI: конверсия “корзина → оплаченный заказ”, % ошибок оплаты, обращения в поддержку по оплате

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

Пример набора требований

User stories:

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

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

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

Use case (фрагмент): “Оплатить заказ картой” с альтернативами:

платёж отклонён банком

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

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

Критерии приемки (пример для “гостевой чек-аут”):

Given пользователь не авторизован, When он переходит к оформлению, Then он может выбрать “Оформить без регистрации”.

Given пользователь оформляет без регистрации, When он вводит email и телефон, Then создаётся заказ и отправляется подтверждение на email.

Given пользователь оформляет без регистрации, When он завершает оплату, Then заказ доступен по ссылке из письма и в поддержке виден контакт клиента.

Приоритизация (примерная логика):

Must: показ итоговой стоимости, обработка ошибок оплаты с понятными сообщениями, логирование причин отказа

Should: гостевой чек-аут (если подтверждается данными как причина отказов)

Could: косметический редизайн блока оплаты

Won’t: полный рефакторинг платёжного модуля в этом квартале (если риск и стоимость высоки)

Итог урока

После этого урока вы должны уметь:

объяснить разницу между user story и use case и выбирать формат по ситуации

писать user stories так, чтобы в них была роль, действие и ценность

описывать use case через основной сценарий и исключения

формулировать проверяемые критерии приемки и отличать их от общего Definition of Done

приоритизировать требования прозрачными методами (MoSCoW, ценность/усилия), привязывая выбор к целям и KPI

Надёжные источники (по желанию)

Atlassian Agile Coach: User stories

Atlassian Agile Coach: Acceptance criteria

Martin Fowler: Gherkin

Моделирование процессов и данных: BPMN, UML, ERD на практике

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

В прошлых уроках вы научились держать фокус на ценности (цели и KPI), понимать контекст (пользователи и стейкхолдеры), собирать информацию (интервью, воркшопы, наблюдение, документы) и превращать её в требования (user stories, use cases, критерии приемки, приоритизация).

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

Модели помогают:

согласовать понимание как сейчас работает процесс и где проблема;

обнаружить пропуски: исключения, ручные обходы, “серые зоны ответственности”;

сделать требования точнее (особенно критерии приемки и исключения);

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

Важно: модель — не цель, а инструмент согласования. Делайте её ровно настолько подробной, насколько нужно для решений.

Что именно мы моделируем

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

Процесс: что происходит шаг за шагом, где решения, ожидания, возвраты назад.

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

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

В этой статье вы освоите три самых распространённых нотации:

BPMN для процессов

UML для сценариев и взаимодействий

ERD для данных

Полезные спецификации и справка:

OMG — BPMN 2.0 Specification

Camunda — BPMN 2.0 Reference

OMG — UML Specification

Wikipedia — Entity–relationship model

BPMN на практике

Что такое BPMN простыми словами

BPMN (Business Process Model and Notation) — нотация, чтобы описывать бизнес-процессы как поток работ: события, задачи, развилки, передачи между ролями.

BPMN хорош, когда нужно:

согласовать процесс as is и to be;

увидеть, где потери времени и ошибки;

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

показать границы ответственности разных команд.

Минимальный словарь BPMN

Ниже — базовые элементы, которых достаточно для большинства задач уровня “с нуля”.

Событие (event): что-то произошло. Обычно старт процесса и завершение процесса.

Задача (task): действие, которое делает человек или система.

Шлюз (gateway): точка решения или разветвления (например, “оплата успешна?”).

Поток (sequence flow): стрелка, показывающая порядок шагов.

Пулы и дорожки (pool/lanes): кто выполняет шаги. Пул часто обозначает организацию/систему, дорожки — роли/отделы.

Практический кейс: “Ошибка оплаты → рост обращений в поддержку”

Возьмём знакомый контекст из прошлых уроков про оформление заказа.

Цель: снизить потери выручки из-за незавершённых оплат и снизить нагрузку на поддержку.

KPI: конверсия “корзина → оплаченный заказ”, % ошибок оплаты, число обращений “не прошла оплата”.

Ниже упрощённый as is процесс, который полезно показать на воркшопе стейкхолдерам.

!BPMN показывает процесс оплаты и что происходит при ошибке, включая обращения в поддержку

Как читать и обсуждать BPMN (чеклист бизнес-аналитика)

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

Где точный старт процесса и что является триггером?

Что является “готовым результатом” (конец процесса) и есть ли несколько вариантов завершения?

Где решения принимаются человеком, а где системой?

Какие исключения наиболее частые и наиболее дорогие по последствиям?

Где ожидания, очереди, ручные операции?

Где переход между ролями и кто “владелец шага”?

Типичные ошибки в BPMN

Делать схему “как в регламенте”, игнорируя наблюдения и реальные обходы.

Смешивать в одной диаграмме и as is, и to be так, что невозможно отличить.

Уходить в микрошаги интерфейса (“нажал кнопку”, “увидел экран”), если цель — улучшение процесса на уровне бизнеса.

UML на практике

Что такое UML и чем он отличается от BPMN

UML (Unified Modeling Language) — набор диаграмм для описания системы и взаимодействий.

Если BPMN отвечает на вопрос как протекает процесс между ролями, то UML чаще помогает ответить на вопросы:

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

кто взаимодействует с системой;

какие шаги и сообщения происходят между участниками в конкретном сценарии.

Для старта бизнес-аналитику чаще всего достаточно двух UML-инструментов:

Use case diagram (диаграмма вариантов использования)

Sequence diagram (диаграмма последовательностей)

Use case diagram: быстро договориться о границах и акторах

Use case в UML — это сценарий “пользователь получает результат от системы”.

Use case diagram полезна, чтобы:

не перепутать пользователей и внешние системы;

зафиксировать границы системы (что в scope, что вне scope);

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

Пример для оплаты:

!Use case diagram показывает, кто взаимодействует с системой и какие ключевые сценарии есть

Практическая подсказка: use case diagram не заменяет требования, но отлично выявляет “забытые” сценарии.

Sequence diagram: когда важны интеграции и порядок сообщений

Sequence diagram показывает, какие участники обмениваются сообщениями и в каком порядке.

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

есть внешние системы (платежи, доставка, антифрод);

важно разрулить статусы, таймауты, повторы;

нужно описать, что происходит при ошибках (то, что потом станет критериями приемки).

Мини-пример логики “оплата → подтверждение”:

Покупатель инициирует оплату.

Интернет-магазин создаёт попытку платежа и отправляет запрос провайдеру.

Провайдер возвращает результат.

Интернет-магазин фиксирует статус и показывает пользователю результат.

Интернет-магазин отправляет подтверждение (если успешно).

!Sequence diagram помогает согласовать порядок интеграций и обработку успеха/ошибки

ERD на практике

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

ERD (Entity-Relationship Diagram) — способ описать данные: какие сущности существуют, какие у них поля, и как они связаны.

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

согласовать определения данных (“что такое заказ?”, “чем отличается попытка платежа от платежа?”);

избежать конфликтов в требованиях из-за терминов и статусов;

уточнить бизнес-правила (например, “у заказа может быть несколько попыток оплаты”).

Базовые понятия ERD

Сущность (entity): объект предметной области (Заказ, Клиент, Платёж).

Атрибут (attribute): поле сущности (id заказа, сумма, статус).

Связь (relationship): как сущности связаны.

Кардинальность: сколько объектов одной сущности соответствует объекту другой (например, “один заказ — много попыток оплаты”).

Первичный ключ (primary key): атрибут, который однозначно идентифицирует запись (часто id).

Внешний ключ (foreign key): атрибут, который ссылается на первичный ключ другой сущности и фиксирует связь.

Мини-ERD для оплаты заказа

Типичный вопрос из практики: “Почему поддержка не видит причину отказа?” Иногда причина проста: данных нет в модели, или они перезаписываются.

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

Клиент (Customer)

Заказ (Order)

Попытка платежа (PaymentAttempt)

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

!ERD показывает, какие данные нужны, чтобы хранить причины отказов и связывать их с заказом

Типичные ошибки в ERD

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

Не фиксировать справочные значения статусов и их смысл (например, “FAILED” — это окончательно или можно повторить?).

Не разделять “событие” и “текущее состояние” (например, хранить только текущий статус без истории попыток).

Как выбрать нотацию под задачу

Ниже — практичная шпаргалка.

| Если вам нужно… | Чаще всего берите | Почему | |---|---|---| | Согласовать шаги процесса между ролями, показать развилки и исключения | BPMN | Лучше всего показывает поток работ и ответственность | | Зафиксировать границы системы и список ключевых сценариев | UML use case diagram | Быстро выявляет акторов и “что система делает” | | Разобрать интеграцию, порядок сообщений, статусы и ошибки | UML sequence diagram | Удобно обсуждать контракты и обработку ошибок | | Согласовать определения данных и связи (что с чем связано) | ERD | Убирает разночтения терминов и статусов |

Практическое правило: если спор идёт о “кто и что делает” — идите в BPMN, если о “кто и с какой системой взаимодействует” — в UML, если о “какие данные должны существовать и как хранить причины/статусы” — в ERD.

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

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

Связка с user stories и use cases

Берёте шаги процесса из BPMN и формулируете user stories там, где появляется ценность или проблема.

Для критичных веток (особенно где деньги, безопасность, ошибки) делаете use case-описание или sequence diagram.

Для каждого исключения в BPMN/sequence добавляете критерии приемки в формате Given-When-Then.

Пример превращения “исключения” в критерий приемки:

В модели видно исключение: “провайдер вернул ошибку, причина не показана”.

Требование: “показывать пользователю понятное сообщение и сохранять код причины для поддержки”.

Критерий приемки:

1. Given платёж отклонён провайдером с кодом причины, When система получает ответ, Then код и текст причины сохраняются в попытке платежа и доступны поддержке в карточке заказа.

Связка с KPI

Модель помогает не “потерять метрику”:

BPMN показывает, где возникает потеря конверсии (на каких развилках и возвратах).

ERD показывает, есть ли данные, чтобы измерять причины (например, fail_reason_code).

UML помогает убедиться, что есть сценарии для диагностики и поддержки (например, “Просмотреть причину отказа”).

Мини-процесс работы на 15 минут

Если у вас мало времени, используйте лёгкий ритуал “15 минут — один артефакт”.

Выберите один проблемный сценарий (например, “Оплата отклонена”).

Нарисуйте черновой BPMN только до первого ключевого шлюза.

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

Добавьте один недостающий элемент данных в мини-ERD (например, “код причины отказа”).

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

Итог урока

После этого урока вы должны уметь:

объяснить, чем отличаются BPMN, UML и ERD, и когда что применять;

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

использовать UML (use case и sequence) для фиксации сценариев и интеграций;

сделать мини-ERD для ключевых сущностей и связей, чтобы убрать разночтения в данных;

превращать элементы моделей в требования и критерии приемки, не теряя связь с целями и KPI.

Решения и изменения: варианты, риски, внедрение и управление изменениями

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

В прошлых уроках вы научились:

держать фокус на ценности (цели, KPI, outcomes);

понимать контекст (пользователи и стейкхолдеры);

собирать информацию;

превращать её в требования (user stories, use cases, критерии приемки, приоритизация);

использовать модели (BPMN, UML, ERD), чтобы согласовать картину процесса и данных.

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

В этом уроке мы разберём, как BA помогает команде пройти путь от “что нужно” к “это реально работает в бизнесе”.

От требований к решениям: что именно выбираем

Важно различать три уровня:

Проблема/возможность: что не так и почему это важно.

Требования: что должно быть обеспечено, чтобы цель была достигнута.

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

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

изменения интерфейса и текстов ошибок;

улучшение логирования причин отказа;

настройку маршрутизации запросов в платёжный провайдер;

обучение поддержки и обновление базы знаний;

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

Роль BA здесь не в том, чтобы “придумать фичу”, а в том, чтобы:

сделать варианты явными;

сравнить их по ценности, рискам и ограничениям;

помочь договориться и спланировать внедрение;

обеспечить измеримость результата.

Как генерировать варианты решения, а не “первую идею”

В реальных проектах частая ловушка: стейкхолдер формулирует решение, будто это проблема (“Нужен новый платёжный экран”). BA возвращает разговор к альтернативам.

Практичный способ собрать варианты — короткий “воркшоп опций” на 30–60 минут.

Мини-шаблон воркшопа опций

Зафиксировать цель и KPI (1–3 метрики, которые должны измениться).

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

Сформулировать 3–6 вариантов решений.

Для каждого варианта зафиксировать:

1. ожидаемый эффект на KPI; 2. кого затронет (пользователи/операции/поддержка); 3. риски и зависимости; 4. примерную сложность.

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

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

Оценка вариантов: ценность, усилия, риски, ограничения

В предыдущем уроке вы уже использовали матрицу “ценность/усилия” для приоритизации требований. Для выбора решения логика похожа, но добавляется слой рисков и внедрения.

Таблица сравнения вариантов (рабочий минимализм)

| Вариант | Какой KPI сдвигаем | Кого затрагиваем | Сложность | Основные риски | Что нужно для внедрения | |---|---|---|---|---|---| | Улучшить тексты ошибок оплаты | % ошибок оплаты, обращения в поддержку | Клиенты, поддержка | Низкая | Не решит корневую причину | Контент, локализация, релиз | | Логировать код отказа и показывать поддержке | Обращения в поддержку, время решения | Поддержка, разработка | Средняя | Доступы к данным, PII | Изменения данных, роли доступа | | Перенастроить маршрутизацию в провайдере | Конверсия оплаты | Клиенты, финансы | Средняя/высокая | Регрессия, контрактные ограничения | Тестирование, согласование с провайдером |

Такой формат хорош тем, что делает обсуждение предметным: люди видят, что выбор — это компромисс.

Матрица “ценность/усилия” для решения

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

Практическая рекомендация: варианты “высокая ценность + высокие усилия” почти всегда стоит дробить и начинать с минимального проверяемого шага.

Риски: что может пойти не так и как BA помогает

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

BA не обязан быть риск-менеджером в одиночку, но BA часто лучше всех видит “стыки”: между отделами, системами, определениями данных и ожиданиями.

Классификация рисков, полезная в ежедневной работе

Бизнес-риски: решение не даст эффекта на KPI, ухудшит экономику, вызовет отток.

Пользовательские риски: ухудшение UX, падение доверия, рост ошибок.

Операционные риски: поддержка/операции не справятся, появится ручной труд.

Технические риски: интеграции, производительность, качество данных.

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

Простой “регистр рисков” (без бюрократии)

| Риск | Вероятность | Влияние | Митигирующее действие | Владелец | Статус | |---|---|---|---|---|---| | Ошибки оплаты будут скрыты, если провайдер вернёт нестандартный код | Средняя | Высокое | Согласовать маппинг кодов, добавить “unknown reason” и алерты | Разработка/BA | Открыт | | Поддержка увидит лишние персональные данные | Низкая | Высокое | Роли доступа, маскирование, аудит | Безопасность | В работе |

Вместо сложных формул используйте “светофор”:

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

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

Низкий риск: мониторим.

Ключевая задача BA: связать риск с конкретным решением и конкретным действием “что делаем”.

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

Очень частый провал проектов: “мы поставили систему”, но люди продолжают работать по-старому, потому что:

процесс не обновили;

роли и ответственность не определили;

обучение не провели;

метрики не настроили;

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

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

Один из популярных практических подходов — модель ADKAR (Awareness, Desire, Knowledge, Ability, Reinforcement) от Prosci: осознание, желание, знание, способность, закрепление. Сама идея проста: чтобы изменение произошло, нужно закрыть все пять “ступеней”.

Модель ADKAR (Prosci)

Чеклист BA: готовы ли мы к изменению

Есть ли ясная причина изменения, объяснённая простым языком (какая проблема и какой KPI)?

Понятно ли, кто меняет поведение (какие роли пользователей затронуты)?

Обновлены ли артефакты процесса (инструкции, регламенты, SLA, база знаний)?

Настроены ли доступы, роли, права (особенно если добавили новые данные)?

Есть ли план коммуникации: кому, что, когда и в каком формате сообщаем?

Есть ли план обучения и поддержки в первые недели (вопросы, “горячая линия”, шаблоны ответов)?

Можем ли мы измерить результат (события, отчёты, определения метрик)?

Если на 2–3 пункта ответа нет — внедрение почти гарантированно “провалится без технических багов”.

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

Запуск — это не одна кнопка “релиз”, а контролируемый процесс.

Частые стратегии запуска

Big bang: всем сразу.

Пилот: на ограниченном сегменте пользователей/подразделений.

Поэтапный rollout: 5% → 25% → 50% → 100%.

Parallel run: старый и новый процесс работают параллельно (часто в критичных операциях).

Как выбирать стратегию

| Фактор | Лучше пилот/поэтапно | Можно big bang | |---|---|---| | Высокая цена ошибки (деньги, безопасность) | Да | Редко | | Много затронутых ролей и процессов | Да | Редко | | Низкая обратимость (сложно откатить) | Да | Нет | | Простое изменение, легко откатить | Не обязательно | Да |

Практическое правило: чем дороже ошибка — тем больше вам нужен пилот и чёткий “план отката”.

Мини-шаблон плана запуска

Область запуска: кто включён (сегменты пользователей/отделы).

Метрики мониторинга в первые 24–72 часа (ошибки, конверсия, обращения в поддержку).

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

План отката: какие условия считаются критичными и как возвращаемся.

Коммуникации: что и кому сообщаем до и после.

Управление изменениями требований: как не утонуть в “а давайте ещё”

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

BA помогает выстроить лёгкий процесс change control:

Зафиксировать запрос изменения (что меняем и почему).

Оценить влияние:

1. на цель и KPI; 2. на пользователей и стейкхолдеров; 3. на сроки/стоимость/риски; 4. на данные и интеграции.

Принять решение: принять, отложить, отклонить.

Обновить артефакты: требования, модели, критерии приемки, коммуникации.

Полезный инструмент из практики ITSM — формальная дисциплина управления изменениями (change enablement) в ITIL. Даже если вы не используете ITIL полностью, идея “изменение должно быть оценено и согласовано” очень применима.

ITIL (Wikipedia)

!Простая карта того, как управлять изменениями требований и не терять связь с KPI

Как проверить, что решение сработало: измерение outcomes

Возвращаемся к первому уроку курса: outputs не равны outcomes.

Output: выпустили функциональность, обновили процесс, провели обучение.

Outcome: уменьшились ошибки оплаты, выросла конверсия, снизились обращения.

Практика “план измерения”

Зафиксируйте заранее:

какие KPI меряем;

что считаем базовой линией (baseline) и за какой период;

когда смотрим эффект (например, через 7, 14, 30 дней);

какие факторы могут исказить сравнение (сезонность, маркетинговые кампании, изменение цен).

Если вы внедряете изменения поэтапно, становится проще отделить эффект изменения от внешних факторов.

Мини-кейс: “Падает конверсия оплаты, растут обращения”

Контекст (из прошлых уроков):

цель: увеличить выручку без роста маркетинговых затрат;

KPI: конверсия “корзина → оплаченный заказ”, % ошибок оплаты, обращения в поддержку по оплате.

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

В BPMN видно, что при ошибке оплаты пользователи часто повторяют попытку 2–3 раза и уходят.

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

Поддержка не может быстро понять, что произошло, и просит клиента “попробовать снова”.

Варианты решений

Добавить сущность “попытка платежа”, хранить код причины и показывать поддержку.

Улучшить тексты ошибок и подсказки пользователю (что делать при отказе).

Пилотно изменить настройки 3DS/маршрутизацию провайдера для части трафика.

Риски и план внедрения

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

Риск метрик: если не настроить события, не поймём эффект → добавить события “payment_attempt_failed” с reason_code.

Запуск: поэтапный rollout 10% → 50% → 100%, мониторинг обращений и конверсии.

Как измеряем результат

Через 7 дней после 50% rollout: сравнить % ошибок и обращения по сегментам.

Через 30 дней: оценить итоговый эффект на конверсию и выручку, с учётом сезонности.

Именно этот блок превращает “мы сделали задачу” в “мы достигли результата”.

Итог урока

После этого урока вы должны уметь:

отличать требования от вариантов решения;

собирать и сравнивать несколько вариантов решения по ценности, усилиям, рискам и внедрению;

вести простой регистр рисков и связывать риски с действиями;

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

организовывать управление изменениями требований через анализ влияния;

планировать измерение outcomes через KPI, baseline и окно наблюдения.

Дополнительные источники (по желанию)

Prosci ADKAR Model

Kotter — 8-Step Process for Leading Change (Kotter International)

ITIL (Wikipedia)

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

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

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

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

Если этот мост слабый, возникают типовые провалы:

Разработчики реализуют «как поняли», а не «как нужно бизнесу».

Тестирование превращается в угадывание.

На UAT всплывают базовые несостыковки, релиз срывается.

Документация отсутствует, и решение «не взлетает» в эксплуатации.

Цель бизнес-аналитика на этом этапе: сделать так, чтобы требования были тестируемыми, передача в разработку была однозначной, а приемка (UAT) — предсказуемой и измеримой.

!Схема «от требований к разработке, UAT и измерению результата»

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

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

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

кто выполняет действие (роль);

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

что именно должно произойти (наблюдаемый результат);

какие есть исключения и ограничения;

где границы (что не входит).

Полезные определения и термины можно сверять в ISTQB Glossary.

Признаки нетестируемого требования

«Сделать удобно», «быстро», «понятно» без измерения.

Не определено, что считать ошибкой и как она должна обрабатываться.

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

Не описаны статусы и их смысл (особенно в интеграциях и платежах).

Чеклист тестируемости для BA

Требование атомарное: его можно реализовать и проверить отдельно.

Есть критерии приемки: минимум 2–5 проверяемых условий.

Определены входные данные и обязательные поля.

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

Указаны бизнес-правила в формате «Если X, то Y».

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

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

Критерии приемки как основной инструмент тестируемости

Наиболее практичный формат — Given-When-Then (BDD-стиль), который вы уже видели в предыдущем уроке.

Given: контекст и предусловия.

When: действие.

Then: ожидаемый результат.

Пример (кейс оплаты):

Given пользователь оформляет заказ и платёжный провайдер возвращает отказ с кодом причины, When система получает ответ, Then код причины сохраняется в данных попытки платежа и виден поддержке в карточке заказа.

Given платёж отклонён, When пользователь видит результат оплаты, Then показывается понятное сообщение и доступна повторная попытка оплаты.

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

Связка требований и тест-дизайна

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

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

Передача в разработку: не «скинуть задачу», а выровнять понимание

Передача в разработку (handoff) — это управляемая коммуникация и фиксация решений. В Agile-среде это обычно реализуется через refinement (grooming), но смысл одинаковый в любом подходе.

Что должно быть готово перед передачей

Минимальный комплект для одной истории (user story) или требования:

Формулировка user story или краткое требование.

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

Ссылки на контекст: цель, KPI, сегмент пользователей.

Модели при необходимости: фрагмент BPMN/UML/ERD.

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

Открытые вопросы и допущения (явно помеченные).

Definition of Ready как «фильтр» качества входа

Во многих командах используют Definition of Ready: критерии того, что задача готова к разработке.

Пример практичного Definition of Ready для BA (как ориентир, не догма):

История понятна и согласована с владельцем продукта.

Есть критерии приемки и хотя бы один негативный сценарий.

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

Известны зависимости (интеграции, доступы, изменения данных).

Известно, как будет проверяться результат (QA и/или UAT).

Как проводить передачу: короткий сценарий встречи

Цель — не «прочитать текст задачи», а убрать неоднозначности.

BA напоминает цель и KPI, которые поддерживает история.

BA показывает основной сценарий и 2–3 критичных исключения.

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

Фиксируются решения и вопросы в журнале решений.

Полезная практика из Agile — совместное уточнение «BA/PO + Dev + QA» (часто называют three amigos): это снижает риск расхождений на этапе тестирования.

UAT: приемка пользователями и бизнесом

UAT (User Acceptance Testing) — это проверка, что решение подходит бизнесу и пользователям и может быть принято в работу.

Важно: UAT не заменяет QA.

QA отвечает на вопрос «работает ли согласно требованиям и без дефектов?»

UAT отвечает на вопрос «это можно принять и использовать для достижения цели?»

Терминологию можно сверять в ISTQB Glossary.

Кто участвует в UAT

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

Реальные пользователи (если возможно) или их представители.

BA как организатор сценариев, критериев приемки и фиксации результатов.

QA и разработка как поддержка (не как исполнители UAT).

Что готовит BA для UAT

Чтобы UAT не превратился в хаос, BA помогает подготовить:

Объем UAT: какие истории и сценарии проверяем.

UAT-сценарии на основе use cases и ключевых веток BPMN.

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

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

Критерии входа и выхода.

Критерии входа и выхода: чтобы приемка была управляемой

Критерии входа (примерные):

Завершено QA по согласованному набору тестов.

Доступна UAT-среда и нужные роли/доступы.

Подготовлены тестовые данные.

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

Критерии выхода (примерные):

Все сценарии UAT пройдены или имеют зафиксированные исключения.

Критичные дефекты исправлены или согласовано решение «не блокирует релиз».

Есть подтверждение приемки (sign-off) от ответственного стейкхолдера.

Как выглядят UAT-сценарии в удобном формате

UAT-сценарий — это не «всё подряд». Это проверка пользовательской ценности в реальном контексте.

!Пример шаблона UAT-сценария, который легко заполнять во время приемки

Триаж дефектов на UAT: как не сорвать релиз

На UAT часто находят не только баги, но и расхождения ожиданий. BA помогает отделить:

дефект реализации (сделано не по критериям приемки);

пробел требований (критерии не покрыли важный сценарий);

запрос на улучшение (не обязательно для релиза).

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

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

Документация в бизнес-анализе нужна не «для галочки», а чтобы:

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

операции могли работать по новому процессу;

бизнес мог принять результат;

команда не потеряла решения и определения через месяц.

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

Практичный набор артефактов (что и для кого)

| Артефакт | Зачем нужен | Основная аудитория | Когда обновлять | |---|---|---|---| | User story + критерии приемки | Однозначная реализация и тестирование | Dev, QA, PO/бизнес | При каждом изменении поведения | | Ключевые модели (BPMN/UML/ERD фрагменты) | Согласованность процесса, интеграций и данных | Dev, QA, операции | Когда меняются ветки процесса или данные | | Глоссарий терминов и статусов | Убирает разночтения в коммуникации | Все стейкхолдеры | Когда появляются новые термины/статусы | | Журнал решений (decision log) | Помнит «почему так», помогает в спорных ситуациях | BA, PO, лиды | После каждого значимого решения | | UAT-скрипты и результат приемки | Прозрачная приемка и следы ответственности | Бизнес, BA, QA | Перед UAT и по итогам | | Release notes и заметки для поддержки | Снижает нагрузку на поддержку после релиза | Поддержка, операции | Перед релизом |

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

Изменения ролей и ответственности.

Изменения шагов процесса и точек контроля.

Новые правила и исключения.

Что делать при сбое (операционные инструкции).

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

Новые поля и их смысл (например, reason_code у попытки платежа).

Источник данных и владельцы.

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

События для аналитики и мониторинга (чтобы измерять KPI).

Мини-кейс: «поддержка не видит причину отказа оплаты»

Контекст из прошлых уроков:

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

KPI: конверсия оплаты, число обращений «не прошла оплата», время решения обращения.

Пример того, как BA связывает тестируемость, передачу и UAT:

Требование оформляется как user story для поддержки: «видеть причину отказа в карточке заказа».

Добавляются критерии приемки с Given-When-Then, включая ошибки и ограничения доступа.

На refinement уточняются статусы и данные (через ERD-фрагмент «заказ — попытки платежа»).

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

Для поддержки готовятся release notes: что изменилось, где смотреть, что делать при UNKNOWN.

Результат: меньше «сюрпризов» на приемке и выше шанс, что изменение действительно сдвинет KPI.

Ритуал на 15 минут: как прокачивать качество передачи и приемки

Выберите одну историю из вашего бэклога или учебного кейса.

Проверьте её по чеклисту тестируемости и допишите 2 критерия приемки.

Добавьте один негативный сценарий (ошибка/исключение).

Сформулируйте один UAT-сценарий, который подтверждает ценность.

Запишите одно решение или допущение в журнал решений.

Эта короткая практика дает накопительный эффект: требования становятся яснее, разработка быстрее, а приемка спокойнее.

Итог урока

После этого урока вы должны уметь:

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

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

понимать роль UAT, организовывать сценарии и критерии входа/выхода;

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