Особенности работы бизнес-аналитика в IT. Часть 2
Продолжаем разговор об особенностях профессии бизнес-аналитика в сфере IT и об этапах его работы. Начало здесь.
Этап № 3: анализ и согласование требований
Итак, перечень требований готов. Теперь можно приступать к обсуждению этих требований всей командой. Для этого бизнес-аналитик подключает менеджера проекта, разработчиков, дизайнеров, QA-специалистов. Все вышеперечисленные эксперты с высоты своего опыта способны указать на неточности требований, на их неполноту, противоречивость и т. д.
Кроме того, командное согласование позволяет убедиться, что сформированные требования можно осуществить в поставленные сроки и с учетом имеющихся ресурсов. Далее команда принимает решение, какую функциональность следует реализовать раньше всего. В случае необходимости, главный разработчик вкупе с архитектором ПО и аналитиком могут распределить эти требования по подсистемам.
Результаты анализа и систематизации согласовываются с заказчиком.
Этап № 4: создание прототипов
Как сделать так, чтобы заказчик имел представление, как именно будет выглядеть и функционировать уже готовое решение? Для этого бизнес-аналитик может подготовить специальный прототип пользовательского интерфейса. Здесь следует понимать, что речь не идет о создании дизайна будущего продукта, скорее, подразумевается создание макетов экранов, где будут отражаться некие базовые функции. То есть мы говорим о создании интерактивного прототипа приложения, где будут сымитированы переходы между экранами, работа кнопок и т. д. Среди инструментов, позволяющих это сделать, -- программы типа Sketch, Axure, Atomic.
Этап № 5: передача требований команде
На этом этапе бизнес-аналитик фиксирует требования в соответствующей спецификации -- Software Requirement Specification. Данный документ станет основным при планировании процесса разработки. В этой спецификации будут содержаться описания функций и функциональных возможностей, которые будут имплементированы. В принципе, в различных IT-компаниях могут существовать различные шаблоны для вышеупомянутого документа. Однако есть и нюансы, например, иногда проект относится к сферам, которые подлежат строгому регулированию: страхование, медицина и пр. В этом случае при сборе и оформлении требований обязательно учитываются отраслевые стандарты, которые действуют в стране заказчика.
Этап № 6: управление изменениями в требованиях
При работе над проектом требования нередко меняются, уточняются и дорабатываются, особенно если вспомнить, что мы живем в эпоху гибких методологий разработки ПО типа Agile. А это значит, что бизнес-аналитик не теряет связи с заказчиком и продолжает с ним коммуницировать. И если возникает необходимость внедрить в разработку новую функциональность, бизнес-аналитик добавляет ее в перечень задач для команды разработки (бэклог). Задачи в данном случае формируются не техническим языком, а в формате цепочки шагов, необходимых к выполнению пользователем для получения конкретного результата (User Stories -- пользовательские сценарии).
По материалам https://www.scnsoft.by/blog/.
