Новый перевод от команды 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.). Нотификации с высоким приоритетом (например, срочные запросы от менеджеров) существенно повышают время, потраченное на задачи на понимание кода, которые являются самыми простыми. При этом те случаи, когда программиста отвлекает другой человек, не так уж и плохи: они помогают снизить уровень стресса.
Интересные статьи
Интересные статьи
