Bug – O grande mal que assola a TI

“O uso do termo bug (em português: “inseto”) para descrever defeitos inexplicáveis foi parte do jargão da engenharia por várias décadas; pode originalmente ter sido usado na engenharia mecânica para descrever maus funcionamentos mecânicos. Diz-se que o termo foi criado por Thomas Edison quando um inseto causou problemas de leitura em seu fonógrafo em 1878, mas pode ser que o termo seja mais antigo.”

Fonte: Wikipedia

Cronograma bem planejado, profissionais competentes e um bom gestor. O que poderia prejudicar o sucesso do projeto?

Resposta: O famigerado BUG!

Um dos grandes males que assolam a TI é a quantidade de bugs nos softwares o que obriga as empresas alocar recursos para solucioná-los. Com quase 22 anos de profissão vi bugs, dos mais simples aos mais complexos, em sistemas de engenharia, previdência, legistativo, financeiro e militar de grandes e pequenas empresas.

Os desenvolvedores tem que deixar de lado seus novos projetos para corrigir os bugs, ou seja, perde-se o foco na resolução de problemas dos softwares que estão em produção/certificação.

Isso impacta, e muito, no cronograma de um desenvolvedor, tanto pela qualidade como pelo prazo pré-estabelecido do projeto. Alguns gestores parecem não entender o quão isso é ruim para o profissional de TI, equipe e para empresa.

Numa grande empresa que trabalhei, cheguei a ficar 3 semanas sem programar uma única linha de código “nova”, somente resolvendo bugs. E eram bugs complexos de se resolver…e como eram…

E o que aconteceu com o meu cronograma? Foi pro espaço! Literalmente…

Cronogramas atrasados já geram um stress com gerência e sistemas entregues com atraso e com bugs geram mais stress ainda.

Cada empresa tenta combater esse mal da sua maneira, mas posso afirmar que é de fundamental importância, independente do tamanho da empresa, uma área de homologação com total conhecimento do business e com um roteiro de testes sempre atualizado.

Como os cronogramas atrasam, geralmente essas áreas são pressionadas a homologar o sistema o mais rápido possível, e é por ai que esse inseto, ops, bug se aproveita para sobreviver.

Acho muito válida a ideia de uma equipe de “infantaria”, ou seja, uma equipe que seja acionada quando um bug for detectado, assim o desenvolvedor só seria necessário em último caso.

Pode parecer utopia, mas converse com qualquer desenvolvedor e com certeza ele gostaria de trabalhar o dia inteiro focado na programação, sem ser interrompido por usuários. Será que um dia ainda verei isso?

Sei também que é muito mais fácil tudo isso na teoria que na prática, pois já presenciei áreas de homologação que não detectavam erros básicos e áreas de “infantaria” que só sabiam pegar o telefone e ligar para o desenvolvedor.

Para equipe de desenvolvedores e para o gestor, acho válido uma conversa franca e profissional, logo após um projeto ser entregue. Para se discutir o que pode ser feito para melhorar, para não os erros não se repitam.

Para finalizar, bugs + atraso de cronograma = prejuízo $$$ para empresa

Bom esse foi o primeiro artigo de 2014!

Espero conseguir a média de 1/mês… 🙂

[Crédito da Imagem: Watirmelon.com]