Artigo - Projetos

Meio Bit Tecnologia » Artigo
Você planeja seus projetos, por menor que sejam? Um caso que deu MUITO errado.
Por Ricardo Bicalho em 27 Março 2008 - 19:43
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 on-line. 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 JPEG’S 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 ponta do iceberg".
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 temos 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 do projeto. Um bom exemplo: Project Planing Step by Step.
Fonte: Bicalho's Memory About Fracked Up Projects
Enviado por:
Saimon Gava, aluno do nosso curso de Sistemas de Informação – UNIP – Tatuapé - SP
[email protected]
Troquei algumas palavras em relação ao texto original, por considerá-las, chulas. Porém
a idéia não foi descaracterizada.
O texto descreve um caso rotineiro na nossa área, do qual também presenciei vários.
Durante o curso vocês apreenderão várias metodologias de gestão de projetos que os
capacitarão para obterem sucesso nestes casos.
Prof. Marcelo Nogueira
28/03/2008.