Já comecei projetos pelo lado errado. Escolhi uma tecnologia interessante, abri um quadro cheio de tarefas e só depois tentei explicar qual problema a solução deveria resolver. No início parece produtivo. Algumas semanas depois, fica mais difícil dizer o que realmente melhorou.
Por isso gostei da ideia central da Lisko Tech: antes de desenhar uma interface ou escrever código, vale entender quem precisa fazer o quê, com quais dados e para tomar qual decisão. É uma forma simples de evitar que a ferramenta vire o centro do projeto.
A pergunta muda o projeto inteiro
“Precisamos de um aplicativo” é uma frase muito diferente de “precisamos reduzir o tempo que uma pessoa leva para concluir esta tarefa”. A primeira já escolhe uma resposta. A segunda ainda permite investigar o problema.
Quando começo pela pergunta, tento descobrir quatro coisas:
- Quem está tentando realizar a tarefa.
- O que essa pessoa precisa fazer.
- Onde o processo fica lento ou confuso.
- Que decisão deverá ser tomada depois.
Isso também evita confundir uma reclamação com a causa real. Um usuário pode dizer que precisa de uma tela nova, quando o problema está numa permissão mal configurada, num dado que não chega ou num fluxo que pede a mesma informação duas vezes.
O contexto vem antes da interface
Uma interface pode parecer clara quando é vista sozinha. No fluxo real, ela depende de dados, permissões, integrações e hábitos que não aparecem no protótipo.
Eu perguntaria, por exemplo:
O que já existe?
Antes de redesenhar tudo, vale entender os sistemas atuais, os campos usados e as regras que ninguém colocou no documento. Um processo antigo pode esconder uma dependência importante.
Quem pode fazer cada coisa?
Uma tarefa pode parecer simples até aparecer a diferença entre quem consulta, quem aprova e quem altera. Permissões não são um detalhe para revisar no fim.
O que acontece quando algo falha?
Se uma integração não responde, a pessoa recebe uma mensagem compreensível? Existe uma forma segura de tentar novamente? O sistema registra o que aconteceu?
Essas perguntas costumam ser menos atraentes do que escolher cores ou componentes, mas têm impacto direto na experiência.
Modelar não é complicar
Às vezes a palavra “modelar” soa como uma etapa pesada, cheia de diagramas que ninguém consulta depois. Eu prefiro pensar nela como uma maneira de tornar as decisões visíveis.
Um modelo simples pode mostrar:
- Quais pessoas participam do processo.
- Quais dados entram em cada etapa.
- Quais regras mudam o caminho.
- Qual resultado indica que a tarefa terminou.
O objetivo não é prever tudo. É perceber cedo onde há uma hipótese frágil. Se não conseguimos explicar o fluxo numa conversa curta, talvez ainda não saibamos o suficiente para automatizá-lo.
Integrações são parte da experiência
Eu já vi integrações serem tratadas como um detalhe técnico escondido atrás da tela. Na prática, elas definem se a experiência será confiável.
Quando dois sistemas trocam informações, eu gostaria de saber:
- Qual sistema é a fonte de cada dado.
- Como uma atualização é identificada.
- O que acontece se a mesma mensagem chegar duas vezes.
- Como uma falha será registrada.
- Como a equipe poderá conferir o resultado.
Sem essas respostas, uma tela pode parecer correta e ainda assim mostrar informação atrasada ou incompleta. O problema aparece justamente quando alguém precisa confiar nela.
Onde dados que mudam podem entrar
Nem todo projeto começa com um modelo de dados perfeito. Eventos de produto, logs e telemetria mudam conforme a equipe aprende mais sobre o sistema.
Foi nesse contexto que encontrei o Rawtree. A proposta de receber dados em formatos que podem evoluir e permitir consultas SQL parece interessante para uma fase de exploração. Em vez de decidir a estrutura definitiva antes de observar os eventos, a equipe pode começar com uma pergunta e conferir o que está realmente chegando.
Isso não substitui uma arquitetura bem pensada. Também não transforma dados confusos em dados confiáveis automaticamente. Ainda é necessário definir acessos, remover informações desnecessárias e decidir o que merece um modelo estável.
O benefício, para mim, está em adiar algumas decisões irreversíveis até que exista evidência suficiente para tomá-las.
Construir o menor pedaço que ensina alguma coisa
Um primeiro lançamento não precisa conter todas as ideias do projeto. Ele precisa responder uma pergunta importante com segurança suficiente.
Eu começaria por um fluxo pequeno, como:
- Uma etapa de cadastro.
- Uma integração que hoje exige trabalho manual.
- Um relatório usado por poucas pessoas.
- Um ponto do processo que gera muitos erros.
Depois, observaria o uso real. As pessoas entendem o próximo passo? Os dados disponíveis são suficientes? O sistema permite corrigir um erro sem começar tudo de novo?
Esse ciclo é mais útil do que tentar adivinhar todas as necessidades antes de colocar qualquer coisa em contato com usuários.
Revisar é parte do trabalho, não uma etapa final
Depois de construir, eu não trataria a revisão como uma inspeção para encontrar culpados. É uma oportunidade de comparar a hipótese inicial com o que aconteceu de verdade.
Algumas perguntas ajudam:
O problema ficou menor?
Uma interface mais bonita não basta se a tarefa continua demorando o mesmo tempo.
O dado está ajudando a decidir?
Se ninguém consegue explicar o que um indicador significa, ele provavelmente precisa ser simplificado ou removido.
O fluxo continua compreensível quando algo sai do caminho normal?
Os casos de erro, atraso e permissão negada costumam mostrar mais sobre um produto do que o caminho perfeito.
Minha conclusão
O que levo da abordagem da Lisko Tech é menos uma receita e mais uma ordem de trabalho: descobrir antes de construir, modelar antes de automatizar e revisar antes de declarar que o projeto terminou.
Começar pela pergunta não deixa o trabalho mais lento. Na maioria das vezes, evita construir a resposta certa para o problema errado.
E quando os dados ainda estão mudando, essa disciplina fica ainda mais importante. Primeiro entendo a decisão que precisa ser tomada. Depois escolho a menor ferramenta e o menor fluxo que ajudam a aprendê-la.