Рабочий день в клочья: почему многозадачность не делает нас эффективнее

Бывает рабочий день, после которого вечером сидишь и не сразу понимаешь, от чего именно так устал.

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

Каждое отдельно выглядит нормально. Ответить — три минуты. Подключиться — десять. Посмотреть скриншот — вообще ерунда. Но к вечеру открываешь свой план и видишь неприятную вещь: важная задача почти не сдвинулась.

У меня такие дни чаще всего возникают не из-за одной большой проблемы, а из-за цепочки мелких незапланированных переключений. Весь день работа вроде кипит: отвечаешь, помогаешь, что-то проверяешь, кого-то направляешь, где-то участвуешь. Но если честно посмотреть на результат, главная задача дня осталась почти там же, где была утром.

И вот это самое неприятное. Формально ты не бездельничал. Наоборот, был полезным. Только полезность ушла в десятки мелких реакций, а не в движение большой задачи.

Рабочий день может быть забит до отказа и при этом почти не двигать важные задачи. Постоянная занятость и реальное продвижение — не одно и то же.

Эта статья не про идеальный мир, где можно отключить все уведомления, закрыть календарь, никому не отвечать и заниматься только сфокусированной работой. В реальной 1С/IT-практике так нельзя. Есть много задач, где реакция действительно нужна.

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

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

Многозадачность часто выглядит лучше, чем работает

Слово “многозадачность” звучит почти как комплимент. Человек умеет быстро реагировать, держит несколько процессов, всем помогает, не теряется в потоке. В вакансиях и резюме это иногда выглядит как суперспособность.

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

Аналитик пишет спецификацию требований и отвлекается на уточнение от пользователя. Руководитель пытается подумать над планом, но день порезан короткими созвонами. Поддержка разбирает обращение, а рядом уже мигают еще три “срочно”. Разработчик смотрит сложную ошибку, но между проверками отвечает в личке.

Со стороны такой день выглядит очень рабочим. Человек всё время занят. Но внутри сложная задача каждый раз открывается почти заново.

Нужно вспомнить, где остановился. Что уже проверил. Какую гипотезу отбросил. Почему полез именно в этот участок кода. Какой пользовательский сценарий хотел проверить. Что хотел написать в следующем абзаце спецификации требований.

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

Небольшой пример из практики

У меня был рабочий день, когда в плане стояла большая доработка в 1С. Нужно было спокойно пройти логику изменения, проверить сценарии, не забыть про права, данные, проверки и последствия для пользователей. То есть не просто “поправить пару строк”, а удержать цель изменения и понять, как оно потом будет жить в сопровождении.

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

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

Проблема была в сумме. Я несколько раз возвращался к основной задаче и каждый раз заново вспоминал, на чем остановился. Вроде база открыта, задача открыта, код перед глазами, но внутренне приходится снова собирать цепочку: что уже проверил, какой вариант отбросил, какой следующий шаг хотел сделать.

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

Что говорят исследования, если перевести их на обычный рабочий день

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

American Psychological Association в материале про switching costs объясняет, что при переходе между задачами возникают когнитивные издержки. Там же упоминается оценка, что частые переключения могут стоить до 40% продуктивного времени. Я не стал бы подавать эту цифру как закон для всех профессий и всех людей. Но как предупреждение она полезна: переключение не бесплатно.

Исследование Gloria Mark, Daniel Gudith и Ulrich Klocke “The Cost of Interrupted Work: More Speed and Stress” добавляет важную деталь. После прерываний люди могут пытаться работать быстрее. Снаружи это может даже выглядеть нормально: человека отвлекли, он вернулся и ускорился. Но цена такого ускорения — стресс, фрустрация, давление времени и большее усилие.

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

У Sophie Leroy есть полезная идея attention residue — остаток внимания. Если переключиться с одной незавершенной задачи на другую, часть внимания может продолжать оставаться в первой. Ты уже открыл новую задачу, но внутри еще держишь старую: “а там я точно проверил условие?”, “почему отчет не сошелся?”, “что я хотел написать дальше?”.

Для 1С это очень узнаваемо. Особенно когда работаешь не с одной кнопкой, а с цепочкой: пользовательский сценарий, права, движения документа, регистры, отчет, обмен, фоновые задания, обработчики, тестовые данные. Пока держишь эту цепочку в голове, задача идет. Стоит несколько раз вылететь из нее — и приходится собирать всё заново.

Почему “быстрый вопросик” редко бывает бесплатным

Самая коварная форма переключения — “быстрый вопросик”.

Он правда может быть быстрым. Три минуты в переписке. Один скриншот. Одна ссылка. Одно “да, посмотри вот здесь”. Формально ничего страшного.

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

Особенно это чувствуется на больших задачах. Например, ты работаешь над доработкой. В этот момент прилетает: “Посмотри отчет, там что-то не так”.

