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

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

В Maxilect системный аналитик в первую очередь концентрируется на технических задачах. Он немного понимает программный код, может самостоятельно писать базовые SQL запросы, осознает и применяет различные принципы построения архитектуры приложений, а также их взаимодействия. Умеет работать и проектировать веб сервисы и очереди (MQ). Но бизнес анализом ему заниматься не приходится. 

Команда получает от бизнеса задачи, которые отвечают на вопрос: “Что нужно сделать”. А системный аналитик решает “Как команда это реализует”. Детально прорабатывая задачу, системный аналитик может обсудить промежуточный вариант с разработчиком или обсудить что-то с архитектором. Но именно он решает, какие веб-сервисы будем вызывать, как обрабатывать полученные данные и какие для этого нужны доработки. Организует обсуждение со сторонними командами, если требуется. Фактически, здесь роль системного аналитика близка к канонической. 

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

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

Поговорим о том, какие направления аналитику открываются чаще.

Аналитик и бизнес

По моим наблюдениям чаще всего системному аналитику приходится закрывать функции бизнес-аналитика.

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

Я обратила внимание, что из этих двух ролей в вакансиях компании чаще пишут “системный аналитик”, предлагая совмещения в текстовом описании позиции или между строк. Мне кажется, бизнес-аналитик - это более редкий узкий специалист, которого не каждая компания может и хочет себе позволить. Так что, закрывая обе роли, ты становишься более универсальным специалистом, которому легче найти работу.

Но отсутствие бизнес-аналитика на проекте не всегда гарантирует, что нужно будет совмещать. It - сфера динамично развивается и в ней появляются новые смежные профессии. Еще 3-4 года не многие слышали про роль product owner, а сейчас роль владельца продукта все более востребована. И я уже ни раз сталкивалась с командами, где именно PO определяет, какие бизнес-задачи войдут в скоуп спринта, а какие нет. В каком-то смысле, помимо выполнения своих основных функций, product owner встраивается в цепочку разработки вместо бизнес-аналитика, взаимодействуя и с заказчиком, и с системным аналитиком.

Нужно ли тестировать?

Системный аналитик должен хорошо разбираться в системе и ее функциях. Поскольку он ориентируется в требованиях заказчика, я все чаще вижу, что аналитиков подключают к тестированию. Я и сама на текущем проекте тестирую отдельные модули системы. Тестировщики же фокусируются на более объемных частях задачи.

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

Системный аналитик vs архитектор

Системный аналитик не является архитектором, но часто ему приходится закрывать эту роль хотя бы частично, хотя на мой взгляд это неправильно.

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

Когда проект обходится без архитектора, его функции делятся между другими участниками команды, например техлидом, product owner, а иногда и самим системным аналитиком (такую схему работы “на троих” я встречала на одном из бывших проектов). Это нельзя назвать обычной или правильной практикой. Но так или иначе системному аналитику все равно придется разбираться в архитектуре, понимать, какая технология и за что отвечает. 

Необходимость изучить архитектуру проекта тянет за собой много требований. Надо уметь работать с интеграционными сервисами - понимать, что куда передать, чтобы совместить две системы, что такое интеграционная шина и как она работает. Надо понимать, как из одной системы в другую дойдет сообщение, и что при этом произойдет, а значит требуется знать, как работают очереди (RabbitMQ, Kafka). Необходима работа с базами данных.

Системному аналитику не обязательно уметь проектировать все это, но надо следить за технологиями, понимать, зачем и в каких ситуациях они применяются.

Выйдет ли из аналитика лид?

Стоит следить и за трендами в управлении. Аналитиков часто ставят на роль лидов - дескать, они хорошо понимают в проекте, умеют общаться с бизнесом. На мой взгляд, это не всегда оправданный шаг. Руководство - это в большей степени менеджерская работа, которая отнимает много времени. Это в первую очередь распределение задач, полученных сверху, между мидлами и джунами в своей команде. Мне кажется, эту работу проще возложить на руководителя проекта или product owner - мне так работать привычнее. А сильный аналитик может сосредоточиться непосредственно на своей работе. Но для некоторых переход из системного аналитика в лиды - это хороший шаг в карьере, к которому лучше готовиться заранее, изучая особенности работы команд, различия в подходах к разработке (это уже про Agile, Scrum, Kanban).

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

Автор статьи: Лейла Кадырова, Максилект.

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.