Como lidar com o gerenciamento de sistemas legados?

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.

A gerência agora quer estender o projeto por mais um ano e, no processo, quase o triplo da base de 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?

• 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 nem documentos de requisitos. O desenvolvimento é muito ad hoc.

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.

Eu já escrevi um relatório informando minhas preocupações

Boa. Essa é a extensão do que você pode fazer como estagiário. Para referência futura ao escrever esses relatórios, enfatizo a apresentação de fatos concretos de maneira imparcial e profissional, isenta de preconceitos emocionais. Você não sabe quem lerá o relatório, possivelmente alguém que pode ou não ter causado alguns dos problemas que você está descrevendo ou que tomou decisões que os levaram a esses problemas. Qualquer coisa diferente de fatos frios pode ser tomada por pessoas como afronta ou ofensa e fará com que elas não gostem de você e possivelmente não leve nada disso a sério.

A gerência agora quer estender o projeto por mais um ano e, no processo, quase o triplo da base de usuários

Lembre-se de que decisões de negócios como essa são tomadas porque elas estão tentando fazer o devido com os recursos disponíveis. Estou certo de que o gerenciamento provavelmente está ciente dos problemas com o software legado e provavelmente das queixas dos usuários, mas eles têm os recursos de desenvolvimento de software disponíveis para lidar com refatoração ou reescrita?

Na maioria das vezes, isso não ocorre, especialmente se o software não é o pão com manteiga da empresa, e a qualidade e a satisfação do usuário com o software não afetam diretamente os resultados finais. Às vezes, tomar esse tipo de decisão é o motivo de ser um gerente ser péssimo, porque muitas vezes você está em uma situação de perda ou perda, não importa o que faça.

manter um sistema obsoleto que foi desenvolvido por vários desenvolvedores (em momentos diferentes) nos últimos 5 anos

Foram cometidos erros ao longo do projeto que o levaram a este ponto. A falta de informações ou requisitos sólidos do usuário, a falta de gerenciamento adequado de produtos e controle de alterações para gerenciar requisitos e necessidades variáveis ​​e a falta de recursos técnicos adequados para implementar causaram os problemas que existem hoje. Não sei se obsoleto é a palavra certa. A tecnologia subjacente é construída sobre estruturas e tecnologias não suportadas ou simplesmente não é a tecnologia de ponta ou ideal?

Como estagiário (ou qualquer posição de nível de entrada), como "recuo"?

Você está em uma posição de menor poder e é temporário nisso. Não importa se você está certo, eu não esperaria que um estagiário me "pressionasse". Espero que eles aprendam, discutam questões como as vêem e sigam as ordens. É sobre isso. Depois que uma ordem é dada, espero que seja executada da melhor maneira possível, porque o tempo para a discussão termina nesse ponto.

Você é estagiário. Duvido muito que você esteja remotamente familiarizado com os imperativos comerciais do dia a dia como um todo e como outras pessoas notaram, uma base de código de 5 anos não é tão antiga assim.

As decisões sobre a substituição de sistemas legados nem sempre são tecnicamente orientadas; eles são motivados pela alteração dos requisitos de negócios. A entrada para aqueles pode ser dificuldades relacionadas à manutenção; mas no final do dia, você precisa reconhecer que sua posição não significa necessariamente que você tem todo o conhecimento disponível e necessário. Eu chegaria ao ponto de dizer que você realmente tem muito pouco do conhecimento necessário para decidir qual é a melhor jogada atualmente.

Meu conselho para você é o seguinte: aprenda com a experiência e pare de supor que seu conhecimento supera o das pessoas que têm que administrar os negócios no dia a dia.

Seu trabalho é manter o sistema funcionando, não sugerir uma nova substituição brilhante.

Parece-me que muitos programadores jovens não percebem que a manutenção de sistemas mais antigos é uma parte maior do trabalho de programação do que projetar novos sistemas brilhantes /

Não recue. A única coisa que você deve fazer é expressar suas preocupações de maneira clara e concisa. O fato é que a maioria das empresas em que você trabalhará no futuro terá sistemas legados. Esses sistemas legados precisam ser mantidos porque, em muitos casos, são muito caros para serem substituídos.

Em muitos casos, você pode até ter as melhores intenções de substituir o sistema atual por um sistema melhor; no entanto, você pode apenas introduzir bugs novos e diferentes ... quando sair do sistema, rapidamente se tornará um sistema legado novamente e a empresa irá estar no mesmo lugar que estava antes. Nada é obsoleto até que não atenda mais a sua finalidade ou seja completamente incompatível com os sistemas modernos. Minha empresa tem um sistema com mais de 20 anos que agora estamos convertendo para o ASP.NET. O sistema ainda funciona, mas o suporte à tecnologia antiga está diminuindo e o trabalho com navegadores da Web modernos está se tornando cada vez mais demorado.

