Um profissional alocado que participa só da daily recebe tarefas, mas não recebe contexto. Ele sabe o que fazer hoje, mas não sabe por que aquilo importa, o que foi descartado na planning ou o que o usuário reclamou na review. Sem esse contexto, ele entrega exatamente o que foi pedido, mesmo quando o pedido não resolvia o problema.
Isso costuma acontecer sem que ninguém decida. O convite da retrospectiva não foi enviado, o canal de arquitetura é “só para o time interno”, o 1:1 fica para depois. Em poucas semanas você tem um time de duas camadas, e a camada de fora entrega menos. A boa notícia é que resolver isso depende quase só de você.
O princípio: mesmos rituais, mesmos canais, mesmas regras
Na Devgo, todo profissional alocado trabalha em regime full-time e 100% dedicado ao seu time. Então trate como parte do time. Na prática, o teste é simples: se você tirasse o crachá de todo mundo, daria para dizer quem é alocado só olhando a agenda e os canais? Se sim, algo está fora do lugar.
A única diferença legítima é a relação contratual. Assuntos de contrato, carreira e remuneração passam pelo parceiro de alocação. Todo o resto, do trabalho técnico às decisões de produto, é igual.
Como incluir o alocado em cada ritual
Daily
Ele fala como qualquer outra pessoa: o que fez, o que vai fazer, o que está travando. Fique atento ao alocado que sempre diz “sem impedimentos”. Às vezes é verdade. Às vezes ele ainda não se sente à vontade para expor um bloqueio na frente do time. Pergunte no 1:1.
Planning
É onde o time discute prioridade, capacidade e trade-offs. O alocado precisa estar para entender o objetivo da sprint e, sobretudo, para estimar o próprio trabalho. Estimativa feita por outra pessoa vira meta imposta, e meta imposta vira atraso sem dono.
Refinamento
Talvez o ritual mais subestimado. É onde as dúvidas técnicas aparecem antes de virarem retrabalho. Um sênior alocado costuma ter visto o mesmo problema em outros contextos. Se ele não está no refinamento, você perde justamente a experiência que contratou.
Review
Quem construiu apresenta. Mostrar o próprio trabalho para quem usa gera responsabilidade sobre o resultado, e não só sobre a tarefa. Também é onde o alocado escuta o negócio sem filtro.
Retrospectiva
Os problemas de processo que atingem o alocado atingem todo o time: ambiente lento, requisitos mudando no meio da sprint, revisão demorada. Garanta que a retro seja um espaço seguro para ele falar. Nas primeiras, vale o facilitador chamar a opinião dele diretamente.
1:1
O gestor direto faz 1:1 com o alocado na mesma cadência que faz com o resto do time. É o espaço para prioridade, feedback sobre o trabalho e bloqueios que não cabem na daily. O parceiro de alocação faz o acompanhamento dele em paralelo, sem substituir o seu.
Canais de comunicação e ferramentas
Ritual é só uma parte. Boa parte das decisões acontece fora deles, em threads e conversas rápidas. Confira:
- Ele está nos mesmos canais de chat do time, inclusive os técnicos e os de incidente?
- Tem acesso ao mesmo board, à mesma wiki e aos mesmos documentos de decisão?
- Está na escala de plantão, se o time tiver uma, com as mesmas regras?
- Recebe os e-mails e convites de eventos internos relevantes, como apresentações de resultado ou de roadmap?
- Pode aprovar pull requests e fazer deploy, dentro das mesmas políticas dos outros?
Cada “não” nessa lista é uma decisão que vai acontecer sem ele.
O que muda em times remotos ou híbridos
Com parte do time remoto, o risco de o alocado ficar de fora aumenta. A conversa de corredor não chega até ele. Algumas regras ajudam:
- Se uma pessoa está remota, todos entram pela chamada. Reunião meio presencial, meio remota, deixa quem está do outro lado da tela como ouvinte.
- Decisão tomada, decisão escrita. Um resumo curto no canal do time depois de qualquer conversa que mudou algo.
- Pauta antes, fala distribuída. Rituais com pauta publicada com antecedência e um facilitador que garante que todos falem.
- Horário de sobreposição combinado. Se houver diferença de fuso, defina as horas em que todos estão disponíveis e concentre os rituais nelas.
Para times em fusos diferentes, o artigo sobre rituais com time em outro fuso detalha como adaptar a cadência.
Responsabilidades de quem gerencia
Integrar o alocado não acontece sozinho. Alguém precisa ser dono disso, e normalmente é o gestor direto ou o tech lead.
Checklist do gestor
- Todos os convites de rituais enviados antes do primeiro dia.
- Acesso aos mesmos canais, ferramentas e documentos do time.
- 1:1 agendado na mesma cadência dos demais.
- O alocado estima o próprio trabalho na planning.
- Pelo menos uma apresentação dele na review no primeiro mês.
- Opinião dele pedida diretamente nas primeiras retrospectivas.
- Um canal claro com o parceiro de alocação para assuntos de contrato.
Erros comuns
- Convidar só para a daily. É o erro mais frequente e o que mais custa em retrabalho.
- Canal paralelo para alocados. Criar um grupo separado “para facilitar” cria, na prática, um time de segunda classe.
- Decisões técnicas sem ele. Chamar o alocado para executar uma arquitetura que ele não ajudou a desenhar.
- Retro sem segurança. Pedir opinião sincera na frente de quem decide a continuidade do contrato, sem deixar claro que a retro não é avaliação.
- Delegar a integração ao parceiro. O parceiro acompanha, mas quem inclui no dia a dia é o time.
Como a Devgo trabalha os rituais
No Squad as a Service, o time completo (devs, QA, design, PM, PO) chega com rituais rodando desde a primeira sprint. Na alocação individual, o profissional entra nos rituais que já existem no seu time, e um agente Devgo acompanha a integração no dia a dia, sinalizando cedo quando ele está ficando de fora de alguma conversa.
Quando falta liderança para conduzir os rituais, a Devgo também aloca tech leads, PMs e POs 100% dedicados. Parte da razão de mais de 95% dos profissionais seguirem alocados é justamente essa: gente que trabalha com o time, não para o time.
Se o profissional alocado não está nos rituais e nos canais, ele trabalha para o time, mas não com o time.
