Переключение контекста Slack–код: налог на deep work
Переключение контекста между Slack и кодом съедает часы глубокой работы каждую неделю. Как измерить потери, сократить их и защитить состояние потока.
By Ellis Keane · 2026-03-13
Сколько минут глубокой работы вы реально получили сегодня? Не время за столом. Не время с открытым IDE. Настоящая, непрерывная, сосредоточенная работа над одной задачей. Если вы можете уверенно ответить на этот вопрос, значит, вы либо лжёте, либо никогда не сталкивались с переключением контекста между Slack и кодом – в таком случае, искренне, научите меня.
Спрашиваю, потому что сам в большинстве дней не знаю своей цифры. Я знаю, что сел работать над миграцией базы данных в 9 утра. Знаю, что в какой-то момент поднял взгляд, а было уже часа. И знаю, что где-то между этим я открывал Slack раза два дюжины – не потому что кто-то нуждался во мне, а потому что этот маленький красный значок обладает гравитационным притяжением, которого устыдился бы небольшой спутник. Миграция, которая должна была занять утро, растянулась до среды.
Миф о 23 минутах (и что на самом деле верно)
Вы, вероятно, встречали статистику: «на повторную концентрацию после переключения контекста уходит 23 минуты». Она происходит из исследования Глории Марк в Калифорнийском университете Ирвайна, и хотя исследование реально, цифра так часто цитируется неверно, что фактически превратилась в ощущение. 23 минуты – это время возврата к исходной задаче, а не время возврата к той же глубине концентрации; и оно было измерено у работников умственного труда в целом, а не специфически у разработчиков.
Для разработчиков реальная стоимость целиком зависит от того, что вы держите в голове. Отлаживаете тонкое состояние гонки, где наконец, после двадцати минут вглядывания, выстроили ментальную модель трёх взаимосвязанных конечных автоматов? Потеря этой модели обходится вам теми же двадцатью минутами. Исправляете опечатку в конфигурационном файле? Секунды. Дело не в точной цифре. Дело в том, что переключение контекста между Slack и кодом имеет стоимость, совершенно невидимую в момент переключения, но чётко проявляющуюся в скорости спринта в конце недели.
Отчёт Lokalise об усталости от инструментов обнаружил, что работники переключаются между приложениями в среднем 33 раза в день, а 17% делают это более 100 раз. Мы построили целую экосистему «продуктивного» ПО, чей основной измеримый эффект – прерывание продуктивности. Где-то продакт-менеджер празднует показатели DAU, состоящие целиком из людей, проверяющих, можно ли уже вернуться к работе.
Почему переключение контекста между Slack и кодом особенно дорого
Я хочу быть справедлив к Slack. Это по-настоящему хороший инструмент, и я не собираюсь утверждать, что инженерным командам следует возвращаться к IRC (хотя некоторые дни такая мысль приходит). Но переключение контекста из Slack в IDE категорически дороже, чем переключение между двумя вкладками браузера, и стоит понять, почему.
Несоответствие ментальных моделей. Когда вы глубоко в коде, вы держите в голове сложную модель – состояния переменных, цепочки вызовов функций, общую форму системы, которую изменяете, и конкретную последовательность изменений, которые нужно сделать в определённом порядке. Slack работает в совершенно другом когнитивном режиме: социальный контекст, ветки переписки, выяснение, кто о чём говорит и касается ли это вас. Переключение между этими режимами – это не как переключение вкладок. Это как переключение между двумя принципиально разными типами мышления, и у вашего мозга нет кнопки «сохранить состояние» ни для одного из них.
Налог неопределённости. Вот что на самом деле убивает вашу концентрацию: не само прерывание, а возможность прерывания. Когда появляется значок уведомления, вы не знаете, важно ли оно, пока не проверите. Эта неопределённость оседает в рабочей памяти как неразрешённый вопрос, подтачивая внимание, даже если вы сопротивляетесь переключению. Я и сам не лучше в этом – замечал, как переключаюсь в Slack через ⌘+Tab прямо посреди написания сообщения коммита, потому что значок мелькнул на периферии зрения. Сообщение было об удалении мёртвого кода. Уведомление – о том, как кто-то ответил на гифку другой гифкой. Продуктивный вечер.
Ловушка веток. Открываешь Slack, видишь уведомление, кликаешь в ветку, читаешь три сообщения, понимаешь, что твой вклад не нужен, выходишь, замечаешь значок в другом канале, проверяешь и его – и вдруг пять минут испарились, а логика миграции – далёкое воспоминание. Ирония в том, что модель веток Slack, призванная снизить шум, на самом деле увеличивает количество кликов между «увидел значок» и «убедился, что ничего не требует меня». Ветки внутри веток. Черепахи до самого дна.
Стоимость переключения контекста между Slack и кодом – это не секунды, проведённые в Slack. Это когнитивные издержки переключения между двумя принципиально разными режимами мышления, усиленные неопределённостью: стоило ли уведомление этого прерывания.
Что реально помогает (а что нет)
Я перепробовал большинство стандартных советов – и говорю «пробовал», а не «прочитал пост в блоге и покивал». Вот к чему я пришёл после примерно шести месяцев активного наблюдения за собственными паттернами отвлечений.
Что работает
- Запланированные окна в Slack. В дни глубокой работы проверяйте Slack в 9 утра, в полдень и в 15:00, а между проверками закрывайте приложение полностью (закрывайте, а не сворачивайте). Количество переключений снижается с пары десятков до однозначного числа. Полностью скрывать иконку из дока в дни фокуса – абсурд, но это работает.
- Режим «Не беспокоить» с исключениями по ключевым словам. Режим «Не беспокоить» Slack, настроенный на пропуск сообщений с определёнными терминами или от определённых людей. Тишина от шума, оповещения при реальной срочности. Несовершенно, но лучше, чем бинарный выбор.
- Пакетная отправка исходящих сообщений. Записывайте сообщения Slack в блокнот и отправляйте пачкой. Снижает отвлечения для других членов команды и устраняет последующие «подожди, игнорируй то последнее сообщение».
Что звучит разумно, но не выживает при столкновении с реальностью
- «Просто выключите уведомления». Великолепно защищает состояние потока. Зато вы пропускаете ветку, где команда меняет контракт API, который вы как раз реализуете. Лечение порождает собственную болезнь.
- «Поставьте статус "занят"». Люди игнорируют статусы. Статус не несёт реальной информации, потому что все всегда утверждают, что заняты – это рабочий эквивалент «как дела?» / «нормально».
Фильтрация на уровне системы
Подход с запланированными окнами работает, но это дисциплинарное решение – а дисциплинарные решения имеют срок годности. Три недели удерживаете, что-то срочное ломает паттерн, и снова проверяете Slack каждый раз, когда значок шевельнётся. Я прошёл этот цикл достаточно раз, чтобы знать: решение – не больше силы воли. Решение – лучший фильтр.
Что реально решило бы проблему переключения контекста на уровне системы – это нечто, понимающее одновременно, над чем вы работаете и что происходит в Slack, и умеющее отличить «в ветке есть решение, напрямую влияющее на код, который вы пишете» от «кто-то обсуждает варианты обеда в #random».
Именно это мы строим в Sugarbug. Он подключается к Slack (а также GitHub, Linear, Figma и другим), классифицирует каждый сигнал по типу – решение, блокер, вопрос, обновление статуса, шум – и связывает их с задачами и людьми. Вы видите, какая активность в Slack релевантна вашей текущей задаче, не открывая Slack. Без значка. Без налога неопределённости. Без пяти минут исследования веток, чтобы обнаружить, что нет, это уведомление было не о вас.
Конкретный пример из прошлой недели: я был глубоко в миграции векторного поиска, когда коллега принял решение в ветке Slack о модели эмбеддингов, которую мы будем использовать. Без фильтрации я бы либо пропустил это полностью (режим «Не беспокоить»), либо наткнулся на это спустя часы при ручном просмотре веток. Классификатор Sugarbug вывел это как сигнал «решение – релевантно вашей текущей задаче». Один взгляд, и вернулся к миграции.
Мы не решили это идеально – классификатор всё ещё упускает граничные случаи, и мы итерируем над тем, как представлять отфильтрованные сигналы, не создавая очередной поверхности уведомлений (что было бы великолепно ироничным автоголом). Но даже несовершенная фильтрация лучше, чем бинарность «все уведомления» или «никаких уведомлений». В тот день миграции я оцениваю, что по меньшей мере двадцать моих визитов в Slack были лишними – двадцать перезагрузок контекста, которые хороший фильтр мог бы полностью предотвратить.
Перестаньте платить контекстный налог каждый раз, когда появляется значок. Sugarbug выводит только те сигналы Slack, которые реально влияют на вашу текущую работу.
Q: Сколько реально стоит переключение контекста между Slack и кодом? A: Исследование Глории Марк из Калифорнийского университета Ирвайна показало, что на возврат к исходной задаче после отвлечения уходит около 23 минут, хотя реальная стоимость огромно варьируется в зависимости от сложности выполняемой работы. Для разработчиков, десятки раз в день переключающихся между Slack и IDE, это складывается в часы потерянной глубокой работы каждую неделю – и ментальная модель, которую вы с трудом выстроили, редко переживает этот круговой рейс нетронутой.
Q: Помогает ли Sugarbug снизить переключение контекста между Slack и кодом? A: Да. Вместо переключения в Slack для проверки, нужно ли ваше внимание, Sugarbug классифицирует сообщения Slack по типам и связывает их с задачей, над которой вы работаете. Решения, блокеры и вопросы, релевантные вашей текущей работе, появляются сами, без необходимости их разыскивать. Цель – устранить переключения «проверю на всякий случай», когда вы открываете Slack, не находите ничего требующего действий, а потом тратите три минуты, вспоминая, чем занимались.
Q: Стоит ли отключить уведомления Slack для снижения переключения контекста? A: Отключение звука защищает состояние потока, но означает, что вы пропустите то, что действительно важно, – например, ветку, где команда решает изменить API, который вы реализуете. Лучший подход – фильтрация: отличать сигналы, требующие вашего внимания сейчас, от шума, который может подождать. Запланированные окна Slack – хорошая ручная версия; Sugarbug – автоматизированная.
Q: В чём разница между переключением контекста и многозадачностью? A: Многозадачность – попытка делать два дела одновременно (с чем люди справляются откровенно плохо). Переключение контекста – это последовательный переход между задачами; стоимость – время и когнитивные усилия на восстановление ментальной модели кода. Для разработчика, удерживающего в голове сложную систему, это восстановление может занять от нескольких секунд до получаса в зависимости от глубины работы.
Q: Может ли Sugarbug фильтровать, какие сообщения Slack стоят прерывания? A: Sugarbug классифицирует сигналы по типам и связывает их с задачами, над которыми вы работаете. Так что вместо открытия Slack и просмотра каждого канала вы видите, какая активность релевантна вашей текущей работе. Мы всё ещё итерируем по оценке релевантности (она не идеальна), но это значительно лучше, чем режим «всё или ничего» режима «Не беспокоить».
---
Если маршрут Slack–IDE выжимает ваши часы глубокой работы досуха – и если скрыть иконку из дока, чтобы не видеть значок уведомления, кажется вам разумной стратегией продуктивности – вот тот самый налог, ради снижения которого был создан Sugarbug. Войдите в лист ожидания.