Портал №1 по управлению цифровыми
и информационными технологиями

Как бизнес-аналитику встроиться в гибкую среду?

Есть ли роль бизнес-аналитика в гибкой среде?

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

Тот факт, что такой вопрос всё время задают, проистекает из руководства по Scrum. Scrum Guide определяет три роли в команде: команду разработчиков, Scrum -мастера и владельца продукта. Легко заметить, что здесь не упоминается о роли гибкого бизнес-аналитика. Нельзя сказать, что мы единственные, кто остался в стороне — также не определены роли для архитекторов решений, тестировщиков, группы обеспечения качества, менеджера развёртывания, дизайнера пользовательского интерфейса или технических писателей. Мы все каким-то образом попали в команду разработчиков.

Это неудивительно, учитывая, что сообщество Scrum.org декларирует, что команды разработчиков кросс-функциональны и у них есть все необходимые навыки, которые потребуются команде для создания инкремента продукта. Более того, ассоциация также не признает никаких титулов для членов команды разработчиков или каких-либо подгрупп.

Это все хорошо, за одним исключением: при организации работы по Scrum все задачи, реализуемые командой разработчиков, выполняются в рамках спринта. Однако работа бизнес-аналитика не основана на спринте.

Как бизнес-аналитик может справиться с этой противоречивой ситуацией?

3 обязанности бизнес-аналитика в Agile

Исходя из моего личного опыта работы бизнес-аналитиком в гибкой среде, иногда гибкие проекты включают Scrum-мастера или проектную группу, выполняющую его обязанности, но не всегда. Постоянными ролями обычно являются команда разработчиков, владелец продукта и бизнес-аналитик.

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

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

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

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

Выделяются три конкретных области, в которых гибкий подход определяет то, как я выполняю свою работу.

Коммуникации

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

Но для того, чтобы коммуникация была эффективной, в гибкой среде должен быть мост между различными уровнями и командами. Этим мостом служит бизнес-аналитик.

Особенно важно сократить разрыв между разработчиками и стейкхолдерами. Бизнес-аналитик может помочь, переведя потребности бизнеса в пользовательские истории и донеся их до разработчиков, а также приоритизируя различные решения для всех команд в списке задач.

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

Создание дорожной карты продукта

Дорожная карта продукта имеет первостепенное значение для своевременного развития и успеха любого гибкого проекта.

Дорожные карты помогают:

  • Превращать потребности бизнеса в технологическое управление рабочим процессом
  • Составлять графики, используемые при проведении анализа динамики проекта
  • Делать разметку тестовых периодов на протяжении всего жизненного цикла проекта

Являясь, как было описано выше, мостом в коммуникациях, бизнес-аналитик может собрать все требования и превратить их в запланированные действенные шаги для команды.

Сохранение команды на правильном пути

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

Я создаю множество моделей и делюсь ими с командами, чтобы все они имели общий взгляд на ситуацию. Я считаю моделирование важным инструментом по нескольким причинам:

  • Переводит бизнес-требования проекта в бизнес-ценности, функциональность и пользовательский опыт
  • Транслирует одинаковое понимание картины предметной области командам, действующим в разных физических средах
  • Напоминает и удерживает внимание на целях и перспективе развития проекта для всех участников

Никогда не позволяйте никому приуменьшать и заставлять оправдывать роль бизнес-аналитика в гибкой среде. Аналитик обеспечивает значительную ценность для гибкой команды, когда придерживается исполнения описанных трёх обязанностей.

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

Фрэнк Гамильтон 
Оригинал статьи: https://www.agileconnection.com/article/fitting-agile-environment-business-analyst 


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Самое свежее

    • Определяем полюс потребителя
      При анализе и построении «путешествия заказчика» (customer journey) одной из важнейших задач является получение ответов на ряд вопросов, а именно: кто конкретно …
    • Семь распространённых мифов о DevOps
      В сообществе разработчиков бытует множество мифов о DevOps. И это и неудивительно, учитывая, сколько новшеств привнесла эта концепция за последние годы. DevOps — это …
    • Разрешение конфликтов в Agile-командах
      Большинство людей предпочло бы избегать конфликтов. Как специалисты по проектам, мы знаем, что это неизбежно, и мы также знаем, что несогласие может быть конструктивным. Но при …
    • Очередность прохождения курсов ITIL 4
      Имеет ли значение, в каком порядке проходить курсы по ITIL? Рассказывает аккредитованный тренер по ITIL 4 Игорь Фадеев. Cleverics — первая в России и одна из первых в …
    • 1 октября конференция «Роботизация бизнес-процессов 2020»
      1 октября 2020 издательство «Открытые системы» проведет ежегодную конференцию «Роботизация бизнес-процессов 2020» https://www.osp.ru/iz/rpa2020, где на одной площадке будут …
    • ITIL® 4 DITS — огонь, вода и медные трубы
      Мы уже писали о скором релизе последнего экзамена в сертификационной линейке ITIL 4 Digital and IT Strategy (DITS). Сейчас стоит добавить следующее (из информации, которую можно …
    • Деловая игра Grab@Pizza: вкусный кейс
      Деловые игры – один из наиболее эффективных видов тренинга, позволяющий на основе близкого к реальному кейса попрактиковаться в выстраивании любой работы. Участники деловой игры …
    • ITAM & SAMday пройдёт в Москве 2 октября
      ITAM & SAMday  – всероссийская независимая конференция, посвященная вопросам управления ИТ-активами и программными активами — пройдёт в Москве 2 октября в режиме …
    • Бэклог! — Как много в этом слове ...
      Команды, работающие над развитием различных продуктов, имеют одну общую цель: обеспечить максимальную скорость изменения своего продукта для реализации возникающих потребностей …
    • ITIL® 4 Specialist: Create, Deliver & Support
      Учебный курс о том, как организовать эффективную работу по созданию, внедрению и поддержке продуктов и услуг, в основе которого лежит публикация «ITIL® 4 Create, Deliver and …
  •  
  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT