Como delegar sem retrabalho: 6 perguntas antes do pedido

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. 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, e 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 não é o tempo. É 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”.

O que resolveu isso pra mim foi um checklist. Seis perguntas que eu respondo pra mim mesmo antes de mandar o pedido. Não é sobre a outra pessoa, é sobre tirar o contexto da minha cabeça e colocar em palavras.

E tem um detalhe que mudou a minha relação com essa lista: ela funciona igual quando quem recebe a tarefa é um agente de IA. Prompt ruim e briefing ruim são o mesmo defeito.

Quando esse checklist serve

• 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.

O que essa pessoa já sabe? O que é novo para ela?

Essa é a pergunta que te tira do seu próprio ponto de vista.

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ê.

O efeito colateral é bom: você 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.

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.

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..."

Tem um bônus aqui. Saber onde a sua parte se encaixa no todo deixa qualquer tarefa mais interessante.

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.

Vale lembrar de uma coisa: 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.

Como é a versão boa disso?

Mostre, não descreva.

Mockup, screenshot, um documento antigo 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 antigo 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."

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.

Um combinado que ajuda: 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.

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

1. O que essa pessoa já sabe? O que é novo para ela?
2. Por que estamos fazendo isso?
3. O que a pessoa precisa para fazer isso?
4. Como é a versão boa disso?
5. Qual o prazo e a prioridade?
6. O que tem mais chance de dar errado? O que dá para fazer agora para evitar?

Como isso fica na prática

Parece muita coisa. Não é. Segue um pedido 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 e testes do time.

Você vai precisar: já te dei acesso de read 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. Menos tempo do que você gastaria respondendo a primeira mensagem de dúvida que ia chegar sem elas.

E quando quem recebe a tarefa é uma IA

Aqui as seis perguntas viram prompt quase sem tradução:

1. O que ela já sabe vira o contexto que você cola junto: stack, versões, decisões anteriores, o que já foi tentado
2. Por que estamos fazendo isso vira o objetivo real, não o passo que você imaginou
3. O que ela precisa vira acesso: arquivos, documentação, ferramentas, saída de comando
4. Como é a versão boa vira exemplo de saída esperada, formato, um trecho de código no estilo que você quer
5. Prazo e prioridade viram escopo: uma correção pontual ou um refactor completo
6. 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.

Um último ponto

Uma coisa que a lista não cobre, e vale dizer: ela é 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, e é a parte que quase ninguém faz.

O checklist não é burocracia. Ele existe para você parar de acreditar que “explicar demora demais”.

Explicar demora uma vez. Não explicar demora todas as vezes.