Наблюдаю интересный дрейф в функциях аналитиков. Уже в нескольких крупных компаниях вижу, что бизнес-аналитиков всё больше и больше нагружают техническими деталями: спецификацией данных, описанием исключений и краевых случаев, обработки ошибок. Ну потому что системный аналитик не может сказать, что нужно делать при возникновении такой ошибки. Бизнесу-то как нужно? Вы расскажите. И дайте примеры данных в виде json. Задачи системных аналитиков при этом тоже смещаются в сторону техники: описания интеграций, структур и форматов данных — как для транспорта, так и для хранения, стратегии надежности обмена и повторных вызовов. В результате такой работы у системного аналитика получается техническая спецификация, практически непригодная для чтения обычным человеком — формальные спеки API, схемы данных. Но и у бизнес-аналитиков получается не лучше — в деталях теряется общая картина, и, например, тестировщики уже перестают понимать — а как и для чего оно должно работать? При такой степени проработки теряется описание бизнес-возможности и потребностей. А схемы бизнес-процессов, которые ещё где-то сохраняются как форма, по содержанию отражают скорее взаимодействие систем при интеграции. Поэтому описание потребностей бизнеса всё чаще возлагают... на сам бизнес. А так как они этого никогда не делали и не владеют инструментами, получается, ну, так. С помощью ИИ даже ещё смешнее — объем большой, а акценты расставлены почти случайно. За что стат.модель зацепилась, о том и говорит. Проконтролировать это у бизнес-заказчиков не хватает квалификации и понимания, что эти слова вообще-то должны что-то означать и для чего-то в дальнейшем использоваться. Возникает синдром студента: "а мы думали, вам просто какой-то текст по теме нужен, ну вот ИИ какой-то сгенерил, разве это не подходит?" Так как с потребностями бизнеса всё-таки нужно разбираться (ну, хотя бы иногда), БА на это уже не способны, а СА вообще к людям не пускают, эта задача отъезжает к... UX-исследователям. Ну правда, им же по роли положено разговаривать с пользователями! Вот пусть и расскажут, что этим пользователям, в конце концов, нужно. Поэтому процесс становится примерно таким: СА находит в постановке непрописанный вариант, просит БА его описать. БА идёт к UX-ресерчеру и спрашивает — как пользователям будет удобно в этом случае, что им нужно? Ну ты же с ними говорила уже, выясни этот момент тоже. И дай сразу макет интерфейса, я вставлю в документ. * UX действительно говорил с пользователями, но совершенно по другим вопросам и по рандомизированной выборке. А делать ещё одно исследование из-за такого мелкого вопроса довольно накладно. Кроме того, переворачивается ответственность: БА просит принести уже готовый макет (принятое решение), который нужно сделать совместно с дизайнером. То есть, не дизайнер получает постановку задачи от БА, а наоборот — БА хочет готовое решение, которое откуда-то извне возьмется, а он только зафиксирует. В этой ситуации функция управления и координации фактически перекладывается на UX-исследователя, который вообще говоря исследователь, а не менеджер. Иногда в этой цепочке всё-таки возникает какой-то младший продакт (если такая роль вообще есть), фактически — фича-оунер. Но если нет — ситуация решается случайным образом. Так как фичу кто-то всё же должен дотащить до прода, но никто не хочет принимать решения, всё превращается в игру "горячая картошка" с перебрасыванием ответственности друг-другу до первого, кто сдастся и возьмет функцию ситуационного лидера на себя. Это может быть кто угодно — UX, БА, дизайнер, кто-то из менеджеров, иногда даже тестировщик. Я даже видел лида поддержки в этой роли. Или же фича так и останется бесхозной, и в каком-то виде доедет до прода без хозяина. Решения в этой ситуации, скорее всего, будут приняты случайными людьми и без надежных оснований. Оценку решений получит опять же либо поддержка, либо UX в ходе очередного скрининга. Такой вот процесс, сталкивались с таким? И что делать, если в команде не предусмотре