Como pensar antes de começar a desenvolver

Introdução: codificar já não é o trabalho inteiro

Codificar continua sendo uma habilidade fundamental para quem desenvolve software. Mas, com a presença de ferramentas de inteligência artificial no cotidiano, a velocidade com que tarefas e entregas podem ser produzidas mudou. Isso torna ainda mais importante entender o que deve ser construído — e por que.

Antes, muitas demandas chegavam relativamente especificadas: o que fazer, de onde viria o dado, qual endpoint utilizar ou qual tecnologia seguir. Em outros casos, o trabalho parecia estar concentrado em escrever uma função, corrigir um botão ou implementar uma tela.

Hoje, o trabalho pode exigir uma compreensão mais ampla do produto: suas regras de negócio, limitações, usuários e consequências das decisões. Isso não é uma particularidade de uma empresa; é uma mudança relevante na forma como equipes de desenvolvimento podem trabalhar com ferramentas de IA.

O risco aparece quando recebemos uma demanda e agimos apenas como executores. Se delegamos uma tarefa ao Claude sem compreender a própria tarefa, também delegamos decisões que deveriam ser discutidas pela equipe.

Imagine receber o pedido:

“Preciso que, no painel de ADMIN, eu consiga controlar qual funcionário terá acesso a cada página.”

Podemos enviar essa frase diretamente ao Claude. Mas como saber se a solução gerada corresponde ao que o solicitante realmente precisa? Para responder, precisamos construir contexto antes de começar a implementar.

1. Descrever o problema com clareza

Entender o problema é o primeiro passo para construir uma solução adequada. A descrição não precisa ser um documento extenso: ela deve funcionar como uma referência prática para a pessoa desenvolvedora, o Claude e a equipe.

Algumas perguntas ajudam a transformar uma solicitação inicial em uma descrição mais concreta:

• Quem enfrenta esse problema?
• Por que as opções disponíveis não são suficientes?
• Qual é o impacto desse problema hoje?
• O que é problema real e o que ainda é suposição?
• Quem são as pessoas envolvidas e quais responsabilidades possuem?
• Quais perfis existem dentro do sistema?
• Como a empresa espera controlar os acessos: individualmente, por grupos ou por perfis?

Aplicando à demanda de permissões

Ao investigar, podemos descobrir que existem perfis como Administrador, Gerente de Marketing, Funcionário de Marketing e Financeiro. O próximo passo não é escolher uma implementação, mas compreender o que cada pessoa precisa fazer no sistema.

O administrador será responsável por gerenciar os acessos? O gerente de Marketing precisa de permissões diferentes das dos demais funcionários? Pessoas do mesmo setor podem ter responsabilidades distintas?

Ainda não estamos decidindo como programar as permissões. Estamos entendendo como as pessoas trabalham e quais necessidades a solução deve atender.

Sem essa compreensão, podemos construir algo tecnicamente funcional, mas incompatível com a realidade de quem vai utilizar o produto. A descrição do problema oferece a base para investigar os requisitos.

2. Investigar os requisitos da solução

Depois de descrever o problema, precisamos descobrir o que a solução deve ser capaz de fazer e quais condições precisa respeitar.

Isso envolve definir o comportamento esperado quando tudo funciona, o que deve acontecer em caso de erro e quais dados e regras são necessários.

Uma distinção útil é entre requisitos funcionais e não funcionais:

• Requisitos funcionais: descrevem o que o sistema precisa fazer — por exemplo, cadastrar funcionários, criar grupos, associar pessoas a grupos, definir permissões e bloquear ações não autorizadas.
• Requisitos não funcionais: descrevem características ou condições que a solução deve atender, como segurança, usabilidade, desempenho e facilidade de manutenção.

Quando esses requisitos não estão claros, o Claude pode acabar tomando decisões em nome da equipe.

A primeira interpretação pode estar incompleta

Voltemos à solicitação:

“Preciso controlar qual funcionário consegue acessar cada página.”

Precisamos esclarecer: as permissões serão individuais ou atribuídas por grupos? Quem pode criar ou alterar permissões? Quais tipos de permissão existem? O que significa, de fato, ter acesso a uma página?

Imagine que eu seja gestor do setor de Marketing. Preciso acessar a página de campanhas e sou a única pessoa autorizada a publicar uma campanha ou excluí-la. Ao mesmo tempo, outras pessoas do setor precisam acessar a mesma página para criar campanhas, editar informações e realizar outras tarefas.

Nesse cenário, ter acesso a uma página não significa necessariamente poder realizar todas as ações disponíveis nela.

A demanda começa a revelar diferentes níveis de permissão e regras específicas por ação. Talvez seja necessário um gerenciador de pessoas, grupos e permissões.

Também precisamos pensar além da funcionalidade. Se um funcionário não tem autorização, a proteção deve valer na API, e não apenas na interface. A configuração precisa ser compreensível para quem administra o sistema, e a estrutura deve permitir evolução sem tornar a manutenção excessivamente complexa.

Uma solicitação que parecia ser apenas “controlar o acesso às páginas” revelou requisitos que não estavam explícitos na descrição original. Se a equipe não toma essas decisões antes, alguém terá de tomá-las durante a implementação — talvez o desenvolvedor, talvez a IA.

3. Mapear o fluxo do usuário

Depois de entender o problema e os requisitos, precisamos visualizar como o usuário vai interagir com a solução.

Não basta saber que teremos pessoas, grupos e permissões. Precisamos entender como essas partes se conectam durante o uso.

No exemplo:

1. O administrador acessa o gerenciamento de pessoas.
2. Seleciona um funcionário.
3. Define ou altera seu grupo e suas permissões.
4. O funcionário acessa o sistema e tenta abrir uma página ou executar uma ação.
5. O sistema verifica as permissões e permite ou bloqueia a operação.

