Meio Bit » Arquivo » Miscelâneas » Você planeja seus projetos, por menor que sejam? Um caso que deu MUITO errado.

Você planeja seus projetos, por menor que sejam? Um caso que deu MUITO errado.

16 anos atrás

Era uma vez uma empresa especializada em soluções financeiras e contábeis que vende para um de seus principais clientes um módulo extra de uma ferramenta online. O gerente de conta que efetuou a venda não era da área de tecnologia e ao ver o que precisava ser feito, estimou na hora um prazo para o cliente que ficou satisfeitíssimo. Apesar de ter profissionais de TI e prestadores no seu quadro, o gerente acertou tudo sem consultá-los.

O projeto consistia em converter 10 planilhas de Excel, com dezenas de cálculos financeiros para um aplicativo web: pesquisa em vários níveis de detalhe, sistema seguro baseado em perfil, relatórios específicos com exportação para Excel, gerar relatórios em PDF, sistema de cadastro de informações e comparação de riscos e um sistema de filtros que criaria tudo dinamicamente de acordo com as opções do cliente (em torno 40). Deveria também gerar gráficos que as planilhas de Excel não possuíam, facilitando a leitura das informações.

O tempo estimado pelo gerente para execução?

Quatro semanas para um programador fazer tudo e entregar, sem bugs e com testes.

A equipe de TI da empresa, atolada de tarefas, diz que não existe pessoal para fazer nesse prazo, pois precisaria de gente mais experiente. Então, resolvem terceirizar.

A empresa contratada também tem um gerente de conta que apresenta o projeto como dinheiro fácil, "rapidin", uma conversão de planilhas e fim de papo. Entrega para um analista alguns jpegs e pede para estimar um prazo, na hora. A reação natural é: bombardear de perguntas. A resposta automática: "não é para se preocupar com isso agora". Essa frase é o equivalente tecnológico de "é só a cabecinha".

Prazo estimado? Duas semanas para o sistema entregue e testado.

O sistema começa a ser desenvolvido, com dois programadores. Pedem as especificações, casos de uso, protótipos de tela: "não precisa de nada disso porque é um sistema baratinho, rápido de se fazer pra conquistar o cliente". As tarefas chegam no seguinte formato: 1 arquivo xls com 10 planilhas, 1 arquivo xls com uma pequena massa de dados e um arquivo pdf de como o sistema deveria ficar, mais ou menos. Vendo o passaralho rodeando suas cabeças, os programadores alertam: "Esse projeto vai demorar umas 1500 horas com 2 recursos e mais um para testes". Resposta da gerência: "Não pode, tem que terminar em 2 semanas, senão vamos levar prejuízo".

Oito meses de atraso depois, o cliente tenta homologar mais uma vez o projeto e a empresa terceirizada descobre que toda a parte de cadastro do sistema é inviável. Não foi feita especificação, nem casos de uso nem protótipos de tela e muito menos um planejamento por causa de custos. O cliente não foi consultado e o que foi entregue não tem como ser usado. O projeto está na sua quarta equipe de programação e serão precisos, no mínimo, mais 2 meses de trabalho para ter uma versão básica de acordo com as necessidades do cliente.

Isso é algo EXTREMAMENTE comum na área de TI. Um gerente sem noção promete algo para um cliente. Um outro gerente sem noção promete esse algo a um custo excelente, um negócio bom para as duas partes. E 3 empresas tomam no behind porque dois completos idiotas que se metem na área de tecnologia da informação por saber operar e-mail e editar planilhas prometeram coisas impossíveis em prazos tão factíveis quanto o coelho da Páscoa.

Moral do Post

  • Por menor que seja, qualquer sistema precisa de um Plano de Projeto;
  • Dependendo das condições, uma solução é inviável dentro do prazo e custo estabelecidos;
  • Não adianta colocar mais gente trabalhando em um projeto problemático: 9 mulheres não conseguem gerar um bebê em 1 mês;
  • Trocar a turbina com o avião em vôo pode ser necessário, em outras palavras: jogar fora grandes porções de código e refazer tudo;
  • Prototipação de telas é essencial para que o cliente, ao ver a tela, lembre-se de detalhes que passaram despercebidos na especificação inicial. A vantagem de prototipar é não criar nenhum código de tela dinâmico antes de ter o design fechado;
  • Não estou dizendo para se aplicar RUP, Iconix, eXtreme Programming ou nenhuma metodologia, mas um Plano de Projetos, antes mesmo de programar a primeira linha;
  • É preferível investir alguns dias planejando o projeto do que cair direto no código, mesmo que isso acarrete ouvir algo como "Atraso de 3 dias?! Absurdo não termos nada e já estamos na quarta-feira!"

Se você nunca viu ou fez um plano de projetos, procure no Google por modelos onde se respondem algumas perguntas básicas. Ao preenchê-las, você terá uma noção maior do tamanho da... do projeto. Um bom exemplo: Project Planing Step by Step.

Fonte: Bicalho's Memory About Fraked Up Projects

relacionados


Comentários