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]
Leave a Comment