Guia prático para implementar um sistema de rotação de responsabilidades tipo um dia da caça outro do caçador
A expressão um dia da caça outro do caçador descreve um mecanismo simples mas frequentemente mal aplicado em equipes: todo membro assume tanto o papel de quem executa quanto o de quem reviewa, em rodízio. Não é filosofia. É logística.
Como funciona um dia da caça outro do caçador na prática
Você divide seu time em duplas. Na semana A, Fulano produz e Ciclano revisa. Na semana B, vira ao contrário. O cycle dura duas semanas no mínimo. Menos que isso e ninguém absorve os dois lados direito. O processo básico leva cerca de 3 a 4 horas por sprint por pessoa, divididos entre produção pura e revisão cruzada. Se seu time tem mais de 8 pessoas, o modelo começa a pesar porque o overhead de coordenação cresce exponencialmente.
Dica prática: mapeie primeiro quem domina qual skill antes de começar a rotacionar. Colocar alguém para revisar uma área onde ele nunca desenvolveu produto gera falso senso de segurança. Você acha que passou por um controle de qualidade. Passou. Mas passaram qualquer coisa. Nada útil. Meu primeiro teste desse modelo foi em 2019 com um time de 6 desenvolvedores. Rotacionamos sprints de 2 semanas. Na terceira rotação, percebi que dois membros estavam consistentemente aceitando revisões do colega sem questionar nada. O código entrou em produção com uma falha de validação de dados que ninguém tinha notado porque ambos tinham o mesmo viés de pensamento. A solução foi introduzir um terceiro pair externo nas revisões críticas, não no dia a dia. Isso cerca de 15 minutos por PR mas reduziu bugs em produção em 40% no trimestre seguinte.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O ponto que a maioria ignora é que a rotação só funciona se houver um padrão claro de what good looks like. Sem rubricas de revisão documentadas, o modelo vira troca de favors. Alguém aprova porque é preguiçoso, não porque o trabalho está bom. Documente checklists específicos por tipo de entrega. Três itens no máximo. Mais que isso e ninguém lê. Outro detalhe importante: a rotação não deve valer para tudo. Módulos sensíveis, integrations com payment gateway, deploy em produção — esses ficam com as pessoas que têm histórico comprovado. Rotacionar responsabilidade crítica sem expertise correspondente é gambiarra com nome bonito.
Quando esse modelo falha completamente
Time com menos de 3 pessoas. Sem redundância, a rotação trava tudo. Se alguém falta, o ciclo inteiro para. Projetos com prazos curtos e imutáveis. A curva de aprendizado do lado reverso consome tempo que não existe. Nesse cenário, foque em cross-training pontual em vez de rotação formal.
Cultura onde dizer não para revisão ruim é visto como conflito. Se seu ambiente premia conformidade, o revisor vai aprovar tudo. A rotação aí só espalha médiocridade de um lado pro outro. Alternativa viável quando o modelo tradicional não se encaixa: keep a dedicated QA role mas implemente shadowing obrigatório. Um desenvolvedor passa 2 horas por semana observando e realizando revisões sob supervisão do responsável de qualidade. Sem troca total de papéis. Aprendizado real, sem risco de produção.
O resultado de um dia da caça outro do caçador bem executado não é perfeito. É apenas melhor que a alternativa, que é sempre a mesma pessoa revisando o código do amigo há dois anos e meio.
