- PVSM.RU - https://www.pvsm.ru -
Управление требованиями — неотъемлемая часть процесса разработки ПО. Преимущества наличия аналитика в проекте не всегда очевидны заказчику, но они неоценимы. Если иногда приходится переделывать функциональность, требования описаны частично, ни у кого нет четкого представления о конечном продукте и где можно взять актуальное описание требований, пора задуматься о привлечении бизнес-аналитика.
Однако очень часто в проекте нет выделенного бизнес-аналитика, и его обязанностями частично занимаются менеджер проекта или QA-менеджер. Такое совмещение иногда может навредить.
Дело в том, что у каждой роли — свои цели и области ответственности. Если PM или QA-менеджер вынужден, кроме основных обязанностей, брать на себя управление требованиями, из-за нехватки времени или квалификации в области бизнес-анализа что-то можно упустить. В результате может возникнуть неправильное понимание ожиданий заказчика, некорректная имплементация, неоправданные затраты времени и денег на переделывание функциональности и повторное тестирование. В итоге — срыв сроков и неудовлетворенный заказчик.
Конечно, такие проблемы возникают не во всех проектах, где нет выделенных бизнес-аналитиков. И в каждом случае нужно принимать во внимание множество факторов. Мы решили понять, какие индикаторы могут подсказать, что надо задуматься о привлечении бизнес-аналитика. Для этого сотрудники центра компетенции по бизнеc-анализу DataArt провели опрос ключевых менеджеров компании и получили наиболее распространенные признаки.
Очень часто заказчик приходит к команде разработчиков с великолепной идеей, но без детального понимания, как эта идея должна бть реализована. В этой ситуации наилучший выход — провести дискавери-фазу в начале проекта. Бизнес-аналитик изучит целевую аудиторию будущего приложения, ожидания заказчика и конкурентов, соберет, проанализирует и аккуратно задокументирует первоначальные требования к продукту.
Это поможет клиенту получиться более полное понимание ожидаемой функциональности, а команде проекта — тщательнее оценить время и стоимость разработки. Полученная в ходе дискавери-фазы документация сэкономит время команды на выяснение требований в процессе разработки.
Если в проекте несколько стейкхолдеров, и каждый — источник требований, могут возникнуть следующие трудности:
И это — не полный список возможных проблем.
В этом случае бизнес-аналитик должен тщательно собрать пожелания всех стейкхолдеров, проанализировать их, систематизировать и приоретизировать.
Уровень сложности требований нелегко определить однозначно. Но можно привести несколько примеров:
Примеров, конечно, гораздо больше, и в подобных случаях требования должны быть подробно выяснены и детально описаны.
Последний, но очень важный фактор — размер и продолжительность проекта. Чем больше людей вовлечено в процесс разработки и чем больше функций создается в единицу времени, тем больше ответственности ложится на плечи бизнес-аналитика.
Для крупных и продолжительных проектов польза от выделенного бизнес-аналитика ощутима особенно в условиях часто меняющихся требований. За долгое время разработки могут приходить новые требования или изменяться старые.
Задача бизнес-аналитика — оценить влияние этих изменений на систему в целом и сообщить о противоречиях, до того, как изменения будут реализованы. В крупных и продолжительных проектах нередко происходит изменение состава команды, при этом новому человеку будет проще разобраться в существующей функциональности при наличии актуальной проектной документации и человека, знающего все детали приложения.
Автор: Надежда Тарасова, Senior Business Analyst.
Автор: DataArt
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/upravlenie-proektami/92526
Ссылки в тексте:
[1] Источник: http://megamozg.ru/post/16626/
Нажмите здесь для печати.