O gerente e time do projeto precisam ser
capazes saber dizer sim e não para as solicitações de mudança do escopo. Em
vários casos é preciso negar à mudança do escopo e colocar ela na fila da
próxima versão ou atualização. É preciso entender que mudanças contantes no
escopo mantam um projeto. A soma de diversas solicitações gera o problema do estouro.
O conjunto de inocentes pequenas mudanças sem novos recursos e aprovações
ampliam sobremaneira os requisitos do projeto e impactam o prazo, custo e
qualidade. Mudanças contantes levam o prazo de entrega para muito longe do
requisito inicial e aumentem fortemente os custos. Muitas vezes a qualidade do
software é negligênciada pela falta de tempo para os testes.
Universo das mudanças
O primo problemático das mudanças contantes do
escopo é a sua amplitude. Existem muitos projetos que são grandes demais e tem
escopo com amplitude de cobertura demasiada. Em geral é melhor nestes casos
escolher projetos de menor porte que avançam em passos menores até que o
portfólio dos projetos entregue o escopo amplo desejado. É importante que o
escopo trabalhado seja bem definido e fácilmente gerenciavel. Desta força é
possível definir com clareza as tarefas necessárias para as entregas e
estabelecer pontos para a passagem de bastão para o próximo projeto entregar o incremento
do escopo total desejado. Em diversos casos os projetos massivos de dados como
o big data fracassam pela complexidade ou pela dificuldade do usuário final de
absorver tamanho volume de conhecimento. Em vários casos, as pessoas que cuidam
do dia a dia da iniciativa não tem condições de aprender simultaneamente o
software e as mudanças do negócio.
Comunicação pobre
Existem boas razões para não convidar todos os
membros para todas as reuniões do projeto. No entanto, não existe justificativa
para não comunicar com clareza as decisões tomadas. A maioria dos projetos de
software fracassado passa por decisões discutidas e tomadas sem o conhecimento
de todos os membros do projeto. O desconhecimento das decisões tem com como
resultado um produto que não endereça os requisitos. Não tem sentido algum em
manter requisitos secretos.
Foco na forma
Muitos projetos fracassam dramaticamente porque
a funcionalidade real da aplicação é tratada com menos ênfase que o formato do
painel de instrumentos. É muito fácil errar no endereçamento dos requisitos
quando o formato do painel de instrumentos é desenvolvido antes da finalização
de todas as funcionalidades requeridas pelo projeto. É evidente que se o alvo
do projeto for desenvolver o formato de um painel de instrumentos, este
objetivo deve ser entendido como a funcionalidade requerida.
Capital intelectual jogado no lixo
As falhas da gestão em escutar o capital
intelectual colaborativo já levaram milhares de projetos de software para o
fracasso. Muitos gerentes preferem fuzilar os mensageiros que querem ajudar na
solução dos problemas enfrentados pelos desenvolvedores do que resolver o
cenário descrito no conteúdo da mensagem. São pessoas que entendem que
desconhecer o problema é o melhor caminho. Todos os gestores que pensam sabem
que quanto mais cedo um problema for enfrentado, a sua solução será mais fácil
e barata. A escolha de caminho não funcional para o gerenciamento limita o
projeto do desenvolvimento do software. A demora excessiva para corrigir os
erros encarece fortemente o custo total.
Alocação falha de recursos
Muitas vezes nos projetos fracassados, as
pessoas contratadas para uma determinada atividade são desviadas para trabalhar
em iniciativas completamente desvinculadas da proposta. Não é preciso ser um
gênio em gestão de projetos que este desvio desnecessário gera atraso e aumento
do custo.
Promessas exageradas
Prazos irrealistas e promessas otimistas ao
excesso dos vendedores são duas das principais causas dos fracassos nos
projetos de software. Muitos profissionais falam “sim” para todos os pedidos
dos usuários sem pensar nas conseqüências de médio e longo prazo. Este é o
caminho mais rápido para a insatisfação, frustração e decepção. Projetos
conduzidos irresponsavelmente rapidamente naufragam. Em geral. Nestes casos, o time
de desenvolvedores passa a gastar todo o seu precioso tempo justificando os prazos
pouco realistas.
Tecnologia errada
Muitos desenvolvedores ávidos por novidades
escolhem tecnologias inadequadas para os projetos de software. Bons programadores
conseguem equilibrar as ações e resultados com as novidades. A nova tecnologia
oferece vantagem relevante para o projeto? Esta sendo adotada uma tecnologia
que já apresentou problemas em outros países? Não é fácil escolher o estado da
arte correto da tecnologia de um projeto de software. Este é o principal motivo
pelo qual é preciso selecionar um time experiente formado nas boas escolas de
engenharia para levar o projeto para o sucesso. Muitos desenvolvedores
inexperientes ou despreparados escolhem para os seus projetos de software
tecnologias em estado beta lançada no mês passado para não ter custo de
licenças. Em todos os casos este estratagema é o caminho mais rápido para o
fracasso.
Fazer ou comprar
Muitos desenvolvedores preferem projetar e
desenvolver as suas próprias ferramentas de gestão e bibliotecas de rotinas
padrões. Uma das principais desvantagens de reinventar a roda em relação aos frameworks
e biblioteca padrões é a perda da inteligencia coletiva do mercado. Ferramentas
de gestão e bibliotecas de rotinas padrões de mercado são otimizadas no
desempenho e qualidade. É possível economizar muito tempo e dinheiro em
desenvolvimento e testes com a utilização de soluções prontas de mercado. O
desenvolvedor que não reinventa a roda e foca o seu tempo na essência do
software gera um resultado melhor e mais barato. Os engenheiros experientes
formados nas boas escolas de engenharia são excelentes desenvolvedores porque eles
têm a mente de empreendedores na execução das tarefas dos projetos. Eles não
perdem tempo. Eles usam sempre que possível rotinas otimizadas de alta
qualidade.
Protótipo errado
É algo óbvio, mas infelizmente é um erro comum.
O time de desenvolvimento que esta trabalhando no protótipo de uma aplicação
precisa escrever funcionalidades iguais ao sistema do projeto real. A línguagem
e tecnologia do protótipo podem ser diferentes do sistema que está sendo
projetado, no entanto, as funcionalidades precisam ser iguais para que o
trabalho não seja jogado fora. O protótipo é sempre uma imagem virtual do
produto real que está sendo desenvolvido. Não tem sentido algum usar uma
estrutura de banco de dados diferente no protótipo. Isto é apenas tempo e
dinheiro jogado no lixo. Para fácilitar o protótipo é válido usar um banco de
dados diferente do produto desde que seja possível fazer a sua migração de
forma fácil e transparente. É um estratagema que reduz ao mínimo o trabalho no
protótipo é permite maior velocidade na sua entrega para os usuários. As pessoas
vão poder com isto realimentar o projeto com as suas impressões e com isto fazer
ajustes e correções no escopo, nas funcionalidades e nas facilidades dentro do
cronograma e orçamento previsto.
Nenhum comentário:
Postar um comentário