O problema
Um diretor de operações manda uma mensagem: "precisamos de um sistema com Claude que resolva o atendimento ao cliente, o mais rápido possível." Um arquiteto júnior lê isso como um pedido de escopo — "construir um chatbot de atendimento" — e já começa a desenhar o fluxo de conversa. Três meses depois, o sistema está pronto, funciona bem tecnicamente, e é rejeitado pelo time jurídico porque nunca ninguém perguntou se as respostas precisavam ficar auditáveis, nem qual era o tempo máximo aceitável antes de escalar pra um humano.
O erro não foi de implementação. Foi de descoberta. "O mais rápido possível" não é um requisito, é uma frase que esconde pelo menos três requisitos diferentes — velocidade de entrega do projeto, latência de resposta do sistema, e tempo de resolução do ticket — e cada um deles restringe a arquitetura de um jeito diferente. Um arquiteto profissional não parte pra desenho até essas três coisas estarem separadas e escritas.
Essa lição é sobre o trabalho que acontece antes da primeira decisão técnica: descobrir o que o negócio realmente precisa, traduzir isso em restrições mensuráveis, e identificar quem vai validar cada uma delas antes que vire código.
Descoberta é sobre separar pedido de requisito
Um pedido de negócio chega quase sempre em linguagem de resultado desejado, não de restrição técnica. "Resolver mais rápido", "reduzir custo", "melhorar a experiência" são objetivos, não especificações. O trabalho de descoberta estruturada é fazer as perguntas que transformam objetivo em restrição:
- Qual é o resultado exato esperado, e como alguém vai saber que ele foi alcançado? Se a resposta é vaga ("melhorar a satisfação"), a descoberta não terminou.
- Qual é a régua de sucesso e quem a define? Um SLA de "resposta em até 2 minutos" definido pelo time de produto pode ser tecnicamente inatingível se o time de dados não consegue garantir atualização da base de conhecimento com a mesma frequência.
- O que é inegociável e o que é preferência? Confidencialidade de dados de cliente costuma ser inegociável. O tom da resposta costuma ser preferência. Tratar os dois com o mesmo peso trava decisões de arquitetura que deveriam ser rápidas.
- Quem precisa aprovar antes do sistema ir ao ar? Jurídico, segurança, o dono do produto — cada um deles pode barrar o lançamento por um motivo que a descoberta deveria ter capturado antes.
Um distrator comum em cenário de prova: uma alternativa que "avança direto para o design técnico com base no pedido inicial, para ganhar velocidade". Parece produtivo. Na prática, converte ambiguidade em decisões técnicas que ninguém pediu — e o retrabalho de descobrir um requisito tarde demais custa muito mais do que uma sessão de descoberta bem feita no início.
SLAs de negócio viram restrições técnicas mensuráveis
Um SLA que não pode ser medido não é um SLA, é uma intenção. "Responder rápido" precisa virar algo como "p95 de latência abaixo de 3 segundos para consultas simples, abaixo de 15 segundos para consultas que exigem busca em base de conhecimento" — um número, uma condição, um jeito de verificar se foi cumprido.
Essa tradução exige entender de onde cada número vem. Um SLA de disponibilidade de 99.9% definido pelo time comercial pode não considerar que o sistema depende de uma API externa cujo próprio SLA é 99.5% — nesse caso, o SLA do time comercial é, na prática, inatingível sem redundância adicional, e é papel do arquiteto trazer essa restrição de volta pra discussão antes de prometer um número que a arquitetura não sustenta.
O mesmo vale para custo: "manter o custo baixo" não orienta nenhuma decisão. "Custo por conversa resolvida abaixo de X" orienta escolha de modelo, decide se cache de prompt é obrigatório, e define se um pipeline de triagem barato antes de chamar o modelo mais caro se paga.
Identificar stakeholders antes de desenhar, não depois
Cada restrição descoberta tem um dono — a pessoa ou time capaz de validar se ela foi atendida. Descoberta estruturada mapeia isso explicitamente: quem aprova política de dados, quem valida a régua de qualidade da resposta, quem é acionado se o sistema tomar uma decisão errada com impacto real.
Pular essa etapa não elimina os stakeholders — só adia a hora em que eles aparecem, geralmente depois que a arquitetura já foi construída em torno de suposições que eles nunca validaram. Um arquiteto que traz jurídico e segurança pra dentro da descoberta, antes do design, transforma uma possível rejeição tardia em uma restrição conhecida desde o dia um.
Coloque em prática
O laboratório desta lição pede que você pegue um pedido de negócio escrito em linguagem vaga e produza, a partir dele, uma lista de restrições técnicas mensuráveis com seus respectivos donos de validação — a mesma tradução que separa um projeto que trava no meio do caminho de um que chega até produção sem surpresa.