В 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-а.
В этом случае ВА, помимо своих функций по выявлению, документированию требований, трансляции бизнес-контекста команде разработки, будет выступать «владельцем» продукта от лица клиента. Это значит, что он будет проверять у команды результаты итерации от имени бизнеса, принимать продуктовые решения, отвечать за успешное достижение бизнес-результатов конкретного функционала. Данный подход типичен для продуктовых компаний.
2. Бизнес-аналитик является частью команды разработки.
В такой конфигурации ВА работает в команде разработки на ежедневной основе. Он транслирует бизнес-контекст требований, полученный от Product Owner-а инженерам. Все решения утверждает представитель бизнеса – Product Owner.
3. Бизнес-аналитик является посредником между Product Owner-ом и командой разработки.
По сути, в данном подходе бизнес-аналитик дублирует функции 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
