5 hacks para destravar de vez o seu projeto de software

Transformar uma ideia em software é um grande desafio.

É comum entre nós programadores, mesmo aqueles com muitos anos de experiência, ficarmos perdidos dentro de nossas caixas de ferramentas tecnológicas quando precisamos desenvolver um novo produto.

Isso acontece por causa da forma como a gente se acostumou a pensar em software, onde instantes depois de ouvir o briefing do cliente, a gente já começa a pensar no código, na arquitetura e em todas as coisas técnicas, pra depois tentar encaixar o problema do cliente na solução que idealizamos.

Essa forma de desenvolver não é sustentável! Ela gera desperdícios, gera frustrações e ainda nos impede de colocar os projetos na rua.

Por isso, neste artigo eu trago 05 hacks que a gente geralmente ignora, mas podem fazer a diferença no processo de transformar as nossas ideias em software de forma prática, rápida e sem dores de cabeça.

01- Foque no problema real e não na solução idealizada

Quem nunca presenciou um programador reclamando que o usuário era burro? Esse é um sintoma clássico de quem estava focado na solução e não no problema.

Esse tipo de coisa acontece quando não desenvolvemos a solução partindo do ponto de vista do cliente. O nosso ponto de partida tem que ser o problema que precisa ser resolvido. Do contrário, a gente vai gastar muito mais energia, mais tempo e mais dinheiro criando softwares não vão ser utilizados por ninguém.

É fundamental que a gente entenda que não é possível programar aquilo que não compreendemos! Não estou dizendo que você tem que virar um analista de negócios ou algo do tipo, mas que você precisa ser um programador que pensa a partir da necessidade do cliente.

Você precisa conhecer a realidade do problema para vislumbrar uma melhor forma de solucioná-lo. A solução vai além do software que você desenvolve, a solução é o problema resolvido!

02 — Não confunda rapidez com agilidade

Nada é pior do que fazer rápido a coisa errada…

A gente precisa ter agilidade para se adaptar ao contexto, contornar as restrições e resolver os problemas. Para fazer isso, é importante compreender e aplicar o conceito de “baby steps” ou “passos de bebê”.

Esse conceito se refere a forma como você aborda o problema, quebrando ele em pedaços que podem ser resolvidos de acordo com as restrições. O “baby steps” te permite sair da lógica industrial do desenvolvimento em cascata, e passar a desenvolver de forma evolutiva, onde o software vai resolvendo o problema cada vez melhor, desde a primeira versão.

Desta forma, você abandona aquele erro de tentar criar um produto “pronto pra tudo”, com arquiteturas complexas, infraestrutura superdimensionada e um monte de coisas tecnológicas. E foca na manutenção de algo que funciona até que o seu projeto se torne o aquilo que o cliente realmente precisa.

03 — Programe guiado pela falta

Software é algo caro de fazer e caro de manter! Por isso, pra gente, menos é mais.

Você não vai ter tempo e nem dinheiro para fazer tudo. Então desenvolver uma solução baseada em achismos, especulando que aquilo é o que seu cliente precisa é desperdício!

O importante para o seu cliente é você entregar uma versão do software funcionando o mais cedo possível e ir fazendo entregas frequentes. Você vai trabalhar a expectativa dele para que ele sinta confiança no seu ciclo de trabalho, e compartilhe o que sente falta no projeto.

Sentir falta não é ruim e nem sinal de incompetência sua! Quando o cliente usa o software e sente falta de algo, isso explicita uma necessidade. O que será o seu guia sobre o que concretamente precisa ser feito, sem desperdiçar tempo e energia no processo.

Não se aproxime do cliente querendo surpreendê-lo com tudo pronto à priori… Construa uma relação de confiança embasada por entregas frequentes intensificando o ciclo de feedback do seu projeto.

04 — Quem não testa, não sabe se funciona.

Algo que eu sempre digo é que teste não é opcional! Quem ainda pensa em testes como “tempo perdido” é porque não entende o verdadeiro trabalho do programador. Fazer software é arriscado e é fundamental que nós façamos a gestão desses riscos.

Testar o software não é sair fazendo análise combinatória das coisas, não é só verificar se o código está funcionando. Fazer teste é abordar a fronteira do problema, criando uma automação que valida se aquele código que você escreveu é uma solução ou uma fonte de mais dores de cabeça.

A gente não precisa fazer tudo da forma perfeita, mas precisamos entregar algo que gere valor, um produto que funcione de verdade e principalmente que possa evoluir conforme a necessidade.

Lembre-se que o valor percebido pelo cliente não está no código que a gente escreve, mas naquele código rodando e cumprindo o seu papel de resolver os problemas.

05 — O ótimo é inimigo do bom

Todo mundo já ouviu essa frase. Mas eu gosto de interpretá-la com uma sutileza a mais.

O ótimo, o perfeito, o ideal, o impossível é inimigo do “homem bom”, da pessoa bem intencionada. Isso porque o feito existe, o perfeito não. Não adianta saber tudo e não entregar nada.

O mercado é bem claro sobre isso!

Um desenvolvedor com pouca experiência, mas que aplica essas 05 atitudes/hacks que falamos neste artigo, pode se revelar um excelente profissional, mesmo que tenha um código pouco sofisticado.

Em contraste com isso, um programador experiente em algoritmos e linguagens, mas que foca apenas no código e pode acabar ficando distraído e perder o foco no cliente, no problema, no contexto e principalmente, na urgência deste cliente.

O cliente, a empresa, seu chefe… Eles não querem seu currículo, eles não querem o seu produto, eles querem que você solucione o problema deles.

Por isso, a minha dica é: se você não tem vergonha do que você botou na rua, você esperou demais! Você não pode ficar apegado a uma solução ideal. Você tem que se dedicar a entregar um resultado, entregar algo que funcione para as pessoas a quem você serve.