[] Business analyst, Requirement specialist, Product Owner и другие. Чем отличаются схожие на первый взгляд роли?
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
В 2021 наметился тренд: повышенный спрос на бизнес-аналитиков. Практически каждый проект стремится заполучить в свои ряды специалиста с такой ролью. При этом вакансии с примерно одинаковым описанием должностных обязанностей поражают многообразием названий: requirement specialist, business analyst, system analyst, (proxy) product owner, product manager. Меня зовут Святослав Щербатюк, я сотрудничаю с ЕРАМ в роли ведущего бизнес-аналитика. В этом материале предлагаю порассуждать, почему сложилась такая ситуация, отличаются ли эти роли между собой и если да, то чем. 
Прежде всего отмечу, что такая разница в названиях и описаниях вакансий свидетельствует о том, что в IT-индустрии практически нет единого понимания данных ролей, которое бы опиралось на какую-то фундаментальную дисциплину. Отрасль – молодая и динамично развивающаяся, а для формирования понятийного аппарата необходима более-менее наработанная, устоявшаяся, стабильная практика. Вдобавок к этому, практически повсеместное использование гибких методологий как раз способствует тому, что любые понятия претерпевают быстрые изменения, адаптируясь под изменяющиеся требования рынка. Кроме того, фреймворки, которые используют разные компании и проекты, также могут интерпретировать организацию процессов и описание ролей с определенной долей уникальности. И это не говоря о том, что и сами фреймворки постоянно обновляются и адаптируются под изменяющиеся условия рынка!Простой поиск в Google выдает десятки статей и мнений, которые описывают различия этих ролей. В этой статье я постараюсь изложить максимально лаконично наиболее характерные черты каждой. Requirement specialist (также иногда встречается requirement engineer, requirement analyst) vs Business analystВ первую очередь необходимо отметить, что границы и отличия между этими ролями достаточно размыты. Часто компании по-разному называют роли с одинаковым набором функций. Но все же основной особенностью requirement инженера является фокус на имплементации конкретного функционала, потому он держит под контролем сбор и документирование требований, которые связаны с процессом. Requirement инжиниринг в отличии от бизнес-анализа не предусматривает анализ и улучшение бизнес-процессов, описание бизнес-кейсов. В нем нет фокуса на доставку business value клиенту. Поэтому любые решения и документация являются инженерно-обоснованными (engineering driven), но не обоснованными бизнесом (business driven). А большинство действий requirement специалиста направлены на три активности, связанные с функциональными и нефункциональными требованиями:
- их выявление;
- документирование;
- менеджмент.
Активности эти, безусловно, связаны с менеджментом заинтересованных лиц и потенциальных конфликтов между ними, умением правильно выявить и задокументировать требования, донести их команде. Однако характерной особенностью все же является то, что requirement инжиниринг не предусматривает необходимость работать с бизнес-требованиями, требованиями пользователей. Такой специалист не будет преломлять контекст на функциональные и нефункциональные требования, которые выявит, он не обязан анализировать, насколько они позволяют достигнуть поставленных бизнес-задач. Круг его стейкхолдеров (или заинтересованных лиц) обычно ограничен subject matter экспертами, у которых он и выявляет требования.
А вот для роли ВА бизнес-контекст любых требований и решений, который сравнивают с первоначальными требованиями и целями бизнеса, первоочереден. Потому количество коммуникаций у этого эксперта намного выше, в круге стейкхолдеров – представители бизнеса, а анализируемые документы включают в себя все, что так или иначе связано с бизнес-процессами и их результатами.Повторюсь: граница между этими ролями достаточно условна. Пожалуй, единственным характерным признаком, по которому роль специалиста можно отнести к бизнес-анализу, является наличие «бизнес-компонента» в его ежедневных активностях, фокус на конкретных бизнес-результатах той или иной функциональности. То есть роль бизнес-аналитика включает в себя задачи реквайремент специалиста, как показано на графике.Подробнее о разнице этих ролей написано здесь, здесь, и здесь.Business Analyst vs (Proxy) Product OwnerВсе характеристики бизнес-аналитика, которые я перечислил выше, очень похожи на описание другой распространенной роли – Product Owner. В чем же все-таки отличия?Начнем с того, что такой популярный фреймворк как Scrum изначально не предусматривает роли ВА, вместо нее существует роль Product Owner-а. Но так как в реальном мире вряд ли существует проект, который на 100% соответствует всем канонам, роль бизнес-аналитика все-таки появилась в проектах, работающих по Scrum-like фреймворкам. Разграничения между ролями бизнес-аналитика и Product Owner-а, как и в случае с requirement специалистом весьма нечеткое. Если коротко, то Product Owner:
- выступает представителем бизнеса для команды разработки;
- отвечает за определение порядка выполнения задач бэклога на пути к бизнес-цели;
- отвечает за бизнес-ценность, которую должна доставить команда.
Исходя из этого есть несколько способов взаимодействия ролей бизнес-аналитика и Product Owner-а:1. Бизнес-аналитик выполняет роль Product Owner-а.
Источник картинки https://www.romanpichler.com/blog/business-analysts-in-scrum/В этом случае ВА, помимо своих функций по выявлению, документированию требований, трансляции бизнес-контекста команде разработки, будет выступать «владельцем» продукта от лица клиента. Это значит, что он будет проверять у команды результаты итерации от имени бизнеса, принимать продуктовые решения, отвечать за успешное достижение бизнес-результатов конкретного функционала. Данный подход типичен для продуктовых компаний.2. Бизнес-аналитик является частью команды разработки. 
Источник каhttps://www.romanpichler.com/blog/business-analysts-in-scrum/ртинки В такой конфигурации ВА работает в команде разработки на ежедневной основе. Он транслирует бизнес-контекст требований, полученный от Product Owner-а инженерам. Все решения утверждает представитель бизнеса – Product Owner.3. Бизнес-аналитик является посредником между Product Owner-ом и командой разработки.
Источник картинки https://www.romanpichler.com/blog/business-analysts-in-scrum/По сути, в данном подходе бизнес-аналитик дублирует функции ProductOwner-а для команды разработки. Последние два подхода весьма распространены в аутсорсе, где на стороне заказчика контактом, транслирующим бизнес-контекст, является Product Owner, а на стороне исполнителя – бизнес-аналитик.
Если кратко охарактеризовать отличие этих двух ролей, то Product Owner предоставляет, транслирует видение продукта и финальные бизнес-цели, не беспокоясь о том, как это реализовать технически. Он – точка контакта с клиентом, которая помогает соотнести ожидания бизнеса с возможностями команды разработки, выяснить открытые вопросы и принять решения.Подробнее о формах взаимодействия этих двух ролей можно прочитать вот здесь и здесь, а также посмотреть в видео моего коллеги Дмитрия Лозовицкого. Business Analyst vs System Analyst
Системный аналитик – еще одна роль, которую часто путают с ВА. В чем же отличие? Упрощенно говоря, бизнес-аналитик работает со сбором и документированием требований, которые связаны с достижениями бизнес-задач, а системный аналитик описывает, как система должна работать технически. Бизнес-аналитик не учитывает платформы реализации и технологии, а стремится максимально учесть все пожелания и цели заказчика, обеспечить полноту, корректность и непротиворечивость требований. Системному аналитику не важен фокус на бизнес-ценности и цели бизнеса, его задача – принять во внимание все особенности работы с определенной технологией и платформой, выбрать оптимальный способ реализации всех заявленных функционально-технических требований, определить платформу реализации, способы интеграции. Главный фокус системного аналитика – нефункциональные требования.Детальнее о системных аналитиках можно почитать тут и тут. Business Analyst vs Product Manager
Упомянув разграничение роли бизнес-аналитика с ролью ProductOwner-a, следует также рассмотреть разграничение этой роли с ролью Product менеджера. В целом, то, что отличает бизнес-аналитика от ProductOwner-a применимо и для разграничения сфер ответственности между бизнес-аналитиком и Product менеджером. Разница в том, ProductOwner оперирует тактическими целями и задачами, а Product менеджер занимается развитием продукта на уровне стратегии. В задачи последнего входит:
- определением видения и миссии продукта;
- создание продуктовых дорожных карт и KPI;
- приоритезация функционала;
- создание стратегии вывода продукта на рынок и его монетизации.
Кроме того, если Product Owner ориентирован на команду и взаимодействие с ней, то продакт менеджер – на конечного пользователя продукта и требования рынка.Рассмотрев все многообразие похожих ролей (requirement specialist, business analyst, system analyst, (proxy) product owner, product manager) можно резюмировать, что основная разница между этими ролями – в предмете фокуса:
- requirement специалист фокусируется преимущественно на сборе и менеджменте требований;
- системный аналитик – на технической стороне проекта;
- бизнес-аналитик – на соответствии требований целям бизнеса, доставке бизнес-ценности заказчику;
- Product Owner – на достижении тактических целей продукта, принятии тактических решений для команды разработки, проверке результата спринта, доставленного командой;
- Product менеджер фокусируется на стратегических целях продукта и успех продукта на рынке.
Возникает вопрос: а может ли один человек совместить в себе все эти роли? На мой взгляд, на маленьких проектах это возможно. Но в случае крупных, в которые вовлечено много участников, могут возникнуть сложности с переключением фокуса на разные задачи и функции. Вообще, споры о том, нужны ли бизнес-аналитики, забавляют. Когда начинаешь выяснять у тех, кто отрицает пользу этой роли, кто на проекте занимается всеми коммуникациями, сбором и приоритизацией требований и прочими типичными для ВА вопросами, оказывается, что делает это проектный менеджер, лид команды разработки или клиент. То есть роль остается, просто ее выполняет кто-то другой.Потому, несмотря на определенную банальность и оскомину от вопроса «В чем, по-вашему, состоит роль бизнес-аналитика?», который мы часто слышим на собеседованиях, он нескоро потеряет свою актуальность. В качестве послесловия. Business Analyst vs Data Analyst (and others)Бывают ли еще какие-либо виды аналитиков, работа которых может функционально пересекаться с ВА? Да, например, data-аналитики, которые работают с массивами информации, извлекая из них сведения, ценные для бизнеса с точки зрения принятия оптимальных управленческих решений, ищут закономерности, визуализируют анализируемую информацию и формулируют гипотезы по повышению KPI бизнеса за счет оптимизации бизнес-процессов. 
С бизнес-аналитиками их объединяет то, что и те, и другие анализируют бизнес-процессы и участвуют в их оптимизации, могут формулировать, собирать и документировать требования к ПО. Однако data-аналитики используют для этого специфическую технику – настройку, сбор и анализ больших наборов данных.Прочитать более детально о вышерассмотренных и других видах аналитиков можно тут и тут. Святослав Щербатюк, Lead Business Analyst, EPAM
===========
Источник:
habr.com
===========
Похожие новости:
- [Удалённая работа] EPAM Anywhere: как это работает. Субъективный взгляд изнутри
- [Машинное обучение] Топ 6 библиотек Python для визуализации: какую и когда лучше использовать? (перевод)
- [Высокая производительность, Программирование] Парное программирование. Быть или не быть?
- [Анализ и проектирование систем] Аналитик в автоматизации — кто он и чем занимается
- [Python, Data Mining, Big Data, R, Визуализация данных] Оценка кредитного портфеля на R
- [Анализ и проектирование систем, Проектирование и рефакторинг, Алгоритмы] Маленькими шагами к красивым решениям
- [Python, SQL, Data Mining, R, Data Engineering] Звездные войны или подробный гайд по dplyr
- [Python, SQL, Big Data, Визуализация данных, Data Engineering] Первые шаги в BI-аналитике. Роль Data Engineering
- [Программирование, Развитие стартапа, Офисы IT-компаний, Будущее здесь, IT-компании] Стажировка и наставничество как инструмент развития команд
- [Тестирование веб-сервисов, Управление продуктом, Статистика в IT] Как выбрать уровень статистической значимости для AB-теста и как интерпретировать результат
Теги для поиска: #_biznesanaliz (бизнес-анализ), #_sistemnyj_analiz (системный анализ), #_product_management, #_data_analysis, #_product_owner, #_requirements_management, #_requirements_engineering, #_blog_kompanii_epam (
Блог компании EPAM
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 25-Ноя 11:57
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 В 2021 наметился тренд: повышенный спрос на бизнес-аналитиков. Практически каждый проект стремится заполучить в свои ряды специалиста с такой ролью. При этом вакансии с примерно одинаковым описанием должностных обязанностей поражают многообразием названий: requirement specialist, business analyst, system analyst, (proxy) product owner, product manager. Меня зовут Святослав Щербатюк, я сотрудничаю с ЕРАМ в роли ведущего бизнес-аналитика. В этом материале предлагаю порассуждать, почему сложилась такая ситуация, отличаются ли эти роли между собой и если да, то чем.  Прежде всего отмечу, что такая разница в названиях и описаниях вакансий свидетельствует о том, что в IT-индустрии практически нет единого понимания данных ролей, которое бы опиралось на какую-то фундаментальную дисциплину. Отрасль – молодая и динамично развивающаяся, а для формирования понятийного аппарата необходима более-менее наработанная, устоявшаяся, стабильная практика. Вдобавок к этому, практически повсеместное использование гибких методологий как раз способствует тому, что любые понятия претерпевают быстрые изменения, адаптируясь под изменяющиеся требования рынка. Кроме того, фреймворки, которые используют разные компании и проекты, также могут интерпретировать организацию процессов и описание ролей с определенной долей уникальности. И это не говоря о том, что и сами фреймворки постоянно обновляются и адаптируются под изменяющиеся условия рынка!Простой поиск в Google выдает десятки статей и мнений, которые описывают различия этих ролей. В этой статье я постараюсь изложить максимально лаконично наиболее характерные черты каждой. Requirement specialist (также иногда встречается requirement engineer, requirement analyst) vs Business analystВ первую очередь необходимо отметить, что границы и отличия между этими ролями достаточно размыты. Часто компании по-разному называют роли с одинаковым набором функций. Но все же основной особенностью requirement инженера является фокус на имплементации конкретного функционала, потому он держит под контролем сбор и документирование требований, которые связаны с процессом. Requirement инжиниринг в отличии от бизнес-анализа не предусматривает анализ и улучшение бизнес-процессов, описание бизнес-кейсов. В нем нет фокуса на доставку business value клиенту. Поэтому любые решения и документация являются инженерно-обоснованными (engineering driven), но не обоснованными бизнесом (business driven). А большинство действий requirement специалиста направлены на три активности, связанные с функциональными и нефункциональными требованиями:
 А вот для роли ВА бизнес-контекст любых требований и решений, который сравнивают с первоначальными требованиями и целями бизнеса, первоочереден. Потому количество коммуникаций у этого эксперта намного выше, в круге стейкхолдеров – представители бизнеса, а анализируемые документы включают в себя все, что так или иначе связано с бизнес-процессами и их результатами.Повторюсь: граница между этими ролями достаточно условна. Пожалуй, единственным характерным признаком, по которому роль специалиста можно отнести к бизнес-анализу, является наличие «бизнес-компонента» в его ежедневных активностях, фокус на конкретных бизнес-результатах той или иной функциональности. То есть роль бизнес-аналитика включает в себя задачи реквайремент специалиста, как показано на графике.Подробнее о разнице этих ролей написано здесь, здесь, и здесь.Business Analyst vs (Proxy) Product OwnerВсе характеристики бизнес-аналитика, которые я перечислил выше, очень похожи на описание другой распространенной роли – Product Owner. В чем же все-таки отличия?Начнем с того, что такой популярный фреймворк как Scrum изначально не предусматривает роли ВА, вместо нее существует роль Product Owner-а. Но так как в реальном мире вряд ли существует проект, который на 100% соответствует всем канонам, роль бизнес-аналитика все-таки появилась в проектах, работающих по Scrum-like фреймворкам. Разграничения между ролями бизнес-аналитика и Product Owner-а, как и в случае с requirement специалистом весьма нечеткое. Если коротко, то Product Owner:
 Источник картинки https://www.romanpichler.com/blog/business-analysts-in-scrum/В этом случае ВА, помимо своих функций по выявлению, документированию требований, трансляции бизнес-контекста команде разработки, будет выступать «владельцем» продукта от лица клиента. Это значит, что он будет проверять у команды результаты итерации от имени бизнеса, принимать продуктовые решения, отвечать за успешное достижение бизнес-результатов конкретного функционала. Данный подход типичен для продуктовых компаний.2. Бизнес-аналитик является частью команды разработки.  Источник каhttps://www.romanpichler.com/blog/business-analysts-in-scrum/ртинки В такой конфигурации ВА работает в команде разработки на ежедневной основе. Он транслирует бизнес-контекст требований, полученный от Product Owner-а инженерам. Все решения утверждает представитель бизнеса – Product Owner.3. Бизнес-аналитик является посредником между Product Owner-ом и командой разработки.  Источник картинки https://www.romanpichler.com/blog/business-analysts-in-scrum/По сути, в данном подходе бизнес-аналитик дублирует функции ProductOwner-а для команды разработки. Последние два подхода весьма распространены в аутсорсе, где на стороне заказчика контактом, транслирующим бизнес-контекст, является Product Owner, а на стороне исполнителя – бизнес-аналитик.  Если кратко охарактеризовать отличие этих двух ролей, то Product Owner предоставляет, транслирует видение продукта и финальные бизнес-цели, не беспокоясь о том, как это реализовать технически. Он – точка контакта с клиентом, которая помогает соотнести ожидания бизнеса с возможностями команды разработки, выяснить открытые вопросы и принять решения.Подробнее о формах взаимодействия этих двух ролей можно прочитать вот здесь и здесь, а также посмотреть в видео моего коллеги Дмитрия Лозовицкого. Business Analyst vs System Analyst  Системный аналитик – еще одна роль, которую часто путают с ВА. В чем же отличие? Упрощенно говоря, бизнес-аналитик работает со сбором и документированием требований, которые связаны с достижениями бизнес-задач, а системный аналитик описывает, как система должна работать технически. Бизнес-аналитик не учитывает платформы реализации и технологии, а стремится максимально учесть все пожелания и цели заказчика, обеспечить полноту, корректность и непротиворечивость требований. Системному аналитику не важен фокус на бизнес-ценности и цели бизнеса, его задача – принять во внимание все особенности работы с определенной технологией и платформой, выбрать оптимальный способ реализации всех заявленных функционально-технических требований, определить платформу реализации, способы интеграции. Главный фокус системного аналитика – нефункциональные требования.Детальнее о системных аналитиках можно почитать тут и тут. Business Analyst vs Product Manager  Упомянув разграничение роли бизнес-аналитика с ролью ProductOwner-a, следует также рассмотреть разграничение этой роли с ролью Product менеджера. В целом, то, что отличает бизнес-аналитика от ProductOwner-a применимо и для разграничения сфер ответственности между бизнес-аналитиком и Product менеджером. Разница в том, ProductOwner оперирует тактическими целями и задачами, а Product менеджер занимается развитием продукта на уровне стратегии. В задачи последнего входит:
 Кроме того, если Product Owner ориентирован на команду и взаимодействие с ней, то продакт менеджер – на конечного пользователя продукта и требования рынка.Рассмотрев все многообразие похожих ролей (requirement specialist, business analyst, system analyst, (proxy) product owner, product manager) можно резюмировать, что основная разница между этими ролями – в предмете фокуса:
 С бизнес-аналитиками их объединяет то, что и те, и другие анализируют бизнес-процессы и участвуют в их оптимизации, могут формулировать, собирать и документировать требования к ПО. Однако data-аналитики используют для этого специфическую технику – настройку, сбор и анализ больших наборов данных.Прочитать более детально о вышерассмотренных и других видах аналитиков можно тут и тут. Святослав Щербатюк, Lead Business Analyst, EPAM =========== Источник: habr.com =========== Похожие новости:
Блог компании EPAM ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 25-Ноя 11:57
Часовой пояс: UTC + 5