Если же вы перестроили процесс деплоя так, что он со всеми циклами тестирования укладывается в 2 недели, то он перестает быть блокирующим фактором для новой фичи. Этим фактором становится капасити команды разработки

То о чем я говорил. Спор ради спора. Дальше не интересно

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

Нет, это как раз про то, что все подобные параметры - не работают в реальности.

Процесс деплоя вообще для коробочки - у клиента :)

Нет это про то что вы докапываетесь до любой мелочи и ваша цель - спор. За сим прекращаю

Нет, я хочу услышать хоть какие-то аргументы в пользу 'снчала померить, потом исправить'. Пока - не вижу ни одного.

А мы ещё про простые вещи говорим, а не про внедрение управлением знания, например.
При этом я понимаю важность метрик для защиты проекта перед владельцами ресурсов, например. Но это не про реальность, а про внутреннюю политику.

Отлично, вы перевели метрику про возможности команды в метрику про желания клиента =)

В реальности где у вас 1 клиент для которого вы пилите один продукт, кажется вам не нужно быстрее, лучше и качественнее. И эти метрики не важны, да. А в реальности где у вас 10 реальных клиентов и еще 100 потенциальных - важны.

А чем важны, покажи связь?

Каждая отдельная метрика отражает некоторый процесс в реальности. Например, частота релизов - насколько маленькие инкременты вы можете доставлять до прода (косвенно отражается на надежности продукта) и как часто можно тестировать гипотезы. Если внедрили 10 фич и выкатили разом, то нельзя говорить что это 10 экспериментов.

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

Да есть совсем простой пример. Samsung должен выкатывать новый телефон серии s не реже одного раза в год иначе потеря рынка , выручки и атата от акционеров. Дальше все метрики производства направлены на достижение этого показателя. Метрика - новая модель каждый год. Расскажите почему она не работает.

Так для поставки коробочек это все не работает. Да и для не коробочек, кстати,  тоже.
Вот у меня какой-то финтех веб-продукт, 10 mln пользователей и так далее.
И пользователю не нужно много изменений, скорее наоборот. И важна не частота деплоев, а надёжность доставки, например. Так как нет разницы, делать релиз раз в неделю или раз в час.
Да, имеет значение метрика 'стоимость организации релиза' и 'скорость реакции на инциденты', но тоже на уровне качественных изменений.

1. Предположим, что мы понимаем какую проблему хотим решить.
2. Именно, я про это и говорю — как и про изменение корпоративной культуры.
Можно пойти "классическим" путем: сходить во все 100 команд, собрать информацию как и что у них работает, попробовать разобрать что подойдет для них всех, потом этот космолет по-очереди к ним внедрять, бороться с сопротивлением, в итоге через 3 года объявить проект неудачным и закрыть, а все так и будут писать записки на стикерах.
Можно для каждой из команд проработать решение, к каждой найти свою аргуметацию или coinage, и пойти по-очереди это решение у них запускать. Займет 3 года, польза для части команд все же будет, но за счет кастомного решения для каждой команды это кажется будет сложно в поддержке.
И я предполагаю, что есть третий вариант — еще более мелкие итеративные изменения, которые нужно масштабировать на всю организацию и отслеживать процесс этого масштабирования.
И я спрашиваю по каким словам можно гуглить ссылки именно про этот третий вариант, потому что самостоятельно я не понимаю что это будут за ключевые слова.

Если клиентам не нужны изменения, то зачем вам команда разработки?

Если мы сами оцениваем нашу системы с т.з. надсистемы кажется такое будет работать, нет?

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

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

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