Модель взаимодействия
В общем виде модель взаимодействия бизнес-аналитика и руководителя проекта выглядит так:
Особенности взаимодействия руководителя проекта и бизнес-аналитика
Особенности взаимодействия зависят от важности решаемых задач. Бизнес-аналитику важно понимать, какие ожидания к нему предъявляет руководитель проекта. Справедливо и обратное – понимание личной зоны ответственности поможет выстроить эффективную коммуникацию.
Подходы к улучшению коммуникации между бизнес-аналитиком и руководителем проекта
Базовые принципы коммуникации работают везде. В случае совместной работы бизнес-аналитика и руководителя проекта на первый план выходят 4 ключевых подхода.
1. Равенство: Помогает избежать конфликтов. Каждый сохраняет приоритетные задачи для своей роли, при этом остается место для взаимопомощи.
2. Ответственность: Помогает установить границы. Каждый понимает сферу ответственности и вклад друг друга, что исключает конкуренцию и способствует успеху проекта.
3. Открытость: Помогает обрести доверие. Каждый имеет возможность обсудить возникшую проблему и совместно найти лучшее решение.
4. Доверие: Помогает избавиться от предубеждений. Каждый осознает общую цель и вклад другого в достижение этой цели.
Сотрудничество бизнес-аналитика и руководителя проекта
При совместной работе бизнес-аналитика и руководителя проекта можно ожидать синергетический эффект. Оба могут дополнить и усилить друг друга. Если в тандеме БА-РП не налажена коммуникация, то они будут только мешать друг другу.[4]
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. Бизнес-требования
Для чего это нужно нашей компании?
– Автоматизировать процессы
– Сократить затраты времени на этапах процесса
– Повысить качество продукции
– Оптимизировать принятие решений
2. Требования стейкхолдеров
Что хочет стейкхолдер?
– Рассчитать производительность и экономическую эффективность
– Получить отчеты в интересующих форматах и детализации
– Отправить запросы и получить актуальную информацию
3. Нефункциональные требования
Какие условия окружающей среды нужно учитывать и для чего?
– Создать условия для локализации
– Обеспечить юридическую, финансовую и аудиторскую прозрачность
