Uma empresa vive de ganhos $$, então a melhor forma de convencê-la a mudar é falando a mesma língua que ela.

Tome cuidado com essa questão de “Refatoração” e “Atualizar tecnologia”, já trabalhei com muita gente que defende isso e faz essa tal de refatoração e atualiza com a tecnologia da moda. E no fim das contas faz uma merda só com a linguagem/framework do momento.

E se alguém já fez isso na empresa que trabalha, vai deixar mais difícil ainda eles aceitarem a mudança.

Posso estar equivocado na minha colocação, mas não acho que exista empresa de TECNOLOGIA, e sim uma empresa que usa a tecnologia para vender o seu produto (mesmo que ela venda a tal “tecnologia”).

Sendo assim, você primeiro precisa levantar as vantagens que e empresa terá quando a “equipe de Tecnologia” participar do processo, além de provar de forma mensurável o que irá melhorar na refatoração do código (vai melhorar a velocidade do desenvolvimento? Vai melhorar a performance? Vou conseguir ganhar mais dinheiro?)

Outra coisa, nunca diga que tem que refazer tudo, isso assusta. Veja onde estão os maiores problemas e refaça aos poucos, quando perceber pode ser que todo o legado já tenha morrido.

Enfim, se você não mostrar por A+B que terá ganho financeiro (seja um produto melhor que facilite sua venda, ou um desenvolvimento mais rápido no qual poderá finalizar um cliente novo em menos tempo), apenas argumentos que está ruim não vai resolver seu problema.

O foco nem é necessariamente atualizar tecnologia para usar coisas da moda ou algo assim, é realmente para reestruturar as coisas que foram feitas como MVP no início e estão lá até hoje. Revisitar o projeto para deixa-lo mais sólido. Não existe documentação ou registro das regras de negócios, o que deixa tudo mais complicado. "Isso deu erro porque o código ta errado? A regra escrita ta certa? O sistema faz o que esperam que ele faça?" Hoje temos dificuldade em manter e criar novas funcionalidades em cima da base caótica e isso pra mim também tem um custo. E acho que hoje é um custo invisível. Questionam o custo de planejar o ajuste de algo pronto, mas não consideram que uma base boa garante uma série de vantagens que economizam dinheiro e logo, refletem no bolso. Concordo com o que você falou sobre EMPRESA DE TECNOLOGIA, eu falei assim mais para deixar nos mesmos termos que eles mesmos dizem. E sobre refatorar ou refazer tudo, com certeza não é algo tratado dessa forma. A vida não vai parar pra gente refazer o que existe. hehehe Acho mesmo que o lance é mostrar o ganho financeiro que pode existir, mas como disse na resposta do outro comentário, a dúvida é se eu vou conseguir fazer isso. Sou dev, não estou acostumado a tratar de tecnologia nesse nível de gestão e tals... por isso uma das minhas críticas foi não ter uma liderança no setor.

É muito difícil mesmo, eu já passei (e ainda passo em alguns casos) as mesmas dores que você. Toda empresa quer que um projeto saia rápido e vem com o bordão (faz um MVP depois melhoramos) e no fim vende o MVP e fica por isso mesmo. No meu caso sempre que tive sucesso em encaixar as soluções foi da seguinte forma. Entre uma tarefa e outra caso sobre um espaço tento melhorar algo que seja **tangível**, depois apresento para alguém que tenha o "**poder**" de autorizar a mudança o que foi feito e mostro o que agregou. Se gostarem é a hora que tento vender isso para o restante. Vou te dar um exemplo (sei que não é arquitetura de software mas uma situação que tive que tomar essa medida). ## Exemplo que aconteceu comigo Imagina um sistema que em uma determinada funcionalidade tenha um fluxo de trabalho com 5 telas, em uma dessas telas eu ia precisar fazer uma pequena implementação (vamos chamar aqui de tela 3). Todas as telas eram lentas e feias, sendo assim estimei fazer a implementação com um pouco de tempo a mais para eu poder melhorar a beleza da tela 3 e sua velocidade. Apresentei a tela 3 com sua beleza e velocidade para quem solicitou, e comparei com as outras telas (“O joaquim olha como essa tela está bem melhor seu layout e sua velocidade comparado com as outras”) Joaquim observou e disse, “É mesmo”. Esse foi o momento chave onde eu disse, “Então o sistema vai ficar estranho se uma etapa é muito lenta e com o layout feio e uma única tela dessa forma. Não posso aplicar isso nas outras, vou precisar de mais uma semana”. E com sorte obtive o sim. Com essa abordagem consegui mostrar algo tangível e convencer de alterar o resto desse fluxo de trabalho. Sei que nem sempre isso vai funcionar, mas nessa circunstância deu certo.
É basicamente o que a equipe vem tentando fazer. Mas as vezes desmanima. A equipe inteira se questiona de praticamente estar se preocupar com o produto mais do que o dono dele.