Explicar demora uma vez, não explicar demora sempre
“É mais rápido eu mesmo fazer.”
Você já disse isso. Eu já disse isso. E a gente estava certo, no curto prazo. É por isso que quase ninguém para para pensar em como delegar de um jeito que não volte pra sua mesa. Explicar a tarefa leva 40 minutos, fazer leva 20. A conta fecha. O problema é que ela fecha de novo na semana seguinte, e na outra. Daqui a seis meses você continua sendo a única pessoa que sabe rodar aquilo.
E tem o outro lado dessa frase, que eu conheço igual. Toda vez que entro num projeto novo, o novato sou eu. É a minha pergunta que faz alguém pensar que era mais rápido resolver sozinho. Ninguém fica sempre do mesmo lado da mesa: todos nós somos o novato de alguém, o tempo todo.
O medo real é o retrabalho. A gente evita delegar porque explica mal, a pessoa entrega outra coisa, e no fim você refaz. Aí a lição que fica é “delegar não funciona”, quando a lição correta seria “eu expliquei mal”. Minha leitura é que pensar em como delegar é, quase sempre, pensar em como explicar.
O que resolveu isso pra mim foi um checklist. Seis perguntas que eu respondo pra mim mesmo antes de mandar o pedido. É sobre tirar o contexto da minha cabeça e colocar em palavras.
Essa lista funciona igual quando quem recebe a tarefa é um agente de IA. Prompt ruim e briefing ruim são o mesmo defeito, e eu já escrevi sobre isso em Context engineering, não só prompts longos.
Quando esse checklist serve
As seis perguntas respondem como delegar nestas situações:
- Você fazia a tarefa e está treinando alguém para assumir
- Você não sabe fazer, mas precisa acionar alguém de outro time
- Você quer que uma IA te dê uma resposta útil em vez de genérica
Os três casos têm a mesma raiz: contexto que só existe dentro da sua cabeça.
1. O que essa pessoa já sabe? O que é novo para ela?
Essa é a pergunta que te tira do seu próprio ponto de vista. Sem ela, como delegar vira adivinhação sobre o que a pessoa já domina.
Ao responder, duas coisas aparecem sozinhas. Primeiro, o que a pessoa já domina, e que você pode resumir em uma frase em vez de explicar do zero. Segundo, o que é novo para ela, e que você provavelmente ia esquecer de mencionar justamente por ser óbvio demais para você.
Você também fica mais paciente. Difícil se irritar com uma dúvida depois de reconhecer que aquilo era mesmo novidade.
O calibre muda conforme o caso. Alguém que já está no projeto e vai pegar outra frente precisa de um briefing. Alguém ouvindo falar do projeto pela primeira vez precisa de outro.
2. Por que estamos fazendo isso?
Toda tarefa que exige julgamento precisa dessa resposta, e quase toda tarefa exige julgamento.
Você não vai estar olhando por cima do ombro na hora da decisão. Se a pessoa entendeu o objetivo, ela decide bem sozinha. Se ela só recebeu passos, ela trava no primeiro caso que não estava no roteiro, ou pior, segue o passo ao pé da letra e produz algo inútil.
Não existe como delegar julgamento sem entregar o porquê junto.
RUIM: [silêncio]
BOM: "Isso importa porque..."
BOM: "O objetivo é descobrir por que o build está levando 12 minutos,
não só deixar o pipeline verde."
BOM: "Quando você terminar, isso vai para o time X, que vai usar
como base para..."Saber onde a sua parte se encaixa no todo deixa qualquer tarefa mais interessante.
3. O que a pessoa precisa para fazer isso?
Acesso a ferramentas, planilha, documento, repositório, credencial, orçamento, o nome de quem aprova. Deixe tudo separado antes, ou pelo menos tenha a lista pronta para falar em voz alta.
É o mise en place da cozinha. Você junta tudo antes de acender o fogo.
Cada item que falta vira uma interrupção. E cada interrupção custa um dia, porque a pessoa manda a mensagem, você responde três horas depois, e o trabalho ficou parado nesse intervalo. Boa parte de como delegar bem é ter essa lista pronta antes do pedido sair.
4. Como é a versão boa disso?
Mostre, não descreva.
Mockup, screenshot, um documento que ficou bom, um link. Você quer que a pessoa reconheça o padrão, não que ela deduza o padrão a partir de adjetivos. “Faz um relatório caprichado” não diz nada. Um relatório anexado diz tudo.
Se a tarefa é nova e não existe um exemplo exato, use o mais próximo e marque a diferença: “é tipo isso aqui, só que sem a parte de X”.
RUIM: [silêncio]
BOM: "O documento final deve ficar parecido com este aqui."
BOM: "Olha esses três documentos de estratégia. O seu não precisa
ter as mesmas seções, mas repare como todos respondem
'por que agora?' logo no começo."5. Qual o prazo e a prioridade?
Diga se é “nas próximas horas”, “essa semana” ou “nas próximas duas semanas”.
Evite “urgente”, “ASAP” e “prioridade máxima”. São palavras vagas que não informam nada e elevam o estresse de graça. Se tudo é urgente, nada é.
Prazo também comunica profundidade esperada. Já delegei tarefas e recebi de volta um trabalho muito mais detalhado do que eu precisava. A culpa foi minha, eu não disse onde era para parar. Saber como delegar prazo é saber dizer onde parar.
Peça um aviso caso a pessoa perceba, no meio do caminho, que a sua estimativa estava errada. Sem drama e sem cobrança. Na maioria das vezes, o que parece lentidão é escopo maior do que o combinado, e escopo não se resolve pedindo para trabalhar mais rápido.
6. O que tem mais chance de dar errado? O que dá para fazer agora para evitar?
Essas duas perguntas cobrem quase todo o trabalho de reduzir risco.
Calibre pelo tamanho do estrago. Risco baixo, responda em trinta segundos e siga. Risco alto, sente e liste os cenários com calma, junto com o que dá para preparar antes.
Na prática, boa parte dos riscos morre com uma frase no briefing. “Cuidado que o dado dessa planilha está desatualizado desde março.” “Esse endpoint tem rate limit, então não rode em loop.” Você já sabia disso. A pessoa não.
O checklist de como delegar
- O que essa pessoa já sabe? O que é novo para ela?
- Por que estamos fazendo isso?
- O que a pessoa precisa para fazer isso?
- Como é a versão boa disso?
- Qual o prazo e a prioridade?
- O que tem mais chance de dar errado? O que dá para fazer agora para evitar?
Como delegar na prática
Na prática cabe num pedido só. Segue um real, com as seis respostas dentro:
Contexto: você já mexeu no GitLab CI desse repo, mas nunca no cache de
camada da imagem Docker daqui (o das camadas, não o cache: do GitLab).
É onde eu acho que está o problema.
Objetivo: o build subiu de 4 para 12 minutos por volta do merge da
semana passada. Queria entender de onde vem esse tempo. O pipeline já
está verde, então não é caso de consertar nada ainda, é de achar a
causa. Está atrapalhando o ciclo de review do time.
Você vai precisar: já te dei acesso de reporter no repo, que é o
suficiente para ler pipeline e log. Os logs das últimas 20 pipelines e o
.gitlab-ci.yml do commit anterior ao merge estão no anexo.
Como é a versão boa: um comentário na issue #142 apontando o estágio que
engordou e o motivo. Não precisa da correção ainda, só do diagnóstico.
Prazo: até quinta. Se passar de meio dia de trabalho, me avisa, porque
aí o escopo é outro.
Cuidado: não rode o pipeline em loop para testar, o runner é
compartilhado com o time de dados.Seis respostas, e é assim que como delegar cabe numa mensagem só. Menos tempo do que você gastaria respondendo a primeira mensagem de dúvida que ia chegar sem elas.
E se o novato for você
Boa parte do meu tempo eu passo do lado que recebe. O briefing chega pela metade, e esperar que ele melhore sozinho nunca funcionou comigo.
O que funciona é devolver as seis perguntas em forma de pergunta. Você faz o trabalho que quem delegou não fez, só que faz junto com a pessoa, enquanto ainda é barato. Quem sabe como delegar reconhece o briefing incompleto mais cedo.
| Pergunta do briefing | O que eu pergunto |
|---|---|
| O que eu já sei | “Meu entendimento é que isso funciona assim. Onde eu estou errado?” |
| Por que estamos fazendo isso | “Que decisão depende desse resultado?” |
| O que eu preciso | “Que acesso, arquivo ou pessoa eu vou precisar antes de começar?” |
| Como é a versão boa | “Tem algum caso que ficou do jeito que você quer?” |
| Prazo e prioridade | “Isso vence antes ou depois do que eu já estou tocando?” |
| O que pode dar errado | “Onde alguém já se queimou nessa tarefa?” |
Repare na primeira linha. Colocar o seu entendimento na mesa rende mais do que pedir “pode explicar?”. Quem te orienta corrige um ponto específico, em vez de repetir tudo do zero.
Junte as dúvidas num bloco só e mande de uma vez. Pergunta pingada custa o mesmo dia de espera que o briefing incompleto ia custar.
Depois das respostas, eu escrevo de volta o que entendi, em cinco linhas. Se o meu resumo estiver torto, o erro aparece ali, e não no dia da entrega.
Quando a tarefa é nova demais para eu saber o que perguntar, peço meia hora para olhar o material e volto com a lista. Chute de pergunta gasta o tempo de quem está orientando.
Prefiro perguntar cedo e passar por lento a entregar rápido a coisa errada. Perguntar tem custo visível, refazer tem custo escondido, e é o escondido que estoura o prazo.
E quando quem recebe a tarefa é uma IA
Como delegar para uma IA usa as mesmas seis perguntas, quase sem tradução:
- O que ela já sabe vira o contexto que você cola junto: stack, versões, decisões anteriores, o que já foi tentado
- Por que estamos fazendo isso vira o objetivo real, não o passo que você imaginou
- O que ela precisa vira acesso: arquivos, documentação, ferramentas, saída de comando
- Como é a versão boa vira exemplo de saída esperada, formato, um trecho de código no estilo que você quer
- Prazo e prioridade viram escopo: uma correção pontual ou um refactor completo
- O que pode dar errado vira restrição explícita: não mexa nesses arquivos, não instale dependência nova, não altere o schema
A diferença está no que acontece quando falta contexto. O agente até pergunta, se você configurar ele para perguntar. Mas o comportamento padrão é preencher a lacuna sozinho, com confiança, e você só descobre no code review.
O que o checklist não cobre
A lista é o começo do trabalho, não o ciclo inteiro. Quem é o dono da tarefa depois que você mandou o pedido, quem revisa, o que conta como pronto, como a pessoa escala um bloqueio. Isso é outra conversa. As seis perguntas resolvem o briefing. O acompanhamento vem depois.
Mas o briefing é onde a maior parte do retrabalho nasce.
O checklist existe para você parar de acreditar que “explicar demora demais”. Aprender como delegar é aceitar pagar esse custo visível uma vez.
Explicar demora uma vez. Não explicar demora todas as vezes.
Deixe um comentário