Будь бизнес-аналитиком

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

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

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

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

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

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

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

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

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

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

При совместной работе бизнес-аналитика и руководителя проекта можно ожидать синергетический эффект. Оба могут дополнить и усилить друг друга. Если в тандеме БА-РП не налажена коммуникация, то они будут только мешать друг другу.[4]

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

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

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

Требования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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