IT Forum 365
5 sinais de que o projeto de software vai dar errado – e o que fazer

5 sinais de que o projeto de software vai dar errado – e o que fazer

Por Paul Ho, chefe de engenharia de software da HPE Cingapura
 
Desde a primeira linha de código de software escrita por Ada Lovelace até hoje, ainda não descobrimos como impedir que projetos de software deem errado. Porém, antes deles falharem, costumam dar sinais. Este artigo identifica cinco desses alertas e apresenta como responder em tempo hábil.

Leia o whitepaper “Como foi a migração do datacenter da NET” e entenda o processo de implementação do modelo de gestão compartilhada na infraestrutura da empresa.

Sinal 1: Altos executivos têm mentalidade e atitudes erradas
Este é um dos erros mais comuns no mundo do desenvolvimento de software: é quando o executivo usa sua posição para forçar a data de conclusão do projeto ao, por exemplo, anunciar publicamente o dia de lançamento de um sistema, surpreendendo a equipe de desenvolvimento.
 
Essa atitude se baseia na crença de que colocar mais pessoas para trabalhar em um projeto aumenta sua velocidade – é como se o desenvolvimento de software fosse o mesmo que construir carros, onde uma segunda fábrica pode dobrar a produção. Gestores alheios a projetos reais de desenvolvimento podem não perceber que a diferença de qualificação e produtividade entre as equipes influencia na qualidade e no tempo necessários para entregar o programa. O final das iniciativas com cronograma irreal é o mesmo: elas se perdem e a qualidade cai.
 
Sugestão: Pratique gestão andando pelo escritório e dialogando com os colaboradores. Isso cria a oportunidade para que a gerência sênior comunique diretamente suas visões e entenda como as metas impactam os funcionários. Um estudo publicado pela Universidade de Ottawa indica que 33% dos projetos falham devido à falta de envolvimento da gerência sênior.
 
Sinal 2: Alocar pessoas a atividades paralelas para atender uma data de entrega impossível
Uma decisão drástica para atender a uma entrega impossível é adicionar pessoas e deixar muitas atividades em paralelo. Mas, se a equipe expande, o esforço para controlar a qualidade e a comunicação também aumenta, o que pode atingir um nível incontrolável.
 
No meio da correria, os novatos não têm tempo suficiente para se adaptar às normas, convenções e práticas, aumentando a chance de o trabalho ter má qualidade e atrasar. Também, o aumento do número de pessoas no projeto aumenta a carga financeira, queimando o orçamento da iniciativa mais rapidamente.
 
Sugestão: Evite pensar só em números, focando em obter as pessoas qualificadas para a entrega. Você também pode pedir uma avaliação externa sobre a viabilidade do cronograma.
 
Sinal 3: O cliente quer mais no mesmo tempo
É positivo ter usuários ou clientes com muitas ideias, no entanto, isso pode levar ao aumento do escopo do projeto. “Esta é uma boa ideia!”, geralmente, não é uma boa ideia.
 
Os clientes e usuários precisam entender que empurrar funcionalidades tende a “sair pela culatra”, resultando em má qualidade, retrabalhos e acúmulo de atrasos. E, como a maioria dos gerentes de projeto sabe, muitas features são usadas por poucos usuários, quando acessadas.
 
Sugestão: Priorize. Estabeleça um sistema de importância simples que considere o valor do negócio, custo e risco, eliminando as funcionalidades não essenciais e simplificando as que forem desnecessariamente complicadas. Os usuários vão resistir, então lembre-se de ouvir todas as sugestões e ideias a tempo de revisitá-las.
 
Sinal 4: A “bala de prata” que vai salvar um projeto grande demais
Novos métodos ou abordagens de desenvolvimento de software são muitas vezes vistos como balas de prata, mas requerem uma grande mudança de cultura da empresa e/ou mentalidade de gestão. Quem acredita que a alteração está restrita à equipe técnica vai se frustrar.
 
Sugestão: Os benefícios de um novo processo só podem ser atingidos com uma mudança de hábito e de mentalidade, portanto não imite mecanicamente um método sem o compromisso dessas transformações estruturais.
 
Sinal 5: Deixar o teste para o final do ciclo de vida do projeto
Uma desculpa comum para esse equívoco é que o sistema está incompleto ou cheio de bugs. Essa prática coloca a equipe de teste sob uma tremenda pressão, enquanto os desenvolvedores se apressam para preparar correções de última hora.
 
Não é preciso  ter um sistema finalizado antes de elaborar scripts de revisão. Também é possível simular subsistemas por meio de algumas ferramentas. Ao implementar essas ações em fases iniciais, defeitos de especificações também podem ser detectados mais cedo.
 
Sugestão: Ferramentas de virtualização são alternativas para simular sistemas e permitir testes de forma controlada e eficiente.

Leia o texto original: http://community.hpe.com/t5/Enterprise-Services/5-Signs-of-a-Failing-Software-Project-and-how-to-fix-it/ba-p/6806479

Comentários

Notícias Relacionadas

IT Mídia S.A.

Copyright 2016 IT Mídia S.A. Todos os direitos reservados.