Переключение контекста — главный убийца продуктивности разработчика

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

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

Каждый раз, когда вы отправляете кому-то “коротенькое” сообщение через Slack, это стоит этому человеку 23 минуты продуктивной работы, и это лишь часть проблемы.

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

Итак, ныряем.

Что такое переключение контекста?

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

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

Термин “переключение контекста” позаимствован из операционных систем (ОС). ОС могут управлять несколькими процессами в одном обрабатывающем модуле (обычно это центральный универсальный процессор, ЦПУ), поставив один из процессов на паузу и работая с другим. Эти системы могут переключать контекст, тогда как наш мозг не может. 

Почему мы переключаем контекст? 

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

Работая, мы также чувствуем давление, которое диктует нам, что мы должны ответить немедленно, и это распыляет наш фокус еще сильнее (и принятая на работе культура обычно вознаграждает за это). И вокруг столько информации — электронные письма, чаты, открытые вкладки — и отвлечься так легко.

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

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

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

Но потерянное время — не самая большая из проблем 

Когда нас отвлекают, мы не просто теряем минуты, качество работы деградирует по многим показателям. 

Снижение ментальной энергии

Наши мозги не рассчитаны на постоянное переключение контекста. Каждое прерывание уменьшает наши когнитивные ресурсы, что напоминает батарейку в телефоне, которая садится гораздо быстрее, когда мы быстро переключаемся между приложениями. Исследование, проведенное Parnin and DeLine обнаружило, что разработчики, которых часто отвлекают, показывают признаки ментальной усталости намного раньше в течение дня, что ведет к большему количеству ошибок в их работе, проделанной во второй половине дня. Такая ментальная усталость может со временем привести к повышенному уровню стресса и даже выгоранию среди разработчиков.

Страдает качество кода

Исследование от Amoroso d'Aragona et al. (2023) проверило влияние прерываний и перерывов на разработку программного обеспечения и обнаружило удивительную корреляцию между переключением контекста и деградацией качества кода. Их анализ показал, что:

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

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

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

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

Эффект снежного кома

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

Понимание поточного состояния

Нам надо поговорить о так называемом “поточном состоянии”, чтобы понять, почему прерывания так плохи Это не просто жаргон программиста — это хорошо исследованное психологическое состояние, которое первым описал Mihaly Csikszentmihalyi в 1990-м году.

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

Вы чувствуете беспокойство или расстройство, если стоящий перед вами вызов слишком сложный по сравнению с вашими способностями. Если он слишком простой, вам скучно. Модель от Mihaly Csikszentmihalyi помещает поток посередине, там, где способности и вызов сбалансированы. В этой зоне вам достаточно сложно, чтобы задача представляла интерес, но не настолько, чтобы вы отключились. 

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

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

Исследования показывают, что отвлекающие моменты на мониторе дают существенный отрицательный эффект (Yimeng M. et al.). Нотификации с высоким приоритетом (например, срочные запросы от менеджеров) существенно повышают время, потраченное на задачи на понимание кода, которые являются самыми простыми. При этом те случаи, когда программиста отвлекает другой человек, не так уж и плохи: они помогают снизить уровень стресса. 

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

Урок от нашей команды

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

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

Но когда команда реализовала защищенное фокусное время, результаты оказались следующие:

• Степень выполнения задач выросла на 35%

• Баг-репорты снизились на 28%

• Оценки удовлетворенности команды выросли на 45%

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

Стратегии по предотвращению переключения контекста 

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

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

Для разработчиков

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

• Вносите задачи в TODO списки: вы можете использовать любой инструмент, такой как Todoist или Microsoft To Do, чтобы выгрузить туда список задач из вашей головы. Этот подход ослабит давление, и вы всегда сможете вернуться позже, чтобы проверить, над какой следующей задачей вам нужно поработать. Идентифицируйте вашу Самую Важную Задачу в TODO списке и выполняйте ее первой.

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

• Блоки для глубокого погружения в работу работы: помечайте свои 90-минутные временные блоки для сфокусированной работы. Исследования показывают, что это время является оптимальным для поддержания непрерывной концентрации. Нам необходимо как минимум 4-6 часов сосредоточенной работы. Отметьте эти блоки в своих календарях и относитесь к ним серьезно в течение дня, когда у вас больше всего энергии (для большинства людей это утро).

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

