Соглашусь. Кстати, инересно услышать аргументы обратного мнения

Есть разница между финансовым аналитиком, продуктовым аналитиком, аналитиком в ит, аналитиком в медицине (клинико-эксперты, например), аналитиком данных (дата-сатанисты всякие и их подмастерья). Аналитика то разная. Но в ИТ конкретно именно разделение на БА и СА на уровне должностей только вредит.

А как быть в продуктовой разработке? Там тогда БА заходить на поляну продуктового аналитикам и придется еще и эту роль на себя взять

Это разные уровни по методологиям, но я зачастую просто слышу  "я БА, а не СА" как отмазку от того, чтобы думать. Потому как обычно мега-знаний доменной области, которые нельзя подчерпнуть за пару вечеров из курсов и статей, не обнаруживается.

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

Да научиться то может любой не глупый человек. Я к тому, что твое утверждение не для всех случаев справедливо

Это больше для интеграторов подходит

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

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

Во!

То есть вопрос в том, что если предметка небольшая. то можно совмещать. если нет, то лучше не стоит

Есть предметка, например, типа трейдинга, где нужно знать финансовую аналитику, да. Но я не так много встречал именно БА в ит, кто хорошо её знает и понимает. Чаще всего там под БА подразумевается именно финансовый аналитик, которого стали привлекать к ИТ как консультанта, например те, кто Мюрексом занимается. У людей там образование финансовое, опыт и т.д., вот только к ИТ они отношиния как такового не имеют. Я говорю про разделение именно в ИТ сфере на уровне тех, кто профессионально учится/работает в разработке. Мой тезис в том, что в ИТ это разделение на БА и СА условно и вредно.

И не всё тут работа аналитика, если что.)

У меня та же позиция. Я сейчас работаю в госухе, и здесь местами очень много нюансов по нормативке, в которых разбираться долго и трудно. Да еще и порой надо привлекать экспертизу. Мой уклон - СА и интеграции. Поэтому я жду от бизнес-аналитиков результатов анализа нормативки и сбора требований от заказчика (который не разбирается в ИТ и вообще говорит на суровом госучрежденском), понимания, как изменятся бизнес-процессы.

Но нормативку нужно узнать всю всё равно же. Я работал в госах и вынужден был вообще всю нормативку прочесть касательно предмета: все ФЗ, рекомендации ФСБ и всяких РосБла-БлаНадЖоров, все приказы по организациям и смежным ведомствам, касательно специфики. Да это есть времени уйму, но погружение в бизнес-домен в этом и заключается. Разделение на то, что кто-то копает туда, а я копаю в другую сторону - это хорошо, чтобы экономить время, но это вынужденное, а не концептуальное. По идее каждый аналитик должен разобраться во всём и уметь говорить на языке всех видов диалектов.)))

ага, и каждый разработчик тоже должен быть фулстеком

Цигель, цигель, ай люлю.

Ну смотрите, в аналитике нет 100500 фреймворков и кучи версий DK, миллиона языков. Нотации для моделирования и виды визуализации знаний не всё это обязательно для знания, важно цмение быстро разобраться и освоить. А вот работа на конкретном проекте требует максимально глубокого знания домена, а это нужно нырять, хоть ты условный БА, хоть СА.
Я понимаю, почему мой тезис вызывает резистентность - дело в том, что объективно всё охватить невозможно и это прям много усилий, а когда кто-то говорит, что аналитик не сильно полноценный, если он стал фокусироваться на домене или направлении, то это же вызывает негодование.
Я разделяю идеалистичное от реальное. Идеально аналитика - это принцип организации мышления + набор паттернов работы + и т.д. Реально мы все работаем в каком-то конкретном месте с конкретными людьми, на конкретных проектах, над конкретными (или не очень) задачами.
Может я немного старпёр 😁, но ведь мы зачастую не СА по классике, там нет разделения на бизнес-аналитиков и системных аналитиков, есть уровни и углы/точки обзора (условное разделение). Системный анализ дисциплина, описанная в 30х-70х годах от теории систем и далее) и она включала в себя в том числе и то, что сейчас относится к бизнес-анализу. Посмотрите книги Блауберга, Садовского, Форрестера, Винера, Эшби, Саати. Там всё есть и всё позиционируется как системный анализ. Естественно, что сейчас не так много СА, кто читал и применяет закон необходимого разнообразия Эшби или знает принципы ранжирования по Саати, умеет в иммитационное моделирование и умеет выделять контуры управления по теории автоматизированных систем, хотя это всё считается необходимым знанием для СА, например, с академической точки зрения. Но ведь работают же люди системными аналитиками. Важно мышление и стремление к тому, чтобы узнать область в которой трудишься сейчас.

Но это не отменяет условность разделения труда на БА и СА.)))

+1.