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

Цель релиз ноутсов - оповещение, разве нет?
Если все команды не заинтересованы в том чтобы улучшать продукт совместными усилиями, то пишутся они из-под палки, а читаются вообще никогда.
Максимум - те, кого зацепило изменение прямо сейчас.

В итоге - нет информированности о том, как меняются части продукта, нет проактивности в этих изменениях. Да и вообще, такие вещи можно и нужно контрактами проверять.

Речь не о том как сравнить две версии продукта, а о том, как обеспечить людям комфортное взаимодействие для решения проблем в более слаженном виде.
Ваша задача решается не через работу с продуктом, а через работу с процессами в компании. С процессом разработки, с процессом постановки задач, в том числе попыткой попросить бизнес не требовать сделать "вчера".

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

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

Это именно то, о чём я писал.
Начинать нужно с того, что высокому руководству по-барабану ваше качество.
Если вы не убедите их в том, что заданную планку нужно поднять выше, останется только путь "с низу", через партизанское движение "дружно будем лучше работать", где вас если не первый, то третий разработчик пошлёт со словами, что ему некогда.

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

У нас есть проект, и он разделен на 4 команды.

а какая структура компании?

И вот продакт овнер (вроде так) в курсе, что делают команды.

И она уже решает, где кто кому уступит и что важнее для системы в данный момент.

ПО может не владеть информацией о том, какие компромиссы более рациональные. Эту информацию как раз и можно попытаться донести.
Но на самом деле, проблема стоит на 2 уровня выше и доносить её надо руководителю компании или его заместителям заинтересованным

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

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

и кто имеет последнее слово за выпуском продукта? можно ли предположить, что этому человеку будет комфортно разделить свою власть влияния?

и думаю надо начать с этого человека...если конечно выпуск не осуществляется посредством хаоса

Ну вот продакт основного бизнеса пусть и вникает.

😅

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

Не хочу показаться грубым

но меня это ебать не должно, какие там у кого цели.

Если бы у человека, принимающего решение, была цель выпустить более качественный продукт, он бы сам пришёл уже к "комитету тестеров"