Я в курсе. Тот что попадался системный я скинул. ИМХО системный и бизнес имеют точки пересечения, а аналитика продаж это лично моя сфера за которой слежу

я не себе, а товарищу

А то я удивился)).

https://starkovden.github.io/
Если товарищ это еще не изучил - будет полезно изучить. И навыки практические будут, и будет о чем на собеседовании рассказать))

Там можно потыкать в рабочий API погодных сервисов, вживую пощупать как это работает.

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

Чойтовы UML/BPMN забыли?
Если профстандарты сравнивать - то да, пересечений не так много, как на самом деле в реальной работе, если смотреть по вакансиям и тому, что приходится на местах делать.
Чаще смешение ролей происходит - по названию СА, а по ролям - СА с БА допами. Или наоборот.
Был я недавно БА с общением с заказчиком, пользователями, пишущим ТЗ, UML/BPMN, рисующим эскизы UI, тестирующим, описывающим интеграции, роющимся в БД, пишущим документацию. Код не приходилось смотреть, только пару раз разработчик скидывал код с правилами формирования флагов.
А до этого - СА, тоже самое - общение с клиентами, интеграции, постановка задач, документация. Только другая компания.

++
та же ситуация сейчас

Хорошо сказано
Более того, очень редко видел успешный конвейер из "чистый ба пишет бт, чистый са переводит их в ст"

Как по мне, зависит от размера конторы, чем она меньше, тем более разнорабочим будет аналитик. Работал в компании на 50 человек, был БА с уклоном в СА. Перешёл в компанию с 10к+ - функции СА и БА перестали пересекаться в принципе.

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

Да, все верно. Я с этим не спорю, речь о другом - конвейер из чистых ба и са редко эффективен (сначала ба узнает у бизнеса с ошибками, потом са не так понимает эти ошибки, а потом еще разработчик напутает)

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

Я видел рабочую схему у коллег в другой конторе, когда в одном проект 1 БА и 3 СА, БА писал на СА задачи, СА делали детализацию для разработки, БА валидировал их детализацию, после уходило в разработку все. В такой схеме все работает.

Но тут БА погружался частично до разработки

Всегда несколько удивлялся наличию роли БА вообще. По идее, бизнес требования может записать и бизнес

А Вы кем работаете?

Без привязки к инфраструктуре выйдет шлак

Возможности реализации это системный анализ

Да, мы так же процесс выстраивали
Перекрытие, хотя бы на стадии согласования/ревью, должно быть, иначе гитлер