Home | Blog | Data study

Custo Real da Troca de Contexto: 5 Milhões de PRs GitHub

Sintetizamos dados de mais de 5 milhões de PRs para medir o custo real da troca de contexto para desenvolvedores – e não está onde você pensa.

By Ellis Keane · 2026-03-29

O custo da troca de contexto que a maioria dos artigos cita – 23 minutos para refocalizar após uma interrupção, da pesquisa de Gloria Mark na UC Irvine – é uma descoberta real de um estudo real. Mas ele mediu trabalhadores do conhecimento em geral em 2008, não engenheiros de software. E a indústria de blogs que multiplica 23 minutos por uma contagem estimada de interrupções diárias (geralmente entre 6 e 15, dependendo do humor do autor) para produzir alarmantes cifras anuais em dólares – sempre acompanhadas de uma foto stock de alguém segurando a cabeça – está fazendo algo que a pesquisa original nunca pretendeu.

Tenho um interesse pessoal nessa questão. Em uma empresa anterior, eu passei – e isso não é hipérbole – de 80 a 100 por cento de alguns dias sendo apenas um roteador humano. Não escrevendo código, não revisando-o. Roteando informações entre pessoas e ferramentas, porque nenhum sistema as conectava. Essa experiência é parte do motivo pelo qual construímos o Sugarbug, mas também é por isso que sou cético em relação às calculadoras padrão de custo de troca de contexto. Elas medem a interrupção. Não medem os dias em que você nunca chega ao que deveria ser interrompido.

Por isso, queríamos saber o que a troca de contexto realmente custa no trabalho de engenharia – não em termos abstratos de produtividade de desenvolvedores, mas medido no artefato que as equipes produzem diariamente: pull requests. Sintetizamos descobertas de três estudos em grande escala cobrindo mais de 5 milhões de PRs em milhares de projetos open source e verificamos o que realmente impulsiona o tempo de revisão de pull requests.

A principal descoberta: a troca de contexto mais cara não é a notificação do Slack que interrompe seu fluxo. É o pull request que fica em uma fila de revisão por um dia, forçando o autor a reconstruir todo um modelo mental quando as perguntas finalmente chegam.

Os Conjuntos de Dados Utilizados

Não construímos um scraper personalizado e analisamos 10.000 PRs de forma isolada. Sintetizamos descobertas de dois estudos revisados por pares e um grande conjunto de dados do setor, e depois verificamos suas conclusões entre si.

stat: "3,35 M" headline: "Pull requests analisados por Zhang et al." source: "Pull Request Latency Explained: An Empirical Overview (Empirical Software Engineering, 2022)"

Os três conjuntos de dados primários:

Zhang et al. (2022), revisado por pares: 3.347.937 PRs fechados em 11.230 projetos. Utilizou regressão linear de efeitos mistos para identificar o que causa atrasos de revisão em PRs. Publicado na Empirical Software Engineering.
Adadot (2023), conjunto de dados do setor: Mais de 300.000 PRs mesclados de ~30.000 desenvolvedores. Não revisado por pares, mas a amostra é grande e a metodologia (correlação tau de Kendall) é transparente. Focado em tamanho de PR vs. tempo de entrega.
Estudo de múltiplas revisões (2019), revisado por pares: 1.836.280 PRs em 760 projetos GitHub. Publicado em Information and Software Technology. Examina comportamento de revisão simultânea – um proxy direto para troca de contexto em revisão de código.

Cruzamos esses dados com o Relatório DORA State of DevOps 2024 e o Relatório de Experiência do Desenvolvedor da Atlassian 2024 (pesquisando mais de 2.100 desenvolvedores sobre troca de contexto, produtividade de desenvolvedores e o lado humano da equação).

A Fila é a Verdadeira Vilã

Zhang et al. descobriram que o tempo que leva para um PR receber sua primeira resposta – primeiro comentário, primeira revisão, qualquer coisa primeiro – explica 58,7% da variância no tempo de vida total do PR. Esse é o preditor mais forte observado no conjunto de dados – à frente do tamanho do PR, complexidade do código ou número de arquivos alterados! Nem de perto.

O maior custo da troca de contexto na revisão de código não é a própria troca – é a fila que se forma enquanto todos estão ocupados trocando de contexto entre outras coisas.

