E o projeto atrasou novamente

Já passei por algumas consultorias e essa realidade não me assusta mais.(Parece brincadeira, não?) Dos projetos que parecem mais simples  aos mais complexos, o risco do cronograma estourar é enorme. É gerente de projeto se descabelando, cliente ficando insatisfeito e equipe estressada e diretores cobrando resultados. Uma amostra do que são os nervos a flor da pele. Mas, porque os projetos de TI atrasam?

Resolvi ir ao novo “pai dos burros“, como minha mãe chamava o dicionário e foi executar uma busca no Google.  “Why do the IT projects Fail” O primeiro resultado foi de uma consultoria chamada  Coley Consultin (http://www.coleyconsulting.co.uk/failure.htm). Segundo eles, antes de mais nada, um projeto executado com sucesso deve atender os seguintes requisitos:

  • Entregue no prazo (Lógico né)
  • No orçamento estimado
  • O produto entregue deve atender os requisitos do cliente

Concordo com todos os pontos levantados pela consultoria. Meus parabéns. Acrescento e reforço os pontos que trago como bagagem de um projeto que participei ativamente e foi bem sucedido:

  1. Envolvimento do cliente com o desenvolvimento e etapas do projeto.
    É muito bom para saúde do projeto que o cliente já consiga ir vendo o que está sendo desenvolvido para que qualquer inconsistência seja detectada logo no início e o retrabalho seja evitado.
  2. Envolvimento da equipe de desenvolvimento com o projeto
    É essencial que principalmente os programadores estejam envolvidos com o produto que está sendo desenvolvimento. Tentar abrir a mente para o negócio e não focar somente nos códigos. Isso é ótimo pois:
    a) eles conseguem ter a visão completa da solução e não do seu produto
    b) entendem o que por que da complexidade e como isso vai ser útil para o cliente
  3. Envolvimento do cliente com o escopo definido na pre venda e o que mudou de lá pra cá (por que sempre muda, não?)
    Muito difícil o cliente pagar por um levantamento de requisitos antes mesmo de fechar o negócio. É bom rever os produtos fechados na pre venda e ver se ainda estão de acordo com o levantamento de requisitos. Eu cansei de ouvir a frase vinda do cliente :”Mas está na proposta, não?” – Referente a um requisito não levantado que vai levar mais horas estimadas e foi prometido de forma superficial na pré venda.
  4. Mitigar possíveis problemas futuros, como: restrições tecnológicas
    Isso acontece muito em ambientes de bancos. A infraestrutura de um banco é coordenada por diversas equipes e a solução técnica escolhida internamente na consultoria pode possuir componentes não homologados e essa notícia apenas se descoberta no momento do Deploy, pois a equipe de homologação não é a equipe responsável pelo projeto (Ai vem o envolvimento, certo?)
    Sendo assim, desenha sua solução técnica e apresente rapidamente aos responsáveis para ter o OK formal da mesma.
  5. Gerente de projeto e o Analista de Sistema
    Ao meu ver, os olhos do gerente de projeto deveria ser o Analista de Sistema. Ele é o que conhece(pelo menos deveria) saber de todo o sistema e todos os impactos que uma alteração pode causar no mesmo. Ter o analista de sistemas como aliado é a melhor forma de se manter antenado com o que está ocorrendo no projeto e sobre os impactos que uma mudança de escopo pode causar.
  6. Sempre conversar com o KeyUser do projeto, se possível
    Em algumas empresas, a pessoa com quem você está levantando os requisitos não é o usuário final do produto. Isso é um ponto fortíssimo de atenção. Você tem um contato para levantar requisitos mas ele não é o usuário do sistema. Às vezes, um requisito mal levantado não é culpa do analista mas sim da informação que ele recebeu. Sempre deixar decisões registradas por email, pois quando chegar o momento do usuário do sistema usar sua versão piloto, algo pode estar faltando e nesse momento a CHANGE é inevitável. Esteja protegido. Decisões importantes registradas por email.

Claro que somente esses pontos não são necessário para o sucesso do projeto. MAs com certeza irão minimizar bastante as futuras surpresas no decorrer do cronograma e como eu sempre digo pra equipe:

“FOCO NO CLIENTE E FACA NA CAVEIRA”

 

Só uma pequena ilustração. Alguém já viu isso ocorrer?

Sobre matchboxt
Owner MatchBox

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: