Projetos de TI – Prazos políticos vs. prazos práticos

De acordo com o Gartner IT Key Metrics Data 2011 do Gartner Group, os projetos de TI tem um índice de 57% entregues no prazo e 67% dentro do orçamento previsto, índice de desempenho extremamente baixo e assustador em seu volume quando aplicado a quantidade de projetos de TI existentes (só na sua empresa, quantos tem?).

Mas por que isso ocorre?

A relação entre áreas e definição de metas

Relacionado ao post “Ainda precisamos do “Cliente Interno”?”, entendo que geralmente as áreas de uma companhia trabalham desconexas, desalinhadas entre si. Metas são facilmente definidas quando considerado o universo restrito de um departamento, porém a complexidade para alcançá-las aumenta consideravelmente quando visto no âmbito geral, considerando o impacto que uma área tem no trabalho da outra.

Dessa forma as metas empresariais e o orçamento são definidos, normalmente, sem dar a devida atenção aos limites e características de todas as áreas envolvidas, como se houvesse intrínseco o conceito de “Definimos o objetivo, agora faça o que for necessário para alcançá-lo”, fazendo com que muitas vezes a meta nasça com o prazo já comprometido pela ineficiência do planejamento.

Trabalhando com as metas

O planejamento de um projeto muitas vezes ocorre em função do prazo da meta definida anteriormente e não em função do esforço necessário e da capacidade produtiva do time, o conhecido “cronograma de trás pra frente”. Quando percebe-se que com a capacidade produtiva atual não é possível realizar o projeto no prazo exigido, aparece a grande solução: aumente o time, contrate mais recursos ou considere horas extras do time atual… e a previsão de custo do projeto é comprometida.

Por muitas vezes ocorre de realizar um trabalho rápido e dentro do orçamento em detrimento da qualidade do projeto. “Faz do jeito que der, só pra atender, depois reserva um tempo para ajeitar e melhorar”, porém é óbvio que se na concepção do projeto não houve a preocupação com a qualidade, não existirá essa atenção depois que o projeto estiver concluído e seu produto funcionando, mesmo que “capenga”. Dificilmente a melhoria ocorreria de forma pró-ativa.

Quando se trata de um projeto de TI que tem por objetivo a entrega de um sistema em um determinado prazo, não há grande atenção à qualidade por se tratar de um produto que trata de informações, de dados, os quais podem ser corrigidos manualmente após o sistema entrar em funcionamento, em caso de falha. Assim o sistema é entregue no prazo, porém os custos e esforços de manutenção são enormes. Fazendo uma analogia com a engenharia naval, é como se a resistência do casco fosse insuficiente para aguentar a pressão da água e que esse fato passasse despercebido na fase de planejamento sendo o navio lançado ao mar assim, por causa do prazo. A diferença é que no navio não dá para trocar o casco com ele em funcionamento e no mar! Já em sistemas de TI, dá-se um jeitinho! Não é à toa que os projetos de engenharia naval são muito mais assertivos do que os de TI.

A mudança necessária

Partindo do princípio da evolução do pensamento, pré-requisito para qualquer mudança, é preciso entender que:

1. Em um projeto de TI construir um sistema é a parte mais rápida. O que mais leva tempo é a análise do negócio e suas diversas facetas;
2. A qualidade de análise de negócio a ser aplicada no sistema deve receber atenção tanto quanto, ou mais, do que em um projeto de construção de um navio (aproveitando a analogia anterior);
3. Não! O trabalho de análise do negócio não fornece nada concreto além de papéis que têm os fluxos e requisitos desenhados. É subjetivo, é impossível pegar a idéia com as mãos, porém é a fase mais importante do desenvolvimento de um sistema. Mais importante do que simplesmente fazer algo é saber o que se faz! É exatamente nessa fase que isso é definido;
4. Sim! É caro fazer isso, custa dinheiro e a sensação de gastar muito para não ter nada palpável vai existir: pense no futuro! Isso é necessário. Se não fosse, por que contratar um arquiteto ao invés de simplesmente pedir ao pedreiro que saia construindo a casa?
5. É necessário tempo suficiente para analisar e traduzir o modelo de negócio que o sistema atenderá, seja em modelo ágil ou cascata.

As metodologias e melhores práticas existem para nos auxiliar, organizar, mas de nada adiantará se continuar em uso os cronogramas “para inglês ver” ou continuar a ver que o dinheiro gasto com análise, levantamento e qualidade é custo ao invés de investimento.

Esse tipo de trabalho não ocorre com a aplicação de uma metodologia, mas sim com a conscientização pessoal e individual. É uma mudança cultural que tem início no indivíduo.

E os benefícios?