FORGE™Do processo ao software

Entenda o negócio antes de pensar no software.

Se o cliente está procurando uma solução personalizada, provavelmente existe um motivo para ele não querer simplesmente contratar mais um software pronto.

Na maioria das vezes, ele está cansado de pagar mensalidades altas por sistemas com mil funções, quando na prática usa três. Ele não quer mais complexidade. Quer clareza na operação dele.

E eu sei que, como desenvolvedor, é fácil cair na armadilha de pensar: “isso aqui também seria legal”, “dá para colocar mais essa função”, “já que estamos fazendo, podemos adicionar isso também”.

Nossa cabeça começa a enxergar possibilidades que o cliente nem pediu.

Você pode até incluir algo que não estava no escopo inicial, mas isso precisa resolver um problema real, como:

• reduzir tempo ou trabalho manual;
• tornar o sistema mais simples e acessível para quem vai usar;
• reduzir erros, custos ou etapas desnecessárias da operação.

Fora disso, provavelmente é só mais uma função.

O cliente não quer pagar pelas mil ideias que você teve enquanto desenvolvia. Ele quer um software que resolva o problema dele, economize tempo e seja rápido e intuitivo de usar.

Por isso, antes de escrever a primeira linha de código, entenda como o negócio funciona.

Se você nunca desenvolveu para aquele nicho, pesquise. Veja vídeos. Entenda a rotina de quem trabalha nele. Teste softwares que já existem e descubra por que eles funcionam, e onde atrapalham.

Depois disso, junte esse conhecimento ao problema que o cliente trouxe.

Só então desenvolva.

Algo que costumo fazer antes de começar a desenhar a UI/UX é me colocar no lugar do funcionário daquele cliente:

“Como eu gostaria de usar esse software todos os dias, ao chegar na empresa e ligar o computador?”

Só então começo a desenhar o sistema.

Antes de abrir Figma, Canva ou Photoshop — sim, eu crio minhas UIs no Photoshop — desenhe o que vai compor o software e como cada tela se conecta.

Para isso, você pode usar mapas mentais e montar uma visão completa do sistema: telas, módulos, funções e ligações entre eles.

Inclusive, eu uso esse desenho na elaboração da proposta.

Isso vai te custar algumas horas e o cliente ainda pode não aceitar. Mas, se aceitar, você ganha algo muito mais valioso depois:

um escopo claro e muito menos espaço para scope creep.

Defina a arquitetura antes de começar a construir.

Com o escopo fechado, é hora de decidir o que o cliente não vê: banco de dados, autenticação, permissões, integrações e onde o sistema vai rodar. Escolha errada aqui só aparece quando o sistema já está no ar, e aí é caro.

Eu também olho os riscos antes de escrever código: limite de API, volume de dados, custo de infraestrutura, dependência de terceiros e o que acontece se um serviço cair. Descobrir isso agora custa uma tarde. Descobrir depois custa o projeto.

Não existe tecnologia certa, existe a que resolve aquele problema. Se um banco comum dá conta, não preciso entrar em algo distribuído só porque está na moda. Quando essa parte termina, eu já sei o que construir, em que ordem e onde estão os pontos que podem dar problema.

Transforme o plano em software que funciona.

Agora o sistema começa a existir de verdade: banco criado, telas andando, integrações conversando. É a etapa mais longa do projeto e a que mais precisa de método, senão vira uma pilha de tarefas abertas.

Eu construo na ordem do que importa: primeiro o que faz o sistema funcionar de ponta a ponta, depois o que deixa ele melhor. Cada parte é testada antes de eu partir para a próxima. Erro consertado no dia em que nasce é rápido; três semanas depois, é caro.

Também olho o que costuma estragar na prática: lentidão, dado inconsistente, tela que confunde quem usa. Software que funciona é o mínimo. O que entrega valor é o que a pessoa consegue usar sem precisar pensar.

Melhore o sistema com o que o uso real mostra.

Depois que o software entra no dia a dia, aparecem coisas que nenhum planejamento pega: a tela que ninguém usa, o relatório que todo mundo pede, o processo que dá para automatizar.

É nesse momento que eu acompanho como o sistema está sendo usado de verdade, corrijo o que incomoda e vejo o que dá para melhorar. Quase sempre o melhor feedback vem de quem usa o sistema oito horas por dia, e não de quem encomendou.

E evoluir nem sempre é adicionar. Muitas vezes é remover uma etapa, juntar duas telas, automatizar algo repetitivo ou deixar o processo mais simples.

O objetivo é o sistema acompanhar a operação da empresa. Se ele fica parado no tempo, vira mais um software que a equipe aprendeu a contornar.