Понял, спасибо

Сколько потеряет бизнес, если вместо рефакторинга будет пилить фичи?

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

Это из практики пример.

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

Да, такой пример естьи и у меня)
Менеджеры гудеть начинают, но менять ничего не хотят. Тут же чисто человеческий фактор

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

К примеру - мы делаем некоторые измерения (вопрос еще как) и определяем что сейчас выкатывание фичи в маркет (среднее) - 3 месяца. Просим денег на рефакторинг на YYY и обещаем что TTM станет - ? 2 месяца. Или каким образом мы будем это обосновывать?
Я не в теме - есть вообще подобные цифры?

Частностей миллион

сложно сказать в какой момент, но в разработке произошел некий дрейф понятий. Почему-то многими считается, что работа разработчика заканчивается, после того, как он запушил изменения в git, работа тестировщика заканчивается когда он прошел тесткейсы и завел баги, работа РП заканчивается, когда к заданному сроку появилась некоторая поделка реализующая определенный функционал и стоило все это плюс минус оговоренные деньги.... Работа всех участников регаты заканчивается только тогда, когда удовлетворена потребность пользователя. А вот для того, чтобы максимально качественно и максимально быстро удовлетворять потребности пользователя может и потребоваться рефакторинг. А то если вы в прод очень быстро льете функционал который никому не нужен... Ну так себе вариант :)

Серединка - это диалог. Только диалог между стейкхолдерами

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

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

Бизнес, Архитектор, команды разработки и пр. Все заинтересованные в продукте/бизнесе лица

в ТТМ заинтересован бизнес в большей степени, может быть архитектор

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

Мне нравится слово "silos". Вот разобщённость нужно устранять

для бизнеса - "нужно". какая выгода для этого будет для разработчиков?

Жизнь свою прожить ненапрасно. Зрелые разработчики понимают, что кодят не ради кода

:) сказано, конечно, красиво :). Но высокие идеи не работают на галере :)

а вы не раотайте на галере :)

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