исходя из этих целей у тебя будет формироваться скоуп задач

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

Поэтому можно смело пропустить терзания и начать создавать у него такую цель

СЕНАТ ТЕСТИРОВАНИЯ

ПРЕДСЕДАТЕЛЬ ПРАВЛЕНИЯ ТЕСТИРОВЩИКОВ

Почему нет?
Есть вариант горизонтального взаимодействия в компаниях, в виде так называемых "гильдий". Как раз совещательный комитет по какому-либо направлению техническому.

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

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

Хотя бы опосредованно через технического руководителя компании

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

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

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

Вообще, в такой ситуации я бы порекомендовал попробовать просто улучшить условия работы отделов(команд?) тестирования и тем самым повысить кпд именно этого участка.
Решить локальные, насущные проблемы вида "мало железа", или "подвисает сеть".

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

А уже тогда можно пробовать влиять на культуру разработки в целом, заработав авторитет на более ограниченной задаче.

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

Блокировать релизы не нужно. Это кратчайший путь провалить затею

Релизы не ваши, чтобы их блокировать

И спасибо за это на первых порах никто не скажет

а в чем тогда власть заключается?

по идее спасибо должны говорить пользователи

Вырабатываете рекомендацию "не катить вот это в прод", ставите в известность владельца релиза и того, кто сверху курирует вашу инициативу