daily como dev junior: como dar update sem parecer perdido

Daily parece uma reunião pequena, quase boba. Três perguntas, alguns minutos, todo mundo falando rápido. Mas para dev junior ela pesa mais do que parece.

É na daily que o time percebe se você está avançando, travado, perdido, escondendo bloqueio ou pedindo ajuda do jeito certo. Não porque daily seja uma prova pública. Ela não deveria ser. Mas, no começo da carreira, muita confiança nasce de sinais pequenos repetidos: você aparece, fala com clareza, não inventa progresso, não some e avisa problema antes de virar atraso.

O erro é tratar daily como teatro. Tem junior que fala demais para parecer ocupado. Tem junior que fala de menos para não parecer perdido. Os dois caminhos geram ruído.

Daily boa é curta, concreta e honesta.

a daily não é relatório para se defender

Muita gente entra na daily achando que precisa provar valor todo dia. Aí transforma uma atualização simples em justificativa longa:

Ontem eu fiquei olhando aquele bug, mas aí tinha umas coisas estranhas no ambiente, e eu tentei várias abordagens, só que a API estava meio diferente, então ainda não consegui terminar, mas acho que hoje vai.

Isso cansa o time e ainda deixa a situação menos clara.

Daily não precisa explicar cada minuto do seu dia. Ela precisa responder quatro coisas:

1. o que mudou desde a última daily;
2. o que você vai fazer agora;
3. se existe bloqueio real;
4. se alguém precisa agir para você destravar.

Essa é a régua. O resto é detalhe para thread, PR, pareamento ou conversa depois da reunião.

use o formato ontem, hoje, bloqueio, próximo sinal

O formato clássico funciona, mas junior precisa de uma quarta linha: próximo sinal.

Ontem: consegui reproduzir o erro no cadastro e identifiquei que acontece só quando o telefone vem vazio.
Hoje: vou ajustar a validação e adicionar um teste para esse caso.
Bloqueio: nenhum agora.
Próximo sinal: abro PR até o fim da tarde ou aviso no canal se o teste expuser outro caso.

Essa última frase é poderosa porque reduz ansiedade. O time não precisa adivinhar quando vai ouvir de você de novo.

Se existe bloqueio:

Ontem: avancei na integração até a chamada da API externa.
Hoje: consigo escrever o teste local, mas não consigo validar o fluxo completo.
Bloqueio: meu token de sandbox retorna 403.
Próximo sinal: já pedi acesso no canal #infra; se não liberar até 14h, vou combinar com a Ana um teste usando o ambiente dela.

Repare que isso não é drama. É operação.

não diga “sem bloqueio” se você está travado

O pior hábito de junior em daily é falar “sem bloqueio” quando está bloqueado de verdade.

Às vezes a pessoa faz isso por vergonha. Às vezes porque acha que bloqueio só conta quando depende de acesso ou decisão externa. Mas travar tecnicamente também pode ser bloqueio, especialmente se você já tentou o suficiente e não sabe o próximo passo.

Bloqueio não é confissão de incompetência. Bloqueio é informação de planejamento.

Compare:

Ruim: sem bloqueios, vou continuar vendo.

Melhor: estou travado na reprodução do bug. Já testei com usuário novo e usuário antigo, mas ainda não consigo gerar o erro do ticket. Vou tentar mais 30 minutos; se não reproduzir, peço ajuda para alguém que conhece esse fluxo.

A segunda resposta mostra autonomia e limite. Você não está jogando o problema no colo do time. Está dizendo: tentei, tenho hipótese, tenho prazo para pedir ajuda.

Se você está no remoto, isso vale em dobro. O guia de trabalho remoto para junior bate nessa tecla porque o time não vê sua cara de dúvida. No remoto, bloqueio invisível vira atraso visível.

fale de resultado, não só de atividade

“Estudei o projeto” é atividade. “Entendi o fluxo de login e rodei o backend local” é resultado.

“Mexi no ticket” é atividade. “Reproduzi o bug e descobri que quebra quando o campo phone vem nulo” é resultado.

“Vou continuar vendo” é atividade vaga. “Vou adicionar o teste do caso nulo e depois ajustar a validação” é plano.

Daily fica muito melhor quando você troca verbos genéricos por evidências pequenas:

• em vez de “estudei”, diga o que entendeu;
• em vez de “mexi”, diga o que mudou;
• em vez de “vou ver”, diga qual próxima ação;
• em vez de “está difícil”, diga onde travou;
• em vez de “acho que termino”, diga qual sinal vai confirmar.

Isso não é burocracia. É como você mostra progresso quando a entrega ainda não fechou.

quando a tarefa durou vários dias

Todo junior passa por uma task que demora mais do que parecia. O problema não é durar. O problema é dar a mesma daily três dias seguidos:

Ontem continuei na task X. Hoje vou continuar. Sem bloqueio.

