No último domingo, 06 de julho, aconteceu o Grande Prêmio de Silverstone, na Inglaterra. Achei dois aspectos interessantes na corrida relacionados a projetos de software que gostaria de comentar aqui.

Pra quem não teve oportunidade de acompanhar, vou contar resumidamente os fatos interessantes. O clima estava bastante instável no final de semana. Chovia e parava seguidamente, e ninguém sabia qual o melhor jogo de pneus usar a cada pit-stop durante a corrida: o de chuva pra pista bastante molhada, o intermediário pra pista molhada (ou secando) ou o liso pra pista seca. Na primeira parada das Ferraris, não estava chovendo, a pista já estava secando e existia uma previsão de chuva que poderia se confirmar ou não. Os carros estavam desde o começo com pneus intermediários, que desgastados ficam próximos dos lisos, servindo bem em pistas secas. Numa corrida anterior, em Mônaco, a Ferrari se viu na mesma situação e confiou na previsão de chuva. Trocou os pneus para de chuva, não choveu, e acabaram perdendo a corrida. Provavelmente influenciados por essa decisão errada, tentaram se redimir e arriscaram apostar contra a previsão do tempo agora – mantiveram os pneus intermediários gastos acreditando que a pista ia secar. Só que choveu… E muito!

Os carros deram algumas voltas com um rendimento bem ruim, perderam bastante tempo, o Felipe Massa rodou 5 vezes na corrida e depois de algum tempo a Ferrari chamou os pilotos de volta pra mais um pit-stop não planejado pra trocar os pneus pra de chuva. Os locutores ficaram se perguntando: “Por que não chamou antes, já que iam fazer uma parada a mais de qualquer jeito? Perderam mais tempo ainda!”. Resultado: Quem não arriscou e apostou na previsão se deu bem e o Massa apesar de ter feito o maior número de voltas (inclusive em torno do próprio eixo), terminou em último. Quem quiser ler mais, pode ver aqui, aqui e aqui também.

A primeira lição tirada desse episódio é sobre tomada de decisão. Quem joga poker sabe que cada mão é um jogo novo. Você tem que manter a mente limpa e se concentrar em uma jogada de cada vez, “se esquecendo” do que se passou nas outras mãos. A Ferrari pecou justo nesse ponto. Olhou pra trás ao invés de olhar pra cima. Ficou comprometida com a recuperação do erro do passado ao invés de analisar a situação atual. Ela não deveria ter arriscado dessa vez. Tirou a lição errada de Mônaco e aplicou em Silverstone. As outras equipes olharam pro céu e viram nuvens realmente bastante negras, estavam na Inglaterra, que tem um dia sem chuva por ano e se lembraram dos dias passados, em que chovia o tempo todo. Claro que havia risco de não chover, mas bem menor.

Depois de cometido ao erro, ficaram comprometidos demais com o planejamento inicial de 3 paradas e demoraram pra tomar uma nova decisão e corrigi-lo: chamar os pilotos pra parar mais uma vez e trocar os pneus pra chuva. A nova parada custaria caro! Mais tempo perdido… Mas será que teria compensado o tempo perdido com as 5 rodadas do Massa? Será que se tivessem trocado pra chuva a corrida seria diferente? Será que se tivessem chamado os pilotos de volta logo depois o resultado não teria sido o mesmo?

A resposta é: nunca saberemos.

Decidir é um negócio difícil! Os americanos dizem “Se tomar uma decisão, pode errar. Se não tomar, já errou.” Hoje, com a velocidade com que as decisões complexas têm de ser tomadas, é muito caro e difícil ter as informações necessárias a tempo. O grau de incerteza é grande e talvez seja mais difícil ainda saber se uma decisão foi a bem tomada, pois também é difícil mensurar e comparar resultados. Assim como na corrida, você passa pela situação aquela vez e não tem como voltar e saber no que outra decisão teria resultado.

Tem um agravante quando o ambiente é instável, como na corrida ou em desenvolvimento de software: com a mudança do ambiente, o que seria aparentemente uma boa decisão pode tornar-se rapidamente ruim. Seria o caso se qualquer variável da corrida tivesse mudado, por exemplo, se a chuva tivesse sido muito breve. Nesse caso, todo mundo que colocou pneu de chuva seria prejudicado depois. E se tivesse dado uma bandeira amarela? bagunça tudo de novo… Gerenciar projetos de software é como se durante a corrida, mudasse o tempo todo o clima, o piloto, a equipe, a pista, o carro, várias bandeiras amarelas, acidentes e etc.

Normalmente nós passamos muito mais tempo convivendo com o efeito das decisões tomadas do que tomando as decisões. Decisões ruins podem se tornar fatais. Além disso, algumas informações só ficam visíveis depois de tomada a decisão. Então, por tudo isso que está escrito, é muito mais importante estar atento a esses efeitos e mudar rápido do que investir em uma decisão excelente.

O ambiente pode mudar e a decisão que foi caríssima e lenta fica mais cara ainda, pois terá que mudar tudo de novo. E como normalmente houve muito comprometimento com essa decisão, há mais demora ainda para que seja corrigida. Enquanto que, se tomar a melhor decisão possível para o momento e ela se mostrar ruim, você aprende e se adapta rapidamente à nova realidade, com baixo custo, e não sofre por completo (nem por muito tempo), seus males.

E o que tem Scrum, XP e agilidade a ver com isso tudo? Tudo!
Um dos valores do Manifesto Ágil é que se adaptar às mudanças é mais importante que seguir um plano… Por essa razão que temos reuniões diárias, semanais, mensais, trimestrais e etc. Cada uma pra inspecionar e nos adaptarmos ao caos do nosso dia-a-dia. Temos vários pit-stops pra inspecionar o tempo e trocar nossos pneus de acordo com o altíssimo ritmo das mudanças de nosso ambiente. Na Fórmula 1 o pit-stop sai caro pois é demorado… Em projetos também pode acabar ficando caro, e é por isso que controlamos o tempo das reuniões.

Também é por essas razões que não planejamos com detalhes todo o projeto antes de iniciá-lo. Ao planejar, tomam-se várias decisões que, à época da execução, podem todas terem “perdido a validade” devido às diversas mudanças de ambiente. Cria-se uma expectativa perigosa com a idéia de que o plano seja uma “previsão do futuro”, e qualquer mudança nele pode gerar frustração. Além disso, cria-se um “comprometimento”, ou “apego” à todo trabalho despendido nesse planejamento que pode retardar uma mudança necessária, como no caso das 3 paradas planejadas antecipadamente para a corrida.

Notaram alguma semelhança com seu dia-a-dia? Acho que é uma analogia bem legal e espero que ajude a clarear as idéias sobre essa forma de planejar, além de motivar algumas mudanças. Que tal um planejamento iterativo agora?

Até a próxima!

Willi