A maioria das vagas de tecnologia nasce de uma frase: “precisamos de um dev back-end sênior, Java, para ontem”. Essa frase vira anúncio, o anúncio vira uma pilha de currículos, e a pilha vira três semanas de entrevistas com gente que até sabe Java, mas não resolve o problema que motivou a vaga.

O perfil técnico é o documento que mais influencia a qualidade dos candidatos, e quase sempre é escrito em cinco minutos. Quem recruta preenche as lacunas com suposições. O candidato também. Quando o desalinhamento aparece, já se passaram semanas. Este artigo traz um modelo de briefing completo, com um exemplo preenchido, para você usar na próxima vaga.

Por que o anúncio não serve como briefing

Anúncio e briefing têm funções diferentes. O anúncio atrai. O briefing orienta quem vai buscar, filtrar e entrevistar. Quando você usa um no lugar do outro, acontece uma de duas coisas: o texto fica genérico demais para filtrar ou específico demais para atrair.

Um bom briefing responde perguntas que o anúncio nunca responde. Por que a vaga existe agora? O que essa pessoa vai destravar? O que o time já tem e o que falta? Com essas respostas, o recrutador consegue descartar um candidato forte que não serve e insistir num candidato menos óbvio que serve muito.

O modelo de briefing em oito blocos

Você não precisa de um formulário longo. Precisa de oito blocos curtos, cada um com duas ou três frases.

1. Contexto do produto

O que a empresa vende, o que o time constrói e em que fase o produto está: descoberta, crescimento, escala ou sustentação. Um back-end para lançar um produto novo e um back-end para manter um sistema crítico em produção são pessoas diferentes, mesmo com a mesma stack.

2. Problema a resolver

A frase mais importante do briefing. Por que abrir a vaga agora? “O time está sobrecarregado” é sintoma. “Precisamos tirar o checkout do monólito antes da próxima temporada de vendas” é problema.

3. Stack obrigatória e desejável

Separe em duas listas. Na obrigatória, só o que a pessoa vai usar desde a primeira semana e não dá tempo de aprender. Na desejável, o resto. Uma regra útil: se ninguém do time atual cumpre todos os obrigatórios, a lista está errada.

4. Senioridade por autonomia

Em vez do título, descreva o que a pessoa vai decidir sozinha, o que vai revisar dos outros e com quem vai negociar prioridade. O artigo sobre como definir a senioridade detalha essa lógica.

5. Rotina e rituais

Tamanho do time, a quem a pessoa responde, quais cerimônias existem, com que frequência há plantão, quanto tempo vai para código novo e quanto para manutenção. É aqui que muita contratação dá errado sem que ninguém perceba na entrevista.

6. Critérios de sucesso em 90 dias

Duas ou três entregas concretas. Esse bloco orienta a entrevista técnica, alinha expectativa com o candidato e vira a régua do acompanhamento depois do start.

7. Modelo de trabalho

Remoto, híbrido ou presencial. Fuso de referência, idioma do dia a dia, se há viagens. Se o time conversa em inglês com a matriz, diga isso e diga em que nível.

8. Faixa e processo

A faixa de remuneração ou orçamento, quem entrevista, quantas etapas existem e em quanto tempo você dá retorno. Sem faixa, o recrutador trabalha às cegas. Sem prazo de retorno, os melhores candidatos aceitam outra proposta.

Um exemplo preenchido

Imagine um varejista de moda com e-commerce próprio, que decidiu separar o checkout do restante da plataforma. O briefing ficaria assim:

  • Contexto: e-commerce em crescimento, time de produto com oito pessoas, plataforma construída como monólito há cinco anos.
  • Problema: o checkout cai em picos de tráfego e qualquer mudança exige deploy de tudo. A meta é isolar o checkout em um serviço próprio antes da próxima grande data de vendas.
  • Stack obrigatória: Java com Spring Boot, bancos relacionais, mensageria, AWS. Desejável: Kubernetes, experiência com gateways de pagamento, observabilidade.
  • Autonomia: decide o desenho interno do serviço, propõe contratos de API, revisa código de dois plenos. Negocia prioridade com o PM do checkout.
  • Rotina: sprints de duas semanas, daily curta, refinamento semanal. Plantão em rodízio mensal. Cerca de 70% do tempo em construção nova.
  • Sucesso em 90 dias: desenho do serviço aprovado pelo time, primeira versão rodando em paralelo ao monólito, métricas de latência e erro visíveis em painel.
  • Modelo: remoto, horário de Brasília, português no dia a dia.
  • Processo: conversa técnica com o tech lead, conversa com o head de engenharia, retorno em até dois dias úteis por etapa.

Com esse texto, qualquer recrutador sabe que um sênior com experiência forte em Java, mas que nunca separou um monólito ou lidou com pagamento sob carga, provavelmente não é o candidato. E sabe que um pleno avançado que já fez exatamente isso merece uma conversa.

Armadilhas comuns

  • Copiar a descrição da última vaga. O problema mudou, o time mudou, e o briefing continua o mesmo.
  • Lista de desejos no lugar de requisitos. Doze tecnologias obrigatórias descrevem um profissional que não existe ou que custa muito acima da faixa.
  • Esconder o desafio real. Se a vaga é para sustentar um legado difícil, diga. O candidato vai descobrir na primeira semana, e a saída custa mais do que a franqueza.
  • Senioridade pelo título. “Sênior” em uma empresa é “pleno” em outra. Sem descrição de autonomia, você compara coisas diferentes.
  • Briefing escrito por uma pessoa e entrevistado por outra. Se o gestor e o tech lead não leram o mesmo texto, cada um avalia uma vaga diferente.

Checklist antes de abrir a busca

  • Consigo explicar em uma frase por que a vaga existe agora?
  • A stack obrigatória cabe em uma linha?
  • Descrevi pelo menos três decisões que a pessoa vai tomar sozinha?
  • Os critérios de 90 dias são entregas, e não qualidades pessoais?
  • Fuso, idioma e modelo de trabalho estão explícitos?
  • Faixa e prazo de retorno estão definidos?
  • Todos os entrevistadores leram e concordam com o texto?

Se alguma resposta for “não”, vale uma conversa interna de vinte minutos antes de publicar qualquer coisa. Ela economiza semanas de entrevistas.

Como a Devgo usa esse modelo

Toda busca na Devgo começa com um deep dive de 30 minutos que percorre exatamente esses blocos: stack, cultura, senioridade e urgência. A partir dele, a IA ranqueia uma shortlist na base de mais de 8 mil talentos, e o time valida cada nome antes de ele chegar até você. É por isso que 82% das indicações são aprovadas pelos clientes.

O mesmo briefing serve para qualquer modelo: alocar um profissional dedicado ao seu time, montar um squad completo ou contratar direto na sua folha via hunting. Se você ainda está decidindo entre eles, o artigo sobre como escolher o modelo de contratação ajuda.

Descreva o problema que a vaga resolve, e não a pessoa ideal que você imagina: é isso que traz os candidatos certos já na primeira rodada.