• Непрерывный рабочий процесс: как вы знаете по опыту решения сложных задач, вы можете оставлять себе “хлебные крошки”. Если вас прервут, быстро написанный комментарий о том, почему вы приняли то или иное решение в своем исходном коде в IDE, может сэкономить часы ментальной реконструкции. Вы также можете сделать это в конце дня, и назавтра вы сразу поймете, как начать работу. Этот подход также поможет нам бороться с эффектом Зейгарника (тенденцией занимать нашу рабочую память незаконченными задачами).

• Минимизируйте отвлекающие факторы: этот пункт может включать звукоизолирующие наушники, отключение несущественных нотификаций или создание зарезервированного рабочего пространства. Прекрасным способом уменьшить количество отвлекающих факторов является отключение мессенджеров (Slack-а и прочих) на некоторое время и включение режима “Не беспокоить” на телефоне.

• Не работайте в многозадачном режиме: наш мозг может корректно фокусироваться только на чем-то одном. Попробуйте фокусироваться только на одной задаче за раз. 

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

• Организованное окружение: ничем не захламленное рабочее пространство снижает когнитивную нагрузку, помогая сосредоточиться на задаче. 

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

• Установите повторяющийся ритуал: нашим мозгам это нравится. Начинайте день с определенного ритуала, и он подаст мозгу сигнал, что пора входить в зону 

• Регулярные перерывы: перерывы по расписанию, такие, как, например, техника Pomodoro, могут помочь поддерживать высокую концентрацию и предотвратить выгорание.

  

• Устанавливайте свой уровень реагирования: если вы работаете в офисе, где высоко ценят вашу доступность, проверьте свой уровень реагирования на обращения. Как написали авторы книги “Алгоритмы жизни”, "Будьте отзывчивы ровно настолько и не более."

• Отдыхайте: невозможно долго работать без перерывов, поскольку это может навредить нам. Попробуйте делать короткие перерывы, меняйте свое местоположение, сделайте себе кофе, а обеденный перерыв используйте только под обед.

Для команд

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

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

• Асинхронные коммуникации должны по умолчанию означать удаленную (много документации, мало митингов) культуру работы. Если вы работаете удаленно, вы должны тратить больше времени для написания и использовать инструменты, которые могут помочь вам сохранять там важные переговоры, чтобы было проще догнать остальных. Вы можете также использовать инструменты, подобные отправке по расписанию в Slack, чтобы ваши коллеги не могли отвлечь вас в ваше фокусное время. Кроме того, когда вы посылаете что-то в середине дня, вы можете сказать, “Нет необходимости отвечать сразу, если вы работаете над чем-то.”

• Гибкие рабочие часы: предложите людям гибкие рабочие часы, чтобы можно было подстраиваться под индивидуальные фокусные времена. 

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

• Говорите на митингах по существу (да, это возможно). Разрешайте сотрудникам пропускать митинги, где нет понятной повестки или отсутствует причина для их присутствия. Это заставит организаторов уважать чужое время и позволит сотрудникам сосредоточиться на работе с высоким приоритетом. Кроме того, ставьте митинги в расписание таким образом, чтобы они оказывались рядом с естественными перерывами в работе (до или после обеда, начало или конец рабочего дня).

Измерение прогресса

Чтобы понять, работает ли ваше управление прерываниями, отслеживайте эти метрики:

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

• Длительность непрерывных сессий написания кода. Следите за тем, чтобы этот параметр со временем рос. 

• Метрики качества кода. Следите за количеством багов и обратной связью по code review.

• Оценки удовлетворенности команды. Регулярно проводите исследования в команде.

• Тренды по скорости спринтов. Посмотрите, быстрее ли вы движетесь вперед после снижения числа отвлекающих факторов.

Эти метрики дадут вам некую часть от целой картины, показывающей, как эти изменения увеличили производительность разработчиков. Например, во фреймворке SPACE они напрямую увеличивают такие параметры, как Satisfaction (Удовлетворение) и Well-being (благополучие), а в DORA они влияют на параметр Lead Time for Changes (Время достижения перемен), поскольку частые прерывания работы замедляют разработку и снижают настрой на работу.

Движение вперед

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

Помните, что:

• Переключение контекста отнимает у человека больше, чем несколько минут. Оно нарушает фокусировку и снижает качество кода.

• Поточное состояние повышает продуктивность, но оно очень хрупкое.

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

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

Защитите ваше фокусное время; ваш код (и команда) скажут вам спасибо.

Присоединяйтесь к русскоязычному сообществу разработчиков на Spring Boot в телеграм — Spring АйО, чтобы быть в курсе последних новостей из мира разработки на Spring Boot и всего, что с ним связано.