скачать книгу бесплатно
2) Моделирует и анализирует бизнес-процессы;
3) Выявляет и анализирует требования, в т.ч. в виде пользовательских историй;
4) Проводит оценку связности требований на предмет взаимных зависимостей, ограничений и целей, создает матрицу трассировки требований;
5) Составляет проектную документацию в части управления требованиями;
6) Разрабатывает финансово-экономическую модель проекта и готовит обоснование эффективности проекта для получения инвестиций;
7) Разрабатывает сценарии тестирования;
Существует достаточно много моделей разработки программного обеспечения. Для начинающего аналитика важно различать два подхода – классический и гибкий.
Каскадная модель («водопад», waterfall)
Классический подход к реализации и внедрению ИТ-решений, в котором каждая следующая стадия начинается только после того, как заканчивается предыдущая (о ней мы уже немного говорили ранее).
– Сбор и анализ требований: определение заинтересованных сторон, выявление и формализация требований
– Проектирование системы: выбор оптимального варианта реализации, детальное проектирование системы
– Разработка: создание ПО
– Тестирование: тестирование реализованного ПО: функционала, интеграций
– Эксплуатация и поддержка: передача в эксплуатацию пользователям и оказание технической поддержки
Проект с использованием гибких методологий
При высокой неопределенности целевого результата создание ИТ-продуктов реализуется с использованием гибких методологий.
Бизнес-аналитик может быть задействован на всех этапах реализации проекта вне зависимости от выбранной модели реализации.
Тогда сначала разрабатывается прототип приложения (который может быть даже не рабочим), чтобы убедиться, что продукт будет отвечать потребностям пользователей. Потом отбирается часть требований, и разрабатывается MVP – минимально жизнеспособный продукт. Он сразу передается пользователям для проверки гипотезы о востребованности. И затем продукт развивается дальше.
В этом случае реализация происходит короткими итерациями, внутри которых каждая доработка проходит все этапы.
А после каждой итерации происходит актуализация требований и задач.
Взаимодействие с руководителем проекта
Руководитель проекта (РП), с одной стороны, относится к стейкхолдерам, а, с другой стороны, сам активно общается со стейкхолдерами и разработчиками.
Для бизнес-аналитика важно понимать разницу между своими задачами и задачами руководителя проекта.
Роли
1. Заказчик
Формулирует запрос
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. Бизнес-требования
Для чего это нужно нашей компании?
– Автоматизировать процессы
– Сократить затраты времени на этапах процесса
– Повысить качество продукции
– Оптимизировать принятие решений
2. Требования стейкхолдеров
Что хочет стейкхолдер?
– Рассчитать производительность и экономическую эффективность
– Получить отчеты в интересующих форматах и детализации
– Отправить запросы и получить актуальную информацию
3. Нефункциональные требования