No terceiro dia, isso soa como sumiço com microfone ligado.

Se a tarefa atravessou mais de uma daily, mostre mudança de estado:

Ontem eu ainda estava tentando entender o fluxo. Hoje já sei que a mudança fica no serviço de cobrança, não no frontend. Falta validar o caso de usuário sem cartão. Se eu não fechar essa validação até 15h, vou pedir pareamento.

Ou:

Ontem o PR voltou com comentário sobre teste. Hoje vou ajustar o teste de integração e responder os comentários. Sem bloqueio, mas vou avisar no PR quando terminar para facilitar o novo review.

O time precisa ver movimento. Movimento não é só merge. Movimento também é hipótese descartada, bug reproduzido, escopo reduzido, teste escrito, dúvida esclarecida.

peça ajuda fora da daily também

Daily não deve ser o único lugar onde você pede ajuda. Se você travou às 10h, não espere a daily do dia seguinte para contar.

Use uma regra simples:

Tente por 20 a 40 minutos.
Registre o que tentou.
Formule uma hipótese.
Peça ajuda com contexto.

Mensagem boa:

Estou tentando reproduzir o bug 234 no cadastro.

O que tentei:
- usuário novo sem telefone
- usuário antigo com telefone vazio
- payload direto pela API

Resultado: nenhum caso gera o erro do ticket.

Minha hipótese é que falta alguma flag de conta paga. Alguém sabe qual cenário ativa esse fluxo?

Essa mensagem é diferente de “alguém me ajuda?”. Ela respeita o tempo do time e deixa mais fácil alguém responder.

O guia de primeira semana como dev junior usa a mesma lógica para setup local: contexto, tentativa, hipótese, pergunta específica. Daily é só mais um lugar onde essa maturidade aparece.

adapte o tom ao time

Nem toda daily é igual. Tem time que faz standup síncrona em chamada. Tem time que manda update assíncrono no Slack. Tem time que usa bot. Tem time que mistura produto, design e engenharia. Tem time que fala só impedimento.

Observe o padrão antes de tentar inventar estilo próprio.

Pergunte ao seu buddy ou gestor:

Nas dailies daqui, vocês preferem update bem curto ou vale dar um pouco mais de contexto quando tem bloqueio?

Essa pergunta parece pequena, mas evita dois erros: falar demais em time que quer só sinal rápido, ou falar de menos em time remoto que precisa de contexto escrito.

Se o time faz daily assíncrona, capriche um pouco mais no texto. Ele vira registro. Se faz chamada ao vivo, fale curto e coloque detalhes no canal depois.

cuidado com três vícios

O primeiro vício é pedir desculpa demais:

Desculpa, ainda não consegui terminar, foi mal, acho que talvez hoje eu consiga.

Troque por responsabilidade objetiva:

Ainda não terminei. Subestimei a validação do caso X. Hoje vou reduzir escopo para fechar o caso principal e aviso se precisar separar o restante.

O segundo vício é parecer confiante sem estar:

Está tudo certo, termino hoje.

Se você não sabe, diga o que falta saber:

Ainda não sei se termino hoje. Falta validar o caso de permissões. Dou um update até 15h com estimativa melhor.

O terceiro vício é transformar daily em pedido de aprovação emocional:

Não sei se fiz do jeito certo, mas tentei, espero que esteja ok.

Prefira pergunta verificável:

Implementei seguindo o padrão do arquivo X. No PR, queria confirmação se esse padrão também vale para o fluxo novo.

um roteiro pronto para copiar

Use este modelo quando estiver começando:

Ontem:
- [resultado concreto]

Hoje:
- [próxima ação concreta]

Bloqueio:
- [nenhum / acesso / decisão / dúvida técnica específica]

Próximo sinal:
- [quando e onde vou atualizar]

Exemplo:

Ontem:
- rodei o projeto local e reproduzi o erro do ticket 234
- descobri que acontece só para usuário sem telefone

Hoje:
- vou ajustar a validação e cobrir com teste

Bloqueio:
- nenhum agora

Próximo sinal:
- abro PR até 16h ou aviso antes se o teste mostrar outro caso

Não precisa falar bonito. Precisa deixar o time menos no escuro.

a régua certa

Daily boa para dev junior não é a mais impressionante. É a que dá previsibilidade.

O time precisa conseguir responder:

• você está avançando?
• você sabe o próximo passo?
• existe bloqueio?
• alguém precisa ajudar?
• quando vem o próximo sinal?

Se sua daily responde isso, você está fazendo bem.

No primeiro emprego, reputação não nasce de discurso grande. Nasce de repetição pequena: update claro, bloqueio cedo, pergunta com contexto, PR pequeno, review respondido sem ego. O guia de primeiros 30 dias como dev junior aprofunda esse ciclo. Daily é uma das peças mais simples, e por isso mesmo uma das mais fáceis de acertar antes dos outros perceberem.