Pense no que isso significa na prática. Um engenheiro abre um PR às 10h. O revisor designado está mergulhado em seu próprio branch de funcionalidade, ou em uma reunião, ou triando mensagens do Slack (e, honestamente, provavelmente os três em sequência). O PR fica parado. No momento em que alguém o pega às 15h, o autor já passou para outra coisa completamente. Agora o revisor tem perguntas, o que significa que o autor precisa fazer uma troca de contexto de volta para o código que escreveu cinco horas atrás, reconstruir o modelo mental e responder. Essa resposta chega às 16h30, mas o revisor já foi embora.

O PR envelhece mais um dia.

Os dados sugerem que isso é mais um problema de enfileiramento do que de disciplina – e o custo de troca de contexto dessa fila se acumula de maneiras que as calculadoras de interrupção perdem completamente.

PRs Pequenos Não Vão te Salvar

Você já ouviu isso antes: PRs menores são revisados mais rápido, então mantenha seus PRs pequenos. Isso não está errado, exatamente, mas o tamanho do efeito é (genuinamente) menor do que você esperaria.

A análise da Adadot de mais de 300.000 PRs encontrou uma correlação tau de Kendall de apenas 0,06 entre tamanho do PR e tempo de entrega – uma associação fraca, embora o estudo não tenha relatado intervalos de confiança para o valor agregado. PRs com menos de 100 linhas têm aproximadamente 80% de probabilidade de conclusão em uma semana, o que soa ótimo até você perceber que essa é a mesma taxa de conclusão de um PR que ficou seis dias na fila de revisão de alguém!

stat: "0,06" headline: "Correlação entre tamanho do PR e tempo de entrega" source: "Análise da Adadot de mais de 300.000 PRs de ~30.000 desenvolvedores (2023)"

A descoberta mais interessante: essa correlação variou muito entre organizações, variando de 0,1 a quase 0,7 dependendo da empresa. O que sugere que o tamanho do PR não é inerentemente o gargalo – a cultura e o processo de revisão em torno do PR são. Uma equipe com uma cadência de revisão forte pode lidar eficientemente com PRs maiores. Uma equipe onde as revisões são uma reflexão tardia vai ter dificuldades com PRs de qualquer tamanho.

O limiar de 400 linhas do estudo de revisão de código SmartBear/Cisco se mantém como uma heurística útil – os dados da Adadot também descobriram que o engajamento na revisão cai além desse intervalo. Mas otimizar para PRs pequenos sem corrigir a cadência de revisão subjacente é – e digo isso com genuíno carinho por todo gerente de engenharia que já tentou – reorganizar as cadeiras do convés.

Todos Estão Revisando Tudo ao Mesmo Tempo

O estudo de múltiplas revisões descobriu que 62% dos pull requests envolvem desenvolvedores que estão simultaneamente revisando múltiplos PRs. Mais importante, encontraram uma correlação estatisticamente significativa: mais revisões simultâneas por revisor estava associado a maior latência de resolução de PR.

62% dos pull requests envolvem desenvolvedores revisando simultaneamente múltiplos PRs – e a múltipla revisão correlaciona diretamente com tempos de resolução mais longos. attribution: Estudo de múltiplas revisões de pull requests, 1,8 milhão de PRs em 760 projetos

O mecanismo é intuitivo (mesmo que o estudo, sendo observacional, não prove a direção da causalidade). Um revisor pega o PR nº 1, lê o diff, começa a formar um modelo mental do que o código está tentando fazer. Então chega uma notificação – o PR nº 2 precisa de revisão porque está bloqueando um deploy. O revisor muda. Quando volta ao PR nº 1, precisa reler metade do diff porque o modelo mental decaiu.

Escale isso para uma equipe de oito engenheiros, cada um com dois ou três PRs abertos, cada um revisando para dois ou três colegas, e a sobrecarga de coordenação começa a se explicar. Separadamente, o Relatório DORA 2024 descobriu que o cluster de "alto desempenho" encolheu de 31% para 22% enquanto o cluster de baixo desempenho cresceu de 17% para 25%. O DORA não isola a simultaneidade de revisão de PR como um fator, mas o aumento da sobrecarga de coordenação é um contribuidor plausível para essa mudança.

O Que as Estimativas de Custo de Troca de Contexto Erram