Desenhar esse fluxo também revela situações que precisam ser consideradas:

• O que acontece se o funcionário tentar acessar uma página sem permissão?
• E se puder acessar a página, mas não puder excluir?
• O que acontece quando ele muda de grupo?
• Como o sistema se comporta quando uma nova página ou ação é criada?

Esses cenários fazem parte da solução e podem revelar requisitos que ainda não havíamos identificado. Pensar no fluxo não é considerar apenas o caminho em que tudo dá certo: é entender o que o usuário pode fazer, como o sistema deve responder e o que acontece quando algo foge do esperado.

4. Tomar decisões sobre a solução e a tecnologia

Depois de entender o problema, os requisitos e o fluxo, podemos decidir como implementar o que foi definido. Antes de escolher uma tecnologia específica, porém, precisamos avaliar as abordagens possíveis.

A pergunta não é simplesmente:

“Qual opção é melhor?”

Mas:

“Qual abordagem representa melhor as regras que precisamos atender, considerando o contexto do produto?”

Exemplo: como organizar permissões

Uma alternativa é trabalhar com perfis fixos — Administrador, Marketing e Financeiro — cada um com permissões previamente definidas. Isso pode ser mais simples de entender e administrar. Porém, duas pessoas do mesmo setor podem ter responsabilidades diferentes, ou alguém pode precisar acessar uma página sem poder executar todas as ações disponíveis nela.

Outra alternativa é trabalhar com permissões configuráveis por página e por ação. Isso permite ajustar acessos conforme as responsabilidades de pessoas ou grupos, mas exige cuidado na criação, organização, alteração e manutenção das regras.

Não existe uma resposta universal. O importante é compreender as necessidades e as consequências de cada alternativa. É aqui que conversar com colegas e com o Tech Lead ajuda a validar se a solução representa o que o produto precisa.

Da decisão de produto à escolha técnica

Depois de definir a abordagem, surgem decisões mais específicas. Em um exemplo com Spring Security, a escolha pode estar entre @Secured e @PreAuthorize.

@PreAuthorize permite expressões e regras mais elaboradas; @Secured trabalha diretamente com as authorities exigidas por uma rota. No cenário discutido, as verificações eram simples e as authorities já estavam disponíveis no token. A decisão foi utilizar @Secured, por expressar a regra necessária de forma direta, mantendo aberta a possibilidade de reavaliar a escolha se surgirem regras mais complexas.

O ponto não é declarar uma tecnologia superior à outra. É compreender por que escolhemos determinada solução, quais consequências ela traz e em quais condições a decisão poderia mudar.

Pensar antes de desenvolver também significa não escolher a ferramenta primeiro e tentar encaixar o problema nela depois.

5. Definir critérios de aceite e validação

Depois de entender o problema, levantar requisitos, definir o fluxo e tomar decisões técnicas, ainda precisamos responder: como saberemos que a solução realmente resolveu o problema?

Antes de desenvolver, precisamos definir o que significa a tarefa estar funcionando corretamente. Isso pode ser uma métrica de negócio — como aumentar conversão ou reduzir o tempo de uma tarefa — ou um comportamento objetivo que precisa acontecer.

No exemplo de permissões, critérios de sucesso poderiam ser:

• Um funcionário com a permissão correta consegue realizar a ação.
• Um funcionário sem a permissão não consegue realizar aquela ação.
• O sistema apresenta o comportamento esperado quando o acesso é negado.
• O administrador consegue configurar as permissões conforme as regras definidas.
• Todas as rotas que precisam de proteção estão realmente protegidas.

Quando sabemos antecipadamente o que significa estar correto, podemos transformar essas definições em testes e validações durante a implementação. Também precisamos pensar nos cenários de erro, não apenas no caminho ideal.

Sucesso não significa apenas “o código funciona”. Significa que a solução atende ao problema definido, respeita os requisitos levantados e se comporta como esperado nos diferentes cenários.

Conclusão: pensar o suficiente para não decidir por acidente

Não precisamos antecipar todos os detalhes antes de desenvolver. Algumas decisões menores podem ser refinadas durante a implementação. Mas precisamos dar atenção às decisões que mudam o comportamento central, as regras de negócio, os fluxos principais, a segurança e os critérios pelos quais vamos avaliar o resultado.

A IA pode acelerar a produção de código, mas não elimina a necessidade de compreender o problema. Quando enviamos uma demanda sem contexto, a ferramenta preenche lacunas com escolhas que talvez não representem a intenção do produto.

A preparação serve para tornar essas decisões visíveis: entender o problema, investigar requisitos, mapear o fluxo, avaliar alternativas e definir como validar a solução.

Não precisamos pensar em tudo antes de desenvolver. Precisamos pensar o suficiente para que as decisões importantes não sejam tomadas por acidente durante o desenvolvimento.

---

Referências

1. Fernando, Heshan. From Concept to Working Software: Before Coding Starts. MVP Hub, 22 ago. 2026. https://mvphub.tech/blog/concept-to-working-software-before-coding-starts
2. Google Engineering Practices. The Standard of Code Review. https://google.github.io/eng-practices/review/reviewer/standard.html
3. Google Engineering Practices. What to Look for in a Code Review. https://google.github.io/eng-practices/review/reviewer/looking-for.html
4. University of Alberta / Coursera. Client Needs and Software Requirements. https://www.coursera.org/learn/client-needs-and-software-requirements

Nota editorial: o artigo foi elaborado a partir do roteiro da palestra. As referências complementam os temas de preparação, requisitos e revisão; os exemplos de permissões e a decisão entre @Secured e @PreAuthorize são apresentados como exemplos do roteiro, não como recomendações universais.