Atualmente, estou em um estágio remunerado e fui encarregado de manter um sistema obsoleto que foi desenvolvido por vários desenvolvedores (em momentos diferentes) nos últimos 5 anos. A gerência concorda que o "sistema está disponível para suporte à vida" e recebo um fornecimento bastante regular de relatórios de erros dos usuários finais que atualmente usam o sistema.
O sistema não é obsoleto se as pessoas ainda o estão usando e está apoiando as atividades de negócios. Como ainda está sendo usado, a empresa não pode simplesmente descartá-lo - ele precisa ser suportado até que a necessidade do sistema não exista mais. Isso pode ser uma mudança nos objetivos de negócios ou um novo sistema foi desenvolvido, testado e implantado com sucesso para os usuários finais.
Realmente, 5 anos não é tão longo. Eu trabalhei com código que tinha 10 anos antes. Se ainda estiver atendendo às necessidades do usuário, por que jogá-lo fora? Isso está desperdiçando muito dinheiro gasto para desenvolvê-lo. Até que se torne inviável a manutenção devido ao aumento dos custos ou à alteração drástica dos requisitos, não há motivo comercial para descartá-la.
A gerência agora quer estender o projeto por mais um ano e, no processo, quase o triplo da base de usuários.
Se a gerência diz que este sistema está "em suporte de vida", por que eles estão tentando implantá-lo ainda mais? É comum que as atividades de manutenção continuem em um sistema legado até que seja substituído, mas se um sistema estiver no fim da vida útil, ele normalmente não será implantado para mais pessoas. Estender a manutenção é uma coisa, mas adicionar usuários que dependem do sistema é uma situação diferente.
Para mim, parece que na verdade não é o fim da vida útil, mas sim em uma fase de manutenção e continuará existindo até que o sistema não atenda mais às necessidades dos usuários.
Como estagiário (ou qualquer posição de nível de entrada), como "recuo"? Já escrevi um relatório informando minhas preocupações, embora em um documento aberto. Existe protocolo ou tipo de documento para sugerir alterações? Estou em posição de fazer sugestões ou devo simplesmente continuar a apoiar o sistema antigo?
Você precisa continuar suportando o sistema antigo. Mais tarde, você menciona que o software não é o principal negócio da sua empresa. Nesse ambiente, o trabalho das equipes de software é apoiar os negócios principais da empresa. No entanto, as equipes de software também precisam manter os objetivos de negócios em mente.
Enquanto isso, capture suas sugestões de uma maneira que não seja arrogante. Indique outras tecnologias ou técnicas que poderiam ser integradas ao sistema ou usadas se / quando um novo sistema for criado e seus prós / contras. Como você faz isso depende da empresa, mas considerando alguns pontos posteriores, talvez seja útil estabelecer um wiki ou outro site colaborativo.
Em uma empresa que não é de software, o software é um custo e as equipes de software (especialmente os gerentes de projeto / programa de software) devem trabalhar para minimizar o custo de construção e manutenção de sistemas de software, tanto quanto possível, além de apoiar as necessidades dos usuários finais . Jogar fora um software que (até onde eu saiba, da sua postagem) atenda às necessidades dos usuários vai contra o que é do melhor interesse da equipe de software.
* Para esclarecer, o desenvolvimento de software não é o principal negócio da minha empresa. Como tal, não existem protocolos internos. Além disso, o projeto não possui documentação formal, documentos de requisitos. O desenvolvimento é muito ad hoc.
Para mim, este é o problema. Não produzir documentação, não desenvolver uma especificação e falta de consistência tendem a aumentar o custo do desenvolvimento de software. Trabalhar para consertar isso seria minha maior prioridade, e eu faria isso trabalhando em coisas como um padrão de codificação, controle de versão, produzindo códigos de auto-documentação e documentos de design, rastreamento de defeitos e especificações de requisitos.