Переключения контекста: сколько — это нормально

Один из показателей, которые DevPace считает автоматически, — количество переключений контекста: сколько раз за час активного времени человек переходит от одной категории задач к другой. IDE → браузер → мессенджер → снова IDE — это три переключения за несколько минут. Отдельно DevPace выделяет, какая доля этих переключений вызвана именно коммуникационными приложениями — мессенджерами и почтой, — потому что именно они чаще всего оказываются источником резких скачков.

Эта статья — про узкий и предельно личный вопрос: сколько переключений в час нормально конкретно для вас. Если интереснее более широкая картина — откуда вообще берётся цена одного переключения, что на этот счёт реально показали исследования и как посчитать потери за рабочий день, — подробный разбор в отдельном материале: Переключение контекста: сколько это стоит и как посчитать. Здесь же — конкретно про число в час и про то, что с ним делать.

Почему нет “правильного” числа

Первый вопрос, который задают почти все: а сколько переключений в час — это много? Честный ответ — универсального числа нет, и любой сервис, который его называет, скорее всего его придумал. У разработчика в режиме глубокой работы над одной задачей норма — 1-2 переключения в час, и это хорошо. У сотрудника поддержки или менеджера проекта, который весь день разруливает параллельные запросы, нормой может быть и 15-20 — это не признак проблемы, а сама суть роли. У продавца на телефонных созвонах, у HR в период активного найма, у дежурного по инцидентам частая смена контекста — это должностная обязанность, а не провал в фокусировке.

Даже у одного и того же человека норма разная в разные дни: день, когда нужно согласовать релиз с тремя командами, устроен иначе, чем день, запланированный под один сложный кусок кода. То же самое верно и в масштабе недели: спринт с релизом обычно фрагментированнее спокойной недели, отведённой под фичу с нуля. Именно поэтому фиксированный порог вроде “не больше 8 переключений в час” — плохой ориентир: он говорит что-то осмысленное только про одного конкретного человека в один конкретный период, а не про роль вообще.

Что известно о цене одного переключения (кратко)

Число переключений в час — только половина вопроса. Вторая половина — во что каждое переключение обходится, и здесь стоит быть аккуратным с цифрами, которые гуляют по интернету. Экспериментальная психология — в первую очередь работа Джошуа Рубинштейна, Дэвида Мейера и Джеффри Эванса 2001 года — показывает, что переход к новому набору правил задачи всегда стоит времени, даже когда обе задачи предельно просты и человек заранее знает, что будет переключение; эффект называется switch cost и растёт вместе со сложностью новой задачи. Софи Леруа в 2009 году описала соседний эффект, attention residue — “остаточное внимание”: часть внимания задерживается на незавершённой предыдущей задаче и мешает следующей, даже когда человек уже формально занят новым делом.

Полевое исследование Глории Марк, Дэниела Гудита и Ульриха Клоке (CHI, 2008) наблюдало за реальными офисными сотрудниками и показало, что к прерванной задаче обычно возвращаются не сразу — в среднем происходит ещё пара промежуточных дел, — а компенсация потерянного времени (люди действительно начинают работать быстрее после прерывания) достаётся ценой более высокого стресса и ощущения дефицита времени.

Здесь же уместно сказать про цифру, которая встречается почти в любом материале на эту тему: “23 минуты 15 секунд на возврат к задаче после отвлечения”. Её связывают с именем Глории Марк, но с точностью до секунд она не встречается в опубликованной рецензируемой статье в таком виде — это, скорее, растиражированное журналистами и блогерами упрощение, чем прямое измерение с указанной методологией. Разумно относиться к ней как к грубому ориентиру порядка величины, а не как к точной константе, которую можно подставить в формулу для любого дня и любой профессии. Полный разбор источников, методологии и того, как из этого честно посчитать потери за рабочий день, — в хабе про стоимость переключения контекста.

Сравнение с собой, а не с чужой нормой

Поэтому DevPace не показывает “у вас переключений больше среднего по индустрии” и не сравнивает с коллегами — такое сравнение не отвечает ни на один полезный вопрос, потому что не учитывает роль и характер задач. Вместо этого DevPace показывает тренд: как сегодняшний темп переключений соотносится с вашими собственными последними днями. Если обычно у вас 4-5 переключений в час, а сегодня 11 — это заметное отклонение именно для вас, и его стоит посмотреть внимательнее. Если у вас обычно 12, а сегодня 14 — это шум, не о чем беспокоиться.

Та же логика работает и в разрезе часов суток, а не только дней: почасовой график в разделе “Паттерны”, «В какое время дня я больше всего отвлекаюсь», схлопывает последние 30 дней в один усреднённый профиль часа. Если у вас, например, 13:00-14:00 стабильно выделяется частыми переключениями — это не случайность одного дня, а часть повторяющегося распорядка, и сравнивать эту цифру снова стоит не с чужим “нормальным часом”, а со своими же остальными часами.

Как это выглядит на реальных данных

Всё сказанное выше — про то, что нормы не существует в принципе. Но полезно увидеть, как эта метрика вообще выглядит на практике, а не только в теории. Для иллюстрации: у одного тестового аккаунта в DevPace, где накопилось около месяца данных, среднее число переключений категорий за последние 7 дней (из тридцатидневного окна, в котором не каждый день имел активность) составило около 6,4 в час активного времени. Это не выдуманное для примера круглое число, а реальный результат формулы, которая стоит за графиком “Тренд”: число переключений категорий, делённое на активное время в часах (а не на календарный час) — поэтому паузы и простой сами по себе не занижают показатель.

