0 added
0 removed
Original
2026-01-01
Modified
2026-03-10
1
<p>Продолжаем разговор об особенностях профессии<strong>бизнес-аналитика</strong>в сфере IT и об этапах его работы. Начало<a>здесь</a>.</p>
1
<p>Продолжаем разговор об особенностях профессии<strong>бизнес-аналитика</strong>в сфере IT и об этапах его работы. Начало<a>здесь</a>.</p>
2
<h4>Этап № 3: анализ и согласование требований</h4>
2
<h4>Этап № 3: анализ и согласование требований</h4>
3
<p>Итак,<strong>перечень требований</strong>готов. Теперь можно приступать к обсуждению этих требований всей командой. Для этого бизнес-аналитик подключает менеджера проекта, разработчиков, дизайнеров, QA-специалистов. Все вышеперечисленные эксперты с высоты своего опыта способны указать на неточности требований, на их неполноту, противоречивость и т. д.</p>
3
<p>Итак,<strong>перечень требований</strong>готов. Теперь можно приступать к обсуждению этих требований всей командой. Для этого бизнес-аналитик подключает менеджера проекта, разработчиков, дизайнеров, QA-специалистов. Все вышеперечисленные эксперты с высоты своего опыта способны указать на неточности требований, на их неполноту, противоречивость и т. д.</p>
4
<p>Кроме того, командное согласование позволяет убедиться, что сформированные требования можно осуществить в поставленные сроки и с учетом имеющихся ресурсов. Далее команда принимает решение, какую функциональность следует реализовать раньше всего. В случае необходимости, главный разработчик вкупе с архитектором ПО и аналитиком могут распределить эти требования по подсистемам.</p>
4
<p>Кроме того, командное согласование позволяет убедиться, что сформированные требования можно осуществить в поставленные сроки и с учетом имеющихся ресурсов. Далее команда принимает решение, какую функциональность следует реализовать раньше всего. В случае необходимости, главный разработчик вкупе с архитектором ПО и аналитиком могут распределить эти требования по подсистемам.</p>
5
<p>Результаты анализа и систематизации согласовываются с заказчиком.</p>
5
<p>Результаты анализа и систематизации согласовываются с заказчиком.</p>
6
<h4>Этап № 4: создание прототипов</h4>
6
<h4>Этап № 4: создание прототипов</h4>
7
<p>Как сделать так, чтобы заказчик имел представление, как именно будет выглядеть и функционировать уже готовое решение? Для этого бизнес-аналитик может подготовить специальный<strong>прототип пользовательского интерфейса</strong>. Здесь следует понимать, что речь не идет о создании дизайна будущего продукта, скорее, подразумевается создание макетов экранов, где будут отражаться некие базовые функции. То есть мы говорим о создании интерактивного прототипа приложения, где будут сымитированы переходы между экранами, работа кнопок и т. д. Среди инструментов, позволяющих это сделать, -- программы типа<strong>Sketch</strong>,<strong>Axure</strong>,<strong>Atomic</strong>.</p>
7
<p>Как сделать так, чтобы заказчик имел представление, как именно будет выглядеть и функционировать уже готовое решение? Для этого бизнес-аналитик может подготовить специальный<strong>прототип пользовательского интерфейса</strong>. Здесь следует понимать, что речь не идет о создании дизайна будущего продукта, скорее, подразумевается создание макетов экранов, где будут отражаться некие базовые функции. То есть мы говорим о создании интерактивного прототипа приложения, где будут сымитированы переходы между экранами, работа кнопок и т. д. Среди инструментов, позволяющих это сделать, -- программы типа<strong>Sketch</strong>,<strong>Axure</strong>,<strong>Atomic</strong>.</p>
8
<h4>Этап № 5: передача требований команде</h4>
8
<h4>Этап № 5: передача требований команде</h4>
9
<p>На этом этапе бизнес-аналитик фиксирует требования в соответствующей спецификации --<strong>Software Requirement Specification</strong>. Данный документ станет основным при планировании процесса разработки. В этой спецификации будут содержаться описания функций и функциональных возможностей, которые будут имплементированы. В принципе, в различных IT-компаниях могут существовать различные шаблоны для вышеупомянутого документа. Однако есть и нюансы, например, иногда проект относится к сферам, которые подлежат строгому регулированию: страхование, медицина и пр. В этом случае при сборе и оформлении требований обязательно учитываются отраслевые стандарты, которые действуют в стране заказчика.</p>
9
<p>На этом этапе бизнес-аналитик фиксирует требования в соответствующей спецификации --<strong>Software Requirement Specification</strong>. Данный документ станет основным при планировании процесса разработки. В этой спецификации будут содержаться описания функций и функциональных возможностей, которые будут имплементированы. В принципе, в различных IT-компаниях могут существовать различные шаблоны для вышеупомянутого документа. Однако есть и нюансы, например, иногда проект относится к сферам, которые подлежат строгому регулированию: страхование, медицина и пр. В этом случае при сборе и оформлении требований обязательно учитываются отраслевые стандарты, которые действуют в стране заказчика.</p>
10
<h4>Этап № 6: управление изменениями в требованиях</h4>
10
<h4>Этап № 6: управление изменениями в требованиях</h4>
11
<p>При работе над проектом требования нередко меняются, уточняются и дорабатываются, особенно если вспомнить, что мы живем в эпоху гибких методологий разработки ПО типа<strong>Agile</strong>. А это значит, что бизнес-аналитик не теряет связи с заказчиком и продолжает с ним коммуницировать. И если возникает необходимость внедрить в разработку новую функциональность, бизнес-аналитик добавляет ее в перечень задач для команды разработки (бэклог). Задачи в данном случае формируются не техническим языком, а в формате цепочки шагов, необходимых к выполнению пользователем для получения конкретного результата (<strong>User Stories</strong>-- пользовательские сценарии).</p>
11
<p>При работе над проектом требования нередко меняются, уточняются и дорабатываются, особенно если вспомнить, что мы живем в эпоху гибких методологий разработки ПО типа<strong>Agile</strong>. А это значит, что бизнес-аналитик не теряет связи с заказчиком и продолжает с ним коммуницировать. И если возникает необходимость внедрить в разработку новую функциональность, бизнес-аналитик добавляет ее в перечень задач для команды разработки (бэклог). Задачи в данном случае формируются не техническим языком, а в формате цепочки шагов, необходимых к выполнению пользователем для получения конкретного результата (<strong>User Stories</strong>-- пользовательские сценарии).</p>
12
<p><em>По материалам https://www.scnsoft.by/blog/.</em></p>
12
<p><em>По материалам https://www.scnsoft.by/blog/.</em></p>
13
13