Бизнес-аналитик и владелец продукта

В последней статье мы говорили о роли БА в гибких проектах, рассматривая, что остаётся неизменным и что меняется по сравнению с традиционными подходами. В этой статье мы коснёмся спорного вопроса о том, как роль БА меняется и пересекается с владельцем продукта (ВП). А также поговорим о сходствах и различиях, включая такие опасные признаки как «БA как посредник ВП» и позитивные модели, такие как «БA как поддержка ВП».

Владелец продукта (ВП)

Во-первых, давайте удостоверимся, что мы понимаем роль владельца продукта (ВП). Она возникла в Scrum, но часто также используется вне Scrum, в других гибких и гибридных методологиях. Scrum несёт ответственность за максимизацию стоимости продукта и работу команды разработчиков. Это включает в себя ответственность за управление бэклогом. Экстремальное программирование (XP) имеет аналогичную роль «Клиент», DSDM имеет одного или нескольких «Бизнес-посредников», в зависимости от масштаба проекта. Все они играют аналогичную роль в управлении бэклогом, в том числе:

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

Преимущества за пределами бэклог-менеджмента

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

Как правило, играть картой «Бизнес просит Х» выгоднее, чем играть картой «Команда просит Х», когда речь идёт об освобождении от процесса или о том, чтобы ускорить решение вопроса. Именно эти преимущества при просьбе чего-либо и ясность бизнес-направления убеждают многих людей в том, что БА не может так же успешно играть роль ВП. Думаю, в теории всё так и есть, но жизнь сложна и запутана. Является ли хороший БА лучше плохого ВП? Как насчёт того, что БА помогает заменить ВП в его отсутствие? Поддерживается ли владелец продукта бизнес-аналитиком наилучшим образом? Давайте посмотрим дальше.

Бизнес-аналитик (БA)

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

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

 

Usually a BA — Обычно БА	Usually a PO – Обычно ВП	Can be a BA or PO – Может быть БА или ВП
Requirements Strategy – стратегия управления Project Focus – нацеленность на проект Non-functional Requirements – нефункциональные требования Help story splitting – помощь в разбиении историй Modeling — моделирование Alignment to business architecture – согласование бизнес-архитектуры Bridge business to technical communications – бизнес-мост с техническими средствами связи	Business Strategy – бизнес-стратегия Customer Focus – нацеленность на клиента Competitive Analysis – анализ конкуренции Business priorities – бизнес-приоритеты Business engagements – бизнес-участие Funding endorsement – утверждение финансирования Market analysis – анализ рынка Request advocating – отстаивание интересов Issue escalation – эскалация проблемы	Product Strategy – стратегия в отношении продукта Tactical Focus – тактическая нацеленность Business case – экономическое обоснование Story gathering – сбор истории Story writing – написание истории Story cost/benefit analysis – анализ затрат и выгод истории Backlog refinement – усовершенствование бэклога Acceptance Testing – приёмочное тестирование Facilitating  – содействие

«Обычно …» и «Может быть …» — важные определители. Есть некоторые очень технические владельцы продуктов и некоторые очень подкованные в бизнесе БА. Если вы давно работаете с командой или партнёром, то передача знаний и навыков — нормальное и желательное явление. Люди также часто меняют работу: из бизнес-роли в техническую роль и наоборот. Все люди разные и сложные. Роли помогают нам говорить о работе, но редко помогают уловить что происходит на самом деле или же, что команде проекта действительно необходимо.

Есть вид личности, что представляет собой смесь навыков. Я бы предпочёл объединить БА и ВП — отличное решение, даже если некоторых бизнес-знаний будет не хватать или техническая сторона будет не такой сильной. Когда не будет коммуникации и сотрудничества или они будут серьезно скомпрометированы, определение ролей и навыков не сможет заставить активных игроков принять участие.

Общие БА / ВП Модели

Давайте рассмотрим некоторые сценарии, которые часто разыгрываются в проектных командах. Мы начнем с классического ВП в качестве моста или звена со стороны делового сообщества к команде разработчиков. Это показано ниже на первой диаграмме с надписью «1) ВП в качестве моста».

Business Community – бизнес-сообщество PO – ВП Development Team – команда разработчиков _______________________________________ ✓ВП в качестве моста Direct representation of business goals and needs – прямое представительство бизнес-целей и потребностей Interface to other business stakeholders – зона контакта с другими заинтересованными сторонами бизнеса

 

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

Ситуация, которую мы хотим избежать, это когда БА действует в качестве посредника между бизнесом и командой разработчиков, как показано ниже «2) БА, как PO Go-Between».

Business Community – бизнес-сообщество PO – ВП BА – БА Development Team – команда разработчиков _____________________________________________ ✓БА, как посредник Dilution of goals and needs – разбавление целей и задач Restrictor of two-way communications – ограничение двусторонней связи

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

БА в качестве доверенного лица ВП — обычная компромиссная ситуация.

Business Community – бизнес-сообщество BА – БА Development Team – команда разработчиков __________________________________________________ ✓БА в качестве доверенного лица ВП Can work but misses benefits beyond backlog management – может работать, но не хватает преимуществ присущих бэклог менеджменту May be better than intermittent PO or absent PO – может быть лучше, чем непостоянный ВП или отсутствующий ВП

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

• Привлечение других заинтересованных сторон бизнеса
• Источник дополнительного финансирования
• Отстаивание бизнес-интересов

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

 Лучшим решением будет «БА, как поддержка ВП».

 

Business Community – бизнес-сообщество PO – ВП BА – БА Development Team – команда разработчиков ___________________________________________________ ✓БА, как поддержка ВП PO represents business goals and needs – ВП представляет собой бизнес-цели и потребности BA supports PO with backlog refinement directed by the PO – БА поддерживает ВП с доработкой бэклога под руководством ВП

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

Хорошие бизнес-аналитики могут помочь владельцам продуктов в изучении деятельности бэклог менеджмента и инструментов, обеспечивая коучинг. Тем не менее, пока роли БА и ВП пересекаются друг с другом, их нельзя назвать синонимичными или взаимозаменяемыми. С точки зрения предпочтений, в идеале я хотел бы иметь как квалифицированных и представительных БА, так и ВП, которые всегда в зоне доступа для проектных групп. Если это не удастся, тогда хотелось бы видеть вовлечённого в процесс владельца продукта (или частично вовлечённого), который имеет поддержку со стороны бизнес-аналитика.

За пределами этого идеального представления мы сталкиваемся с некоторыми вопросами. Отсутствующий или негативно настроенный ВП может быть замещён БА или действовать через команду разработчиков.

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

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

Original