А тут постоянное и понятное решение с завязкой на легаси.

По идее да, но по факту получается, что очень, очень долгое время идёт разделение: часть ресурсов выделяется на постоянное мелкое перепиливание того, что есть, а часть - на создание нового будущего

Это развитие нового продукта?

Не-не, такая ситуация обычно при поддержке уже внедренного корпоративного "нечто", на что смотрят критичные стейкхолдеры (акционеры, поставщики, клиенты)

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

Погоди, ты ведь сейчас говоришь про перестройку существующего решения из старой архитектуры в новую?
Тут вроде сбор требований и работы легаси системы > реализация > миграция (опционально: временная синхронизация данных) > проверка качества > отключение легаси?

Тут важный вопрос, когда вы начали разработку, техническое решение, в целом, было готово?

Может быть и такое. Может быть и реализация новых, корректных фич вместо старых "работающих абы как", при сохранении архитектуры.

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

Ну новое тех решение готово, просто выбор - либо влить все ресурсы в его  реализацию (грубо, 3-4 месяца), либо пилить его в стол, параллельно "подтачивая" существующее, и тогда до ввода нового в прод может пройти 7-9 месяцев, а может и больше, никто не знает

Мы кажется про разное говорим. Я про то, что если архитектуру надо менять в процессе формирования решения, то её надо менять, а не пытаться делать костыли как ненормальные (например, потому, что так будет дешевле).

Ты про то, что в целевое решение не нужно закладывать костыли?

как же без церемонии заложения костылей то жить дальше

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

Вообще, последнее время у меня сформировалось понимание, что системный аналитик - это человек, ответственный за архитектуру решения, но не имеющий права её изменять.

Мы выбрали новый стек и архитектуру. Тогда ведь, пока мы идем к ней, мы попадаем в ситуацию которую я описал?  

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

Олег, касательно последней части с выводами. Я понимаю, что все архилогично, но... очень радикальненько звучит. Надо иметь смелость послать все к черту и отпустить. :)

Ты про стандартный перенос функциональности на новые рельсы c добавлением фечей.
А я больше про ошибки такого подхода:
- начнём делать на старом стеке не рассматривая новый
- начнём делать без понимания всех подводных камней

Ты не первый, кто так говорит. От проекта пока не получится уйти, так что приходится уменьшать время его присутствия, фокусироваться на других вещах.
Послать всё и уйти сейчас не вариант. Может потом перейду в другой отдел или что-то в этом роде.
Но сейчас на проекте работает много человек, на мне многое завязано, надо было соскакивать раньше.
В целом работа у меня хорошая, просто конкретно проект вышел неудачный.

И я говорю сейчас про то, как почувствовать, что всё идёт через одно место и соскочить вовремя.

В целом у меня поведение такое - о хороших практиках я медленно снимаю видео, о плохих ору в чат. Так и живём. xD

Тогда ты про стандартную доработку без пересмотра архитектуры?)