Como lidar com o gerenciamento de sistemas herdados?

14

Atualmente estou em um estágio remunerado e fui encarregado de manter um sistema obsoleto que foi desenvolvido por vários desenvolvedores (em diferentes momentos) ao longo dos últimos 5 anos. A gerência concorda que o "sistema está em suporte vital" e eu recebo um suprimento bastante regular de relatórios de bugs de usuários finais que atualmente usam o sistema.

O gerenciamento agora quer estender o projeto por mais um ano e, no processo, quase triplicar a base de usuários.

Como estagiário (ou em qualquer posição de nível de entrada), como faço para "retroceder"? Eu já escrevi um relatório declarando minhas preocupações, ainda que 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 antigo sistema?

  • 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 e nem documentos de requisitos. O desenvolvimento é muito ad hoc.
por James 02.11.2011 / 14:05
fonte

8 respostas

23

I am currently on a paid internship, and have been tasked with maintaining an obsolete system that has been developed by multiple developers (at different times) over the course of the past 5 years. Management agrees the "system is on life support", and I receive a fairly regular supply of bug reports from end users currently using the system.

O sistema não está obsoleto se as pessoas ainda o estiverem usando e suportando as atividades de negócios. Como ainda está sendo usado, o negócio não pode simplesmente jogá-lo fora - ele precisa ser suportado até que a necessidade do sistema não exista mais. Isso poderia ser uma mudança nos objetivos de negócios ou um novo sistema foi desenvolvido, testado e implantado com êxito para os usuários finais.

Realmente, 5 anos não são tão longos. Eu trabalhei com código que tinha 10 anos antes. Se ainda está atendendo às necessidades do usuário, por que jogá-lo fora? Isso está jogando fora muito dinheiro gasto para desenvolvê-lo. Até que se torne inviável de se manter devido ao aumento de custos ou os requisitos mudem drasticamente, não há razão comercial para jogá-los fora.

Management now wants to extend the project for another year, and in the process nearly triple the user base.

Se a gerência diz que esse 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 ele seja substituído, mas se um sistema estiver em fim de vida, ele não é normalmente 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 não é realmente o fim da vida, mas sim em uma fase de manutenção e continuará lá até que o sistema não sirva mais às necessidades dos usuários.

As an intern (or any entry level position) how do I "push back"? I've already written a report stating my concerns, albeit in an open-ended document. Is there protocol or document type for suggesting changes? Am I in a position to make suggestions, or should I simply continue to support the old system?

Você precisa continuar a suportar o sistema antigo. Mais tarde, você mencionou que o software não é o principal negócio da sua empresa. Em tal ambiente, o trabalho das equipes de software é apoiar os principais negócios da empresa. No entanto, as equipes de software também precisam manter os objetivos de negócios em mente.

Nesse meio tempo, capture suas sugestões de uma maneira que não seja arrogante. Aponte outras tecnologias ou técnicas que possam ser integradas ao sistema ou usadas se / quando um novo sistema for criado e suas vantagens / desvantagens. Como você faz isso depende da empresa, mas considerando alguns pontos posteriores, talvez seja útil criar um wiki ou outro site colaborativo.

Em um negócio sem software, o software é um custo e as equipes de software (especialmente os gerentes de projetos / programas de software) devem estar trabalhando para minimizar o custo de criação e manutenção de sistemas de software tanto quanto possível, ao mesmo tempo em que atendem às necessidades de software. os usuários finais. Jogar fora o software que (até onde eu posso dizer, do seu post, de qualquer maneira) atende às necessidades dos usuários vai contra o que é do melhor interesse da equipe de software.

*To clarify, software development is not my company's primary business. As such no internal protocols exist. Additionally, the project has no formal documentation at all, no requirements documents. The development is very ad hoc.

Para mim, esse é o problema. Não produzir documentação, não desenvolver uma especificação, e uma falta de consistência tende a aumentar o custo de 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.

    
por 02.11.2011 / 14:23
fonte
7

I've already written a report stating my concerns

Bom. Isso é sobre a extensão do que você pode fazer como estagiário. Para referência futura, ao escrever tais relatórios, enfatizo a apresentação de fatos concretos de maneira imparcial e profissional, livre de preconceitos emocionais. Você não sabe quem lerá o relatório, possivelmente alguém que possa ou não ter causado alguns dos problemas que você está descrevendo ou tenha tomado decisões que levaram a esses problemas. Qualquer coisa que não sejam fatos frios pode ser tomada por tais pessoas como uma afronta ou uma ofensa e fará com que eles não gostem de você e possivelmente não levem nada a sério.

Management now wants to extend the project for another year, and in the process nearly triple the user base

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

Na maioria das vezes, não, 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 o resultado final. Tomar esse tipo de decisão é, às vezes, por que ser um gerente é uma droga, porque você geralmente está em uma situação de perda, não importa o que você faça.

maintaining an obsolete system that has been developed by multiple developers (at different times) over the course of the past 5 years

Erros foram cometidos durante todo o projeto que levou 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 como eles existem hoje. Eu não sei se obsoleto é a palavra certa embora. A tecnologia subjacente é construída sobre estruturas e tecnologias desatendidas, ou simplesmente não é a tecnologia de ponta ou ideal?

As an intern (or any entry level position) how do I "push back"?

