Управление требованиями — неотъемлемая часть процесса разработки ПО. Преимущества наличия аналитика в проекте не всегда очевидны заказчику, но они неоценимы. Если иногда приходится переделывать функциональность, требования описаны частично, ни у кого нет четкого представления о конечном продукте и где можно взять актуальное описание требований, пора задуматься о привлечении бизнес-аналитика.
Однако очень часто в проекте нет выделенного бизнес-аналитика, и его обязанностями частично занимаются менеджер проекта или QA-менеджер. Такое совмещение иногда может навредить.
Дело в том, что у каждой роли — свои цели и области ответственности. Если PM или QA-менеджер вынужден, кроме основных обязанностей, брать на себя управление требованиями, из-за нехватки времени или квалификации в области бизнес-анализа что-то можно упустить. В результате может возникнуть неправильное понимание ожиданий заказчика, некорректная имплементация, неоправданные затраты времени и денег на переделывание функциональности и повторное тестирование. В итоге — срыв сроков и неудовлетворенный заказчик.
Конечно, такие проблемы возникают не во всех проектах, где нет выделенных бизнес-аналитиков. И в каждом случае нужно принимать во внимание множество факторов. Мы решили понять, какие индикаторы могут подсказать, что надо задуматься о привлечении бизнес-аналитика. Для этого сотрудники центра компетенции по бизнеc-анализу DataArt провели опрос ключевых менеджеров компании и получили наиболее распространенные признаки.
У клиента нет четкого представления о конечном продукте
Очень часто заказчик приходит к команде разработчиков с великолепной идеей, но без детального понимания, как эта идея должна бть реализована. В этой ситуации наилучший выход — провести дискавери-фазу в начале проекта. Бизнес-аналитик изучит целевую аудиторию будущего приложения, ожидания заказчика и конкурентов, соберет, проанализирует и аккуратно задокументирует первоначальные требования к продукту.
Это поможет клиенту получиться более полное понимание ожидаемой функциональности, а команде проекта — тщательнее оценить время и стоимость разработки. Полученная в ходе дискавери-фазы документация сэкономит время команды на выяснение требований в процессе разработки.
Много заинтересованных лиц на стороне заказчика
Если в проекте несколько стейкхолдеров, и каждый — источник требований, могут возникнуть следующие трудности:
- Избыточные требования.
- Противоречивые требования.
- Упущенные требования.
- Некорректная приоритезация.
И это — не полный список возможных проблем.
В этом случае бизнес-аналитик должен тщательно собрать пожелания всех стейкхолдеров, проанализировать их, систематизировать и приоретизировать.
Сложные требования
Уровень сложности требований нелегко определить однозначно. Но можно привести несколько примеров:
- Требования достаточно объемные, с большим количеством правил и исключений.
- Требования для проектов со сложной иерархией пользователей и различным уровнем доступа к функциональности.
- Требования для системы в индустрии, мало знакомой исполнителям, со специальной терминологией и правилами, которые кажутся очевидными заказчику, но не приходят в голову разработчикам.
Примеров, конечно, гораздо больше, и в подобных случаях требования должны быть подробно выяснены и детально описаны.
Крупные/продолжительные проекты
Последний, но очень важный фактор — размер и продолжительность проекта. Чем больше людей вовлечено в процесс разработки и чем больше функций создается в единицу времени, тем больше ответственности ложится на плечи бизнес-аналитика.
Для крупных и продолжительных проектов польза от выделенного бизнес-аналитика ощутима особенно в условиях часто меняющихся требований. За долгое время разработки могут приходить новые требования или изменяться старые.
Задача бизнес-аналитика — оценить влияние этих изменений на систему в целом и сообщить о противоречиях, до того, как изменения будут реализованы. В крупных и продолжительных проектах нередко происходит изменение состава команды, при этом новому человеку будет проще разобраться в существующей функциональности при наличии актуальной проектной документации и человека, знающего все детали приложения.
Автор: Надежда Тарасова, Senior Business Analyst.
