VOCÊ SABE COMO FUNCIONAM OS CRONOGRAMAS DOS PROJETOS DEDESENVOLVIMENTO DE SOFTWARE?Você se lembra de quando foi a última v...
Testes limitados (quando existe algum teste). Assim encontramos os erros muito tarde        e por vezes é preciso reinicia...
Outra ação que poderia reduzir os atrasos seria minimizar as mudanças nos requisitos fazendouma análise mais solida e sist...
Próximos SlideShares
Carregando em…5
×

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

356 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
356
No SlideShare
0
A partir de incorporações
0
Número de incorporações
7
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

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

  1. 1. VOCÊ SABE COMO FUNCIONAM OS CRONOGRAMAS DOS PROJETOS DEDESENVOLVIMENTO DE SOFTWARE?Você se lembra de quando foi a última vez que o cronograma de um projeto dedesenvolvimento de software foi cumprido? Eu não me lembro.Nestes anos de vivência nas áreas de desenvolvimento e de teste, trabalhei em diversascompanhias e com as principais empresas de desenvolvimento de software do país, e possoafirmar sem medo de errar, que o cumprimento dos prazos não é levado a sério. Ninguémrealmente acredita nas datas planejadas.Uma pesquisa recente nos EUA revelou que no mundo, mais de 75% dos projetos dedesenvolvimento de software são entregues com atraso. Acredito que no Brasil este númeroseja maior. Outra constatação é que tamanho não faz diferença, os atrasos estãouniformemente distribuídos entre projetos pequenos, médios e grandes. Esta notícia deveriaser preocupante, principalmente para uma indústria em que os prazos são tão importantes eos 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 odesenvolvimento de software é tão afetado por atrasos e se algo pode ser feito para melhorareste quadro?Em primeiro lugar, quais os problemas mais comuns que levam ao atraso aos projetos dedesenvolvimento 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. 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 concordaramcom as mentiras, desde o momento que aceitaram os prazos e aprovaram o plano do projeto eo cronograma. E o pior é que eles sabem disto.Como funciona o processoTempos atrás levávamos anos para desenvolver e implantar um sistema, as metodologias eramburocráticas e lentas, a tecnologia não ajudava muito no aumento da produtividade, umabsurdo, concorda? Na atual conjuntura de mercado seria impossível imaginar isto, pois avelocidade dos novos negócios não permite e os prazos estão cada vez mais apertados. Mas, arealidade é que, se considerarmos as novas metodologias e as ferramentas disponíveis paraagilizar o desenvolvimento, o prazo relativo de entrega final de um sistema continua sendo omesmo ou até superior ao do passado.Na verdade o processo de desenvolvimento funciona assim. Primeiro fazemos um plano doprojeto com um cronograma que todos sabem que será impossível cumprir. Depois fazemos asentregas nas datas planejadas ou replanejadas, apesar do sistema não estar pronto ainda efuncionando 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, aresponsabilidade agora é de outro. Quando os erros aparecem é só voltar e corrigir, quantasvezes forem necessárias.Agora chegou a hora de implantar o sistema, o produto não está bom ou ainda não atende atodos os requisitos, os erros aparecem, fazemos algumas reuniões para achar os culpados, asvezes 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 muitotempo houve mudança nos requisitos, refazemos os requisitos... O tempo passa, o ciclorecomeça e a vida continua. Fácil, não é?Também é comum adotar outras ações reativas para recuperação de prazos, tais como: mudara prioridade do projeto, transferir parte do serviço para outras equipes, renegociar o plano e ocronograma ou adiar parte das implantações para uma próxima versão. Mas nenhuma causaraiz 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 defazer. Todos deveriam ser honestos, dizer a verdade e prometer somente o que podemcumprir. É o mais difícil porque o cliente precisa do sistema no prazo, ele é pressionado pelomercado e acionistas, e a empresa de desenvolvimento precisa trabalhar para sobreviver, elaprecisa 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. 3. Outra ação que poderia reduzir os atrasos seria minimizar as mudanças nos requisitos fazendouma análise mais solida e sistemática, sempre passar por uma inspeção de qualidade e manterum canal constantemente aberto com os clientes até o fim do projeto para esclarecimento depossíveis duvidas e agilizar as correções.Equipes mal dimensionadas, profissionais despreparados e com pouca experiência com oambiente e os processos, uso compartilhado de recursos em outros trabalhos de manutençãoe a troca de pessoas chaves durante o desenvolvimento são fatores críticos para aumentar osatrasos.Algumas ações como as relacionadas acima podem até ajudar, mas sinceramente não vejosolução a curto ou médio prazo, será preciso mudar o pensamento e o comportamento daspessoas e a cultura das empresas. E convenhamos, isto não é nada fácil.

×