Você está em uma posição de menos poder e você é temporário nisso. Não importa se você está certo, eu não esperaria que um estagiário me "empurrasse" para trás. Espero que aprendam, discutam questões à medida que as vêem e sigam as ordens. É sobre isso. Uma vez dada uma ordem, espero que seja realizada com o melhor de sua capacidade, porque o tempo para a discussão acabou nesse ponto.

    
por 02.11.2011 / 14:22
fonte
5

Você é um estagiário. Eu duvido muito se você é mesmo remotamente au fait com os imperativos de negócios do dia a dia como um todo e como outras pessoas têm notado, uma base de código de 5 anos de idade não é realmente tão antiga.

As decisões sobre a substituição de sistemas legados nem sempre são dirigidas tecnicamente; eles são impulsionados pela alteração dos requisitos de negócios. Entrada para aqueles pode ser dificuldades relativas à 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 diria até que você tem muito pouco do conhecimento necessário para fazer a ligação sobre qual é a melhor jogada no momento.

Meu conselho para você é o seguinte: aprenda com a experiência e pare de assumir que seu conhecimento supera o de pessoas que precisam administrar os negócios diariamente.

Seu trabalho é manter o sistema funcionando, não sugerir um novo substituto brilhante.

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

    
por 02.11.2011 / 14:47
fonte
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 caros demais para serem substituídos.

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

O que você pode fazer:

Deixe as coisas mais limpas

Quando você mantém alguma coisa, deixe-a mais limpa do que quando começou. faça sua correção, mas também limpe as coisas para que a 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ê está trabalhando em uma parte específica do sistema, documente-o.

Torne menos doloroso

Como afirmei, você pode exprimir as suas preocupações, mas o seu melhor, apenas trabalhando diligentemente no sistema e fazendo com que seja melhor trabalhar para aqueles que o seguem. Corrigir erros corretamente. Documento. O código de dispersão cheira. Melhorar. E quando você fizer essas coisas, deixe seus superiores saberem. 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.

    
por 02.11.2011 / 15:40
fonte
3

VOCÊ NÃO FAZ !!! Esta é uma ótima oportunidade!

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

Você tem muita sorte em ter isso. O fato de você não ser qualificado não é sua preocupação. (Se \ quando a administração percebeu isso, você terá ganho muito)

VOCÊ estará qualificado quando terminar este estágio E isso é uma ótima notícia.

PS: Faça backups religiosamente, tenha certeza de que QUALQUER COISA que você faça possa ser revertida. Comece com os problemas que são "correções fáceis", mas grandes pontos problemáticos para os usuários. Dê passos de bebê.

    
por 02.11.2011 / 14:51
fonte
3

Eu acho que, em um sentido muito teórico - não existe tal coisa chamada Sistema legado . 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 foram um dia o estado-da-arte. É apenas o tempo que precisamos. Além disso, quando há trabalhos consideráveis em andamento, não é que refazer todo o material novamente em plataformas modernas significa que ele será automaticamente livre de erros (ou sem problemas).

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

  1. Deixe de lado sua antipatia pelo "sistema legado" primeiro. Isso vai te fazer muito contraproducente.

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

  3. Em vez de tentar retroceder na promoção de "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 novo, que pode ser isolado, pode ser feito passo a passo em novas plataformas sem quebrar a interoperabilidade com sistemas antigos. Lentamente (e isso será muito devagar) à medida que as coisas evoluírem, a necessidade de manter o sistema legado desapareceria. Essa é a única maneira de dizer adeus a qualquer sistema antigo.

Dipan.

    
por 02.11.2011 / 17:52
fonte
2

A verdade é que ninguém dá aos internos o trabalho que eles querem fazer. Quando você é a pessoa mais jovem, você recebe o trabalho menos excitante. Quão bem você lida com isso, diz muito à organização se eles podem confiar em você para fazer mais o trabalho emocionante.

Então, aqui está uma oportunidade inestimável para mostrar que você pode entregar fazendo as correções de bugs, que você pode refatorar fazendo cada parte do código tocar um pouco, criar testes unitários, começando a criá-los para este sistema e que você pode documentar criando documentação para a próxima alma pobre que está presa neste sistema. Ele também lhe dá a oportunidade de mostrar que você pode lidar com os usuários de forma eficaz (para obter mais detalhes sobre os bugs relatados) e atender às suas necessidades. Se o projeto não estiver agora no controle de origem, coloque-o lá e se os erros não forem rastreados em um rastreador de bugs, inicie um. Esses tipos de ações mostram que você sabe trabalhar profissionalmente. Tudo isso é uma experiência muito mais valiosa do que apenas trabalhar em alguma tecnologia divertida, fazendo um projeto que será lançado assim que você for embora (as outras coisas que alguns estagiários são designados a fazer).

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 receberá um emprego nessa empresa após o seu estágio.

    
por 02.11.2011 / 20:16
fonte
1

Você provavelmente não tem informações suficientes para determinar se é rentável ir 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 acontecendo e eles simplesmente não podem se dar ao luxo de recuar financeiramente ou sob certas restrições de tempo para criar outro aplicativo. Construir um novo aplicativo raramente é a melhor escolha. 5 anos não é tão antigo, a menos que eles construíram em tecnologia antiga para começar.

    
por 02.11.2011 / 23:56
fonte