задача для СРО: как настроить разработку в продукте с миллионами пользователей?

как вообще придумать подход к работе над махиной внутри которой куча микросервисов, пользовательских путей и продуктов?

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

как это решают компании?
1) некоторые выбирают идти по пути, где каждая команда, которой что-то надо, сама разбирается в коде и пытается внести туда изменения. можете догадаться, какие минусы у этого подхода?
2) другие делают доменную систему, где каждый кусочек продукта, вроде карточки товара, — это отдельный домен со своей командой разработки. но кто тогда управляет этой командой?

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

на такие техкомы можно приходить только с посчитанными метриками (у каждого домена свои) и быть готовым их защитить

как у вас с доменной системой? или у всех своя разработка?

#продуктовый