Бизнес-аналитик помогает команде понять потребность бизнеса, сформулировать требования и сохранить связь между исходной задачей и итоговым решением. При этом он работает на стыке нескольких ролей: Product Owner определяет приоритеты продукта, технические специалисты выбирают способ реализации, а Project Manager организует выполнение проекта.
Разберём, что входит в зону ответственности бизнес-аналитика, где проходят границы с соседними ролями, какие артефакты он готовит и как сопровождать требования после передачи в разработку.
Что входит в зону ответственности бизнес-аналитика?
В зону ответственности бизнес-аналитика обычно входит работа с требованиями на протяжении их жизненного цикла: выявить потребность, проанализировать и описать её, согласовать требования со стейкхолдерами, передать их команде и сопровождать последующие изменения.
В BABOK эта работа рассматривается через несколько областей знаний: выявление требований и взаимодействие со стейкхолдерами, управление жизненным циклом требований, анализ стратегии, анализ требований и определение дизайна, а также оценку решения.
При разграничении ответственности полезно смотреть на тип работы. Бизнес-аналитик отвечает за качество анализа требований и их связность, но не принимает единолично решения о приоритете продукта, архитектуре или сроках проекта.
Где проходит граница обязанностей бизнес-аналитика?
Граница проходит между анализом содержания требования и решениями, которые относятся к продукту, технологии и организации проекта. Бизнес-аналитик выясняет, какую проблему нужно решить, формализует потребность и описывает условия результата. Соседние специалисты определяют приоритет, способ реализации и план выполнения.
Границы ролей
Отдельно стоит разграничить работу бизнес-аналитика и Project Manager. Аналитик помогает определить и уточнить содержание требований, а менеджер проекта оценивает, как изменения влияют на сроки, ресурсы и общий план.
Например, если стейкхолдер меняет требование, бизнес-аналитик анализирует, какие другие требования и сценарии затронет изменение. Project Manager, в свою очередь, оценивает последствия для плана проекта.
Что берёт на себя системный аналитик?
Системный аналитик детализирует требования с точки зрения устройства информационной системы и технического взаимодействия её компонентов. В зависимости от структуры команды он может описывать интеграции, модели данных, API, форматы обмена и системные ограничения.
Бизнес-аналитик при этом сохраняет фокус на потребности бизнеса и пользователей: зачем требуется изменение, какой результат нужен и какие условия должны быть выполнены.
| Бизнес-аналитик Потребности бизнеса, процессы, бизнес- и пользовательские требования, критерии результата. | Системный аналитик Системная детализация требований, данные, взаимодействие компонентов и технические ограничения. |
На практике граница между ролями зависит от устройства команды. Поэтому в начале проекта полезно заранее определить, кто описывает интеграции, модель данных, API и другие технические детали.
Что остаётся за Product Owner?
Product Owner определяет приоритеты Product Backlog и принимает решения о том, какие элементы продукта важнее реализовать раньше. Бизнес-аналитик помогает подготовить для такого решения содержательную основу: уточняет требования, анализирует процессы и последствия изменений, детализирует элементы бэклога и критерии приёмки.
Фокус двух ролей отличается. Product Owner оценивает продуктовую ценность и приоритет, а бизнес-аналитик глубже анализирует потребность, процессы и взаимосвязи требований.
В некоторых командах бизнес-аналитик может выполнять часть функций proxy Product Owner. Тогда дополнительные полномочия лучше определить заранее, чтобы участники понимали, кто принимает окончательное решение о приоритетах.
Как меняются обязанности бизнес-аналитика по фазам проекта?
По мере развития проекта меняется соотношение задач бизнес-аналитика. На старте больше времени занимает исследование потребности и сбор требований, во время разработки — уточнения и сопровождение изменений, а ближе к внедрению — проверка соответствия результата согласованным требованиям и работа с переходными условиями.
На этапе внедрения могут появляться переходные требования: например, к миграции данных, обучению пользователей или временному процессу работы. Они действуют только во время перехода к новому решению, поэтому их также нужно выявить и зафиксировать заранее.
Как бизнес-аналитик собирает требования на старте проекта?
На старте проекта бизнес-аналитик подбирает техники сбора требований под конкретную ситуацию. Это могут быть интервью со стейкхолдерами, рабочие сессии, наблюдение за текущим процессом, анализ документов и данных, опросы и другие способы получения информации.
Основные способы собрать требования
- интервью со стейкхолдерами;
- рабочие сессии и воркшопы;
- наблюдение за текущим процессом;
- анализ документов и отчётов;
- опросы и анкеты;
- анализ данных из используемых систем.
После сбора информации важно подтвердить понимание потребности со стейкхолдерами. Бизнес-аналитик возвращает им сформулированный результат и уточняет спорные места до передачи требований команде.
Как бизнес-аналитик разграничивает функциональные и нефункциональные требования?
Функциональные требования описывают, что система должна делать, а нефункциональные — какие характеристики и ограничения должны соблюдаться при её работе.
Оба типа относятся к требованиям к решению. Помимо них, бизнес-аналитик может работать с бизнес-требованиями, требованиями стейкхолдеров и переходными требованиями.
За какие артефакты отвечает бизнес-аналитик?
Бизнес-аналитик работает с артефактами, которые описывают потребность, требования и связи между ними. Конкретный набор зависит от методологии и правил команды: не каждый проект требует отдельного документа для каждого типа информации.
Код, проектный план, дизайн-макеты и тестовая документация обычно относятся к ответственности других специалистов, хотя бизнес-аналитик может участвовать в их обсуждении и уточнении.
Пользовательская история не ограничивается одной формулировкой по шаблону «как пользователь, я хочу..., чтобы...». Она требует обсуждения деталей и критериев приёмки, по которым можно проверить результат.
Если история слишком крупная, её полезно разбить на подзадачи или более мелкие элементы работы, которые проще уточнить и проверить.
Как бизнес-аналитик оформляет техническое задание?
При подготовке технического задания важно связать каждое требование с его источником, понятной формулировкой и способом проверки. Структура документа зависит от проекта и принятых в компании стандартов.
Для автоматизированных систем в российской практике одним из формальных ориентиров может служить ГОСТ 34.602-2020. Он описывает состав технического задания, включая общие сведения, цели и назначение системы, требования, порядок разработки, контроля, приёмки и документирования.
Что проверить перед передачей требования
- понятен источник потребности;
- формулировка допускает однозначное прочтение;
- есть критерий проверки результата;
- указаны необходимые ограничения и условия.
Кому бизнес-аналитик передаёт требования в команде?
Одно требование может использоваться сразу несколькими специалистами, но каждому нужна своя часть информации. Product Owner использует её при работе с приоритетами, технические специалисты — при проектировании решения, разработчики — при реализации, QA — при подготовке проверок, а дизайнер — при проектировании пользовательских сценариев.
В обратную сторону возвращаются вопросы, технические ограничения и изменения.
Обратная связь от команды не менее важна: разработчики и технические специалисты уточняют неоднозначные места и сообщают об ограничениях, а стейкхолдеры могут менять исходные условия.
Чтобы уточнения не оставались только в переписке, полезно заранее договориться, как ставить задачи разработчикам: где хранится формулировка требования, критерии приёмки, связанные материалы и исходный запрос.
При передаче в тестирование важно сохранить связь с согласованным требованием. Если формулировка меняется в процессе работы, изменение также нужно зафиксировать, чтобы разработка и QA опирались на одну актуальную версию.
Кто отвечает за требование после передачи бизнес-аналитиком в разработку?
После передачи требования ответственность распределяется между несколькими участниками. Разработчики отвечают за реализацию, QA — за проверки в своей зоне, Project Manager — за организацию проекта, а бизнес-аналитик продолжает сопровождать содержание требований и изменения в них.
Задача аналитика на этом этапе — отвечать на вопросы по требованиям, оценивать влияние изменений на связанные условия и помогать сверять реализованное решение с тем, что было согласовано со стейкхолдерами.
Следить за движением работы проще, если команда заранее договорилась, как контролировать выполнение и где фиксировать изменение требований.
Как бизнес-аналитику сохранить прослеживаемость требований после передачи?
Прослеживаемость означает, что для требования можно восстановить связь как с причиной его появления, так и с последующей реализацией. В обратную сторону нужно видеть исходную потребность и стейкхолдера, в прямую — связанные задачи, проверки, результат и изменения.
Для такой связи можно использовать матрицу трассировки или связи непосредственно в рабочей системе. Отдельная таблица требует регулярного обновления, поэтому в итерационной работе часть связей удобно хранить рядом с задачами.
Например, у задачи можно сохранить ссылку на исходное требование, связанные материалы, исполнителя и текущий статус. Если требование изменилось, изменение также фиксируется в рабочем процессе, а не остаётся только в личной переписке.
В Strive можно вести задачи на общей канбан-доске, назначать исполнителей и отслеживать их движение по статусам. Исходные материалы и договорённости при этом можно связывать с рабочей задачей, чтобы участникам не приходилось восстанавливать историю по сообщениям.
Права участников и доступ к рабочим материалам можно дополнительно настроить через роли в Strive.
