Интересуют процессы по поддержке и доработке существующего приложения.

Суть.
На сегодняшний день есть приложение(клиент+база)
Есть несколько достаточно разных типов бизнеса, между которым клиентская часть примерно общая(общий код храниться в репозитарии), данные разные(по каждому бизнесу своя база+таблицы подключены в клиентскую часть).
Весь код клиента- это море разных if (бизнес=такой то) , то делать то и так далее.

В отделе программистов порядка 30 человек, по 2-3 на каждый тип бизнеса. Нет постановщика задач, нет архитектора(архитектура приложения достаточно вмеяемая ..была раньше, на сегодня пущено все на самотек и разрывается студентами на части).

Каждый из разработчиков при разработке проходит следующие этапы:
-бизнес логика(совещание с бизнесом, влияние изменений на бизнес логику программы)
-архитектура(влияние изменений в программе на остальные бизнесы:внесение разных use, if и etc, в том числе +,- поля из таблиц баз данных, и хотя базы разные, но поля то все равано могут быть удалены и потом ввиду несовершенства кода, либо потеряны данные, либо ошибки при копировании из локальных таблиц в общие)
-тестирование
-первый запуск продукта

На этапе поддержке приложения(возникшие сбои в последствие, после первого запуска) есть 2 дежурных(в 1м городе физически программисты и географически поделены на 2 группы ), по 1 му на каждую группу.
При возникшем сбое он пытается либо сам решить проблему, либо раз в N е время отвлечь ответственного по бизнесу программиста, либо передать инцидент менеджеру тот же своим решением оторвет остальных программистов от разработки.


И технически и с точки зрения процессов довольно уныло. Есть прецеденты по переходу (с вмеяемыми сроками ) на слегка иную архитектуру(не говорим о конкретных СУБД или языке программирования) поддержки и разработки?

Немного вертикали власти(немного иерархии с верху вниз):

-Начальник отдела

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