Есть ли роль бизнес-аналитика в гибкой среде?
Я уже довольно давно работаю бизнес-аналитиком, и этот вопрос возникает постоянно. Бизнес-аналитики зачастую считают, что они должны оправдывать свою роль в гибкой разработке.
Тот факт, что такой вопрос всё время задают, проистекает из руководства по Scrum. Scrum Guide определяет три роли в команде: команду разработчиков, Scrum -мастера и владельца продукта. Легко заметить, что здесь не упоминается о роли гибкого бизнес-аналитика. Нельзя сказать, что мы единственные, кто остался в стороне — также не определены роли для архитекторов решений, тестировщиков, группы обеспечения качества, менеджера развёртывания, дизайнера пользовательского интерфейса или технических писателей. Мы все каким-то образом попали в команду разработчиков.
Это неудивительно, учитывая, что сообщество Scrum.org декларирует, что команды разработчиков кросс-функциональны и у них есть все необходимые навыки, которые потребуются команде для создания инкремента продукта. Более того, ассоциация также не признает никаких титулов для членов команды разработчиков или каких-либо подгрупп.
Это все хорошо, за одним исключением: при организации работы по Scrum все задачи, реализуемые командой разработчиков, выполняются в рамках спринта. Однако работа бизнес-аналитика не основана на спринте.
Как бизнес-аналитик может справиться с этой противоречивой ситуацией?
3 обязанности бизнес-аналитика в Agile
Исходя из моего личного опыта работы бизнес-аналитиком в гибкой среде, иногда гибкие проекты включают Scrum-мастера или проектную группу, выполняющую его обязанности, но не всегда. Постоянными ролями обычно являются команда разработчиков, владелец продукта и бизнес-аналитик.
Пока команда разработчиков находится на начальной стадии гибкого процесса, самостоятельная группа дизайнеров пользовательского интерфейса и независимый специалист по обеспечению качества время от времени поддерживают разработку. Примечательно, что другие роли, такие как архитекторы решений, развёртывание и эксплуатация, а также технические писатели, находятся вне группы разработчиков.
Все роли в гибкой среде должны выполнять определённые обязанности, но я обнаружил, что беру на себя разные роли, в зависимости от особенностей организации, возглавляющей проект. В целом, обычно я поддерживал владельца продукта и выполняю ряд необходимых функций:
- Проведение оценок
- Создание моделей бизнес-процессов и системных требований
- Обеспечение правильного ведения пользовательских историй в бэклоге продукта
- Планирование, написание, анализ, проверка и поддержка проектной документации
Эти функции важны для гибкой среды, в которой я работаю. Однако со временем я понял, что методология гибкой разработки влияет на то, какую деятельность я могу вести как бизнес-аналитик.
Выделяются три конкретных области, в которых гибкий подход определяет то, как я выполняю свою работу.
Коммуникации
Если вы когда-либо работали в гибкой среде, вы знаете, что налаженные коммуникации жизненно важны для успеха ваших проектов. Agile требует согласованности решений всех заинтересованных лиц, включая менеджеров и пользователей. Разработка также сильно зависит от пользовательских историй и активных циклов обратной связи.
Но для того, чтобы коммуникация была эффективной, в гибкой среде должен быть мост между различными уровнями и командами. Этим мостом служит бизнес-аналитик.
Особенно важно сократить разрыв между разработчиками и стейкхолдерами. Бизнес-аналитик может помочь, переведя потребности бизнеса в пользовательские истории и донеся их до разработчиков, а также приоритизируя различные решения для всех команд в списке задач.
Бизнес-аналитик помогает обеспечивать соблюдение дисциплины коммуникаций между всеми группами, задействованными во время разработки.
Создание дорожной карты продукта
Дорожная карта продукта имеет первостепенное значение для своевременного развития и успеха любого гибкого проекта.
Дорожные карты помогают:
- Превращать потребности бизнеса в технологическое управление рабочим процессом
- Составлять графики, используемые при проведении анализа динамики проекта
- Делать разметку тестовых периодов на протяжении всего жизненного цикла проекта
Являясь, как было описано выше, мостом в коммуникациях, бизнес-аналитик может собрать все требования и превратить их в запланированные действенные шаги для команды.
Сохранение команды на правильном пути
Фокусировка команд — ещё одна фундаментальная обязанность бизнес-аналитик. Он следит за тем, чтобы менеджеры, разработчики и пользователи были сосредоточены на конечной цели проекта.
Я создаю множество моделей и делюсь ими с командами, чтобы все они имели общий взгляд на ситуацию. Я считаю моделирование важным инструментом по нескольким причинам:
- Переводит бизнес-требования проекта в бизнес-ценности, функциональность и пользовательский опыт
- Транслирует одинаковое понимание картины предметной области командам, действующим в разных физических средах
- Напоминает и удерживает внимание на целях и перспективе развития проекта для всех участников
Никогда не позволяйте никому приуменьшать и заставлять оправдывать роль бизнес-аналитика в гибкой среде. Аналитик обеспечивает значительную ценность для гибкой команды, когда придерживается исполнения описанных трёх обязанностей.
Сосредоточьтесь на улучшении сотрудничества, обмене знаниями, передаче навыков, повышении ценности работы, сохранении фокуса на приоритетные цели проекта и всестороннем развитии как специалиста.
Фрэнк Гамильтон
Оригинал статьи: https://www.agileconnection.com/article/fitting-agile-environment-business-analyst
Также по теме:
- Введение в OKR (Objectives and Key Results)
- «12 шагов к гибкому бизнесу» — новая книга Cleverics
- Самоорганизованная команда. Направлять или управлять?
- Разработчики в одиночку не могут сократить технический долг
- Побыть в шкуре бизнеса
