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

Для этого есть бизнес-аналитики

Сколько раз делал ремонт: обязательно расштрабили — позвали. Пересчитал розетки, обратил внимание, что две забыли. Доштробили — позвали, получили добро на штукатурку. Доштукатурили — позвали, получили добро на обои. Поклеили — позвали...

А все равно качество звукоизоляции выясняются после окончания работ (

Я не зря тут ною про некомптетентность “команд” в прикладном домене, сейчас это прямо проблема. Учить команды понимать бизнес-прцоессы системы.

Именно. Иногда случаются парадоксальные вещи. Команда/группа людей работающая над проектом, забывает даже цель решения. На встречах львиная доля времени уделяется обсуждению "кнопочек", а в центре этой истории - UI дизайнер, герой нашего времени.

Или хороший UX-ер как-то мешает архитектору выполнять его работу?

Складывается ощущение, что мы (рынок) слишком быстро растём (разбухаем). Решаем задачи числом, а не умением.

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

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

Можно не буду отвечать) не хочется троллить) сорри

Воот, а проверить это как?)

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

а можно ссылочку

Решением проблем звукоизоляция занимаются не на этапе реализации, а на этапе проектирования. Как ни странно, в ПО такими вещами, как производительность, также занимаются на уровне проектирования. Иначе вообще не понятно, за что платят архитектору.

Роман, про опыт Росатома по управлению знаниями много сказано. Вот один из моих докладов (аж 14 года), но за эти 30 минут детально разобраны все элементы СУЗ Росатома https://www.youtube.com/watch?v=EOec4Zvg_So