VOCÊ SABE COMO FUNCIONAM OS CRONOGRAMAS DOS PROJETOS DE DESENVOLVIMENTO DE SOFTWARE?

Ricardo Bozzeda, MBA, CTFL-AT, CTAL-TM, ITIL

Você se lembra de quando foi a última vez que o cronograma de um projeto de desenvolvimento de software foi cumprido? Eu não me lembro.

Nestes anos de vivência nas áreas de desenvolvimento e de teste, trabalhei em diversas companhias e com as principais empresas de desenvolvimento de software do país, e posso afirmar sem medo de errar, que o cumprimento dos prazos não é levado a sério. Ninguém realmente acredita nas datas planejadas.

Uma pesquisa recente nos EUA revelou que no mundo, mais de 75% dos projetos de desenvolvimento de software são entregues com atraso. Acredito que no Brasil este número seja maior. Outra constatação é que tamanho não faz diferença, os atrasos estão uniformemente distribuídos entre projetos pequenos, médios e grandes. Esta notícia deveria ser preocupante, principalmente para uma indústria em que os prazos são tão importantes e os atrasos podem trazer consequências graves para as outras áreas do negócio.

Mas de qualquer forma estas informações oferecem a motivação para questionar porque o desenvolvimento de software é tão afetado por atrasos e se algo pode ser feito para melhorar este quadro?

Em primeiro lugar, quais os problemas mais comuns que levam ao atraso aos projetos de desenvolvimento de software:

    • Subestimar a complexidade da aplicação. Levando a gastar muito mais tempo para as tarefas planejadas;

    • Mudanças nos requisitos. Requisitos mal definidos, incompletos ou errados, levando a um retrabalho sem fim;

    • Documentação (quando existe) sem o mínimo da qualidade esperada e sempre desatualizada. Podendo levar ao desenvolvimento de soluções equivocadas e que terão que ser refeitas;

    • Baixa qualidade dos códigos escritos, com erros primários. Novamente levando ao retrabalho;

    • Testes limitados (quando existe algum teste). Assim encontramos os erros muito tarde e por vezes é preciso reiniciar todo o processo para corrigir.

A principal consequência disto são sistemas ruins, ou melhor, muito ruins. Mas também, prazos e custos estourados e o estresse dos clientes e das equipes.

E de quem é a culpa? De todos, negócios, sistemas e testes. Todos mentiram ou concordaram com as mentiras, desde o momento que aceitaram os prazos e aprovaram o plano do projeto e o cronograma. E o pior é que eles sabem disto.

Como funciona o processo

Tempos atrás levávamos anos para desenvolver e implantar um sistema, as metodologias eram burocráticas e lentas, a tecnologia não ajudava muito no aumento da produtividade, um absurdo, concorda? Na atual conjuntura de mercado seria impossível imaginar isto, pois a velocidade dos novos negócios não permite e os prazos estão cada vez mais apertados. Mas, a realidade é que, se considerarmos as novas metodologias e as ferramentas disponíveis para agilizar o desenvolvimento, o prazo relativo de entrega final de um sistema continua sendo o mesmo ou até superior ao do passado.

Na verdade o processo de desenvolvimento funciona assim. Primeiro fazemos um plano do projeto com um cronograma que todos sabem que será impossível cumprir. Depois fazemos as entregas nas datas planejadas ou replanejadas, apesar do sistema não estar pronto ainda e funcionando corretamente. Assim o cronograma está em dia, tipo “eu fiz a minha parte”, enviamos para a área de teste ou para o cliente validar (se virar...) e ganhamos mais tempo, a responsabilidade agora é de outro. Quando os erros aparecem é só voltar e corrigir, quantas vezes forem necessárias.

Agora chegou a hora de implantar o sistema, o produto não está bom ou ainda não atende a todos os requisitos, os erros aparecem, fazemos algumas reuniões para achar os culpados, as vezes até alguém é punido, voltamos para o desenvolvimento, os cronogramas são revisados, corrigimos o sistema, geramos novo release, que ainda não está bom, pois como passou muito tempo houve mudança nos requisitos, refazemos os requisitos... O tempo passa, o ciclo recomeça e a vida continua. Fácil, não é?

Também é comum adotar outras ações reativas para recuperação de prazos, tais como: mudar a prioridade do projeto, transferir parte do serviço para outras equipes, renegociar o plano e o cronograma ou adiar parte das implantações para uma próxima versão. Mas nenhuma causa raiz do problema foi eliminada.

Podemos fazer alguma coisa para melhorar este caos?

O fator principal para melhorar as estimativas e criar cronogramas realistas é o mais difícil de fazer. Todos deveriam ser honestos, dizer a verdade e prometer somente o que podem cumprir. É o mais difícil porque o cliente precisa do sistema no prazo, ele é pressionado pelo mercado e acionistas, e a empresa de desenvolvimento precisa trabalhar para sobreviver, ela precisa pagar os funcionários, os impostos e os acionistas. Então todos concordam com tudo, inclusive com os prazos e custos, mesmo sabendo que são irreais.

Outra ação que poderia reduzir os atrasos seria minimizar as mudanças nos requisitos fazendo uma análise mais solida e sistemática, sempre passar por uma inspeção de qualidade e manter um canal constantemente aberto com os clientes até o fim do projeto para esclarecimento de possíveis duvidas e agilizar as correções.

Equipes mal dimensionadas, profissionais despreparados e com pouca experiência com o ambiente e os processos, uso compartilhado de recursos em outros trabalhos de manutenção e a troca de pessoas chaves durante o desenvolvimento são fatores críticos para aumentar os atrasos.

Algumas ações como as relacionadas acima podem até ajudar, mas sinceramente não vejo solução a curto ou médio prazo, será preciso mudar o pensamento e o comportamento das pessoas e a cultura das empresas. E convenhamos, isto não é nada fácil.