Tem uma pergunta que aprendi a fazer antes de qualquer outra, quando uma ideia de automação me ocorre: dá pra eu testar isso sozinho, sem mobilizar ninguém?
Na maior parte das vezes, dá. E o caminho que uso é sempre o mesmo: um HTML que roda localmente, direto no navegador, sem servidor, sem infraestrutura, sem depender da TI para nascer. Funciona como um mockup, um protótipo do que, se fizer sentido, poderia se tornar um SaaS de verdade. É o analista prototipando a própria solução, validando o conceito, e só então, se fizer sentido, levando para industrializar com a TI.
Isso muda a ordem natural das coisas. Em vez de descrever uma ideia numa reunião e esperar que alguém da TI a traduza (e, no caminho, perca ou distorça alguma premissa), eu mesmo construo a primeira versão. Uso a IA como parceiro: descrevo o problema, discuto a lógica, deixo que ela me faça perguntas antes de eu pedir o resultado, e no fim tenho uma tela funcional, com dados simulados, que já deixa claro se a ideia resolve o problema ou não.
Um protótipo simples é, muitas vezes, a melhor forma de testar uma ideia. Uma aplicação local, um fluxo automatizado ou um painel com dados simulados permite validar a experiência, as regras e as saídas antes de mobilizar uma estrutura maior. O protótipo responde primeiro se o problema foi compreendido; a industrialização responde depois como operar com segurança, escala e suporte. São duas perguntas diferentes, e cada uma tem seu momento: misturar as duas é o motivo pelo qual tanto projeto de TI nasce descrevendo o problema errado.
Os vídeos e demos que venho postando às terças e quintas, na série Guardião de Valor, nasceram exatamente assim. Antes de qualquer tela polida, existiu um HTML rodando sozinho no meu notebook, às vezes feio, sempre funcional o suficiente para eu decidir se valia a pena continuar. Alguns desses protótipos morreram ali mesmo, porque testando percebi que o problema que eu resolvia não era o problema real. Outros amadureceram até virar as demonstrações que mostro hoje.
O ganho não é só velocidade. É qualidade de decisão. Quando eu mesmo construo o protótipo, entendo o problema num nível que nenhuma reunião de levantamento de requisitos alcança, porque estou dentro do dado, testando exceção por exceção, e não descrevendo de fora o que acho que acontece.
E é esse o espírito por trás do perfil que venho descrevendo nessa série: não esperar que a tecnologia venha até o problema. Ir até a tecnologia, sozinho, o quanto for possível, e só chamar reforço quando o protótipo já provou que existe valor ali.
💡 LIÇÃO APRENDIDA
O protótipo não substitui a TI. Ele garante que, quando a TI entrar, o problema já esteja certo.