Ты отвлекся. Ответил. Вернулся. Конфигуратор открыт, задача открыта, база открыта. Но мысль уже не открыта. 

Один такой вопрос не разрушит день. Два-три тоже можно пережить. Но если весь день состоит из таких вопросов, большая задача превращается в фон. Ты открываешь ее десять раз, но каждый раз не успеваешь зайти достаточно глубоко.

“Быстрый вопросик” может быть коротким для того, кто спросил, но длинным для того, кого выдернули из сложной работы.

Важно не обвинять людей за вопросы. Вопросы будут всегда. Пользователь не обязан знать, что у разработчика сейчас в голове сложная цепочка проверок. Руководитель не всегда видит, что короткий созвон разрезал единственный нормальный фокус-блок за день. 

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

Контекст — это не просто “я помню название задачи”

Когда говорят “потерял контекст”, иногда кажется, что речь о чем-то абстрактном. На практике контекст — это конкретные рабочие связи.

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

Постоянные переключения ломают именно этот момент. Человек не просто отвлекся на сообщение. Он потерял часть собранной рабочей модели.

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

Кто страдает от переключений

Эта тема не только про разработчиков. Разработчикам проще показать пример: код, ошибка, отладка, контекст. Но разорванный день бьет по всем, кто работает головой и держит в памяти рабочую логику.

У каждой роли свой контекст. Но механизм похожий: чем больше задача требует удерживать логику, тем болезненнее незапланированное переключение.

Какие задачи нужно защищать особенно

Не любую работу нужно защищать фокус-блоком. Есть задачи, которые нормально живут короткими подходами. Но есть работа, которую опасно делать между сообщениями.

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

Срочно или просто громко?

Один из самых сложных моментов — отличить реальную срочность от вопроса, который просто прилетел прямо сейчас.

Я не верю в совет “просто игнорируйте сообщения”. В рабочей реальности он слишком примитивный. Бывают ситуации, где реагировать нужно сразу.

Но не каждое сообщение становится срочным только потому, что оно пришло в личку.

Полезный вопрос перед переключением: что случится, если я отвечу не сейчас, а через час?

Если ответ — “ничего критичного”, это не авария. Это задача, которой нужно место в очереди, а не право разорвать любую текущую работу.

Что может сделать сам специалист

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

1. Выделять фокус-блоки под конкретный результат

Фокус-блок на 60–90 минут полезен не как модная привычка, а как рабочий инструмент под конкретную задачу. Не “поработать над ошибкой”, а “проверить две гипотезы по ошибке проведения”. Не “заняться требованиями”, а “дописать раздел по правам и ограничениям”. Не “подумать над релизом”, а “собрать риски и список проверок”.

Такой блок не делает человека недоступным на весь день. Он просто защищает кусок времени, где сложная задача может реально сдвинуться.

2. Перед неизбежным переключением оставлять себе след

Иногда тебя всё равно выдернут. Тогда полезно перед уходом из задачи оставить короткую заметку:

• что сейчас проверял;
• какая была гипотеза;
• что уже не подтвердилось;
• какой следующий шаг.

Это занимает меньше минуты, но при возврате экономит гораздо больше. Такая заметка работает как закладка: не нужно заново вспоминать, почему задача была открыта именно в этом месте.

3. Разбирать мелкие вопросы пачками

Если отвечать на каждый мелкий вопрос сразу, день быстро распадается. Лучше выделять окна для мелких вопросов: после фокус-блока, перед обедом, ближе к концу дня.

Да, часть вопросов подождет. И часто окажется, что ничего страшного не произошло.

4. Не планировать день так, будто прерываний не будет

Это частая ошибка. Человек ставит на день несколько сложных задач, хотя знает, что половина времени уйдет на коммуникации, поддержку, уточнения и согласования.

Потом вечером появляется чувство провала. Но проблема была не только в переключениях. Проблема была еще и в плане, который не учитывал реальность.

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

5. Отключать не всё, а лишнее

Совет “отключите уведомления” часто звучит оторвано от жизни. В команде могут быть реальные аварии. Значит, нужен не информационный вакуум, а фильтр.

На время сложной работы можно отключить то, что не является аварийным каналом. А для действительно важных вещей оставить понятный способ достучаться.

Что может сделать команда

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

Команде нужны простые правила. Не толстый регламент на двадцать страниц, а понятные договоренности: куда писать, что считать срочным и когда не нужно дергать человека напрямую.

1. Не превращать личку в систему задач

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

Если вопрос требует проверки, решения или времени, ему место в задаче, очереди поддержки или общем канале с понятными правилами.

2. Договориться, что считается срочным

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

Тогда слово “срочно” перестает быть просто усилителем сообщения.

3. Сделать отдельный канал для действительно важных вещей

Если специалист на время фокус-блока отключает часть уведомлений, у команды должен быть понятный аварийный канал. Но этот канал нельзя превращать в обычную личку с красной лампочкой.

