Научись превращать расплывчатую просьбу заказчика в понятную проблему, проверяемые требования и согласованный способ решения. Девять уроков построены вокруг рабочих ситуаций, а не только терминов.
Бизнес-аналитик помогает понять проблему или возможность, согласовать нужный результат и описать изменения так, чтобы бизнес и команда разработки одинаково их понимали.
Главная мысль: ценность аналитика — ясность задачи и проверяемость результата, а не количество документов.
С кем работает аналитик
Заказчик и владелец процесса объясняют цель и ограничения.
Пользователи показывают фактическую работу и исключения.
Разработчики и архитекторы оценивают варианты реализации.
Тестировщики и бизнес проверяют соответствие требованиям.
Пример. Просят добавить статус заказа. Аналитик выясняет, какую проблему он решит, кто меняет статус, какие переходы разрешены и как измерить улучшение.
Проверь себя
Заказчик просит новую кнопку. Что спросить первым?
Урок 2 · постановка задачи
От жалобы к проблеме и цели
Фраза «заказы обрабатываются слишком долго» — повод для исследования, а не готовое требование. Нужны текущий уровень, желаемый результат, период и границы работ.
Пять вопросов перед началом
Что происходит и кого затрагивает?
Какую бизнес-цель хотим улучшить?
Как измерим успех и с чем сравним?
Что входит в объём работ, а что нет?
Какие сроки, бюджет и зависимости ограничивают решение?
Расплывчато: «Сделать обработку заказов удобнее». Проверяемо: «Снизить медианное время подтверждения с 18 до 2 часов за 8 недель и не увеличить число ошибок».
Не придумывай показатели за заказчика. Согласуй формулу, источник данных и период до начала разработки.
Проверь себя
Какая формулировка лучше подходит для контроля?
Урок 3 · исследование
Заинтересованные стороны и интервью
У одного процесса несколько взглядов: руководитель видит показатели, оператор — исключения, клиент — ожидание, разработчик — ограничения системы. Выслушай разные стороны и проверяй противоречия.
Как подготовить интервью
Уточни роль человека и решения, на которые он влияет.
Попроси показать реальный недавний случай шаг за шагом.
Обсуди обычный сценарий и исключения.
Уточни источники данных, документы и используемые системы.
Перескажи вывод своими словами и попроси подтвердить.
Не так: «Вам нужна автоматическая рассылка, верно?» Лучше: «Как сейчас сообщаете о задержке? Когда уведомление не доходит? Что должно произойти после отправки?»
Проверь себя
Какой вопрос полезнее задать оператору?
Урок 4 · требования
Бизнес-требования, функции и ограничения
Требование описывает нужный результат, поведение или ограничение достаточно конкретно, чтобы его можно было согласовать и проверить.
Вид
Пример
Бизнес-требование
Снизить долю заказов, ожидающих подтверждения более 2 часов.
Функциональное
Показывать оператору список неподтверждённых заказов.
Нефункциональное
Список открывается не дольше 2 секунд при согласованной нагрузке.
Бизнес-правило
Нельзя передать заказ в сборку до подтверждения оплаты.
Хорошее требование конкретно, необходимо, непротиворечиво, проверяемо и связано с целью. Слова «быстро», «удобно», «надёжно» требуют уточнения.
Проверь себя
«Страница открывается за 2 секунды при 500 активных пользователях» — это…
Урок 5 · сценарии
Истории пользователей и Варианты использования
История пользователя кратко описывает ценность для роли пользователя. Вариант использования подробнее фиксирует предусловия, основной путь, альтернативы и результат.
Шаблон История пользователя: «Как [роль], я хочу [действие], чтобы [ценность]». Пример: «Как оператор поддержки, хочу видеть возраст заказа, чтобы первым обрабатывать задержанные заказы».
Уточни сценарий
Кто начинает действие и зачем?
Какие условия нужны заранее?
Как выглядит нормальный путь?
Что произойдёт при ошибке, запрете или отсутствии данных?
Как выглядит успешный результат?
История пользователя не заменяет все требования. Правила, исключения и критерии проверки нужно фиксировать отдельно.
Проверь себя
Какой вариант больше похож на История пользователя?
Урок 6 · моделирование
AS-IS, TO-BE и основы BPMN
AS-IS — как процесс работает сейчас. TO-BE — как он должен работать после изменения. Сначала зафиксируй фактические шаги и исключения, затем предлагай улучшение.
Поток заказа:
Поступил оплаченный заказ.
Проверены обязательные данные.
При полном наборе данных заказ передаётся оператору.
При нехватке данных заказ направляется на уточнение.
С чего начать описание процесса для автоматизации?
Урок 7 · приёмка
Критерии приёмки, тестирование и UAT
Критерии приёмки описывают условия, при которых заказчик признаёт требование выполненным. Их можно проверить одинаковым способом, в том числе при ошибке.
Дано: оператор имеет доступ к ожидающим заказам. Когда: оператор сортирует список по времени ожидания. Тогда: в начале списка самые давно ожидающие заказы, у каждого показаны статус и время создания.
Проверь три вида сценариев
Позитивный — корректные данные и разрешённое действие.
Негативный — нет доступа, данных или доступности сервиса.
Граничный — пустой список, много строк, повторный запрос.
UAT — пользовательская приёмка, когда бизнес-пользователи проверяют решение на рабочих сценариях.
Проверь себя
Какой критерий приёмки лучше?
Урок 8 · управление объёмом
Приоритеты, риски и управление изменениями
Ресурсы ограничены, поэтому требования сравнивают по пользе, риску, срочности, стоимости и зависимостям. Приоритеты должны быть согласованы с ответственными участниками.
Москва
Значение
Пример
Должно быть
Без этого цель не достигается.
Отображение статуса заказа.
Должен был иметь
Важно, но есть временный обход.
Фильтр по времени ожидания.
Мог бы иметь
Дополнение при наличии ресурсов.
Цветные метки.
теперь не будет
Сознательно не входит в текущий объём.
Полный редизайн программы лояльности.
Уточни цель нового пожелания.
Определи связанные требования и системы.
Оцени влияние на срок, бюджет, риски и объём.
Зафиксируй решение и обнови документацию.
Проверь себя
Что делать, когда заказчик просит новую функцию после согласования?
Урок 9 · итоговая практика
Собери черновик требований
Ситуация. В интернет-магазине часть оплаченных заказов долго ждёт подтверждения. Клиенты обращаются в поддержку, операторы вручную проверяют несколько систем. Причина ещё не доказана.
Заполни черновик как бизнес-аналитик. Не придумывай неизвестное — отмечай, что нужно выяснить, у кого и как проверить.
Хороший результат связывает проблему с целью, содержит требования и критерии проверки, отмечает неизвестные детали. Самопроверка помогает увидеть пропуски, но не заменяет согласование с заказчиком.
Проверь себя
Как завершить первичное исследование?
Результат обучения
Постановка проблемы, цели и границ работ.
Выявление участников и сбор требований.
Истории пользователей, Варианты использования и основы BPMN.