Старший бизнес-аналитик EPAM Anywhere Руслан Ахмедов рассказывает о разнице между бизнес-аналитиком и системным аналитиком, их проектные роли и обязанности.
БОЛЬШЕ ИНФОРМАЦИИ О БИЗНЕС АНАЛИЗЕ В НАШЕМ ТЕЛЕГРАМ КАНАЛЕ: Бизнес Аналитик|IT
В чем же заключается разница между бизнес-аналитиком и системным аналитиком? В ответ на этот вопрос я обычно отвечаю, что бизнес-аналитик – это тот, кто собирает бизнес-требования от заинтересованных сторон с помощью различных методик. Системные аналитики, которых также называют аналитиками бизнес-систем, разбивают высокоуровневые бизнес-требования на более конкретные функциональные требования и предоставляют подробную спецификацию команде разработчиков.
Однако в действительности эти две роли куда более сложны, чем кажется на первый взгляд. Давайте рассмотрим различия и сходства между ними, начав с сути проблемы.
Проблема (она же разработка ПО)
Разработка программного обеспечения существует уже давно, но за последнее десятилетие с появлением облачных технологий она существенно изменилась. Теперь в основе всего лежит программное обеспечение, которое необходимо разрабатывать, тестировать и постоянно обновлять после его выпуска.
Любой новый проект по разработке ПО обычно начинается с описания того, чего хотят заинтересованные стороны. Обычно это смесь видения маркетологов, описания некоторых ключевых функций и желаемых финансовых результатов.
Это может быть презентация стартапа, концептуальный документ объемом от 2-х до 100 страниц или просто краткое изложение того, чего хочет клиент. Например: «Это как Uber, но для выгульщиков собак» или «Я хочу создать Tinder для коллекционеров марок».
Обычно люди, которым приходят в голову эти замечательные идеи, думают, что все, что им нужно сделать, – это нанять кучу программистов, которые за пару месяцев сделают все, как надо. На самом деле все гораздо сложнее.
Для успешного ведения цифрового бизнеса, такого как Uber или Netflix, требуется современная программная архитектура (скорее всего, на основе микросервисов) для серверной части, приложения для каждой популярной мобильной платформы и адаптивный веб-сайт.
Чтобы все это заработало, необходимо собрать команду специалистов из разных областей: дизайнеров, фронтенд- и бэкенд-разработчиков разного уровня, тестировщиков, DevOps-инженеров. Перед каждым из них должна быть поставлена конкретная задача, которую они должны оценить, реализовать, протестировать и развернуть.
Прежде чем каждый сможет начать работать и расходовать бюджет, ему нужно сказать, что именно делать. Это важно сделать в очень конкретной форме, которую заинтересованные стороны могут легко подтвердить и одобрить, а команда разработчиков – понять, разбив ее на более мелкие задачи для каждого члена команды. Именно в этом случае на помощь приходят бизнес-аналитики, а затем и системные аналитики.
Роль бизнес-аналитика в проекте
Бизнес-аналитик (БА) обычно подключается к проекту на подготовительном этапе, задолго до его запуска, после того, как все предпродажные мероприятия завершены и контракт подписан.
На данном этапе целью БА является понимание основной идеи проекта, а также бизнес-целей, желаний и ожиданий заказчика. Для этого бизнес-аналитик организует серию семинаров с заинтересованными сторонами по выяснению требований, дискуссии с экспертами предметной области и фокус-группы с людьми, соответствующими профилю “персонажей” – словесных портретов потенциальных пользователей нового программного продукта.
Для успешной работы бизнес-аналитики должны хорошо знать популярные методики выявления бизнес-требований, а также владеть такими подходами и инструментами, как “бизнес-модель Канвас“, “ценностное предложение” и “карты эмпатии“, позволяющими лучше понять потребности конечных пользователей. Знание и опыт работы в бизнес-сфере – еще одна важная составляющая резюме бизнес-аналитика, которая, вероятно, является главным аргументом в пользу его кандидатуры для большинства работодателей.
Кроме того, БА должны уметь проводить собеседования и мозговые штурмы. Организация встреч, ведение записей всех обсуждений и отправка отчетов о встречах — это также большая часть повседневной деятельности бизнес-аналитика — задачи, которые не следует игнорировать как неважные.
Ближе к завершению подготовительного этапа БА документирует бизнес-требования и, в некоторых случаях, готовит документ, описывающий видение бизнеса и его основные цели, определяющий ключевых заинтересованных лиц, а также очерчивающий рамки и границы проекта (или продукта).
По окончании данного этапа проекта бизнес-аналитик присоединяется к команде разработчиков. Его задача – передать собранную информацию команде разработчиков, наполнить бэклог пользовательскими историями (краткими описаниями задач пользователей, которые должен решить программный продукт), расставить их приоритеты по бизнес-ценности вместе с владельцем или менеджером продукта, а также оказать дальнейшую поддержку команде разработчиков, если у них возникнут вопросы.
После того, как часть рабочей функциональности будет завершена, бизнес-аналитик должен провести серию приемочных испытаний (UAT), чтобы убедиться, что конечные пользователи и заинтересованные стороны довольны результатами разработки и что все потребности пользователей удовлетворены. На этом этапе БА должен также зафиксировать все дополнительные требования и улучшения для дальнейшего совершенствования программного продукта.
Роль бизнес-аналитика: резюме
| Этапы проекта | Подготовка. Разработка. |
| Основная задача | Убедиться, что любой релиз разработчиков соответствует реальным требованиям конечных пользователей, клиента и других заинтересованных сторон. |
| Критерии успеха | Основными критериями успеха хорошего БА являются удовлетворенность конечного пользователя и заказчика разработанным продуктом с точки зрения того, насколько он соответствует целям пользователей и бизнес-задачам заказчика. |
| Поставляемые продукты | Документ с бизнес-требованиями. Документ о видении и области применения. Истории пользователей. Результаты приемочного тестирования пользователей. |
| Компетенции | Выявление бизнес-требований. Интервьюирование. Мозговой штурм. Расстановка приоритетов. Коммуникация. Приемочное тестирование пользователей. |
Роли системного аналитика в проекте
Если задача бизнес-аналитика заключается в том, чтобы четко донести до команды разработчиков, что необходимо сделать, то системные аналитики (СА) – это те, кто берет эти видения, утверждения, истории и требования и разрабатывает рабочее решение для каждой потребности конечных пользователей.
Как правило, системный аналитик подключается к проекту после этапа подготовки, когда установлены бизнес- и высокоуровневые пользовательские требования для первой итерации продукта.
Задача системного аналитика – разбить бизнес-требования на более конкретные функциональные требования, которые затем могут быть переданы архитекторам и разработчикам. В некоторых случаях системные аналитики предлагают программные решения, готовят требования к данным и документируют другие технические детали.
В отличие от бизнес-аналитиков, системные аналитики не общаются с конечными пользователями и заказчиком напрямую. Они должны иметь хорошую подготовку в сфере IT, как минимум, знать SQL, объектно-ориентированное программирование и API. Кроме того, СА должен владеть моделями данных и и диаграммами классов/последовательностей UML, которые помогают проверять и правильно документировать требования к данным.
В тех случаях, когда новое решение требует работы с каким-то устаревшим кодом или данными или когда требуется интеграция со сторонними бизнес-системами, СА будет анализировать данные, бизнес-правила и другие аспекты этих систем, а также создавать дополнительные требования к команде разработчиков.
Роль системного аналитика: резюме
| Фазы проекта | Разработка |
| Ключевые задачи | Предоставить команде разработчиков подробную техническую спецификацию системы. Убедиться, что разработанное решение покрывает все функциональные и нефункциональные требования. |
| Критерии успеха | Система работает в соответствии с ожиданиями и справляется с требуемыми нагрузками; интеграции работают без сбоев. |
| Поставляемая продукция | Документированные данные и технические требования. |
| Компетенции | SQL. Объектно-ориентированное программирование. UML-диаграммы. Модели данных. Диаграммы классов и последовательностей. Современная архитектура программного обеспечения и основы баз данных. |
“Нам не нужны БA и СA, теперь все по Agile!”
Да, в манифесте Agile четко сказано, что вместо детальных спецификаций мы должны иметь работающее программное обеспечение, а вместо следования плану – реагировать на изменения.
Значит ли это, что больше нет необходимости в БА, СА и артефактах, которые они создают? Можно сказать, что и да, и нет.
Независимо от того, какой подход к управлению проектами вы выберете, итоговый продукт все равно должен удовлетворять потребности конечного пользователя и помогать клиенту достигать бизнес-целей. Разработчикам, даже если они участвуют в обсуждении бизнес-ценностей и хорошо понимают бизнес-сферу, все равно нужны требования в той или иной форме для итераций. Поскольку системы становятся все более сложными, взаимодействие между ними необходимо анализировать и документировать, чтобы облегчить будущую интеграцию.
Будущее бизнес-аналитиков и системных аналитиков
Сегодняшние бизнес-аналитики и системные аналитики, вероятно, не соответствуют первоначальным должностным инструкциям 40-летней давности. Эти роли продолжают меняться постоянно и сейчас.
БА, обладающие хорошими коммуникативными навыками и обширными знаниями в своей области, скорее всего, перейдут на позиции менеджера или владельца продукта. Вместо того чтобы создавать подробную документацию со сложными диаграммами, которые никто не понимает, они должны научиться эффективно организовывать семинары по упрощению требований, помогать клиентам формулировать бизнес-модель и ценностное предложение, а также проводить интервью с конечными пользователями.
Современные бизнес-аналитики также должны выступать в роли пресс-секретаря и менеджера по коммуникациям в команде разработчиков, чтобы убедиться, что вся команда продуктивно сотрудничает друг с другом и с заинтересованными сторонами. Они должны внимательно относиться к обратной связи с конечными пользователями, быть готовыми воспринимать критику и использовать современные средства сбора обратной связи с пользователями.
Системные аналитики, скорее всего, перейдут на позиции системного архитектора, архитектора решений или архитектора предприятия, в зависимости от того, насколько глубоко они хотят погрузиться в техническую реализацию. Современные системные аналитики также должны хорошо разбираться в DevOps и быть проводниками изменений в своих командах, выступая за культурные и организационные изменения и способствуя межкомандному сотрудничеству на уровне решений.
Выводы
Из приведенного выше обсуждения становится ясно, что бизнес-аналитики и системные аналитики – это совершенно разные люди, причем не только по своему образованию и компетенциям, но и по тем аспектам программных продуктов, с которыми они имеют дело, и по их деятельности на разных фазах проекта.
В некоторых случаях один человек может выполнять обе роли одновременно. Но это не означает, что БА – это более новая версия СА или что СА – это более квалифицированный БА. Обе роли актуальны и важны сегодня для любого вида разработки программных продуктов.
Поскольку программные продукты становятся все более сложными, спрос на людей, которые способствуют сотрудничеству заинтересованных сторон и разработчиков, будет только расти. Мы будем наблюдать дальнейшую трансформацию ролей бизнес-аналитиков и системных аналитиков, но основные компетенции в области системного и бизнес-анализа останутся значимыми в обозримом будущем.
Перевод статьи «Systems analyst vs. business analyst: same or different?».