Владелец продукта против Бизнес-аналитика (PO vs. BA)

Есть много сценариев взаимодействия Владельца продукта (Product owner) с Бизнес-аналитиком (Business analyst) внутри команды. Из моего опыта: иногда Бизнес-аналитик может заменить Владельца продукта или Владелец продукта сильно погружен в проект, делая роль бизнес-аналитика избыточной.

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

Эта статья описывает взаимодействие и пересечение ролей Бизнес-аналитика (BA) и Владельца продукта (PO). Мы рассмотрим в ней сходства и различия моделей взаимодействия, как не самых лучших, «BA как посредник», так и хороших «BA как помощник PO».

Для начала, рассмотрим роль Владельца продукта. Эта роль появилась в методологии Scrum, но её используют и в других гибких или гибридных методологиях. В Scrum описывают эту роль как ответственную за максимальную ценность продукта и за работу команды разработки. Она включает в себя также ответственность за управление бэклогом продукта.

Методологии, такие как «Экстремальное программирование» имеет похожую роль «Заказчика». Или методология «Метод разработки динамических систем» имеет одного и более «Бизнес-амбасадора», в зависимости от масштаба проекта. Все эти роли, ответственные за управление бэклогом продукта, включают в себя:

• Обеспечение доступности и прозрачности бэклога продукта. Делает бэклог продукта понятным для всех, демонстрируя над чем команда будет работать в будущем.

• Обеспечение понимания командой, задач бэклога и их приоритета.

• Определение задач бэклог продукта.

• Определение порядка выполнения задач бэклог продукта на пути к достижению цели.

• Ответственность за ценность работы, выполняемой командой.

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

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

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

Теоретически, я согласен с этим, но как правило в жизни всё сложнее. Разве хороший Бизнес-аналитик не лучше решит задачу, чем нерадивый Владелец продукта? Что если Бизнес-аналитик поможет вам заменить отсутствующего Владельца продукта? Возможно совместная работа Владельца продукта и Бизнес-аналитика приведёт к синергии? Давайте разберёмся.

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

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

Очень важно понимать, что это не точное разделение на «Только… » и «Пересечение». Допустим, есть несколько Владельцев продукта, имеющих технические образование и навыки, и есть несколько Бизнес-аналитиков, погружённых в бизнес-сообщество. При длительной работе в команде, обмен знаниями и навыками – это нормально, даже полезно.

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

Так же не стоит забывать про личные качества и soft skills участников команды. Проще работать с Бизнес-аналитиком или Владельцем продукта, с которым можно договориться или устроить мозговой штурм, даже если у него не будет хватать бизнес-навыков или технических навыков, чем с закрытым гением, не умеющим работать в команде. Когда в команде пропадает коммуникация, люди, знания, навыки не играют никакой роли.

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

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

Бизнес-аналитик выступает как посредник Владельца продукта в общении с командой разработки. Не самый лучший сценарий.

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

Однако, agile manifest включает принцип:

«Представители бизнеса и команда разработки должны работать вместе на протяжении всего проекта».

Во время повседневной работы придётся иметь дело с обильным потоком требований и проблемами с приоритетами. Задача Бизнес-аналитика отфильтровать поток информации и перевести его на язык, понятный для команды разработки.

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

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

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

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

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

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

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

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

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

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

Оригинал статьи