Planejamento

Esse é para quem trabalha ou interfere de alguma forma com desenvolvimento de sistemas.

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 para 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 Fracked Up Projects