Поток: как разработчики входят в него и почему их оттуда выбивают

Проблема: восемь часов на работе, два часа работы

Разработчик приходит в офис (или открывает ноутбук дома), садится за задачу, через десять минут приходит уведомление из Slack, потом standup, потом вопрос от коллеги, потом ревью чужого PR, потом синк с продакт-менеджером. К обеду задача продвинулась на 15 минут. Это типичный день, и проблема здесь в устройстве человеческого внимания.

Михай Чиксентмихайи в 1990 году описал состояние, которое назвал «потоком»: полное погружение в деятельность, когда человек теряет ощущение времени, работает с максимальной продуктивностью и испытывает глубокое удовлетворение от процесса. Чиксентмихайи выделил четыре условия для входа в поток: ясная цель (например, «сделать так, чтобы auth endpoint возвращал корректную ошибку при истёкшем токене»), немедленная обратная связь (тесты, компилятор, визуальный результат), баланс сложности и навыка (задача достаточно трудная, чтобы требовать концентрации, но не настолько, чтобы вызывать ступор), и защищённое окно времени без прерываний.

Цена переключения контекста

Исследователи из Microsoft Research измерили стоимость прерываний для разработчиков: после каждого переключения контекста инженер тратит 10–15 минут, чтобы вернуться к редактированию кода, и 30–45 минут, чтобы восстановить полный ментальный контекст задачи. Прерванные задачи занимают вдвое больше времени и содержат вдвое больше ошибок.

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

Особенно разрушительны «невинные» прерывания. Коллега подошёл «на секунду спросить». Уведомление в Slack, на которое даже не нужно отвечать. Календарное напоминание о встрече через час. Каждое из них стоит недорого по отдельности, но в сумме они превращают рабочий день в мозаику из фрагментов по 15–20 минут, ни один из которых не достаточен для входа в поток.

Maker’s Schedule vs Manager’s Schedule

Пол Грэм в эссе 2009 года описал фундаментальный конфликт двух рабочих режимов. Менеджеры работают в часовых блоках: встреча, встреча, перерыв, встреча. Для менеджера встреча составляет единицу работы. Разработчики работают в блоках по полдня: утро на код, после обеда на код. Для разработчика встреча означает разрушение рабочего блока.

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

Что работает на практике

Meeting-free дни. Shopify, GitHub и десятки других компаний выделяют два-три дня в неделю, когда запрещены встречи для инженеров. Это гарантирует, что у каждого разработчика есть блоки времени, достаточные для входа в поток. Shopify пошёл дальше и удалил все повторяющиеся встречи в начале 2023 года, заставив команды заново обосновать каждую из них.

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

Асинхронная коммуникация. Переход от real-time сообщений к асинхронным снижает количество прерываний. Разработчик проверяет Slack два-три раза в день в удобное время, а не реагирует на каждое уведомление. Это требует культурного сдвига: организация должна принять, что ответ через два часа считается нормой.

Режимы фокуса. DND-режимы в мессенджерах и статус «в потоке» в Slack помогают формализовать защиту фокусного времени.

Связь с DevEx Framework

DevEx Framework от Noda, Storey и Forsgren выделяет состояние потока как одно из трёх ключевых измерений Developer Experience наряду с feedback loops и когнитивной нагрузкой. Авторы фреймворка подчёркивают, что поток представляет собой свойство рабочей среды, а не индивидуальную характеристику. Организация либо создаёт условия для потока, либо системно его разрушает.