Indicativos de que seu projeto de TI pode fracassar


projeto-de-ti-fracasso

Na condição de gerente de projeto eu passei a reconhecer os sinais de alerta de um projeto de TI que está a caminho do fracasso, e aprendi os melhores métodos para colocá-lo volta nos trilhos. Aqui estão três coisas nas quais você deve ficar de olho e o que fazer se você se encontrar enfrentando esses problemas comuns… ou melhor ainda, coisas a evitar desde o início. Se você estiver usando uma metodologia ágil como Scrum em seu projeto, então cada uma destas é endereçada por um ou mais princípios ágeis e dão suporte ao processo de Scrum.

1. O escopo é grande e o prazo de entrega longo.

Há, sem dúvida, uma forte correlação entre o tempo que leva para entregar um produto ou serviço com a satisfação do cliente. A regra simples é que quanto maior o prazo de entrega, maior o risco de que o produto não atenderá às necessidades do cliente. Por quê? Porque uma organização precisa de mudança. É simples assim. Foram-se os dias nos quais você reunia os requisitos e um ou dois anos mais tarde o sistema era entregue. Você provavelmente estará se preparando para o fracasso se lhe pedem para executar um projeto assim.

Solução: Divida o projeto em partes menores que podem ser entregues mais rápido (2 meses ou menos), e entregue os itens de maior prioridade em primeiro lugar. Não se esqueça desta segunda parte muito importante. Não faz bem ao projeto se você se concentrar nos itens mais fáceis de baixo valor agregado e deixar toda a funcionalidade importante para o fim. Se a funcionalidade importante não atende as necessidades do cliente você vai querer saber o mais breve possível.

Princípio Ágil: Entregar software funcionando com frequência, a partir de algumas semanas a alguns meses.

2. Mudanças nos requisitos são vistas pela liderança de TI como se os stakeholders funcionais não soubessem o que eles querem.

“Será que eles não sabem o que querem?”, diz o diretor de TI.

“Será que essas pessoas de TI não se importam com o fato desse produto não ser o que eu quero?”, diz o patrocinador funcional.

Nenhuma dessas perguntas são aquelas que você quer ouvir, mas a realidade é que muitas vezes mudanças de requisitos são vistas como algo negativo ao invés de uma oportunidade. Operamos em um ambiente dinâmico, onde as necessidades do negócio, bem como de tecnologia, mudam rapidamente. Não abraçar a mudança coloca a organização em uma desvantagem significativa.

Será que abraçar a mudança significa que você não precisa de uma visão sólida para o produto e requisitos sólidos? Claro que não! Isso significa, porém, que a equipe de desenvolvimento e liderança sênior em ambos os lados, funcionais e técnicos, devem estar confortáveis com o fato de que a mudança acontece… e ter um plano em prática para incorporar essas mudanças no produto.

Solução: Em primeiro lugar, faça a primeira sugestão acima – entregue consistentemente funcionalidades em iterações curtas, para irá aumentar a probabilidade do produto atender as necessidades do cliente. Em seguida, pratique a elaboração progressiva e mantenha uma lista priorizada de pendências do produto (uma lista priorizada de funcionalidades) e a reveja regularmente. A lista de pendências faz duas coisas: 1) mantém o proprietário do produto (negócio) focado no que é mais importante; e 2) mantém as discussões sobre os requisitos constantes em vez de um exercício mais demorado.

Princípio Ágil: Dê boas-vindas às mudanças de requisitos, mesmo no final do desenvolvimento. Processos ágeis aproveitam a mudança para a vantagem competitiva do cliente.

3. Os usuários finais não estão envolvidos.

É ótimo que você tenha obtido a adesão da liderança da organização e sua opinião sobre o que o produto deve e não deve fazer, mas o que acontece com as pessoas que irão usá-lo? Você está falando com eles? Se não, então em algum momento você vai enfrentar um problema óbvio e provavelmente receber as perguntas “Quem queria esse recurso?” ou “por que é que funciona dessa maneira?”.

Solução: Identifique um proprietário do produto com poder de influência e garanta que esta pessoa se engaje continuamente com os clientes e stakeholders para garantir que a equipe esteja construindo o produto certo. É fundamental que o dono do produto tenha um papel ativo na compreensão das necessidades dos stakeholders e comunique as necessidades e prioridades para a equipe.

Princípio Ágil: Nossa maior prioridade é satisfazer o cliente através da entrega em curto prazo e contínua de um software valioso.

A chave para satisfazer esse princípio é saber quem o seu cliente realmente é!

Autor: Andy Bacon, gerente de projetos de TI experiente em projetos governamentais de recursos humanos.

Artigo publicado originalmente no site PM Hut

Publicidade