Отдельные дни внутри этой недели держались в диапазоне примерно 6,9-8,2 переключения в час — кроме одного нетипичного дня с заметно меньшим объёмом накопленных данных, где посчитанное значение оказалось ниже и потянуло итоговое среднее вниз, до тех самых 6,4. Это хорошая иллюстрация мысли из первого раздела: даже за одну неделю у одного и того же человека число заметно скачет ото дня ко дню, и один нетипичный, малонаполненный день способен сдвинуть недельное среднее сильнее, чем кажется на глаз.

Важно правильно прочитать эту цифру. Это не “средний норматив по всем пользователям DevPace” и не результат опроса или отдельного исследования — это фактический результат работы формулы на одной конкретной, тестовой учётной записи с правдоподобными, но не репрезентативными данными. Смысл в другом: показать, что метрика вообще устроена реалистично и ведёт себя предсказуемо на живых данных, а не в абстрактном примере с округлёнными цифрами — а не дать эталон, к которому нужно стремиться или которого нужно бояться, если ваше число выше или ниже.

На этом дне видно и общий счётчик переключений за день на карточке внизу, и саму последовательность работы — участок с частыми короткими отрезками разных категорий в середине дня, где темп переключений заметно выше, чем в начале и конце.

Внешние и внутренние отвлечения

Не любое переключение контекста запускается одинаково, и для личной нормы это тоже важно: у одного и того же человека соотношение типов переключений может сильно отличаться ото дня ко дню, и именно оно, а не голое число, обычно объясняет, почему один день “тяжелее” другого при одинаковом счётчике.

DevPace не видит содержимого переписки и не знает, что написано во входящем сообщении, — только категорию активности и её длительность. Но категория “коммуникации” выделена отдельно, и это уже даёт зацепку: если резко выросла именно доля переключений в мессенджеры и почту, это больше похоже на внешний триггер; если рост случился за счёт метаний между задачами внутри одной рабочей категории — это, скорее, внутренняя фрагментация. Различие важно и для личной нормы: у специалиста поддержки высокая доля внешних переключений — часть роли, а не сигнал проблемы; а вот у разработчика в режиме глубокой работы резкий рост именно внутренних, самостоятельно инициированных переключений чаще говорит об усталости, скуке или плохо сформулированной задаче, чем о внешнем давлении.

Как найти свою личную норму

Универсальное число получить не получится, но собственное — вполне, и для этого не нужно ничего, кроме нескольких обычных рабочих дней подряд.

1. Не смотрите на один день. Один день — это шум: он может выпасть на аврал или, наоборот, на редкий спокойный день. Ориентир строится по неделе-двум обычных дней, без отпуска и авралов.
2. Смотрите на среднее, а не на пик. Пиковый час почти у всех выше среднего — это не проблема само по себе, важно, как часто повторяется именно этот уровень.
3. Разделяйте типы переключений. Прежде чем решать, что не так, посмотрите, вырос ли внешний или внутренний тип из таблицы выше — у них разные причины и разные решения.
4. Ищите отклонение, а не абсолютное число. Вопрос не “у меня 9 в час — это много?”, а “у меня обычно 6, а сегодня 9 — это про что?”.
5. Пересматривайте норму при смене роли или проекта. Личная норма — не константа на годы вперёд: смена команды, роли или типа задач сдвигает её, и старое сравнение перестаёт быть честным.

Это именно то, что делает DevPace автоматически на графике “Тренд” — считает вашу собственную среднюю за период и подсвечивает день, заметно от неё отклонившийся, вместо того чтобы сравнивать с общим нормативом, которого попросту не существует.

Гипотетический пример: неделя, где темп пополз вверх

Представим человека, у которого в течение нескольких недель темп переключений держался в районе 5-6 в час. В понедельник — 6, во вторник — 7, а к четвергу и пятнице — уже 11-12. Само по себе число мало о чём говорит, но DevPace дополнительно показывает разбивку по причине переключения, и в этом примере видно, что почти весь прирост пришёлся именно на переключения в мессенджеры и почту — доля “коммуникационных” переключений выросла с обычных 30% до 70% от общего числа.

Это уже конкретная зацепка. Дело не в том, что человек стал хуже работать или “разучился фокусироваться” — просто на неделе резко выросла коммуникационная нагрузка: обсуждение задачи разбилось на десятки коротких сообщений вместо одного звонка, или несколько параллельных чатов требовали постоянного присутствия. Увидев это на графике, человек может сознательно решить: перенести часть обсуждений в один созвон вместо переписки весь день, или выделить закрытые интервалы без уведомлений на следующей неделе — и потом проверить по тому же графику, сработало ли это.

Почему это честнее, чем правило “держите переключения ниже N”

Правило вида “не больше 8 переключений в час” звучит просто, но игнорирует контекст: оно накажет специалиста поддержки за то, что он хорошо делает свою работу, и не заметит проблему у разработчика, который скатился с 2 до 7 переключений в час на ровном месте. Личная базовая линия решает обе проблемы сразу: она автоматически подстраивается под роль и характер дня и реагирует именно на отклонение от привычного для конкретного человека, а не на абстрактный порог.

Хорошим побочным индикатором того, насколько раздроблен день, служит и обратная метрика — доля глубокой работы: чем выше частота переключений, тем ниже, как правило, этот процент, и наоборот. Смотреть стоит на оба числа вместе, а не на одно в отрыве от другого.

Если хотите увидеть, как это выглядит на ваших собственных данных — Посмотреть демо и посмотрите на свою личную динамику переключений уже за первую неделю.

Смотрите также

• Переключение контекста: сколько это стоит и как посчитать
• Когда вы на самом деле сосредоточены, а когда только кажется
• Почему DevPace сравнивает вас только с вами самим

Посмотреть демо

Опубликовано: 30 июня 2026 г. · обновлено: 26 июля 2026 г.