Особенности работы бизнес-аналитика в IT. Часть 2

Продолжаем разговор об особенностях профессии бизнес-аналитика в сфере IT и об этапах его работы. Начало здесь.

Этап № 3: анализ и согласование требований

Итак, перечень требований готов. Теперь можно приступать к обсуждению этих требований всей командой. Для этого бизнес-аналитик подключает менеджера проекта, разработчиков, дизайнеров, QA-специалистов. Все вышеперечисленные эксперты с высоты своего опыта способны указать на неточности требований, на их неполноту, противоречивость и т. д.

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

Результаты анализа и систематизации согласовываются с заказчиком.

Этап № 4: создание прототипов

Как сделать так, чтобы заказчик имел представление, как именно будет выглядеть и функционировать уже готовое решение? Для этого бизнес-аналитик может подготовить специальный прототип пользовательского интерфейса. Здесь следует понимать, что речь не идет о создании дизайна будущего продукта, скорее, подразумевается создание макетов экранов, где будут отражаться некие базовые функции. То есть мы говорим о создании интерактивного прототипа приложения, где будут сымитированы переходы между экранами, работа кнопок и т. д. Среди инструментов, позволяющих это сделать, -- программы типа Sketch, Axure, Atomic.

Этап № 5: передача требований команде

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

Этап № 6: управление изменениями в требованиях

При работе над проектом требования нередко меняются, уточняются и дорабатываются, особенно если вспомнить, что мы живем в эпоху гибких методологий разработки ПО типа Agile. А это значит, что бизнес-аналитик не теряет связи с заказчиком и продолжает с ним коммуницировать. И если возникает необходимость внедрить в разработку новую функциональность, бизнес-аналитик добавляет ее в перечень задач для команды разработки (бэклог). Задачи в данном случае формируются не техническим языком, а в формате цепочки шагов, необходимых к выполнению пользователем для получения конкретного результата (User Stories -- пользовательские сценарии).

По материалам https://www.scnsoft.by/blog/.