Конечно)

Да и энтерпрайз энтерпрайзу рознь. Я вот вижу как по разному думают в телекоме и в "новых банках".

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

+1 Важно - уметь при этом ещё и не испачкаться )))

И не испачкать других

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

Это если у продукта одно внедрение (1 штука). А если их 100, то получаем 101 технаря :)

Не очень понял почему 101. если «циклом эксплуатации» после внедрения должен заниматься один выделенный человек - то ок, наверное минимум 101. Если нет - то наверное меньше. Как правило, все живут во 2 модели, первая модель жизнеспособна если это зафиксировано в договоре/иных обязательствах и за это хорошо платят)

Все равно, при большом количестве разнообразных внедрений приходится или добавлять в команду много людей (и усложнять процессы и коммуникацию) или строить отдельные команды delivery&support.

Я скорее за ротацию между командами и единый продактменеджмент

Но мне вот скоро надо будет решать эту проблему )

Сугубо ИМХО. Если вы считаете саппорт/сервис частью жизненного цикла продукта/частью продукта - то команда одна.

А почему для одного продукта - одна команда? Это совершенно не обязательно, как только команда дойдет до некоторого предела по размеру - нужно делить на несколько. И при большом количестве кастомизаций это произойдет быстро (
Но все команды одного продукта должны быть как-то связаны, конечно.

Согласен. Хочу сказать что при таком делении наверное делить не на команды «саппорт» и «деливери». А на фуллстек подкоманду 1 и подкоманду 2. Где внутри каждой команды саппорт - такая же роль как и разработчик ( и может даже саппортом не называться).

Разработка не всегда продуктовая

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

Извечная дилемма как нарезать команды - горизонтально или вертикально, прям как про 2 палочки твикс)

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

Можете описать кейс, интересно.

архитектура слоеного пирога,
у нас есть платформенные команды и продуктные вертикальные команды