ну вот platform teams в teams topology как раз эту проблему решают

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

uikit-ы всякие

Да, это бы в идеале. Пока платформ тим строим для всего девелопмента: эксплуатация, инфра, инструменты и т.д

А это уже dev-to-dev платформ тима

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

если без тикетов удается работать - то все очень хорошо) такое бывает вообще?

речь не о том что "без тикетов". Оно как обычно бывает...

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

Другой подход - когда команда выявляет (вместе с продуктом) реальные проблемы, когда мониторит аналитику на предмет "стопэ эти челы чет не так юзают как мы думали" и тд. Когда команда понимает "для чего они чет делают" - это позволяет решение проблемы распределить на большее количество голов что позволяет находить более оптимальные решения. Продукт в этом случае не говорит что делать а выбирает варианты и говорит почему те или иные варианты хорошо а какие плохо и почему. Это дает команде фидбэк и т.д. и т.п. происходит процесс обучения и ноледж трансфера.

Я сейчас пытаюсь все с опсами из первого (где они хотят от разработчиков расписанные тикеты че им сделать) ко второму придти. Что бы мы описывали просто outcomes какие-то а они уже нам решения раздавали.

основная идея - что если "кто-то сверху" тикеты выдает и говорит что делать - этот кто-то быстро становится ботлнеком. А если у команды есть понятные outcomes, мол какую проблему мы решить хотим и как понять что проблема решена (на достаточном уровне) - то тут уже веселее.

С такой культурой хочется так же убрать с продуктовых команд всю запару по поддержанию инфраструктуры. Пусть они лучше сфокусируются на проблемах продукта и будут сообщать о проблемах платформы кому-то другому.

Ты у опсов прямой руководитель или есть лид?

у них есть типа лид, но опсы у нас "отдел" и за каждым продуктом закреплены отдельные челики. И мы тим таким образом колаборацию делаем. Что бы devops все дела

ну а я просто шумный потому обычно меня слушают когда про проблемы инфраструктуры говорю.

Просто я пытался решить ту же проблему. Имхо, в опсов нужно очень много времени инвестировать, чтобы донести ценности, чтобы они сами понимали что такое «платформа» и т.д

Мне удалось решить проблему только тогда, когда появился человек уже понимающий «философию» и идею

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

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

А у кого-то по-другому?))

оч грустно наблюдать за людьми которые понимают идею и философию и которые скатываются к "дай таску" потому что организация по другому устроена

баги могут и будут лежать годами. Если не болит то не трогай.

фичи которые годами лежат - тут могут быть проблемы

проблема обычно не с тем что "бэклог пусто" а "не хватает проработанной работы"