VOCÊ SABE COMO FUNCIONAM OS CRONOGRAMAS DOS PROJETOS DE DESENVOLVIMENTO DE SOFTWARE?
1. VOCÊ SABE COMO FUNCIONAM OS CRONOGRAMAS DOS PROJETOS DE
DESENVOLVIMENTO DE SOFTWARE?
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;
2. 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.
3. 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.