Testar grátis
6 min leitura Guide 136 of 877

Configurando Rotações On-Call Times Desenvolvimento

Responsabilidades on-call frequentemente caem desigualmente em developers senior, levando a burnout e ressentimento. Uma rotação bem estruturada distribui a carga justamente, fornece paths escalação claros, e compensa tempo on-call apropriadamente—para que times possam responder a incidentes sem sacrificar tempo pessoal ou compromissos sprint.

O Problema On-Call

Por Que Rotações Falham

DISFUNÇÃO ON-CALL:
┌─────────────────────────────────────────────────────────────┐
│ FALHAS COMUNS ON-CALL                                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ PADRÃO "HERÓI":                                             │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ "Sarah conhece melhor o sistema, ela deveria lidar"     ││
│ │                                                         ││
│ │ Resultado após 6 meses:                                 ││
│ │ • Sarah está exausta                                    ││
│ │ • Ninguém mais aprendeu o sistema                       ││
│ │ • Sarah sai da empresa                                  ││
│ │ • Time entra em pânico                                  ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
│ PADRÃO "TODOS O TEMPO TODO":                                │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ "Todos compartilhamos on-call, então todos sempre on-call"││
│ │                                                         ││
│ │ Resultado:                                              ││
│ │ • Ninguém se sente verdadeiramente desconectado         ││
│ │ • Alertas são ignorados (alguém vai pegar)              ││
│ │ • Confusão durante incidentes                           ││
│ │ • Sem accountability                                    ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
│ PADRÃO "CARGA INVISÍVEL":                                   │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ On-call acontece mas não é rastreado ou compensado      ││
│ │                                                         ││
│ │ Resultado:                                              ││
│ │ • Developers ressentem estar "sempre disponíveis"       ││
│ │ • Trabalho fora horário não reconhecido                 ││
│ │ • Compromissos sprint sofrem                            ││
│ │ • Equilíbrio vida-trabalho se erode                     ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
└─────────────────────────────────────────────────────────────┘

Estrutura Rotação

Projetando Rotações Justas

DESIGN ROTAÇÃO:
┌─────────────────────────────────────────────────────────────┐
│ CRIANDO ON-CALL EQUITATIVO                                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ PADRÕES ROTAÇÃO:                                            │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Opção A: Rotação semanal                                ││
│ │                                                         ││
│ │ Sem 1: Developer A (primário), Developer B (backup)     ││
│ │ Sem 2: Developer B (primário), Developer C (backup)     ││
│ │ Sem 3: Developer C (primário), Developer D (backup)     ││
│ │ Sem 4: Developer D (primário), Developer A (backup)     ││
│ │                                                         ││
│ │ Pros: Previsível, contexto completo para semana         ││
│ │ Cons: Períodos longos estando "ativo"                   ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Opção B: Divisão dias úteis/fim de semana               ││
│ │                                                         ││
│ │ Sem 1 Dias úteis: Developer A                           ││
│ │ Sem 1 Fim semana: Developer B                           ││
│ │ Sem 2 Dias úteis: Developer B                           ││
│ │ Sem 2 Fim semana: Developer C                           ││
│ │                                                         ││
│ │ Pros: Períodos on-call mais curtos                      ││
│ │ Cons: Mais handoffs, perda contexto                     ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
│ TAMANHO MÍNIMO TIME PARA ON-CALL SUSTENTÁVEL:               │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 4+ developers: Rotação semanal com backup               ││
│ │ 6+ developers: Divisão dias úteis/fim semana viável     ││
│ │ 8+ developers: Múltiplos tiers on-call possível         ││
│ │                                                         ││
│ │ Abaixo 4: Considerar on-call compartilhado outro time   ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
└─────────────────────────────────────────────────────────────┘

Implementação GitScrum

Rastreando On-Call no Seu Workflow

TRACKING ON-CALL:
┌─────────────────────────────────────────────────────────────┐
│ TORNANDO ON-CALL VISÍVEL                                    │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ SCHEDULE ROTAÇÃO (NoteVault):                               │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ # Q1 2025 Schedule On-Call                              ││
│ │                                                         ││
│ │ | Semana   | Primário| Backup  | Notas              |   ││
│ │ |----------|---------|---------|--------------------│   ││
│ │ | Jan 6-12 | Sarah   | Mike    |                    │   ││
│ │ | Jan 13-19| Mike    | Alex    |                    │   ││
│ │ | Jan 20-26| Alex    | Emma    |                    │   ││
│ │ | Jan 27-2 | Emma    | Sarah   | Emma PTO Feb 1     │   ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
│ TRACKING TAREFAS INCIDENTE:                                 │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Quando incidente ocorre, criar tarefa:                  ││
│ │                                                         ││
│ │ Título: [INCIDENTE] Descrição breve                     ││
│ │                                                         ││
│ │ Labels:                                                 ││
│ │ tipo/incidente                                          ││
│ │ severidade/p1 (ou p2, p3)                               ││
│ │ on-call/janeiro-semana-2                                ││
│ │                                                         ││
│ │ Detalhes:                                               ││
│ │ - Hora detectado: 2:34 AM                               ││
│ │ - Hora acknowledged: 2:38 AM                            ││
│ │ - Hora resolvido: 3:15 AM                               ││
│ │ - Engenheiro on-call: Mike                              ││
│ │ - Tempo total on-call: 41 min                           ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
└─────────────────────────────────────────────────────────────┘

Paths Escalação

Estrutura Escalação Clara

DESIGN ESCALAÇÃO:
┌─────────────────────────────────────────────────────────────┐
│ SABER PARA QUEM LIGAR                                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ ESCALAÇÃO POR NÍVEIS:                                       │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ NÍVEL 1: Primário on-call (0-15 min)                    ││
│ │ • Primeiro respondedor                                  ││
│ │ • Triageia e tenta resolução                            ││
│ │ • Escala se não pode resolver em 15 min                 ││
│ │                                                         ││
│ │ NÍVEL 2: Backup on-call (15-30 min)                     ││
│ │ • Entra se primário não pode resolver                   ││
│ │ • Fornece contexto/expertise adicional                  ││
│ │ • Escala se não pode resolver em 30 min                 ││
│ │                                                         ││
│ │ NÍVEL 3: Lead engenharia (30+ min)                      ││
│ │ • Apenas incidentes maiores                             ││
│ │ • Coordena resposta multi-time                          ││
│ │ • Aprova rollbacks/mudanças maiores                     ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
└─────────────────────────────────────────────────────────────┘

Compensação e Recuperação

Reconhecendo Carga On-Call

MODELOS COMPENSAÇÃO:
┌─────────────────────────────────────────────────────────────┐
│ TRATAMENTO JUSTO PARA ON-CALL                               │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ COMPENSAÇÃO BASEADA TEMPO:                                  │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Opção A: Folga compensatória                            ││
│ │ • 4 horas folga por cada incidente noturno              ││
│ │ • 8 horas folga por incidentes fim semana               ││
│ │                                                         ││
│ │ Opção B: Estipêndio on-call                             ││
│ │ • Quantia fixa por semana on-call                       ││
│ │ • Bônus adicional por incidente                         ││
│ │                                                         ││
│ │ Opção C: Carga sprint reduzida                          ││
│ │ • Semana on-call = 70% capacidade sprint                ││
│ │ • Buffer para resposta incidentes                       ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
└─────────────────────────────────────────────────────────────┘

Soluções Relacionadas