Causas de fracassos em projetos de TI e como as metodologias ágeis poderiam ajudar

quinta-feira, 27 de agosto de 2009 às 13:59

Tamanho da fonte:

Entregas atrasadas, prazos estourados, qualidade aquém do desejado… Quem nunca vivenciou uma ou mais situações dessas em projetos de tecnologia?

Que existem problemas, todos sabem.. Mas onde está a causa dos mesmos? Paulo Moraes, diretor do capítulo São Paulo do PMI, apontou alguns destes problemas no site CIO.

Ok, mas onde a agilidade se relaciona com esses problemas? Seria possível fazermos uma relação entre os problemas levantados por Paulo Moraes com as melhorias que conseguiríamos com a utilização de metodologias ágeis? Vamos tentar:

- Falta de uma camada de gerenciamento de projetos: Achei interessante sua opinião “qualquer metodologia serve, desde que esteja presente”. Não é qualquer metodologia que irá resolver os problemas. Mas ter uma metodologia e segui-la já é um bom passo.

- Falha no planejamento do projeto: As pessoas têm preguiças de escrever, fazer diagramas etc., porque muitas vezes não vêem resultados rápidos nos seus trabalhos. Aí entra o conceito de entregas periódicas das metodologias ágeis.

- Processos críticos de negócios mal definidos: “a empresa terá de fazer mudanças no sistema depois de estar pronto”. Para evitar mudanças no sistema depois de pronto, entregue em partes e avalie a adequação do sistema periodicamente.

- Falha em detalhar os processos nas pontas: Conheça o P.O. (Product Owner) e entregue software sempre. Assim, você irá conhecer seus usuários com mais rapidez.
- Falta de envolvimento do pessoal das pontas: Se você entregar um software sempre, esse problema não ocorrerá. Os problemas serão descobertos com antecedência.

- Falha em preparar o sistema para agüentar os picos de utilização: Novamente mais um problema que seria facilmente resolvido com entregas periódicas.

- Evangelizar os patrocinadores do projeto: “Todos os envolvidos no projeto precisam ter consciência do que está no papel e saber que é isso que será realizado, nada menos, nada mais”. Os patrocinadores terão consciência do que será desenvolvido e verá o resultado mais rapidamente em partes.

- Iniciar a implantação antes de definir o escopo: Terminar todo um escopo antes de implantar um sistema é muito bonito (na teoria!). Clientes têm pressa, o mercado é dinâmico, não pode esperar. Para isso, entregue software sempre.

- Estouro do escopo: “Não é possível modificar o projeto a cada novidade de mercado”. É possível, desde que seja combinado e que você esteja preparado para se antecipar às mudanças.

- Falhas de testes: O SCRUM define o envolvimento de toda equipe (inclusive os testadores) durante o Sprint Planning, onde os requisitos são definidos. Além disso, diariamente os testers acompanham a evolução das tarefas, conhecem os impedimentos dos desenvolvedores e tentem a errar menos, porque sabem mais.

- Falta de treinamento: Um plano de treinamento é necessário, mas quase impossível de ser colocado em prática. As metodologias ágeis prevêem a integração de todo o time durante todo o projeto. Com isso, você não tem um treinamento formal propriamente dito, mas consegue disseminar o conhecimento durante o dia-a-dia com muito mais facilidade.

- Falhas ao carregar os dados no sistema: Entregue software periodicamente que esse problema será descoberto antes da implantação.

Com base nos comentários acima, percebemos que um dos grandes, senão o maior, problema do RUP tradicional é você ter as fases muito amarradas: primeiro o escopo, depois o dsv, depois os testes e depois a implantação. Isso gera inúmeras possibilidades de falhas no escopo, de entendimento etc.

Neste aspecto, as metodologias ágeis apresentam uma solução muito simples, mas que resolveria a maioria dos problemas: entregue software de forma iterativa e incremental.

Você concorda com meus comentários? Deixe sua opinião!

Aproveite e continue lendo outros conteúdos relacionados:

Tags:gerenciamento de projetos