Profissionais TI - Pra quem respira informação

Leia também outros artigos da série: Artigo 0, Artigo 1, Artigo 2, Artigo 3, Artigo 4

Quando falamos sobre gerenciamento de projetos, temos 3 tipos clássicos de perfis:

• Os que defendem os métodos clássicos e convencionais, criticando os métodos ágeis e inovadores
• Os que acham que métodos e práticas ágeis são a solução para tudo e acham métodos clássicos obsoletos
• E os que usam o melhor de todas as práticas pois se preocupam com as metas do projeto, não com o rigor de uma ou outra prática.

Não importa o perfil. Ao ver a essência de cada prática, técnica, metodologia ou boa prática de projeto, em NENHUMA delas existe qualquer menção que, ao usá-la, é garantia de sucesso no projeto. Um projeto que falhou pode sim ter tido uma gestão de sucesso.

Um dos maiores desafios de um Gerente de Projetos é aceitar que o projeto vai falhar e tomar a decisão na hora certa. Voltando aos 3 perfis, quando isso acontece, temos os 3 cenários:

• Modelos Clássicos: Geralmente culpa os “recursos”, administração, terceiros pois acredita que as práticas tradicionais são infalíveis
• Modelos exclusivamente ágeis: Culpa falta de orçamento, capacidade técnica dos ‘recursos’ ou encerra o projeto prematuramente com poucos testes pois acha o método de “falha rápida” infalível.
• Métodos Híbridos: Após ver os cenários de teste de sua equipe, considerar o retorno de investimento e comparativo com outros projetos, percebe que o mesmo não é adequado para aquele momento e o encerra com justificativas claras, sem culpar ninguém da “equipe”.

Nos dois primeiros momentos temos o problema da equipe desmotivada. Tudo começa quando o Gerente de Projetos assume um papel de “chefe” e chama seus membros da equipe de “recursos”. Aquele “Engenheiro com 10 anos de experiência” é chamado apenas de recurso com a capacidade X de entrega de atividades. Se o projeto precisa de X² de capacidade de entrega, a culpa é dos recursos que não são bem treinados ou capacitados.

Em Modelos Híbridos, o Gerente do Projeto acredita em sua equipe. Sabe que a capacidade X de entrega na verdade é a “motivação X”. A equipe motivada, sentindo-se parte do projeto pode entregar 2X, 3X e até mesmo 4X, no tempo adequado, pois acreditam no sucesso do projeto. Se todos os indicadores mostram que o projeto vá falhar, não adianta contratar uma equipe que possui supostamente X², X³ de capacidade. Estará apenas gastando dinheiro e tempo de todos.

Problemas em Projetos Clássicos de ERP

O mercado recebeu recentemente uma avalanche de profissionais formados recentemente em gerenciamento de projetos. Muitos deles foram inundados com a informação errada que podem gerenciar qualquer tipo de projetos, desde softwares até mesmo usinas nucleares utilizando as mesmas práticas clássicas de projetos. Acham que não precisam conhecer o produto para ter sucesso.

Ao implantar um ERP temos questões contábeis, emissão de notas fiscais, tipos de empresa (lucro real, presumido, simples nacional, etc) e dependendo da necessidade do cliente o projeto pode ser completamente diferente entre eles, mesmo o ERP sendo um produto, teoricamente, padrão em sua maior parte.

Ao não conhecer o produto, o GP acaba caindo na conversa daqueles que, outrora, ele chamou apenas de “recursos”, não como equipe, e nada sai como o esperado. Por serem meros recursos, um programador pode buscar a solução mais simples. O vendedor pode querer a melhor margem, já o técnico pode querer o menor trabalho. Como são apenas recursos e não equipe, não estão preocupados com o sucesso do projeto e sim com o próprio sucesso: O melhor vendedor, o melhor técnico, o melhor programador.

Neste ponto, o Gerente de Projetos clássicos de ERP percebe que seu objetivo nunca foi gerenciar o projeto e sim apenas acompanhá-lo, buscando o maior faturamento e manter o cliente calmo perante os erros de seus recursos.

Contratos e Mais Contratos

Nesse mar de confusões, o gerente de projetos de ERP, ao ver seu projeto indo por água abaixo, não vê outra alternativa senão buscar aquele contrato na gaveta e ver as entrelinhas de modo a tentar justificar e proteger seus recursos (e a si mesmo).

