After hours work é um dos sinais mais claros de que um squad está sob pressão, mas a maioria dos líderes de engenharia só percebe isso quando o burnout já aconteceu. After hours work são commits, atividade em pull requests ou atualizações de issues que ocorrem fora do horário padrão de trabalho de um player, geralmente antes das 9h ou depois das 18h em dias úteis, ou a qualquer momento nos fins de semana. Quando esse padrão se torna consistente no seu squad, geralmente aponta para um problema de processo: compromissos de sprint irreais, trabalho bloqueado se acumulando, ou pressão de deploy que força os players a recuperar o atraso no próprio tempo. Esta página cobre a definição, como medir, quais benchmarks indicam preocupação e o que líderes de engenharia podem fazer a respeito.
Principais conclusões
- After hours work é o percentual da atividade Git e de issues de um squad que ocorre fora do horário comercial padrão. Isso importa porque padrões sustentados de after hours se correlacionam com queda na qualidade do código, ciclos de revisão mais lentos e rotatividade, fatores que afetam diretamente a capacidade de entrega do seu time.
- After hours work é calculado como o número de eventos de engenharia (commits, aberturas de PR, revisões, atualizações de issues) fora do horário principal dividido pelo total de eventos, expresso como percentual. Não existe um benchmark universal, mas a maioria dos squads saudáveis vê atividade after hours abaixo de 15% do output semanal total. Taxas consistentemente acima de 25% justificam uma análise mais cuidadosa da distribuição de carga e da precisão do planejamento de sprint.
- O erro mais comum é tratar after hours work como sinal de dedicação em vez de sinal de processo. Taxas altas não são motivo de orgulho. Elas frequentemente indicam que o trabalho não está sendo concluído no horário normal por causa de bloqueios, escopo indefinido ou calibração ruim de sprint, e nenhum desses problemas se resolve com os players simplesmente trabalhando mais.
- O DevStats detecta padrões de after hours work automaticamente ao se conectar ao seu provedor Git e ao seu issue tracker, com heatmaps de atividade que mostram quando o trabalho está acontecendo no seu squad. Você pode comparar os padrões do seu squad com benchmarks de mais de 1.000 times de engenharia. Comece um trial gratuito e veja seus números em menos de dois minutos.
Definição de after hours work
After hours work é qualquer atividade de engenharia, incluindo commits, submissões de pull request, revisões de código ou atualizações no issue tracker, que ocorre fora do horário principal definido pelo time. Geralmente é medido como percentual do total de atividade: After hours work % = (eventos after hours / total de eventos) × 100.
Para squads distribuídos ou assíncronos, "after hours" é calculado em relação ao fuso horário local de cada player, não em uma janela global única. A métrica importa além da engenharia: padrões sustentados de after hours aumentam o risco de burnout, reduzem a retenção e sinalizam que seu processo de entrega tem problemas de capacidade ou priorização que vão acabar afetando seus compromissos de roadmap.
O activity heatmap do DevStats visualiza quando o trabalho está acontecendo no seu squad, facilitando identificar se os padrões de after hours são incidentes isolados ou um problema estrutural consistente.
Por que after hours work importa para times de engenharia
Quando squads trabalham regularmente fora do horário principal, os efeitos subsequentes são previsíveis e se acumulam. Código escrito sob fadiga gera mais defeitos. Pull requests submetidos tarde da noite ficam sem revisão até a manhã seguinte, aumentando o PR cycle time e desacelerando todo o pipeline de entrega. Se a taxa de after hours do seu squad está subindo e você não está medindo isso, provavelmente está perdendo o sinal precoce antes que vire um problema de retenção ou qualidade.
After hours work se conecta diretamente aos KPIs centrais do líder de engenharia. Taxas altas predizem compromissos de sprint não cumpridos, redução de throughput nos sprints seguintes enquanto os players se recuperam, e queda nas pontuações de satisfação em pesquisas de engajamento. Dentro do SPACE framework, after hours work é um proxy direto para a dimensão de "wellbeing", ao lado de satisfação e eficiência como medida de capacidade sustentável de engenharia.
Medir after hours work não diz o que fazer. Diz onde olhar. O líder de engenharia decide se a causa raiz é excesso de compromisso no sprint, trabalho não planejado, dependências bloqueadas ou outra coisa, e age conforme o diagnóstico.
Como medir after hours work
After hours work é calculado extraindo eventos de engenharia com timestamp do seu provedor Git e issue tracker, depois classificando cada evento como ocorrendo dentro ou fora do horário principal definido para o fuso horário de cada player. A fórmula é direta: After hours work % = (eventos fora do horário principal / total de eventos) × 100. Você define o horário principal por squad ou por indivíduo, e o cálculo roda sobre seus dados históricos de commit, PR e issue.
Nenhum benchmark publicado do DORA ou da pesquisa do SPACE cobre after hours work como métrica isolada. Os benchmarks variam por tamanho de time, obrigações de plantão e se o squad opera em um modelo follow-the-sun. A tabela abaixo reflete os níveis de sinal qualitativo usados por líderes de engenharia na prática. O recurso de benchmarks do DevStats permite comparar os padrões do seu squad com times similares.
| Nível de desempenho | Benchmark de after hours work | O que sinaliza |
|---|---|---|
| Saudável | Abaixo de 15% da atividade semanal | O trabalho está sendo concluído no horário principal; ritmo sustentável |
| Atenção | 15–25% da atividade semanal | Pressão pontual ou de prazo; monitore a tendência |
| Preocupante | 25–40% da atividade semanal | Sobrecarga estrutural provável; revisão de sprint ou carga necessária |
| Crítico | Acima de 40% da atividade semanal | Alto risco de burnout; intervenção imediata necessária |
Esses limites são guias qualitativos, não regras rígidas. Um squad com rotação de plantão planejada vai naturalmente mostrar taxas de after hours mais altas nas semanas de incidente. O contexto dos seus dados de sprint e das métricas de planning accuracy é essencial para interpretar o que o número realmente significa.
After hours work na prática: um exemplo real
Uma VP de Engenharia em uma empresa SaaS de 40 pessoas percebeu que a atividade after hours do seu squad de backend havia subido de 12% para 31% em seis semanas. Ela puxou os dados do activity heatmap e viu que o pico coincidia exatamente com o início de uma nova feature que havia sido incluída no escopo no meio do sprint sem remover nenhum trabalho existente. O squad não estava trabalhando com mais eficiência. Estava absorvendo escopo não planejado em cima do trabalho já comprometido, e fazendo isso no próprio tempo.
Ela conduziu uma retrospectiva focada especificamente em mudanças de escopo no sprint, introduziu uma política exigindo trocas formais de escopo para qualquer adição no meio do sprint, e estabeleceu como norma do squad não fazer revisões de PR depois das 19h no horário local. Nos dois sprints seguintes, a atividade after hours caiu de volta para 14%. Ela acompanhou a mudança usando produtividade e taxa de conclusão de sprint como indicadores defasados para confirmar que a intervenção se manteve.
Como reduzir after hours work
- Audite os compromissos de sprint em relação à velocidade histórica. Se o seu squad termina sprints consistentemente com trabalho incompleto, o compromisso está alto demais. Puxe os últimos seis sprints de dados de planning accuracy e recalibre as estimativas de pontos. Excesso de compromisso é o fator mais comum de after hours work.
- Implemente uma política de mudança de escopo no meio do sprint. Cada item não planejado adicionado a um sprint ativo deve exigir uma troca explícita: algo sai. Sem essa proteção, after hours work se acumula silenciosamente enquanto os players absorvem a diferença.
- Revise a profundidade da fila de revisão de PR no nível do squad. PRs sem revisão forçam os autores a fazer follow-up after hours ou retomar o trabalho tarde da noite. Monitorar o tempo de retorno de code review como indicador antecedente vai revelar gargalos antes que empurrem o trabalho para as noites.
- Verifique a alocação de trabalho em busca de sobrecarga oculta. Às vezes, after hours work não é sobre escopo de sprint. É sobre um player carregando alocação desproporcional em múltiplos squads ou iniciativas ao mesmo tempo. O DevStats mostra padrões de alocação para você ver onde existe risco de concentração.
- Defina normas explícitas de squad em relação a janelas de revisão assíncrona. Defina uma janela, por exemplo, das 9h às 17h no horário local, durante a qual revisões e respostas são esperadas. Players que trabalham em fusos horários diferentes devem ter seu horário principal documentado para que os limites de after hours sejam calculados corretamente.
After hours work vs. horas extras
After hours work e horas extras são conceitos relacionados, mas distintos: horas extras são uma categoria formal de RH e folha de pagamento, enquanto after hours work é um sinal comportamental medido a partir de dados de atividade de engenharia.
| After hours work | Horas extras | |
|---|---|---|
| Mede | Timestamps de atividade de engenharia fora do horário principal | Horas trabalhadas além do contratado, reportadas ao RH |
| Começa quando | Um commit, PR ou atualização de issue é registrado fora do horário principal | Um funcionário trabalha além do turno programado |
| Termina quando | A atividade retorna consistentemente às janelas de horário principal | As horas extras são registradas e fechadas na folha de pagamento |
| Melhor para | Identificar pressão de processo e problemas de distribuição de carga | Remuneração, compliance e planejamento de força de trabalho de RH |
Use dados de after hours work para diagnosticar a saúde do processo de entrega, e use dados de horas extras para decisões de remuneração e compliance. Eles respondem perguntas diferentes e não devem ser substituídos um pelo outro.