O que você pode fazer:

Deixe as coisas mais limpas

Quando você mantém algo, deixe-o mais limpo do que quando você começou. faça sua correção, mas também limpe as coisas, para que da próxima vez que alguém precise fazer uma modificação seja mais fácil de entender.

Criar documentação

Se a falta de documentação for um problema, crie documentação. Quando você estiver trabalhando em uma parte específica do sistema, documente.

Torná-lo menos doloroso

Como afirmei, você pode expressar suas preocupações, mas é melhor trabalhar apenas diligentemente no sistema e melhorar o trabalho para as pessoas que estão atrás de você. Corrija os erros corretamente. Documento. O código disperso cheira. Melhorar. E quando você fizer essas coisas, informe seus superiores. Diga a eles que você está fazendo X, Y e Z para melhorar o processo de desenvolvimento. Isso cria credibilidade e, a longo prazo, ajudará você e sua empresa mais do que qualquer outra coisa.

VOCÊ NÃO !!! Esta é uma grande oportunidade!

Você é um estágio para aprender! Este projeto é um mundo real como ele ganha.

Você tem muita sorte de tê-lo. O fato de você não estar qualificado não é da sua conta. (Se \ quando a gerência percebeu isso, você ganhou muito)

Você será qualificado assim que terminar este estágio, e isso é uma ótima notícia.

PS: Faça backups religiosamente, certifique-se de que QUALQUER COISA que você faz pode ser revertida. Comece com os problemas que são "Correções fáceis", mas existem muitos problemas para os usuários. Dê passos de bebê.

Eu acho que, em um sentido muito teórico - não existe um sistema chamado Legacy . Eu tenho um telefone muito antigo (um sistema legado) e hoje em dia existem bons telefones Android (plataformas modernas), mas meu telefone funciona e faz o que eu preciso. Por que eu deveria jogar isso fora?

Todos os sistemas que você chama de "legado" hoje eram um dia o estado da arte. É apenas o tempo que precisamos. Além disso, quando há um trabalho considerável, não é que refazer tudo novamente nas plataformas modernas, significa que ele estará automaticamente livre de bugs (ou sem problemas).

Aqui está o que eu recomendo que você faça:

1. Deixe de lado sua antipatia pelo "sistema legado" primeiro. Isso fará com que você seja muito contraproducente.

2. Comece a documentar o que você faz agora e o que pensa. Ainda que passo a passo. Não há tempo melhor para fazer a documentação do que aquela em que você percebe que precisa.

3. Em vez de tentar retroceder o avanço do "sistema legado" - tente definir o caminho para sua saída sem problemas. Tente ver que você pode convencer o gerenciamento de que o desenvolvimento mais recente, que pode ser isolado, pode ser feito passo a passo em novas plataformas, sem interromper a interoperabilidade com os sistemas antigos. Lentamente (e isso será muito lento) à medida que as coisas evoluem, a necessidade de manter o sistema legado desapareceria. Essa é a única maneira de se despedir de qualquer sistema antigo.

Dipan.

A verdade é que ninguém dá aos estagiários o trabalho que eles querem fazer. Quando você é a pessoa mais jovem, obtém o trabalho menos emocionante. O quão bem você lida pessoalmente com isso diz muito à organização sobre se eles podem confiar em você para fazer mais um trabalho emocionante.

Portanto, aqui está uma oportunidade inestimável para mostrar que você pode entregar as correções de erros, refatorar tornando cada parte do código que você toca um pouco melhor, que você pode criar testes de unidade, começando a criá-los para este sistema e que você pode documentar criando documentação para a próxima pobre alma que está presa a esse sistema. Também oferece a oportunidade de mostrar que você pode lidar com os usuários de maneira eficaz (para obter mais detalhes sobre os bugs relatados) e atender às suas necessidades. Se o projeto não está agora no controle de origem, coloque-o lá e se os bugs não forem rastreados em um rastreador de bugs, inicie um. Esses tipos de ações mostrarão que você sabe como trabalhar profissionalmente.

Ou você pode seguir o caminho oposto e apenas reclamar sobre o quão ruim é o projeto e como seria legal substituí-lo. Nesse caso, você quase certamente não será oferecido um emprego nessa empresa após o estágio.

Você provavelmente não possui informações suficientes para determinar se é rentável passar mais um ano ou não. Seria interessante entender a empresa e por que eles estão adicionando usuários. Parece que pode haver algum crescimento e eles simplesmente não podem dar um passo atrás financeiramente ou com certas restrições de tempo para criar outro aplicativo. A criação de um novo aplicativo raramente é a melhor opção de qualquer maneira. Cinco anos não são tão antigos, a menos que eles tenham sido construídos com tecnologia antiga.