Em projetos clássicos de ERP a busca é sempre pelo maior faturamento. Quanto mais horas cobrarem do cliente melhor. Sucesso? Se o cliente ficar feliz é apenas um luxo, mas se conseguirem tirar mais e mais dinheiro, isso sim é um sucesso. Durante um projeto ERP temos geralmente dois tipos de cobrança: As horas que fazem parte do pacote e as famosas horas avulsas. Aquela solicitação do cliente que precisa de uma função a mais, um relatório, uma personalização, não faz parte das horas do pacote e são cobradas a parte. Nesse quesito a turma do ERP “pinta e borda”: Nada está incluso e tudo é por fora. O negócio é arrancar mais e mais horas, esquecendo do valor e satisfação do cliente para com o ERP.

Este gerente clássico, que confia nos métodos convencionais para o sucesso sabe que precisa formalizar toda e qualquer solicitação do cliente pois ele acredita que dessa forma, se o projeto falhar, poderá culpar apenas o cliente pois gerentes convencionais encerram seus projetos culpando alguém.

A equipe de desenvolvimento clássica se apega aos documentos de requisitos e especificações de mudança. Se não está escrito, não está incluso. O cliente pode até dizer que tinha entendido fazer parte mas perderá essa briga pois assinou aquele documento. Perdem-se dias, semanas na discussão e, no fim, o cliente paga pelo tempo perdido e pelas novas horas para incluir aquela função (e, novamente, gera-se um novo documento) e o ciclo não termina bem.

Mas cadê o vendedor?

O gerente clássico, que não está preocupado com o valor do projeto para o cliente se vê naquela situação: A equipe de desenvolvimento não quer desenvolver a função a menos que o cliente pague. O cliente não quer pagar porque o vendedor disse que o recurso existia. Nesta hora o cliente geralmente diz: “Chama lá o Sr. Fulano, ele disse que estava incluso tal coisa no pacote!”. Neste ponto está ao Gerente Clássico de Projetos dizer “Ah, o vendedor não está na nossa equipe/saiu da empresa/mudou-se”.

Nesta hora o cliente percebe que já gastou muito dinheiro com o projeto e não quer perder este dinheiro. Com isso ele se vê obrigado a pagar as horas adicionais para ter aquilo que era seu direito: o valor do projeto. Nisso ele paga as horas para ter aquele recurso, a equipe desenvolve, a empresa do ERP fica feliz pois acha que ganhou mas o cliente nunca mais comprará nada. E, se comprar, será a contra-gosto.

Sucesso? Só na cabeça de quem ganhou dinheiro nessa.

Mas o que fazer então?

O próprio PMI sugere em suas práticas que um projeto deve ser planejado em ondas sucessivas. Em métodos ágeis um dos pontos principais é buscar entregar o valor do cliente fugindo da rigidez do contrato. Ninguém está dizendo que um cliente que comprou um módulo de Compras terá um módulo Contábil apenas porque quer. Estamos dizendo que por planejar o projeto ao longo do mesmo estaremos sempre alinhados com a expectativa do cliente. Regras de negócio podem mudar. Hoje ele pode não precisar de um módulo contábil mas a classificação da empresa pode mudar na virada do ano e a negociação deve ocorrer de maneira saudável. Temos que prever esta mudança (conforme os métodos clássicos indicam) mas entregar primeiro o que o cliente precisa.

O próprio modelo de contrato deve ser diferente. Pode ser feito com base em entregas, em número de funcionalidades, em releases independente do conteúdo dele, enfim. Buscar um modelo que foque em entregar resultados, tanto ao cliente como ao fornecedor do ERP.

O próprio cenário da empresa precisa mudar. Muitas vezes um Gerente de Projetos se vê obrigado a seguir métodos rígidos e burocráticos, pois a empresa não aceita as mudanças. Não permite nem fornece liberdade ao gerente para inovar, pois acredita que o que funciona há anos continuará funcionando.

Os tempos mudaram, temos que mudar com eles.

Espero que tenham gostado do artigo. Resolvi abordar o tema, pois ainda existem dúvidas sobre as aplicações de métodos ágeis e híbridos em projetos considerados fechados como ERP, sistemas de caixinha ou hardware. Precisamos entender e aprender a usar o melhor de cada prática, no momento certo do projeto para entregar o valor que o cliente precisa.

No próximo artigo pretendo falar sobre como elaborar um cronograma híbrido, seguindo métodos convencionais e ágeis, separando o projeto em fases, marcos e entregas. Passarei o que acredito ser importante constar em um cronograma e como gerenciá-lo adequadamente. Até lá!

Leia também outros artigos da série: Artigo 0, Artigo 1, Artigo 2, Artigo 3, Artigo 4

Publicado Originalmente em http://www.vignado.com.br/?p=456