Диана Анатольевна Сюняева "Будь бизнес-аналитиком"

2. Руководитель проекта

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

3. Бизнес-аналитик

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

Модель взаимодействия

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

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

Особенности взаимодействия зависят от важности решаемых задач. Бизнес-аналитику важно понимать, какие ожидания к нему предъявляет руководитель проекта. Справедливо и обратное – понимание личной зоны ответственности поможет выстроить эффективную коммуникацию.

Подходы к улучшению коммуникации между бизнес-аналитиком и руководителем проекта

Базовые принципы коммуникации работают везде. В случае совместной работы бизнес-аналитика и руководителя проекта на первый план выходят 4 ключевых подхода.

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

2. Ответственность: Помогает установить границы. Каждый понимает сферу ответственности и вклад друг друга, что исключает конкуренцию и способствует успеху проекта.

3. Открытость: Помогает обрести доверие. Каждый имеет возможность обсудить возникшую проблему и совместно найти лучшее решение.

4. Доверие: Помогает избавиться от предубеждений. Каждый осознает общую цель и вклад другого в достижение этой цели.

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

При совместной работе бизнес-аналитика и руководителя проекта можно ожидать синергетический эффект. Оба могут дополнить и усилить друг друга. Если в тандеме БА-РП не налажена коммуникация, то они будут только мешать друг другу.[4 - Источник: exposit.com/blog/pm-and-ba-collaboration-during-project-development-best-practices/]

1. Управление требованиями: Сотрудничество РП и БА помогает предотвратить крах проекта с помощью активной работы с требованиями: создание прототипов, разработку плана управления проектом и др. После окончания сбора требований, РП и БА поддерживают контакт для решения проблем, возникающих при разработке.

2. Анализ производительности: Когда проект уже выпущен, БА и РП могут совместно анализировать достижение КПЭ с учетом изначально заложенных ожиданий. Это поможет определить приоритеты будущих улучшений продукта.

3. Приемочное тестирование пользователей: Помогает снизить риски на ранних этапах и сэкономить время и средства, затрачиваемые на разработку. Совместная работа РП и БА поможет улучшить планы тестирования, валидацию действий при тестировании, анализ результатов и др.

Требования

Следующий шаг приведет нас к главе, посвященной требованиям.

Все начинается с идеи. Например, такой идеи: «Хочу, чтобы холодильник сам заказывал продукты, когда надо». Такая «хотелка» к моменту итоговой реализации начинает обрастать другими «хотелками», как снежный ком при спуске с горы. Юристы хотят, чтобы пользовательское соглашение к холодильнику было размером с «Войну и мир». Продуктовые магазины хотят, чтобы холодильник заказывал у них только самые дорогие продукты. А пользователь хочет… вкусно поесть и не переживать за пустой холодильник. И чтобы было место для магнитиков.

Набор таких «хотелок» и называется требованиями.

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

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

Требования – это спецификация того, что должно быть реализовано. В них описано поведение системы, свойства системы или ее атрибуты. Требования могут служить ограничениями в процессе разработки системы. [5 - Лучшее определение по мнению К. Вигерса]

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

Требования не равно цель

Важно понимать, что Цель и Требование – это разные понятия в рамках реализации проекта.

Цель проекта – это желаемый результат (эффекты, выгоды), достигаемый в итоге успешного осуществления проекта. Основными показателями здесь являются получение результата, заданного уровня качества, в рамках временных и стоимостных ограничений.

Требования – это формализованное описание потребностей (т.е. конкретные функции, свойства и атрибуты).

Цель. Строго связано с бизнес-показателями. Ставится 1 раз на весь период реализации проекта.

Пример: Повысить эффективность процесса обслуживания на 20%.

Требования могут ставиться многократно к разным объектам внутри проекта изменений.

Пример: Запускать процесс X ежедневно с 9 до 10 утра за исключением вторника и воскресенья.

Требования могут быть не только к ИТ-решению, но и к бизнес-процессам (о них будем говорить позже).

К ИТ-системе / к ИТ-решению

– Выбираем конкретную компоненту в ИТ-решении

– Описываем ее функциональность

– Описываем нефункциональные требования

Акценты на:

– атрибуты системы

– сроки осуществления операций

– использование справочников

К Бизнес-процессу

– Выбираем процесс или часть процесса (с учетом рамок процесса)

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

– Описываем условия выполнения подшагов процесса

Акценты на:

– сроках выполнения

– участниках и ответственных

– ограничениях процесса

– условиях процесса

Существует универсальная формула описания требований:

Пример 1

1.1. Требуется, чтобы будильник включался ежедневно с понедельника по пятницу в 7.00 и играл с повышением звука от уровня 1 до уровня 5.

1.2. В случае отсутствия реакции на будильник в течение 1 минуты, будильник производит паузу в течение 20 секунд и цикл п. 1.1 запускается заново.

Пример 2

2.1. Требуется автоматизированная отправка платежного поручения на адрес контрагента из системы N в момент осуществления транзакции К для каждой операции с меткой J.

2.2. В случае отсутствия электронной почты в информационной системе N система записывает в неуведомительные логи, что платежное поручение по контрагенту в транзакции К отправлено не было.

Классификация

Сбор требований начинается с определения того, что требование должно из себя представлять. Разобраться в типах требований поможет общая классификация.

1. Бизнес-требования

Для чего это нужно нашей компании?

– Автоматизировать процессы

– Сократить затраты времени на этапах процесса

– Повысить качество продукции