quinta-feira, 17 de maio de 2012

Gambiarra é Empréstimo de Produtividade.


Recentemente, enquanto conversava com meu amigo Raphael sobre "soluções de caráter paliativos e temporário mas que serão utilizadas por período indeterminado", mais conhecidas como gambiarras, e como o mal uso dessas pode se acabar com um projeto, surgiu um comparativo que acredito que pode ajudar muito pessoas que não são desenvolvedoras mas que, por algum motivo, interagem com a área de desenvolvimento. Pronto? lá vai...

Gambiarra é Empréstimo de Produtividade.

Imagina que você quer comprar um carro novo mas não tem dinheiro o suficiente para comprar um agora. Você tem duas opções:

  • Espera alguns meses e com um pouco do salário vai fazendo uma poupança para comprar;
  • Pega um empréstimo, começa a usufruir do carro hoje, mas vai ter que ficar pagando nos próximos meses.


Na primeira opção você precisa esperar um bom tempo, até que o total de dinheiro acumulado seja suficiente para a compra. Não há dívidas e o carro quando entregue é 100% seu. Em compensação você teve de esperar muito tempo para ter o seu carro e não é raro, que você precise do carro com urgência.

Na segunda opção, você conseguiu resolver o problema da urgência. O carro que você precisava foi entregue e você pode usufruir deste enquanto pagava mas isso não foi de graça. O empréstimo tem juros o que vai fazer com que, muitas vezes, você acaba pagando dois carros para ter um.

Empréstimos são parte da nossa vida. Mas, repetindo o que todo economista está cansado de dizer é preciso saber usar. Se ao fazer um empréstimo você não faz um planejamento de pagamento deste, o dinheiro do mês que vem não será suficiente para as suas necessidades diárias e então você vai ter de pegar outro empréstimo, ou se preferir entrar no cheque especial de novo. Esse ciclo de dívidas apenas vai reduzindo a quantidade de dinheiro que, de fato, você terá disponível durante o mês.

Assim também gambiarras são parte do desenvolvimento. Um time de desenvolvimento tem uma capacidade praticamente fixa, similar a um salário de uma pessoa. Mas, bem sabemos que não vivemos no mito do mundo sem prazos ou sem expectativas onde se pode levar um prazo infinito para se desenvolver. Então vai aqui a primeira lei de Thiago Mata - até que alguém prove que já disse isso antes: 

"Quando se demanda, de um time, uma produtividade acima da sua capacidade, alguém vai fazer uma gambiarra".

A gambiarra dá a impressão que seu time conseguiu produzir acima da capacidade assim como, o empréstimo, dá a impressão de que você conseguiu, em um mês, ganhar acima do seu salário e logo está mais rico. Mas isso, é uma ilusão. Você na verdade está mais pobre.

Manter uma gambiarra num projeto é manter uma dívida rolando sem pagar. Quanto mais tempo levar, mais complexo será alguém saber resolver, alguém entender como deveria ter sido feito e corrigir. Assim, quanto mais tempo levar, menos o seu time terá disponível para produzir outras coisas. Não resolver a gambiarra é como ignorar a prestação do cartão de crédito, ela não só não se resolve como piora a cada dia.

Existem dívidas tão grandes que são acima do seu salário mensal. Eu mesmo já precisei de uma assim. O que você faz para não perder o controle? Você cria um plano de pagamento. Todo mês, de alguma forma, seja carne ou débito em conta ou boleto, você reduz a sua dívida progressivamente, até quita-la totalmente.

Para sistemas com muitas gambiarras, é preciso fazer algo similar. Deve-se fazer um plano de melhoria do software, para que sua equipe, utilize um pouco da sua capacidade produtiva para resolver as gambiarras do passado, no lugar de produzir novas funcionalidades. Mas a equipe vai produzir menos? É claro! O empréstimo foi feito e agora está sendo pago, e com juros.

Todos nós temos um limite de crédito. Mesmo que eu queira pegar um dívida milionária, o banco não vai aceitar, porque ele sabe que eu não tenho como pagar. Assim, é preciso muitas vezes que uma equipe de desenvolvimento saiba o seu limite máximo de gambiarras o que, seguindo a analogia da lógica monetária, deve ser proporcional a sua capacidade produtiva.

Eu já convivi com projetos que, a cada dia, tinham uma capacidade produtiva menor. Para tentar reduzir esse problema, as empresas, aumentavam o tamanho do time. Mas, utilizaram de gambiarras para resolver gambiarras, que é como pegar empréstimo para quitar empréstimo, no juro sobre juro. Até chegar ao ponto que, mudar a cor de um botão, precisava de duas semana com tantos desenvolvedores. Projetos assim "faliram" ou estão a beira da "falência".  Uma empresa fali quando todo o seu patrimônio não é suficiente para pagar suas dívidas. Segundo Thiago Mata, até que alguém prove o contrário:
"Um projeto fali quando gerar um conjunto de novas funcionalidades neste demora, quase tanto ou mais do que fazer um novo com elas" 

É importante dizer que, essas coisas acontecem, não por falta de esforço ou capacidade produtiva das equipes, mas  falta de gestão estratégica de quem gerenciava esse pessoal.

Então, mantendo a dica mais fundamental de economia, procure não fazer empréstimos e gambiarras, planejando bem seus gastos e entregas. Caso não seja possível, procure fazer o uso com moderação, já fazendo um plano de abatimento destas, parcelado ou não. Deste modo você não tornará o seu time, a próxima Grécia da TI.

Ps - É importante ressaltar que estou chamando de gambiarra aqui, soluções que não são as mais rápidas ou mais recomendadas mas que geram um produto que apresenta os resultados esperados, sejam lógicos ou matemáticos. Entregar intencionalmente um produto que informa dados inválidos, que só parece que funciona, não é apenas uma gambiarra, é trapaça! pra lá de bandidagem. Nesse cenário é melhor jogar limpo com o cliente que não é possível entregar o produto no prazo do que entregar uma fraude.

2 comentários:

Ricardo Abu Hana disse...

Mata, saber dizer NÃO, é uma arte! Aprendendo isso, sua vida profissional e pessoal melhoram consideravelmente. Pena que grade parte dos diretores, coordenadores, GPs ou mesmo desenvolvedores não tem essa capacidade.

fagury disse...

Concordo com o Hana. Mas acho que workarounds também são necessários eventualmente, especialmente em situações emergenciais. Minha dica é manter sempre um comment padrão onde houver gambi (#ToDo ou #ReviewThisCat) e reservar um tempo a cada fim de ciclo de desenvolvimento para refinar as implementações. É preciso disciplina para revisar depois, mas há casos em que os desenvolvedores de uma organização que trabalhei deixavam o comment #ReviewThisCat para que o arquiteto, que coçava o saco o dia todo, refinasse as implementações depois.