Deixe-me ser direto sobre a cifra de "R$50.000 por desenvolvedor por ano" que circula amplamente nos artigos sobre custo de troca de contexto. A metodologia por trás da maioria dessas estimativas é: pegue os 23 minutos de refoco, multiplique pelas interrupções diárias estimadas (geralmente entre 6 e 15, dependendo de quão dramático o autor está se sentindo), multiplique por uma taxa horária de desenvolvedor, e anualise.

O problema não é que a matemática esteja errada. O problema é que trata todas as trocas de contexto como equivalentes. Mudar de codificação profunda para uma mensagem do Slack perguntando onde é o almoço da equipe – isso é uma troca de contexto. Mudar de revisar um PR para revisar um PR diferente em uma base de código completamente diferente – isso também é uma troca de contexto. Mas o custo cognitivo não é nem remotamente comparável, e nivelá-los em uma única taxa horária obscurece onde o dano real acontece.

Para colocar concretamente: no meu último emprego, um dia típico significava alternar entre Notion, Linear, Mattermost, Proton Mail, Proton Calendar, Discord, Twitter, Farcaster e inúmeros canais do Telegram e Signal – e tenho certeza que estou esquecendo meia dúzia. Agora uso alguns poucos (Signal, Obsidian, Figma, GitHub, e-mail, calendários). O custo por troca não mudou. O que mudou foi quantos contextos estavam concorrendo por atenção – e quais deles realmente importavam.

Os dados de PR sugerem que as trocas caras são as que criam filas, não as que interrompem o fluxo. Um desenvolvedor que recebe um ping para revisar um PR imediatamente (em minutos) e faz uma revisão rápida de 50 linhas – essa é uma curta interrupção com alto retorno. Um desenvolvedor que enfileira essa solicitação de revisão junto com quatro outras e chega a isso amanhã – essa é uma interrupção mais longa para o revisor, mas cria um custo muito maior para o autor e a equipe.

O que as calculadoras de custo medem

Interrupções individuais – com que frequência o fluxo de alguém é quebrado
Tempo de refoco – quanto tempo para voltar à tarefa anterior
Multiplicação da taxa horária – grandes e assustadores números anuais

O que os dados de PR realmente mostram

Formação de fila – PRs aguardando primeira resposta
Simultaneidade de revisão – revisores lidando com múltiplos PRs
Atrasos em cascata – trocas de contexto do autor compondo atrasos do revisor

O Que Isso Significa para Sua Equipe

Se você está tentando reduzir o custo de troca de contexto para os desenvolvedores da sua equipe, a resposta prática é chata – o que provavelmente explica por que não se escreve muito sobre ela. Não é uma ferramenta. Não é um framework de processo com um programa de certificação. É cadência de revisão. (Eu sei, eu sei. Ninguém nunca foi promovido por melhorar a cadência de revisão.)

Os benchmarks de engenharia da LinearB para 2025, extraídos de 6,1 milhões de PRs em 3.000 organizações, descobriram que as equipes que alcançam tempos de ciclo de elite (abaixo de 2,5 dias) compartilhavam uma característica: revisavam PRs rapidamente. Não porque tinham menos PRs, ou porque seus PRs eram menores (embora frequentemente fossem), mas porque responder a solicitações de revisão em horas era uma norma de equipe, não uma reflexão tardia.

Para constar, Ben e eu – uma equipe de duas pessoas – temos média de minutos na primeira resposta a PRs, não horas. Isso não é exibição de disciplina (não somos assim). É um acordo de equipe: solicitações de revisão são a única notificação que você não enfileira. Ações de CI e testes automatizados lidam com as verificações mecânicas, o que significa que a revisão humana – a parte que requer contexto real – é mais curta e acontece imediatamente. O acordo veio primeiro. As ferramentas apenas o tornaram sustentável.

Na prática, isso significa:

Meça o tempo para a primeira resposta, não apenas o tempo de ciclo. Se você está acompanhando métricas DORA, adicione esta. É o preditor mais forte de throughput de PR (explicando 58,7% da variância do tempo de vida, segundo Zhang et al.).

Limite a simultaneidade de revisão. Se um revisor tem três solicitações de revisão pendentes, a quarta não vai receber uma boa revisão de qualquer forma. Os dados de múltiplas revisões mostraram uma associação clara entre simultaneidade e latência. Comece com um limite WIP de duas revisões simultâneas e monitore o impacto.