Иначе он быстро перестанет быть фильтром. Туда снова начнет прилетать всё подряд: от критичной ошибки до вопроса “а где посмотреть старый отчет?”.

4. Использовать первую линию или очередь обращений

Первая линия нужна не для того, чтобы спрятать разработчика или аналитика от людей. Она нужна, чтобы к специалисту не прилетало каждое “не вижу кнопку” без проверки базы, периода, отборов, прав и инструкции.

Часть обращений решается до передачи дальше. А если вопрос действительно требует специалиста, он приходит уже в нормальном виде: кто пользователь, что делал, что ожидал, что получил, что уже проверили.

5. Не назначать созвоны без понятной цели

Созвон “на минуту” редко занимает минуту. Но даже если он короткий, он разрывает рабочий блок.

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

Вид переключения, скрытая цена и что сделать

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

Чек-лист: задача требует фокус-блока, если...

• нужно держать в голове несколько условий;
• ошибка плохо воспроизводится;
• требуется написать или проверить важный текст;
• нужно принять решение с последствиями;
• цена ошибки высокая;
• после каждого возврата приходится вспоминать контекст заново;
• важен не быстрый ответ, а качество решения.

Если по задаче совпадает хотя бы несколько пунктов, ее опасно делать между сообщениями. Так можно долго “заниматься задачей”, но не двигать ее по сути.

Как понять, что день уже разорван на куски

• к вечеру сильная усталость, но главный результат не готов;
• одна и та же задача открывалась много раз, но каждый раз ненадолго;
• при возврате приходится вспоминать, что вообще хотел сделать;
• половина работы прошла в ответах и уточнениях;
• план дня проиграл тому, что громче прилетело в чат;
• появляется раздражение даже на нормальные рабочие вопросы;
• сложные задачи постоянно переносятся “на завтра”.

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

Фокус — это не отказ помогать

Разговор о фокусе легко понять неправильно. Будто человек хочет не отвечать, не помогать, не участвовать в командной работе и заниматься только своими задачами.

Но фокус нужен не для изоляции от команды. Он нужен, чтобы команда получала нормальный результат.

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

Задача не в том, чтобы запретить вопросы. Задача в том, чтобы вопросы не уничтожали весь рабочий день.

Практические правила 

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

1. На день выбирать одну главную крупную задачу. Не шесть “важных”, а одну, которую реально нужно сдвинуть.
2. Ставить фокус-блок под конкретный результат. Например: проверить гипотезу по ошибке, дописать раздел, подготовить решение.
3. Перед неизбежным переключением записывать следующий шаг. Это снижает цену возврата.
4. Разбирать мелкие вопросы пачками. Не каждое сообщение требует реакции в ту же минуту.
5. Определить аварийный канал. Для реально важных вещей должен быть фильтр, а не общий шум.
6. Не называть срочным то, что просто удобно получить сейчас. Иначе слово “срочно” быстро обесценивается.
7. Планировать день с учетом коммуникаций. Если роль связана с людьми, нельзя делать вид, что весь день будет чистым фокусом.

Это не волшебная система. Она не уберет все прерывания. Но она помогает вернуть главное: возможность хотя бы часть дня работать не в режиме дерганья, а в режиме продвижения.

Вывод

Многозадачность часто не ускоряет работу, а дробит внимание. Особенно там, где нужно думать, держать контекст, проверять гипотезы, писать важный текст, принимать решения и не ошибаться.

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

Это не значит, что нужно закрыться от людей. Вопросы, поддержка и срочные проблемы никуда не исчезнут. Но если все вопросы летят напрямую, сразу и без фильтра, важные задачи каждый день будут проигрывать рабочему шуму.

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

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

Что использовал

• American Psychological Association — Multitasking: Switching costs. Использована мысль о стоимости переключения между задачами и осторожное упоминание оценки “до 40%” как неуниверсального ориентира. Ссылка: https://www.apa.org/topics/research/multitasking
• Gloria Mark, Daniel Gudith, Ulrich Klocke — The Cost of Interrupted Work: More Speed and Stress. Использована мысль, что после прерываний люди могут работать быстрее, но платят за это стрессом, фрустрацией, давлением времени и усилием. Ссылка: https://dl.acm.org/doi/10.1145/1357054.1357072
• Sophie Leroy — Why is it so hard to do my work? The challenge of attention residue when switching between work tasks. Использована идея attention residue: часть внимания может оставаться на предыдущей незавершенной задаче. Ссылка: https://doi.org/10.1016/j.obhdp.2009.04.002
• Rubinstein, Meyer, Evans — Executive control of cognitive processes in task switching. Использовано как дополнительное подтверждение, что переключение задач связано с отдельными когнитивными процессами. Ссылка: https://pubmed.ncbi.nlm.nih.gov/11518143/