Acho útil revisitar o artigo de Steve McConnell de Steve McConnell sobre os erros clássicos do processo de desenvolvimentoe o estudo de caso complementar, pelo menos uma vez por ano. Se o senhor já ouviu isso antes, me interrompa:
“Veja, Mike”, disse Tomas. “Posso entregar meu código hoje e chamá-lo de ‘recurso completo’, mas provavelmente terei três semanas de trabalho de limpeza para fazer depois de entregá-lo.” Mike perguntou o que Tomas queria dizer com “limpeza”. “Ainda não consegui que o logotipo da empresa apareça em todas as páginas e não consegui que o nome e o número de telefone do agente fossem impressos na parte inferior de cada página. São pequenas coisas como essas. Todas as coisas importantes funcionam bem. Estou 99% pronto”.
Como diz aquele velho provérbio sobre software, os primeiros noventa por cento da tarefa levam noventa por cento do tempo, e os últimos dez por cento levam os outros noventa por cento.
O Estudo de caso da Classic Mistakes é enervante de ler; é como aquelas encenações que o senhor vê no America’s Most Wanted (Os mais procurados da América). É um resumo exagerado, mas estranhamente preciso, de todos os projetos de software patológicos dos quais já participei, ou seja, quase todos.
Esse é o fenômeno que McConnell compara a Gilligan’s Island (Ilha de Gilligan). Toda semana há um esquema novo e maluco para escapar da ilha, mas, no final do episódio, os náufragos sempre acabam presos na ilha por mais uma semana.
Se o senhor não perceber imediatamente os paralelos com o desenvolvimento de software, permita-me reapresentá-lo a a longa e triste história do fracasso dos projetos de software. Os erros clássicos são clássicos porque são muito sedutores. É preciso reconhecer ativamente quando o senhor está caindo em uma dessas armadilhas. Como Steve disse certa vez em uma entrevista:
Na verdade, ter sucesso em um projeto de software depende muito menos de não fazer algumas coisas erradas, mas de fazer quase tudo certo.
É por isso que o senhor deve ter cada um dos os 36 erros clássicos descritos no livro de McConnell Desenvolvimento rápido que o senhor já tem na memória:
| Erros das pessoas | Erros de processo |
|
Motivação prejudicada |
Cronogramas excessivamente otimistas |
| Erros de produto | Erros de tecnologia |
|
Requisitos de revestimento de ouro |
Síndrome da bala de prata |
Cada vez mais acredito que a única diferença entre desenvolvedores de software experientes e inexperientes é que os experientes percebem quando estão cometendo erros. A mesma regra se aplica a projetos de software e gerentes de projeto. Se o senhor não estiver examinando ativamente a lista de Erros Clássicos de Desenvolvimento de Software enquanto executa seu projeto de software, não tem ideia da probabilidade de estar cometendo um desses erros agora mesmo.
Cometer erros é inevitável, mas repetir os mesmos erros várias vezes não precisa ser assim. O senhor deve se esforçar para cometer erros totalmente novos, espetaculares e nunca vistos antes. Para isso, Steve McConnell destacou alguns novos erros clássicos em seu blog que ele está prestes a acrescentar ao cânone, 10 anos depois:
- Confundindo estimativas com metas
- Excesso de multitarefas
- Supondo que o desenvolvimento global tenha um impacto insignificante no esforço total
- Visão pouco clara do projeto
- Confiar mais no mapa do que no terreno
- Terceirização para reduzir custos
- Deixar uma equipe ficar no escuro (substitui a anterior “falta de controles gerenciais”)
Steve também está buscando nosso feedback. Ele publicou um Pesquisa sobre erros clássicos e convidou todos a participar. Se o senhor tiver algum tipo de experiência em projetos de software, por favor, participe.
É verdade, as chances estão contra o senhor. Mas é uma boa ideia lembrar periodicamente ao senhor que talvez, apenas talvez… se o senhor puder evitar cometer os mesmos erros clássicos de tantos outros projetos de software anteriores – o senhor poderá realmente conseguir escapar da ilha um dia desses.