Управление требованиями — неотъемлемая часть процесса разработки ПО. Преимущества наличия аналитика в проекте не всегда очевидны заказчику, но они неоценимы. Если иногда приходится переделывать функциональность, требования описаны частично, ни у кого нет четкого представления о конечном продукте и где можно взять актуальное описание требований, пора задуматься о привлечении бизнес-аналитика.

Однако очень часто в проекте нет выделенного бизнес-аналитика, и его обязанностями частично занимаются менеджер проекта или QA-менеджер. Такое совмещение иногда может навредить.

Дело в том, что у каждой роли — свои цели и области ответственности. Если PM или QA-менеджер вынужден, кроме основных обязанностей, брать на себя управление требованиями, из-за нехватки времени или квалификации в области бизнес-анализа что-то можно упустить. В результате может возникнуть неправильное понимание ожиданий заказчика, некорректная имплементация, неоправданные затраты времени и денег на переделывание функциональности и повторное тестирование. В итоге — срыв сроков и неудовлетворенный заказчик.

Конечно, такие проблемы возникают не во всех проектах, где нет выделенных бизнес-аналитиков. И в каждом случае нужно принимать во внимание множество факторов. Мы решили понять, какие индикаторы могут подсказать, что надо задуматься о привлечении бизнес-аналитика. Для этого сотрудники центра компетенции по бизнеc-анализу DataArt провели опрос ключевых менеджеров компании и получили наиболее распространенные признаки.

У клиента нет четкого представления о конечном продукте

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

Это поможет клиенту получиться более полное понимание ожидаемой функциональности, а команде проекта — тщательнее оценить время и стоимость разработки. Полученная в ходе дискавери-фазы документация сэкономит время команды на выяснение требований в процессе разработки.

Много заинтересованных лиц на стороне заказчика

Если в проекте несколько стейкхолдеров, и каждый — источник требований, могут возникнуть следующие трудности:

• Избыточные требования.
• Противоречивые требования.
• Упущенные требования.
• Некорректная приоритезация.

И это — не полный список возможных проблем.

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

Сложные требования

Уровень сложности требований нелегко определить однозначно. Но можно привести несколько примеров:

• Требования достаточно объемные, с большим количеством правил и исключений.
• Требования для проектов со сложной иерархией пользователей и различным уровнем доступа к функциональности.
• Требования для системы в индустрии, мало знакомой исполнителям, со специальной терминологией и правилами, которые кажутся очевидными заказчику, но не приходят в голову разработчикам.

Примеров, конечно, гораздо больше, и в подобных случаях требования должны быть подробно выяснены и детально описаны.

Крупные/продолжительные проекты

Последний, но очень важный фактор — размер и продолжительность проекта. Чем больше людей вовлечено в процесс разработки и чем больше функций создается в единицу времени, тем больше ответственности ложится на плечи бизнес-аналитика.

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

Задача бизнес-аналитика — оценить влияние этих изменений на систему в целом и сообщить о противоречиях, до того, как изменения будут реализованы. В крупных и продолжительных проектах нередко происходит изменение состава команды, при этом новому человеку будет проще разобраться в существующей функциональности при наличии актуальной проектной документации и человека, знающего все детали приложения.

Автор: Надежда Тарасова, Senior Business Analyst.