Prawdziwy koszt przełączania kontekstu: 5 mln PR-ów GitHub
Przeanalizowaliśmy dane z ponad 5 mln PR-ów, aby zmierzyć realny koszt przełączania kontekstu dla programistów – i nie tam, gdzie myślisz.
By Ellis Keane · 2026-03-29
Koszt przełączania kontekstu, który cytuje większość artykułów – 23 minuty na ponowne skupienie po przerwaniu, według badań Glorii Mark z UC Irvine – to rzeczywiste odkrycie z rzeczywistego badania. Zostało ono jednak przeprowadzone na ogólnych pracownikach wiedzy w 2008 roku, a nie na inżynierach oprogramowania. A przemysł blogowy, który mnoży 23 minuty przez szacowaną liczbę dziennych przerw (zazwyczaj od 6 do 15, w zależności od nastroju autora), by uzyskać alarmujące roczne kwoty w dolarach – zawsze w towarzystwie zdjęcia stockowego osoby trzymającej głowę w dłoniach – robi coś, czego oryginalne badanie nigdy nie zakładało.
Mam osobisty stosunek do tego zagadnienia. W poprzedniej firmie spędzałem – i to nie jest przesada – 80 do 100 procent niektórych dni jako ludzki router. Nie pisałem kodu ani go nie przeglądałem. Przekazywałem informacje między ludźmi i narzędziami, bo żaden system ich nie łączył. To doświadczenie jest częścią powodu, dla którego zbudowaliśmy Sugarbug, ale też dlatego sceptycznie podchodzę do standardowych kalkulatorów kosztu przełączania kontekstu. Mierzą przerwanie. Nie mierzą natomiast dni, w których nigdy nie docierasz do tego, od czego miałeś zostać przerwany.
Chcieliśmy więc wiedzieć, co przełączanie kontekstu naprawdę kosztuje w pracy inżynierskiej – nie w abstrakcyjnych kategoriach produktywności programistów, ale mierzone artefaktem, który zespoły produkują codziennie: pull requestami. Zebraliśmy wyniki z trzech dużych badań obejmujących ponad 5 milionów PR-ów w tysiącach projektów open source i sprawdziliśmy, co naprawdę wpływa na czas przeglądu pull requestów.
Główne odkrycie: najdroższym przełączeniem kontekstu nie jest powiadomienie ze Slacka przerywające przepływ pracy. To pull request, który przez cały dzień czeka w kolejce do przeglądu, zmuszając autora do odbudowania całego modelu mentalnego, gdy pytania w końcu nadchodzą.
Wykorzystane zestawy danych
Nie zbudowaliśmy własnego scrapera i nie analizowaliśmy 10 000 PR-ów w izolacji. Zebraliśmy wyniki z dwóch recenzowanych badań naukowych i jednego dużego branżowego zestawu danych, a następnie wzajemnie weryfikowaliśmy ich wnioski.
stat: "3,35 mln" headline: "Pull requestów przeanalizowanych przez Zhang i in." source: "Pull Request Latency Explained: An Empirical Overview (Empirical Software Engineering, 2022)"
Trzy główne zestawy danych:
- Zhang i in. (2022), recenzowane: 3 347 937 zamkniętych PR-ów w 11 230 projektach. Do identyfikacji czynników powodujących opóźnienia w przeglądzie PR-ów użyto mieszanej regresji liniowej z efektami losowymi. Opublikowane w Empirical Software Engineering.
- Adadot (2023), branżowy zestaw danych: Ponad 300 000 scalonych PR-ów od ~30 000 programistów. Nierecenzowane, ale próba jest duża, a metodologia (korelacja tau Kendalla) jest przejrzysta. Skupione na rozmiarze PR a czas realizacji.
- Badanie wieloprzeglądowe (2019), recenzowane: 1 836 280 PR-ów w 760 projektach GitHub. Opublikowane w Information and Software Technology. Analizuje zachowania przy jednoczesnym przeglądzie – bezpośredni wskaźnik zastępczy dla przełączania kontekstu w recenzji kodu.
Skonfrontowaliśmy je z raportem DORA State of DevOps 2024 oraz raportem Atlassian Developer Experience 2024 (ankieta ponad 2100 programistów na temat przełączania kontekstu, produktywności programistów i ludzkiego wymiaru problemu).
Kolejka to prawdziwy zabójca
Zhang i in. stwierdzili, że czas potrzebny PR-owi do otrzymania pierwszej odpowiedzi – pierwszego komentarza, pierwszego przeglądu, czegokolwiek pierwszego – wyjaśnia 58,7% wariancji w całkowitym czasie życia PR-u. To najsilniejszy zaobserwowany predyktor w zestawie danych – przed rozmiarem PR, złożonością kodu czy liczbą zmienionych plików! Bez żadnego porównania.
Największy koszt przełączania kontekstu w recenzji kodu to nie samo przełączanie – to kolejka, która tworzy się, gdy wszyscy są zajęci przełączaniem się między innymi zadaniami.
Pomyślmy, co to oznacza w praktyce. Inżynier otwiera PR o 10:00. Wyznaczony recenzent jest pogrążony we własnej gałęzi funkcjonalności, albo jest na spotkaniu, albo przegląda wiadomości na Slacku (i szczerze mówiąc, prawdopodobnie wszystkie trzy po kolei). PR czeka. Kiedy ktoś wreszcie go podejmuje o 15:00, autor zdążył już zająć się czymś zupełnie innym. Teraz recenzent ma pytania, co oznacza, że autor musi przełączyć kontekst z powrotem na kod, który pisał pięć godzin temu, odbudować model mentalny i odpowiedzieć. Odpowiedź dociera o 16:30, ale recenzent już skończył pracę.
PR starzeje się kolejny dzień.
Dane sugerują, że to bardziej problem kolejkowania niż dyscypliny – a koszt przełączania kontekstu tej kolejki kumuluje się w sposób, którego kalkulatory przerw całkowicie nie dostrzegają.
Małe PR-y cię nie uratują
Słyszałeś to wcześniej: mniejsze PR-y są przeglądane szybciej, więc dbaj o małe PR-y. To nie jest całkowicie błędne, ale efekt jest (naprawdę) mniejszy, niż można by oczekiwać.
Analiza Adadot obejmująca ponad 300 000 PR-ów wykazała korelację tau Kendalla wynoszącą zaledwie 0,06 między rozmiarem PR a czasem realizacji – słaba zależność, choć badanie nie podało przedziałów ufności dla wartości zagregowanej. PR-y poniżej 100 linii mają około 80% szans na ukończenie w ciągu tygodnia, co brzmi świetnie – dopóki nie uświadomisz sobie, że to taki sam wskaźnik ukończenia, jak PR, który od sześciu dni czeka w czyjejś kolejce do przeglądu!
stat: "0,06" headline: "Korelacja między rozmiarem PR a czasem realizacji" source: "Analiza Adadot obejmująca ponad 300 000 PR-ów od ~30 000 programistów (2023)"
Ciekawsze odkrycie: ta korelacja znacznie różniła się między organizacjami, wahając się od 0,1 do prawie 0,7 w zależności od firmy. Sugeruje to, że rozmiar PR nie jest sam w sobie wąskim gardłem – wąskim gardłem jest kultura i proces przeglądu wokół PR-u. Zespół z silnym rytmem przeglądów może sprawnie obsługiwać większe PR-y. Zespół, w którym przeglądy są kwestią drugorzędną, będzie się zmagał z PR-ami dowolnego rozmiaru.
Próg 400 linii z badania SmartBear/Cisco dotyczącego recenzji kodu nadal stanowi użyteczną heurystykę – dane Adadot również wykazały, że zaangażowanie w przegląd spada powyżej tego zakresu. Ale optymalizowanie pod kątem małych PR-ów bez naprawy leżącego u podstaw rytmu przeglądów to – i mówię to z prawdziwą sympatią dla każdego menedżera inżynierskiego, który próbował – przestawianie leżaków na pokładzie.
Wszyscy przeglądają wszystko jednocześnie
Badanie wieloprzeglądowe wykazało, że 62% pull requestów dotyczy programistów, którzy jednocześnie przeglądają wiele PR-ów. Co ważniejsze, znaleziono statystycznie istotną korelację: większa liczba jednoczesnych przeglądów na recenzenta wiązała się z dłuższym opóźnieniem w rozwiązywaniu PR-ów.
62% pull requestów dotyczy programistów jednocześnie przeglądających wiele PR-ów – a wieloprzeglądanie bezpośrednio koreluje z dłuższym czasem rozwiązywania. attribution: Badanie wieloprzeglądowe pull requestów, 1,8 mln PR-ów w 760 projektach
Mechanizm jest intuicyjny (choć badanie, będąc obserwacyjnym, nie dowodzi kierunku przyczynowości). Recenzent podejmuje PR nr 1, czyta diff, zaczyna tworzyć model mentalny tego, co kod stara się zrobić. Potem nadchodzi powiadomienie – PR nr 2 wymaga przeglądu, bo blokuje wdrożenie. Recenzent przełącza się. Gdy wraca do PR nr 1, musi ponownie przeczytać połowę diffa, bo model mentalny zanikł.
Przemnóż to przez zespół ośmiu inżynierów, każdy z dwoma lub trzema otwartymi PR-ami, każdy przeglądający dla dwóch lub trzech kolegów, a koszty koordynacji zaczynają same się tłumaczyć. Odrębnie raport DORA 2024 wykazał, że klaster „wysokich wykonawców" skurczył się z 31% do 22%, a klaster niskich wykonawców wzrósł z 17% do 25%. DORA nie wskazuje jednoczesności przeglądów PR jako czynnika, ale rosnące koszty koordynacji są jednym z prawdopodobnych źródeł tej zmiany.
Co kalkulatory kosztu przełączania kontekstu pomijają
Pozwolę sobie być bezpośredni w kwestii liczby „50 000 dolarów na programistę rocznie", która krąży szeroko w artykułach o koszcie przełączania kontekstu. Metodologia większości takich szacunków wygląda następująco: weź 23 minuty na ponowne skupienie, pomnóż przez szacowaną liczbę dziennych przerw (zazwyczaj od 6 do 15, w zależności od dramatyzmu autora), pomnóż przez stawkę godzinową programisty i annualizuj.
Problem nie leży w tym, że matematyka jest błędna. Problem polega na tym, że traktuje wszystkie przełączenia kontekstu jako równoważne. Przełączenie z głębokiego kodowania na wiadomość na Slacku z pytaniem, gdzie jest lunch zespołu – to jest przełączenie kontekstu. Przełączenie z przeglądu jednego PR na przegląd innego PR w zupełnie innej bazie kodu – to też jest przełączenie kontekstu. Ale koszt poznawczy nie jest nawet porównywalny, a sprowadzanie ich do jednej stawki godzinowej zaciemnia, gdzie naprawdę dzieje się szkoda.
Mówiąc konkretnie: w poprzedniej pracy typowy dzień oznaczał przełączanie się między Notion, Linear, Mattermost, Proton Mail, Proton Calendar, Discord, Twitterem, Farcasterem i niezliczonymi kanałami Telegram i Signal – i jestem pewien, że zapominam o kilku. Teraz używam kilku narzędzi (Signal, Obsidian, Figma, GitHub, e-mail, kalendarze). Koszt pojedynczego przełączenia się nie zmienił. Zmieniło się to, ile kontekstów rywalizuje o uwagę – i które z nich naprawdę mają znaczenie.
Dane z PR-ów sugerują, że drogie przełączenia to te, które tworzą kolejki, a nie te, które przerywają przepływ pracy. Programista, który dostaje ping z prośbą o przegląd PR natychmiast (w ciągu kilku minut) i robi szybki przegląd 50 linii – to krótkie przerwanie z wysokim zwrotem. Programista, który kolejkuje tę prośbę o przegląd razem z czterema innymi i zajmie się tym jutro – to dłuższe przerwanie dla recenzenta, ale generuje znacznie większy koszt dla autora i zespołu.
Co mierzą kalkulatory kosztów
- Indywidualne przerwania – jak często czyiś przepływ pracy zostaje przerwany
- Czas ponownego skupienia – jak długo trwa powrót do poprzedniego zadania
- Mnożenie stawki godzinowej – duże, przerażające roczne liczby
Co naprawdę pokazują dane z PR-ów
- Tworzenie kolejek – PR-y czekające na pierwszą odpowiedź
- Jednoczesność przeglądów – recenzenci żonglujący wieloma PR-ami
- Opóźnienia kaskadowe – przełączenia kontekstu autora kumulujące opóźnienia recenzenta
Co to oznacza dla twojego zespołu
Jeśli chcesz zmniejszyć koszt przełączania kontekstu dla programistów w swoim zespole, praktyczna odpowiedź jest nudna – i to prawdopodobnie dlatego nie pisze się o niej zbyt wiele. To nie narzędzie. To nie framework procesowy z programem certyfikacyjnym. To rytm przeglądów. (Wiem, wiem. Nikt nigdy nie dostał awansu za poprawienie rytmu przeglądów.)
Benchmarki inżynierskie LinearB z 2025 roku, oparte na 6,1 miliona PR-ów w 3000 organizacjach, wykazały, że zespoły osiągające elitarne czasy cyklu (poniżej 2,5 dnia) miały jedną wspólną cechę: szybko przeglądały PR-y. Nie dlatego, że miały mniej PR-ów lub że ich PR-y były mniejsze (choć często tak było), ale dlatego, że odpowiadanie na prośby o przegląd w ciągu kilku godzin było normą zespołową, a nie sprawą drugorzędną.
Dla informacji: Ben i ja – dwuosobowy zespół – odpowiadamy na pierwsze PR-y średnio w minuty, nie w godziny. To nie jest popis dyscypliny (nie jesteśmy tacy). To umowa zespołowa: prośby o przegląd to jedyne powiadomienie, którego się nie kolejkuje. Akcje CI i automatyczne testy obsługują mechaniczne sprawdzenia, co oznacza, że ludzki przegląd – ta część, która wymaga rzeczywistego kontekstu – jest krótki i następuje natychmiast. Umowa była pierwsza. Narzędzia tylko ją utrwaliły.
W praktyce oznacza to:
- Mierz czas pierwszej odpowiedzi, nie tylko czas cyklu. Jeśli śledzisz metryki DORA, dodaj tę. To najsilniejszy predyktor przepustowości PR-ów (wyjaśniający 58,7% wariancji czasu życia według Zhang i in.).
- Ogranicz jednoczesność przeglądów. Jeśli recenzent ma trzy oczekujące prośby o przegląd, czwarta nie dostanie dobrego przeglądu. Dane o wieloprzeglądaniu wykazały wyraźną zależność między jednoczesnością a opóźnieniem. Zacznij od limitu WIP wynoszącego dwa jednoczesne przeglądy i monitoruj wpływ.
- Przestań optymalizować rozmiar PR w izolacji. Małe PR-y są dobre, ale nie zastąpią zespołu, który naprawdę przegląda. Zespół produkujący dwadzieścia PR-ów po 50 linii dziennie z 48-godzinnym zaległym przeglądami jest w gorszej sytuacji niż zespół produkujący pięć PR-ów po 200 linii z przeglądami tego samego dnia.
- Przyznaj, że przegląd to prawdziwa praca. Ankieta Atlassian z 2024 roku wykazała, że 69% programistów traci 8+ godzin tygodniowo na nieefektywność. Przegląd nie musi być jedną z tych nieefektywności – ale tylko wtedy, gdy jest traktowany jako pierwszorzędna aktywność inżynierska, a nie przerwa w „prawdziwej" pracy.
I tu jest część, o której nikt w przestrzeni narzędzi do produktywności – włącznie z nami, trzeba przyznać – nie chce mówić głośno: najbardziej skuteczna interwencja w zakresie kosztu przełączania kontekstu w zespołach inżynierskich to nie narzędzie. To umowa zespołowa o tym, kiedy PR-y są przeglądane. Jeśli domyślna norma twojego zespołu brzmi „zajmę się przeglądami, gdy będę mieć chwilę", żadna ilość narzędzi nie zapobiegnie kaskadzie kolejkowania, którą ujawniają dane z PR-ów.
Narzędzia pomagają – możliwość zobaczenia pełnego kontekstu PR bez otwierania czterech kart przeglądarki zmniejsza poznawczy koszt przełączenia, a wyróżnianie, które przeglądy blokują pracę innych, pomaga w ustalaniu priorytetów. Ale główna dźwignia to umowa, a umowy są bezpłatne. Kalkulator 23 minut nie jest potrzebny.
Najdroższe przełączenie kontekstu to nie powiadomienie przerywające twój przepływ pracy. To prośba o przegląd, która przez cały dzień czeka w kolejce, zmuszając autora do odbudowania kontekstu mentalnego, gdy pytania w końcu nadchodzą.
Otrzymuj inteligencję sygnałów prosto do swojej skrzynki.
Często zadawane pytania
Q: Ile kosztuje przełączanie kontekstu na jednego programistę rocznie? A: Szacunki są różne, ale podstawowe badania są skromniejsze, niż sugeruje większość artykułów. Badanie Glorii Mark z UC Irvine wykazało 23 minuty na ponowne skupienie po przerwaniu, a ankieta Atlassian z 2024 roku przeprowadzona wśród ponad 2100 programistów wykazała, że 69% traci 8+ godzin tygodniowo przez nieefektywność. Kwota w dolarach zależy w dużej mierze od założeń dotyczących wynagrodzenia, częstotliwości przerw i sposobu zdefiniowania „przełączania" – dlatego skupiliśmy się na danych z PR-ów.
Q: Czy Sugarbug pomaga ograniczyć przełączanie kontekstu dla zespołów inżynierskich? A: Tak. Sugarbug łączy narzędzia takie jak Linear, GitHub, Slack i Figma w jeden graf wiedzy, dzięki czemu inżynierowie mogą zobaczyć pełny kontekst zadania – odpowiedni PR, dyskusję na Slacku, komentarz w Figmie – bez otwierania czterech kart. Celem jest mniej przełączeń, a nie mniej narzędzi.
Q: Jaki jest idealny rozmiar pull requesta, aby zminimalizować opóźnienia w przeglądzie? A: Z analizy Adadot obejmującej ponad 300 000 PR-ów wynika, że PR-y poniżej 100 linii kodu mają około 80% szans na ukończenie w ciągu tygodnia. Powyżej 400 linii spada zarówno jakość przeglądu, jak i szybkość ukończenia. Mniejsze PR-y zmniejszają też obciążenie recenzenta przełączaniem kontekstu.
Q: Czy Sugarbug integruje się z pull requestami na GitHubie? A: Tak. Sugarbug pobiera aktywność z GitHuba – PR-y, komentarze, przeglądy i zmiany statusu – i łączy je z powiązanymi sygnałami w innych narzędziach. Jeśli zgłoszenie w Linearze dało początek PR-owi, a wątek na Slacku dotyczył podejścia do rozwiązania, Sugarbug automatycznie łączy wszystkie trzy.
Q: Skąd pochodzi statystyka „23 minuty na ponowne skupienie"? A: Pochodzi z badań Glorii Mark z UC Irvine, opublikowanych jako „The Cost of Interrupted Work: More Speed and Stress" (CHI 2008). Badanie wykazało, że pracownicy potrzebowali średnio 23 minut i 15 sekund, aby wrócić do pierwotnego zadania po przerwaniu. Warto zaznaczyć, że badanie dotyczyło ogólnych pracowników wiedzy, a nie konkretnie inżynierów oprogramowania.