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

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

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

По методологии RUP, на примере которой я расскажу о процессе разработки ПО, проектирование состоит из фаз:

1. Inception. Начало. На этой стадии решается вопрос, to be or not to be — стоит ли начинать

2. Elaboration. Уточнение, проектирование. На этой стадии мы проектируем решение, снимаем риски ошибок следующей фазы

3. Construction. Разработка.

4. Transition. Подготовка релизных сборок, документации, развертывание

Рисунок. процесс разработки в методологии Rational Unified Process

Внутри фаз есть итерации, которые команда выпускает, проверяет и так далее по циклу.

В строках на картинке процесса показаны дисциплины:

1. Бизнес–моделирование — определяем, какие бизнес–задачи тех или иных лиц, участвующих в бизнес–процессах, должна автоматизировать система

2. Проработка требований — определяем, ЧТО должна делать система, чтобы реализовать бизнес сценарии пользователей, решить их задачи. На этом уровне сама система рассматривается как черный ящик. «Что» и «Как» — это важный момент, разграничительная линия компетенций.

3. Проектирование системы — фиксируем, КАК должна быть реализована система: модель данных, компоненты системы, протоколы обмена данных, технологии и т.п. На этом уровне система рассматривается как белый ящик.

4. Реализация требований — разработчики пишут код, проектировщики интерфейса создают макеты и т.д.

5. Тестирование. На примере тестирования поясню, что значат «горбы» на диаграмме. Это интенсивность работ. тестирование идет по итерациям, поэтому оно максимально в середине итерации, и спадает к концу итерации. На процессах, не привязанных к итерациям, рост и спад активности привязан к фазам.

6. Развертывание. Определяем, какое количество серверов и других hardware компонент нужно для развертывания системы.

Бизнес аналитик исследует клиентский опыт, описывает текущий (As Is), целевой (To Be) процессы:

Рисунок. Бизнес–процесс на диаграмме, выполненной в нотации BPMN

В процессе работы выявляет и фиксирует, какие бизнес–правила должна выполнять система. Например, федеральный закон ФЗ-152 о персональных данных. Если вы не участвовали в разработке ПО, хочу обратить ваше внимание, что, кроме того, что нужно непосредственно пользователю, например, снять деньги в банкомате, система должна соответствовать вагону требований регуляторов, стандартов хранения данных, подзаконных актов и т.д. Эти требования должен выявить и зафиксировать бизнес–аналитик (БА).

Задача БА — определить концептуальные, высокоуровневые требования к системе, руководствуясь тем, как должны решаться задачи бизнес–пользователей, участвующих в бизнес процессах. В V–модели разработки ПО зона ответственности бизнес аналитика это разработка концепции и технического задания к продукту:

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

Иначе говоря, бизнес аналитику нужно знать бизнес–правила, регламентирующие индустрию работы заказчика Бизнес аналитик должен уметь моделировать бизнес процессы, например, в нотации BPMN, EPC, чтобы наглядно представить модели процессов As Is, To Be.

Поскольку у БА больше компетенций в зоне пользовательского опыта, логичное развитие БА может быть в сторону продакт менеджера (product manager) или владельца продукта (product owner):

БА —> старший БА —> Ведущий БА —>Продакт Менеджер

СА берет на вход целевую модель решения от БА. Если на проекте нет БА, то системный аналитик берет на вход в проработку какую–то фичу, которую ему дает в работу менеджер продукта или руководитель проектной группы.

СА выявляет и фиксирует системные сценарии, в которых участвуют пользователи системы. Он коммуницирует команде разработки и тестирования набор функциональных функциональных и нефункциональных требований.

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

Для того чтобы описать решение, системному аналитику нужно знание специфики работы на различных платформах, в различных технологиях. Например, разбираться в веб–сервисах, облачных технологиях и т.д. Часто системному аналитику требуется знать SQL, иметь опыт работы с базами данных. Уметь описывать интерфейсы взаимодействия между модулями системы или с внешними сервисами. Т.е. описывать API. API (Application Programming Interface или интерфейс программирования приложений) — это совокупность инструментов и функций в виде интерфейса для создания новых приложений, благодаря которому одна программа будет взаимодействовать с другой.

БА —> старший СА —> Ведущий СА —>Архитектор

Дальнейший рост системного аналитика я вижу больше в специальности архитектор ПО. Системный аналитик начинает с того, что осваивает знания технологий, используемых протоколов, способов интеграции систем, а дальнейшая перспектива — определение компонент, зон ответственностей каждой из компонент, репликации данных в наследуемые системы и т.д.

Я работаю сейчас бизнес аналитиком, именно потому, что я не вижу себя в будущем архитектором. Мне интереснее изучать клиентский опыт, определять бизнес–решение, которое оптимально решит задачи бизнес–пользователей

Если кратко, то:

Бизнес–аналитик – про знание предметной области, общение с заказчиком, постановка задачи черному ящику в формулировке «ЧТО должна делать система».

Системный аналитик – про общение с разработчиками и погружение в продукт, постановка задачи белому ящику в формулировке «КАК это должно быть реализовано в системе».

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

При выборе также учитывайте такие факторы:

• Разработчику/тестировщику будет проще освоить специальность именно системного аналитика, потому что СА ближе к нему по компетенциям.

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

• Системному аналитику проще переходить между разными тематиками, иначе говоря, доменами. Если СА знает стек технологий, REST/Soap, может описывать XML, XSD схемы, знает способы интеграции систем, знает SQL, то он может успешно работать в компании из любого домена, где требуются знания этих технологий: гос. услуги, e-commerce