Como lidar com o gerenciamento de sistemas legados?


14

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.

6
Simpatizo com o seu problema. Infelizmente, não há uma maneira fácil de contornar isso e tenho certeza de que sua pergunta já foi feita de muitas maneiras diferentes. Uma coisa que eu recomendaria é evitar escrever um relatório com preocupações "abertas". Os gerentes (especialmente os não técnicos) odeiam isso, digam ou não. Se você se queixa de algo, precisa fazer recomendações concretas e práticas para melhorá-lo.
Angelo

3
@ James, o formato do documento, no seu contexto, é totalmente irrelevante. O que importa é que você 1) identifique as mudanças que precisa fazer, 2) descreva um plano concreto para implementá-las e 3) convença os envolvidos a concordar com o plano. Em um ambiente em que as coisas são "ad-hoc", a estrutura formal de documentos não significa nada.
Angelo

7
A menos que exista um sistema de substituição em desenvolvimento ativo, eu argumentaria que o atual não está "em suporte de vida". Especialmente se a empresa incluí-lo em planos futuros.
TMN

7
Desde quando um sistema de 5 anos de idade é "legado"?
Marjan Venema

1
@ James - Essa não é a definição de um sistema legado. O legado é definido por haver (claramente) uma tecnologia mais nova ou mais eficiente disponível, não a falha dos processos internos ou a retenção da equipe.
Jon Hopkins

Respostas:


23

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.


9
I've worked with code that was 10 years old before Que tal 25 anos :) Ainda atendeu às necessidades da empresa e fez um excelente trabalho no que foi projetado para fazer, apesar do fato de tocar no código ser tão agradável quanto um mergulho no Ártico.
maple_shaft

@maple_shaft Nada há 25 anos. Eu acho que o código mais antigo que eu já vi tinha entre 10 e 15 anos. Não é agradável, mas o usuário não se importa com código limpo. Eles se preocupam em usar um software que faça o que eles precisam de uma maneira que ajude seus negócios.
Thomas Owens

1
@ James Na verdade não. Se é um aprimoramento ou defeito de software que requer algumas alterações no sistema existente, é rastreado em um rastreador de defeitos, onde é priorizado e atribuído. Se é um processo, metodologia ou aviso para um projeto futuro, que é capturado por um projeto de viabilidade que protótipo da solução ou um memorando de engenharia.
Thomas Owens

1
Estou trabalhando em um sistema de 15 anos e isso é uma alegria. Sim, existem partes que poderiam ser aprimoradas, mas que podem ser partes antigas ou escritas há apenas seis meses. Como nas pessoas: a idade é insignificante. É o cuidado que foi tomado no desenvolvimento do software e quanta dívida técnica foi incorrida durante esse desenvolvimento, que determina quanto ou quão pouca alegria você pode obter dele.
Marjan Venema

1
@ James O SRS é técnico. Se você está lidando diretamente com o gerenciamento, e o desenvolvimento de software não é o principal negócio, terá que colocá-lo em termos comerciais. Como não há documentação do projeto existente e assim por diante, eu começaria com um caso de negócios ou plano de projeto ou uma análise de opções para reengenharia antes de qualquer SRS. Uma coisa que os gerentes e os negócios entendem é o custo. Uma reescrita completa pode ser repleta de dificuldades, então cuidado.
Jason S

7

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.


Talvez o uso do termo "legado" esteja incorreto. Atualmente, o técnico que dirige o sistema é o VBA e o ASP clássico. A base de código foi criada por vários estagiários rotativos no passado. A Wikipedia identifica um sistema legado como aquele que não é mais entendido e que essas situações ocorrem quando o sistema não está documentado e / ou os desenvolvedores originais deixaram. Além disso, "empurrar para trás" está entre aspas, porque tenho um lema pessoal de "nunca ficar satisfeito com a mediocridade" e, como tal, não pode ficar sentado sem expressar preocupações. Eu sinto como se não estivesse sendo útil #
James

@ James É bom expressar preocupações, mas faça-o uma vez, faça-o completamente, apresente uma alternativa viável e deixe-o assim. Se você falar sobre o mesmo problema mais de uma vez, será percebido como um chorão e os chorões não serão úteis. Se você não entende, e ninguém em casa realmente entende tecnicamente, então é realmente um legado que você está correto.
Maple_shaft

7
James, pode ser que você nunca esteja satisfeito com a mediocridade, mas com esse intercâmbio você está dando a impressão de que não é bom no quadro mais amplo de como o software suporta os negócios e como as prioridades dos negócios diferem das suas.
temptar

2
"A Wikipedia identifica um sistema legado como aquele que não é mais compreendido". Bem, se você o entender e documentar, para que seja entendido, não será mais um sistema legado.
quer

2
"nunca fique satisfeito com a mediocridade" é um bom lema, mas se aplica apenas a coisas que você pode controlar. Se você pegar uma base de código medíocre e transformá-la em uma base de código bem documentada e fácil de manter, é um excelente trabalho do qual você deve se orgulhar.
DJClayworth

5

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 /


Acredito que você esteja certo ao afirmar que não entendo o cenário mais amplo, pois não estou familiarizado com a sobrecarga associada ao desenvolvimento de software interno. A educação a que fui exposto até o ponto em que lida principalmente com processos formais ou, pelo menos, onde o desenvolvimento de software é o principal negócio #
James

4

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.


1
Uma das coisas mais importantes que podem ser feitas como X, Y ou Z é escrever testes de unidade. A realização de testes torna o trabalho com código legado, que pode ser interrompido a qualquer momento e muito menos estressante.
9117 Kevin

3

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ê.


A outra coisa para a qual os estágios são ótimos é determinar se você deseja ou não trabalhar para uma empresa e (para eles) se eles querem ou não que você trabalhe para eles. Essa é uma situação muito melhor do que se o OP tivesse sido contratado como funcionário em período integral e estivesse preocupado em manter o primeiro emprego ou sair rapidamente.
226117 Kevin

3

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.


2

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.


1

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.