Como prometido, vou falar um pouco sobre projetos em si. Na maioria dos projetos que falham, sempre alguém – ou quase todo mundo – sabe que as coisas vão dar errado logo no começo. Os motivos são vários: prazo impossível, equipe sub-dimensionada, despreparo, gerência caótica, restrições técnicas ridículas e absurdas etc. O problema acaba sendo que ninguém fala e depois fica reclamando, no velho esquema sabia-desde-o-começo-que-não-ia-funcionar. Alguns não falam simplesmente porque isso não funcionou das outras vezes e acham que nada vai ser diferente se fizerem alguma coisa. Então, do que adianta falar que as coisas vão dar errado? Depende da sua atitude.
Se você tiver argumentos para justificar a sua expectativa de falha – projetos passados que deram errado são uma ótima referência nessas horas -, use-os. Procure convencer as pessoas que trabalham com você antes de tentar convencer gerentes e/ou outros responsáveis. Muitas vezes você poderá ouvir coisas do tipo: “fizemos tal mudança depois da última vez, logo dessa vez vai funcionar”. O fato é que, se as coisas não deram certo da vez anterior, só vão dar certo depois da primeira vez que não ocorrer um fracasso. Logo, se a última vez tudo deu errado, dessa vez provavelmente o máximo que pode acontecer é que tudo não seja um desastre completo, a menos que alguém que tenha um histórico em entregar projetos bem-sucedidos esteja liderando a equipe ou tenha poder de decisão dentro dela.
Outra coisa que geralmente as pessoas dizem é que você não está a fim de se matar de trabalhar. Bem, se isso for verdade, parabéns; afinal você é um dos poucos profissionais de TI que acha que existe vida fora do micro :-) Agora, falando sério, projetos funcionam como uma maratona: só adianta dar um gás perto do final e, se você sabe que o prazo final não é nem de longe a linha de chegada, você seria apenas um idiota de se gastasse suas energias agora e morresse bem antes da metade do caminho. É mais fácil – e vai causar muito menos danos ao cliente e a todos os envolvidos – se você disser na primeira semana do projeto que a entrega vai atrasar do que avisar uma semana depois do término do prazo… Infelizmente, a maioria das consultorias acredita que a segunda estratégia seja a mais inteligente, mas acredito que você, que vai passar seis meses sem ver sua família e seus amigos, deixando sua vida as traças e se sentindo um zumbi durante todo esse período – e mais algum tempo depois, geralmente -, não compartilhe desse mesmo pensamento.
Uma armadilha comum é começar a se convencer de que as coisas vão dar certo. Por quê? Os outros acreditam, é isso? Por um acaso deu certo da última vez em que os outros acreditavam? Realmente mudou alguma coisa? Existe alguma evidência concreta de que as coisas vão ser diferentes? Não adianta tentar se enganar, pois quem vai pagar o pato é você mesmo. Se você ganha (bem) por hora e prefere o dinheiro a sua vida, pode se dar por feliz, mas se não for o caso, é melhor manter sua posição inicial se você quiser passar pelo menos algumas horas fora do escritório. Caso contrário, você ainda corre o risco de se matar e ouvir de alguém da gerência coisas do tipo: “mas vocês trabalharam tanto pra entregar só isso no final?”, “são muitas horas, não sei se teremos como pagar” ou ainda “se você sabia que ia dar errado, por que mudou de idéia?”, que, com certeza, vai ser muito pior do que continuar lembrando porque as coisas vão dar errado…
Resumindo, dizer que as coisas não vão dar certo no começo, quando se tem base pra isso, não é ser pessimista nem preguiçoso, mas é, na realidade, uma forma de economizar o dinheiro da empresa – que não vai queimar recursos achando que miraculosamente vai entregar em três meses o projeto que vai levar um ano pra ser desenvolvido e que provavelmente vai ter condições de fazer a coisa certa, mudando radicalmente a situação ou tomando medidas reais para lidar com o atraso -, não decepcionar de verdade o cliente, dizendo depois do prazo que ainda falta mais do que o tempo de projeto inicial para entregar o que ele pediu, e poupar a sua própria vida, ou salvar a sua pele, se assim preferir. Como esse é um post um tanto quanto existencial – quem disse que projetos e desenvolvimento de software são ciências exatas estava delirando e muito -, comentários, mesmo que desmintam totalmente o que eu disse, são bem-vindos :-)