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

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

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

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

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

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

После пары лет работы, первых столкновений с микросервисами, REST, SOAP и т.п. специалист превратится в мидла, который сможет решать задачи самостоятельно. И начиная с этого момента он сможет осваивать смежные роли, продолжая углубляться в детали своей профессии. Уровня сениора с его многолетним опытом, базовыми навыками архитектора, пониманием интеграционных сервисов или умением пилить монолиты, а также опытом руководства командой, он скорее всего достигнет уже совмещая несколько направлений.

Не исключено, что именно совмещение и дает этот толчок в развитии. Но разделение на уровни настолько условно, что дальше я не буду акцентировать внимание на том, как смежные роли с ним связаны.

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

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

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

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

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

Но отсутствие бизнес-аналитика на проекте не всегда гарантирует, что нужно будет совмещать. 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.