Снова привет! Мы уже встречались в материале про карьерный рост бизнес‑аналитиков. Я — Лариса Дансарунова, бизнес‑аналитик с 9-летним опытом в IT‑индустрии. Ментор на курсе «Бизнес‑аналитик» в Практикуме и эксперт в «Эйч». Автор канала про бизнес‑анализ и карьеру в IT IThumanWork. Сегодня расскажу больше о задачах бизнес‑аналитика, а также — как меняется его роль в зависимости от методологии разработки ПО, которую используют в команде. И конечно — о самих методологиях и чем они различаются.

Как меняется роль бизнес-аналитика в разных методологиях разработки ПО

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

Бизнес-аналитик под «водопадом»

Методология Waterfall — «Водопад», представляет собой последовательный подход к разработке продуктов, при котором задачи выполняются шаг за шагом и строго в соответствии с изначальным планом. Термин был введён в 1970 году в статье директора Lockheed Software Technology Center Уинстона Уокера Ройса. Структура методологии «Водопад» построена на принципах диаграммы Ганта.

Принципы каскадной методологии:

• Документы обязательны — всё должно быть зафиксировано.

• Этапы работ идут строго последовательно. Следующий не начнётся, пока не завершится предыдущий.

• Нельзя вернуться на предыдущий этап — только, если пройти по всему циклу.

• Если требования изменились, нужно переписать техническое задание — ТЗ.

• ПО создается только на основе готового ТЗ. Во время разработки ТЗ редактировать нельзя, если требуется внести какие-то корректировки, сначала заканчиваем цикл, после создаём новую версию ТЗ.

В каскадной модели разработки бизнес-аналитик особенно важен на начальных этапах проекта: он практически в одиночку работает с заказчиком для выявления и документирования всех требований к будущей системе. При любой неточности, допущенной при сборе требований, придётся создавать новую версию ТЗ, и только после выпуска первой версии продукта. Когда разработчики приступают к работе, бизнес-потребности заказчика уже должны быть собраны и обработаны. Это значит, что аналитик готовит полное ТЗ по системе ещё до начала разработки. Для этого он ориентируется на ГОСТы или другие стандарты.

Бизнес-аналитик в семействе Agile-практик

Agile — философия разработки ПО и других продуктов, позволяющая оперативно реагировать на изменения требований. Основана она на 4 ценностях и 12 принципах, которые пришли на смену строгим взглядам Водопада.

4 ценности agile-манифеста — «не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева»:

1. Люди и взаимодействие важнее процессов и инструментов.

2. Работающий продукт важнее исчерпывающей документации.

3. Сотрудничество с заказчиком важнее согласования условий контракта.

4. Готовность к изменениям важнее следования первоначальному плану. 

12 принципов Agile:

1. Приоритет команды проекта — удовлетворение потребностей заказчика с помощью своевременной и регулярной поставки качественного продукта.

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

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

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

5. Над проектом должны работать мотивированные специалисты. Нужно создать для них необходимые условия и обеспечить поддержку.

6. Личное общение — самый практичный и эффективный способ обмена информацией в команде.

7. Работающий продукт — основной показатель прогресса.

8. Процессы в Agile должны быть настроены так, чтобы проект развивался устойчиво. Заказчики, разработчики и пользователи должны быть готовы к тому, что изменения будут вноситься равномерно.

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

10. Не стоит переусложнять проект — лишние процессы нужно свести к минимуму.

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

12. Команда должна постоянно искать способы работать эффективнее и корректировать свой стиль работы.

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

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

• Планирование. Аналитик помогает с определением сроков и необходимым составом задач исходя из понимания ценности и приоритетности функциональности продукта.

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

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

• Тестирование. Проводит исследование на фокус-группе, обучает пользователей. 

• Обратная связь. Помогает собрать и проанализировать фидбек, а также сделать выводы. 

• Запуск. Актуализирует или полностью обновляет состав задач.

Бизнес-аналитик и фреймворк Scrum

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

• проверка пользовательских историй, созданных владельцем продукта, на соответствие критериям приёмки. Все бизнес-правила должны быть учтены, а функциональность истории — соответствовать требованиям;

• анализ потребностей клиентов для поиска возможных решений;

• структурирование бэклога продукта на основе приоритетов, установленных владельцем продукта;

• создание пользовательских историй в соответствии с требованиями и обеспечение их соответствия критериям приёмки;

• предоставление и улучшение требований во время взаимодействия с владельцем продукта и заинтересованными сторонами — стейкхолдерами.

В Scrum-команде роль бизнес-аналитика может быть разнообразной в зависимости от контекста и потребностей. Основные модели включают в себя роль бизнес-аналитика как владельца продукта и как члена команды: 

• Владелец продукта. Бизнес-аналитик становится главным посредником между командой и стейкхолдерами, ответственным за понимание требований и определение приоритетов. Он создает карты пользовательских историй — User Story Map, бэклог продукта, участвует в планировании развития продукта или построении видения продукта — Product Vision, помогает команде разобраться в потребностях пользователей и стейкхолдеров.

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

Сравнение методологий глазами бизнес-аналитика

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

Если перед вами стоит выбор подходящей методологии для проекта с учётом особенностей работы бизнес-аналитика, рассмотрите следующие факторы:

• степень изменчивости требований проекта;

• уровень вовлечённости заказчика и его готовности к активному участию;

• жёсткость сроков и ограничения бюджета;

• размер и специфика проекта.

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