Por que projetos de desenvolvimento se tornam desnecessariamente complexos e como evitar isso
Todo mundo que trabalha em TI conhece essa história: um projeto começa super simples, mas depois de alguns meses você de repente se vê em um projeto confuso, com muitas horas extras já feitas. O orçamento voa pelos ares e a data de entrega vai empurrando cada vez mais para frente. Por que, afinal, os projetos de desenvolvimento se tornam com tanta frequência desnecessariamente complexos? No meu trabalho como especialista em backend e arquitetura, vejo duas grandes causas: desenvolvedores que começam a codar rápido demais e um escopo que não está bem definido de antemão.
Primeiro codar, depois pensar: código espaguete
Quando você trabalha em uma equipe, infelizmente ainda vejo isso acontecer com frequência: os desenvolvedores simplesmente começam a construir e só depois realmente pensam sobre a estrutura. Se você quer ajustar um botãozinho simples ou resolver um problema fácil de código, tudo bem, mas se você quer construir sistemas de CMS completos ou plataformas, isso é um verdadeiro drama.
O que você acaba obtendo dessa forma é puro código espaguete. No meio do projeto você trava, recebe feedback de outros desenvolvedores e descobre que a base não está bem construída. Resultado? Você precisa reconstruir tudo de novo. No fim das contas, você acaba levando tranquilamente de duas a três vezes mais tempo no desenvolvimento do que seria realmente necessário. Pensar primeiro na arquitetura técnica economiza muito tempo depois.
"Mas eu sempre quis isso?!"
Outro grande problema é que o escopo não está bem claro para o cliente desde o início. Quando o escopo está bem definido, ambas as partes sabem exatamente o que vai ser construído. Ainda assim, na prática, isso às vezes dá errado.
Recentemente vivi uma situação em que havia projetado um aplicativo para um cliente. Tudo estava alinhado, mas, quando já estávamos com o trabalho em andamento, o cliente de repente quis que também fosse incluído um sistema de pagamento completo. Quando fui conversar que isso era uma expansão considerável e, portanto, custaria horas extras de desenvolvimento, a resposta foi: "Mas eu sempre quis isso?!"
Nesse tipo de momento, é preciso buscar juntos um meio-termo, mas isso gera atraso e discussão. Minha solução para isso hoje é bem simples: logo depois de assinar a proposta, reviso ponto por ponto com o cliente exatamente o que vou construir. Ainda está faltando algo? Então isso precisa entrar agora, antes de começarmos.
A armadilha das ferramentas e frameworks grandes demais
Além disso, percebo que empresas (e desenvolvedores) costumam tornar os projetos grandes demais do ponto de vista técnico. Eles querem usar logo de cara frameworks complicados ou integrar sistemas como o HubSpot, quando isso ainda nem é necessário para o projeto.
Você não precisa de sistemas pesados nem de uma plataforma WordPress totalmente montada para as coisas básicas. Basta olhar para o que o projeto realmente precisa agora e construir isso da forma mais simples e enxuta possível. Escalar sempre pode ser feito depois.
Como manter a simplicidade?
Se você quer que um projeto de software corra bem, lembre-se destas três regras básicas:
Deixe o escopo à prova d'água: Depois da proposta, revise mais uma vez, passo a passo, todas as funcionalidades com o seu desenvolvedor.
Pense primeiro na arquitetura: Não deixe os desenvolvedores simplesmente sair codando — garanta que exista um plano para sistemas maiores.
Escolha a ferramenta certa para o trabalho: Comece simples. Construa o que você precisa agora e não se deixe levar por novas tecnologias que outros estão usando. Mantenha-se no básico.
O que vemos na Freelancer.com.br?
Na Freelancer.com.br observamos que muitos contratantes buscam desenvolvedores para projetos, plataformas ou softwares já existentes e que já estão em desenvolvimento. Nesses casos, é comum perceber que o escopo original mudou pelo caminho ou que não houve atenção suficiente, desde o início, à arquitetura e às escolhas técnicas. Nossos dados mostram, ainda, que projetos de desenvolvimento especializados costumam ter, em média, um valor mais alto do que muitas outras especializações freelance. É justamente por isso que vale a pena definir com clareza, desde o início, o que precisa ser construído para que o valioso tempo de desenvolvimento não seja perdido com retrabalho ou alterações feitas depois.