Pare de otimizar o tamanho de PR de forma isolada. PRs pequenos são bons, mas não substituem uma equipe que realmente revisa as coisas. Uma equipe produzindo vinte PRs de 50 linhas por dia com um backlog de revisão de 48 horas está em situação pior do que uma equipe produzindo cinco PRs de 200 linhas com revisões no mesmo dia.

Reconheça que revisão é trabalho real. A pesquisa da Atlassian de 2024 descobriu que 69% dos desenvolvedores perdem 8+ horas semanais com ineficiências. A revisão não precisa ser uma dessas ineficiências – mas apenas se for tratada como uma atividade de engenharia de primeira classe, não como uma interrupção do trabalho "real".

E aqui está a parte que ninguém no espaço de ferramentas de produtividade – incluindo nós, para ser justo – quer dizer em voz alta: a intervenção mais impactante para o custo de troca de contexto em equipes de engenharia não é uma ferramenta. É um acordo de equipe sobre quando os PRs são revisados. Se a norma implícita da sua equipe é "vou cuidar das revisões quando tiver uma pausa", nenhuma quantidade de ferramentas vai prevenir a cascata de enfileiramento que os dados de PR revelam.

Ferramentas ajudam – poder ver o contexto completo de um PR sem abrir quatro abas do navegador reduz a carga cognitiva por troca, e destacar quais revisões estão bloqueando o trabalho de outras pessoas ajuda a priorizar. Mas a alavanca principal é o acordo, e acordos são gratuitos. Nenhuma calculadora de 23 minutos necessária.

A troca de contexto mais cara não é a notificação que interrompe seu fluxo. É a solicitação de revisão que fica em uma fila por um dia, forçando o autor a reconstruir o contexto mental quando as perguntas finalmente chegam.

Receba inteligência de sinais direto na sua caixa de entrada.

Perguntas Frequentes

Q: Quanto custa a troca de contexto por desenvolvedor por ano? A: As estimativas variam, mas a pesquisa subjacente é mais rasa do que a maioria dos artigos sugere. O estudo de Gloria Mark na UC Irvine encontrou 23 minutos de tempo de refoco por interrupção, e a pesquisa da Atlassian de 2024 com mais de 2.100 desenvolvedores constatou que 69% perdem 8+ horas semanais com ineficiências. O valor em dólares depende muito de premissas salariais, frequência de interrupções e como você define 'troca' – por isso nos focamos nos dados de PRs.

Q: O Sugarbug ajuda a reduzir a troca de contexto para equipes de engenharia? A: Sim. O Sugarbug conecta ferramentas como Linear, GitHub, Slack e Figma em um único grafo de conhecimento, para que os engenheiros possam ver o contexto completo de uma tarefa – o PR relevante, a discussão no Slack, o comentário no Figma – sem abrir quatro abas. O objetivo é menos trocas, não menos ferramentas.

Q: Qual é o tamanho ideal de pull request para minimizar atrasos de revisão? A: A pesquisa da análise da Adadot de mais de 300.000 PRs descobriu que PRs com menos de 100 linhas de código têm aproximadamente 80% de probabilidade de serem concluídos em uma semana. Acima de 400 linhas, a qualidade e a velocidade de conclusão da revisão caem. PRs menores também reduzem a carga de troca de contexto do revisor.

Q: O Sugarbug se integra com pull requests do GitHub? A: Sim. O Sugarbug coleta a atividade do GitHub – PRs, comentários, revisões e mudanças de status – e os vincula a sinais relacionados em suas outras ferramentas. Se um issue do Linear originou o PR e um thread do Slack debateu a abordagem, o Sugarbug conecta os três automaticamente.

Q: De onde vem a estatística dos '23 minutos para refocagem'? A: Vem da pesquisa de Gloria Mark na UC Irvine, publicada em 'The Cost of Interrupted Work: More Speed and Stress' (CHI 2008). O estudo descobriu que os trabalhadores levavam em média 23 minutos e 15 segundos para retornar à tarefa original após uma interrupção. Vale notar que o estudo observou trabalhadores do conhecimento em geral, não engenheiros de software especificamente.