Чем занимаются системные аналитики?

Часто на менторингах и в неформальном общении встречаю вопрос: а чем именно должен заниматься системный аналитик на проекте?

Я обычно ссылаюсь на профстандарт. Но это общее описание, к тому же, далеко не все нанимающие менеджеры его читали.

В первой компании, где у меня была должность системный аналитик (2019г), я занималась: проектным менеджментом, UX-дизайном, бизнес и системным анализом, ручным тестированием, поиском багов в коде, поддержкой пользователей, внедрением системы в работу компании.

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

В итоге следующие 5 лет я занималась в основном бизнес и системным анализом, с упором на системный. И тут надо было погружаться в технику: описывать спецификации API, интеграционные процессы, физ модели БД и архитектурные решения.

Мне это интересно, и я уходила все больше в детали реализации и все дальше от пользователей. И вроде бы все хорошо — рынок такое сейчас приветствует. Но иногда я ловила себя на мысли: а почему я прописываю индексы на этапе проектирования БД? Это же разработчик пишет запросы. Хотя в некоторых случаях запросы в виде псевдокода тоже пишу я.🤷🏻‍♀️

От коллег слышала, что бывают также системные аналитики: девопсы, сетевые инженеры, деливери менеджеры и т.д.

В общем, грань очень тонка и как будто становится все тоньше. И сейчас у меня, как и в 2019 году, нет полного понимания: где начинается и заканчивается зона компетенций СА?

И надо ли мне проходить курсы бекенд-разработчиков, SRE, Data и DevOps? И обязательно ли уметь жонглировать аналитикой и метриками?

Понятно, что в идеале хорошо бы все знать и все уметь. Но человеческий ресурс несколько ограничен. И хочется также ограничить область знаний, необходимых для той или иной работы.

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

А дальше погружаться глубже уже в какую-то конкретную тему при необходимости или интересе.

Однако востребован ли сейчас на рынке такой подход?

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

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

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

А какой у вас был опыт в роли СА? И какую стратегию на современном карьерном рынке вы выбираете?