Реальна вартість перемикання контексту: 5 млн GitHub PR
Ми узагальнили дані з понад 5 млн PR, щоб виміряти реальну вартість перемикання контексту для розробників – і вона не там, де ви думаєте.
By Ellis Keane · 2026-03-29
Вартість перемикання контексту, яку цитує більшість статей – 23 хвилини для повторного зосередження після переривання, із дослідження Gloria Mark в UC Irvine – є реальним результатом реального дослідження. Але воно вимірювало загальних інтелектуальних працівників у 2008 році, а не програмних інженерів. І ціла індустрія блог-постів, яка множить 23 хвилини на припущену кількість переривань, щоб отримати тривожні щорічні цифри збитків (завжди зі стоковим фото когось, хто тримається за голову), робить те, чого оригінальне дослідження ніколи не передбачало.
Я маю особисту зацікавленість у цьому питанні. У попередній компанії я витрачав – і це не перебільшення – від 80 до 100 відсотків деяких днів на те, щоб бути просто людським маршрутизатором. Не писав код, не переглядав його. Маршрутизував інформацію між людьми та інструментами, бо жодна система не з'єднувала їх. Цей досвід частково пояснює, чому ми побудували Sugarbug, але він також пояснює, чому я скептично ставлюся до стандартних калькуляторів вартості перемикання контексту. Вони вимірюють переривання. Вони не вимірюють дні, які ти проводиш, так і не дійшовши до того, чим мав займатися.
Тому ми хотіли дізнатися, скільки насправді коштує перемикання контексту в інженерній роботі – не в абстрактних термінах продуктивності розробників, а виміряний у тому, що команди виробляють щодня: pull requests. Ми синтезували результати трьох великомасштабних досліджень, які охоплювали понад 5 мільйонів PR у тисячах проєктів з відкритим вихідним кодом, і подивилися, що насправді впливає на час перевірки pull request.
Головний висновок: найдорожче перемикання контексту – це не сповіщення в Slack, яке руйнує ваш потік. Це pull request, який день пролежить у черзі перевірки, змушуючи автора заново відбудовувати цілу ментальну модель, коли нарешті надходять запитання.
Набори даних, якими ми користувалися
Ми не створювали власний парсер і не аналізували 10 000 PR ізольовано. Ми синтезували результати двох рецензованих досліджень та одного великого галузевого набору даних і протестували їхні висновки один проти одного.
stat: "3.35M" headline: "Pull requests, проаналізованих Zhang та ін." source: "Pull Request Latency Explained: An Empirical Overview (Empirical Software Engineering, 2022)"
Три основних набори даних:
- Zhang та ін. (2022), рецензоване дослідження: 3 347 937 закритих PR у 11 230 проєктах. Для виявлення того, що спричиняє затримки перевірки PR, використовувалася лінійна регресія зі змішаними ефектами. Опубліковано в Empirical Software Engineering.
- Adadot (2023), галузевий набір даних: понад 300 000 злитих PR від ~30 000 розробників. Не рецензоване, але вибірка велика, а методологія (кореляція Kendall tau) прозора. Зосереджено на розмірі PR порівняно з lead time.
- Дослідження multiple-reviewing (2019), рецензоване: 1 836 280 PR у 760 проєктах GitHub. Опубліковано в Information and Software Technology. Вивчає поведінку одночасного перегляду – прямий проксі для перемикання контексту під час перевірки коду.
Ми зіставили ці дані з 2024 DORA State of DevOps Report і звітом Atlassian про досвід розробників 2024 (опитування понад 2100 розробників щодо перемикання контексту, продуктивності розробників та людського аспекту питання).
Черга – справжній вбивця
Zhang та ін. виявили, що час, потрібний PR для отримання першої відповіді – першого коментаря, першого огляду, будь-чого першого – пояснює 58,7% дисперсії загального терміну існування PR. Це найсильніший спостережуваний предиктор у наборі даних – випереджає розмір PR, складність коду або кількість змінених файлів! Навіть близько немає.
Найбільша вартість перемикання контексту під час перевірки коду – це не саме перемикання, а черга, яка формується, поки всі зайняті перемиканням між іншими речами.
Подумайте, що це означає на практиці. Інженер відкриває PR о 10 ранку. Призначений рецензент глибоко занурений у свою власну гілку функцій, або на нараді, або переглядає повідомлення в Slack (і чесно, мабуть, усі три по черзі). PR чекає. До 15:00, коли хтось його нарешті підбирає, автор вже повністю переключився на щось інше. Тепер у рецензента є запитання – а це означає, що автор мусить перемикнути контекст назад до коду, написаного п'ять годин тому, відновити ментальну модель і відповісти. Відповідь надходить о 16:30, але рецензент вже пішов додому.
PR старіє ще на один день.
Дані свідчать, що це проблема черги, а не дисципліни – і вартість перемикання контексту через цю чергу накопичується так, як калькулятори переривань повністю не враховують.
Малі PR вас не врятують
Ви чули це раніше: менші PR перевіряються швидше, тому тримайте ваші PR малими. Це не зовсім неправильно, але розмір ефекту (справді) менший, ніж можна очікувати.
Аналіз Adadot понад 300 000 PR виявив кореляцію Kendall tau лише 0,06 між розміром PR і lead time – слабкий зв'язок, хоча дослідження не подавало довірчих інтервалів для сукупного показника. PR менше 100 рядків мають приблизно 80% ймовірність завершення протягом тижня, що звучить чудово, поки ви не усвідомите, що це та сама частота виконання, що й у PR, який шість днів пролежав у черзі перевірки!
stat: "0.06" headline: "Кореляція між розміром PR та lead time" source: "Аналіз Adadot понад 300 000 PR від ~30 000 розробників (2023)"
Цікавіший висновок: ця кореляція дико варіювалася між організаціями – від 0,1 до майже 0,7 залежно від компанії. Це свідчить про те, що розмір PR не є вузьким місцем за своєю суттю – а ось культура і процес перевірки навколо PR є. Команда з міцним ритмом перевірки може ефективно справлятися з більшими PR. Команда, яка розглядає перевірки як щось вторинне, буде мати труднощі з PR будь-якого розміру.
Поріг 400 рядків із дослідження SmartBear/Cisco щодо перевірки коду залишається корисним орієнтиром – дані Adadot також виявили, що залученість до перевірки падає після цього діапазону. Але оптимізація малих PR без усунення базового ритму перевірки – це (і я кажу це з щирою любов'ю до кожного інженерного менеджера, який намагався це зробити) перестановка шезлонгів на палубі тонучого корабля.
Усі перевіряють усе одночасно
Дослідження multiple-reviewing виявило, що 62% pull requests залучають розробників, які одночасно переглядають кілька PR. Важливіше: вони виявили статистично значущу кореляцію – більше одночасних переглядів на рецензента було пов'язано з довшою затримкою вирішення PR.
62% pull requests залучають розробників, які одночасно переглядають кілька PR – і множинний перегляд безпосередньо корелює з довшими термінами вирішення. attribution: Дослідження multiple-reviewing pull-requests, 1,8 млн PR у 760 проєктах
Механізм інтуїтивно зрозумілий (навіть якщо дослідження, будучи спостережним, не доводить напрямок причинно-наслідкового зв'язку). Рецензент бере PR #1, читає diff, починає формувати ментальну модель того, що код намагається зробити. Потім приходить сповіщення – PR #2 потребує перевірки, тому що блокує деплой. Рецензент перемикається. Повернувшись до PR #1, йому доводиться перечитати половину diff, тому що ментальна модель розпалася.
Помножте це на команду з восьми інженерів, у кожного з яких відкрито два-три PR, кожен з яких переглядає для двох-трьох колег – і накладні витрати на координацію починають пояснювати самі себе. Окремо, звіт DORA 2024 виявив, що кластер «high performers» скоротився з 31% до 22%, тоді як кластер низької ефективності виріс з 17% до 25%. DORA не виокремлює одночасність перевірки PR як чинник, але збільшення накладних витрат на координацію є одним із вірогідних факторів цього зрушення.
Що не так із оцінками вартості перемикання контексту
Дозвольте мені бути прямим щодо цифри «$50 тис. на розробника на рік», яка широко циркулює в статтях про вартість перемикання контексту. Методологія більшості цих оцінок така: беремо 23 хвилини повторного зосередження, множимо на приблизну кількість щоденних переривань (зазвичай від 6 до 15, залежно від того, наскільки драматично налаштований автор), множимо на погодинну ставку розробника і перераховуємо на рік.
Проблема не в тому, що математика неправильна. Проблема в тому, що вона ставить усі перемикання контексту в один ряд. Перемикання з глибокого кодування на повідомлення в Slack із запитанням, де буде командний обід, – це перемикання контексту. Перемикання від перегляду одного PR до перегляду іншого PR у зовсім іншій кодовій базі – це теж перемикання контексту. Але когнітивна вартість навіть близько не порівнянна, і зведення їх до єдиної погодинної ставки приховує, де насправді відбувається реальна шкода.
Якщо говорити конкретно: на останньому місці роботи типовий день означав перемикання між Notion, Linear, Mattermost, Proton Mail, Proton Calendar, Discord, Twitter, Farcaster та незліченними каналами Telegram і Signal – і я впевнений, що забув ще півдесятка. Тепер я використовую жменьку (Signal, Obsidian, Figma, GitHub, електронна пошта, календарі). Вартість за перемикання не змінилася. Змінилося те, скільки контекстів стоїть у черзі за увагою – і які з них насправді важливі.
Дані PR свідчать, що дорогі перемикання – це ті, що створюють черги, а не ті, що переривають потік. Розробник, якому одразу (протягом хвилин) пінгують, щоб переглянути PR, і він робить швидкий 50-рядковий огляд – це коротке переривання з високою віддачею. Розробник, який ставить цей запит на перевірку в чергу разом із ще чотирма і доходить до нього завтра – це довше переривання для рецензента, але набагато більші витрати для автора і команди.
Що вимірюють калькулятори вартості
- Індивідуальні переривання – як часто чийсь потік переривається
- Час повторного зосередження – скільки часу потрібно для повернення до попереднього завдання
- Множення на погодинну ставку – великі страшні щорічні цифри
Що насправді показують дані PR
- Формування черги – PR, що очікують першої відповіді
- Одночасність перевірки – рецензенти, які жонглюють кількома PR
- Каскадні затримки – перемикання контексту автора, що підсилює затримки рецензента
Що це означає для вашої команди
Якщо ви намагаєтеся зменшити вартість перемикання контексту для розробників у вашій команді, практична відповідь нудна – що, мабуть, пояснює, чому про неї мало пишуть. Це не інструмент. Це не процесний фреймворк із програмою сертифікації. Це ритм перевірки. (Я знаю, я знаю. За поліпшення ритму перевірки ніхто ніколи не отримував підвищення.)
Інженерні орієнтири LinearB 2025, отримані з 6,1 мільйона PR у 3000 організаціях, виявили, що команди, які досягають елітного часу циклу (менше 2,5 днів), мали одну спільну рису: вони швидко переглядали PR. Не тому, що у них було менше PR або їхні PR були меншими (хоча часто були), а тому що реагувати на запити на перевірку протягом годин було нормою команди, а не другорядною справою.
Варто зазначити, що ми з Беном – команда з двох осіб – в середньому витрачаємо хвилини, а не години, на першу відповідь на PR. Це не хвальба про дисципліну (ми не такі). Це командна угода: запити на перевірку – це єдине сповіщення, яке ви не ставите в чергу. CI actions та автоматизовані тести обробляють механічні перевірки, що означає, що людський огляд – та частина, яка вимагає справжнього контексту, – коротший і відбувається негайно. Угода з'явилася першою. Інструменти просто зробили її стійкою.
На практиці це означає:
- Вимірюйте час до першої відповіді, а не лише час циклу. Якщо ви відстежуєте метрики DORA, додайте цю. Це єдиний найсильніший предиктор пропускної здатності PR (пояснює 58,7% дисперсії часу існування згідно з Zhang та ін.).
- Обмежте одночасність перевірки. Якщо у рецензента є три запити на перевірку, четвертий все одно не отримає якісного перегляду. Дані про множинний перегляд показали чіткий зв'язок між одночасністю та затримкою. Почніть із WIP-ліміту двох одночасних перевірок і відстежуйте вплив.
- Припиніть оптимізувати розмір PR ізольовано. Маленькі PR – це добре, але вони не є заміною команді, яка насправді переглядає речі. Команда, що виробляє двадцять 50-рядкових PR на день із 48-годинним накопиченням перевірок, гірша за команду, що виробляє п'ять 200-рядкових PR із перевірками в той же день.
- Визнайте, що перевірка – це справжня робота. Опитування Atlassian 2024 виявило, що 69% розробників втрачають понад 8 годин на тиждень через неефективність. Перевірка не обов'язково має бути одним із таких неефективностей – але тільки якщо вона розглядається як першокласна інженерна діяльність, а не переривання «справжньої» роботи.
І ось частина, яку ніхто у просторі інструментів продуктивності (зокрема й ми, якщо чесно) не хоче говорити вголос: найбільш ефективне втручання для зниження вартості перемикання контексту в інженерних командах – це не інструмент. Це командна угода про те, коли переглядаються PR. Якщо неявна норма вашої команди – «я дійду до перевірок, коли буде вільний час», жоден інструмент не запобіжить каскаду черги, який розкривають дані PR.
Інструменти допомагають – можливість бачити повний контекст PR без відкриття чотирьох вкладок браузера зменшує когнітивне навантаження за перемикання, а наочність того, які перевірки блокують роботу інших людей, допомагає розставляти пріоритети. Але основний важіль – угода, а угоди безкоштовні. Жодний 23-хвилинний калькулятор не потрібен.
Найдорожче перемикання контексту – це не сповіщення, яке руйнує ваш потік. Це запит на перевірку, який цілий день стоїть у черзі, змушуючи автора заново відбудовувати ментальний контекст, коли нарешті надходять запитання.
Отримуйте сигнальну розвідку прямо у вашу поштову скриньку.
Часті запитання
Q: Скільки коштує перемикання контексту на одного розробника на рік? A: Оцінки різняться, але відповідне дослідження значно скромніше, ніж більшість статей натякає. Дослідження Gloria Mark з UC Irvine виявило 23 хвилини повторного зосередження після кожного переривання, а опитування Atlassian 2024 року серед понад 2100 розробників показало, що 69% втрачають понад 8 годин на тиждень через неефективність. Доларовий показник суттєво залежить від припущень щодо зарплати, частоти переривань і того, як ви визначаєте "перемикання" – саме тому ми сфокусувалися на даних PR.
Q: Чи допомагає Sugarbug зменшити перемикання контексту для інженерних команд? A: Так. Sugarbug з'єднує інструменти на кшталт Linear, GitHub, Slack і Figma в єдиний граф знань, щоб інженери могли бачити повний контекст завдання – відповідний PR, обговорення в Slack, коментар у Figma – не відкриваючи чотири вкладки. Мета – менше перемикань, а не менше інструментів.
Q: Який ідеальний розмір pull request для мінімізації затримок перевірки? A: Дослідження на основі аналізу Adadot понад 300 000 PR виявило, що PR до 100 рядків коду мають приблизно 80% ймовірність завершення протягом тижня. Понад 400 рядків якість перевірки та швидкість завершення обидві знижуються. Менші PR також зменшують навантаження перемикання контексту для рецензента.
Q: Чи інтегрується Sugarbug з GitHub pull requests? A: Так. Sugarbug збирає активність GitHub – PR, коментарі, огляди та зміни статусу – і пов'язує їх із відповідними сигналами в інших ваших інструментах. Якщо завдання Linear породило PR, а гілка обговорення в Slack дебатувала підхід, Sugarbug автоматично з'єднає всі три.
Q: Звідки береться статистика "23 хвилини для повторного зосередження"? A: Вона походить з дослідження Gloria Mark в UC Irvine, опублікованого у "The Cost of Interrupted Work: More Speed and Stress" (CHI 2008). Дослідження показало, що працівники витрачають у середньому 23 хвилини 15 секунд, щоб повернутися до свого первісного завдання після переривання. Варто зазначити, що дослідження спостерігало за загальними інтелектуальними працівниками, а не конкретно за програмними інженерами.