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

в виде пользовательских историй;

4) Проводит оценку связности требований на предмет взаимных зависимостей, ограничений и целей, создает матрицу трассировки требований;

5) Составляет проектную документацию в части управления требованиями;

6) Разрабатывает финансово-экономическую модель проекта и готовит обоснование эффективности проекта для получения инвестиций;

7) Разрабатывает сценарии тестирования;

Существует достаточно много моделей разработки программного обеспечения. Для начинающего аналитика важно различать два подхода – классический и гибкий.

Каскадная модель («водопад», waterfall)

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

– Сбор и анализ требований: определение заинтересованных сторон, выявление и формализация требований

– Проектирование системы: выбор оптимального варианта реализации, детальное проектирование системы

– Разработка: создание ПО

– Тестирование: тестирование реализованного ПО: функционала, интеграций

– Эксплуатация и поддержка: передача в эксплуатацию пользователям и оказание технической поддержки

Проект с использованием гибких методологий

При высокой неопределенности целевого результата создание ИТ-продуктов реализуется с использованием гибких методологий.

Бизнес-аналитик может быть задействован на всех этапах реализации проекта вне зависимости от выбранной модели реализации.

Тогда сначала разрабатывается прототип приложения (который может быть даже не рабочим), чтобы убедиться, что продукт будет отвечать потребностям пользователей. Потом отбирается часть требований, и разрабатывается MVP – минимально жизнеспособный продукт. Он сразу передается пользователям для проверки гипотезы о востребованности. И затем продукт развивается дальше.

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

А после каждой итерации происходит актуализация требований и задач.

Взаимодействие с руководителем проекта

Руководитель проекта (РП), с одной стороны, относится к стейкхолдерам, а, с другой стороны, сам активно общается со стейкхолдерами и разработчиками.

Для бизнес-аналитика важно понимать разницу между своими задачами и задачами руководителя проекта.

Роли

1. Заказчик

Формулирует запрос

2.