Desenvolvimento

18 mai, 2012

Meu querido prédio de bits

Publicidade

É muito comum em qualquer projeto de desenvolvimento de software esbarrarmos com entraves técnicos. Quantas vezes você já achou que o melhor caminho é modificar e recompilar o código fonte de um componente terceiro? Ou construir seu próprio componente? Ou um framework? Ou fazer aquele ajuste no framework da empresa? Ou até mesmo ajustes menores na infra do seu projeto?

Todos esses são caminhos que, de alguma forma, já cruzaram a vida profissional de quem trabalha na área de TI. A questão toda é: como lidar com esses entraves? A maneira ideal seria termos tempo o suficiente para fazer uma análise no projeto e assim prever grande parte desses entraves com antecedência. Mas, infelizmente, no mundo das empresas privadas é muito difícil conseguir isso, pois é complicado convencer um cliente a ficar quatro meses sem ver nada de software, por exemplo. Nessa realidade, em geral, começamos a construir um sistema tendo a ideia do macro. O micro só irá surgir durante a construção. E, já que em boa parte das vezes não temos nem ideia, o que devemos fazer então?

Em uma situação dessas, a primeira coisa com a qual nós devemos nos preocupar é em dar visibilidade a essas questões para que possamos notá-las e decidir pelo melhor a ser feito, sem que atrapalhem o andamento de um sprint de trabalho.

Nós, desenvolvedores, costumamos ter uma visão bem técnica das coisas e, normalmente, nos preocupamos se temos a solução para o problema. Por exemplo, estamos com uma tarefa para ser realizada em duas horas e, no meio dela, esbarramos com um entrave técnico qualquer. Nessa hora, é muito comum pensarmos nele e termos uma solução que vai demorar, por exemplo, dois dias para ser feita – mas que vai resolver outras situações no futuro. Nesse cenário, é natural abaixarmos a cabeça e começarmos a dar tal solução, o que vai gerar um atraso de pelo menos 800% nessa atividade. É como costumamos dizer: os atrasos nos projetos não são gerados ou medidos ao final dos mesmos. O atraso acontece dia-a-dia, sprint-a-sprint.

O mais importante é desenvolver de forma consciente e alinhada com os responsáveis pelo projeto. Pois decisões como essa deverão surgir aos montes e, se começarem a acontecer no meio das atividades diárias, vão gerar atraso e tornar qualquer ação muito difícil de ser tomada. É importante tomar cuidado para não se precipitar e resolver o problema simplesmente por já “ter a solução”. Analise, pense, discuta prós e contras para, só então, tomar uma decisão pensada – e não instintiva.

Acredito que, muitas vezes, o melhor é pensar apenas o necessário para definir uma solução para o problema no lado do sistema (por exemplo, definindo interface de métodos e serviços) e deixar a solução final para depois. Isso nos permite agir de forma específica e focada nessas questões, não tirando o foco do que agrega valor naquele momento. Além disso, acredito que minimize o esforço necessário para resolver tais problemas quando eles realmente atacarem. Em situações como essas, é comum resolvermos mais do que o necessário por acreditar que já vamos solucionar problemas futuros. Porém, esses problemas nem sempre aparecem, ou aparecem de uma forma que ainda não foi solucionada. Se adiarmos essas ações, vamos ter a oportunidade de fazer apenas o necessário e evitar retrabalho.

Imagine construir um prédio sem saber exatamente o formato, as condições climáticas do ambiente ou a quantidade exata de andares que ele irá possuir. Com certeza será necessário construir uma base bem robusta para aguentá-lo. Muitas vezes, essa é a nossa realidade no desenvolvimento de software, porém, diferentemente da construção civil, nós temos a possibilidade deixar uma série dessas decisões para serem resolvidas quando o prédio já estiver erguido. Podemos, até mesmo, construir a cobertura antes de decidir como será o térreo.

Portanto, nesses cenários em que o futuro é incerto, acredito que qualquer decisão que não impacte o trabalho que está sendo feito naquele momento e que pode ser deixada para o futuro, assim deve ficar. Certamente será melhor retomá-la tendo o problema real do que avançar especulando como ele será.