После COVID-19 наша культура труда в основном изменилась к лучшему, но были и негативные изменения, например, увеличение количества совещаний на 13,5%[1].

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

В своей знаменитой статье «Maker's Schedule, Manager’s Schedule» [2] Пол Грэм писал:

«Когда работаешь в режиме творца, совещания — это катастрофа. Единственное совещание может поломать день, разделив его на две части, в каждой из которых невозможно сделать ничего достаточно сложного».

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

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

Но сначала давайте поговорим о глубокой работе:

Что такое глубокая работа?

Этот термин сформулировал Кэл Ньюпорт в своей книге «Deep Work: Rules for Focused Success in a Distracted World»[3].

Глубокая работа (Deep Work) — это работа, требующая большой доли мыслительных усилий, обычно несущая некую уникальную ценность. Её нельзя выполнять, когда тебя отвлекают! Если вы можете работать над задачей в процессе созвона через Zoom, то это — НЕ глубокая работа.

Поверхностная работа (Shallow Work) — это нечто противоположное: задачи, которые можно решать без напряжения 100% мозга. Например, это могут быть ответы на сообщения в Slack/почте, просмотр документа и так далее.

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

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

Почему глубокая работа настолько критична

Глубокая работа — единственный способ достижения состояния «потока».

Длительная глубокая работа позволяет разработчикам:

• Совершать меньше ошибок.

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

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

Менеджеры совершают большую ошибку, полагая, что благодаря ИИ-инструментам это уже не важно. Они думают, что разработчикам нужно привыкать к постоянному переключению контекста — между промптами всё равно ждать всего пару минут, так что кому важны эти отвлекающие факторы? 

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

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

В чём же проблема с глубокой работой?

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

С 2020 года в дополнение к росту общего количества совещаний на 13,5% также увеличилось на 60% число удалённых совещаний[5]. Неудивительно, что 92% сотрудников сообщают, что во время этих совещаний они пытаются заниматься многозадачностью[6], и мне кажется, в случае разработчиков ПО этот показатель почти равен 100%.

Здесь возникают две основные проблемы:

1. Глубокая работа превращается в поверхностную

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

Отличный пример этого — проверка пул-реквестов. Если сегодня занятой день с кучей совещаний, то когда их лучше всего проверять?

Разумеется, во время совещания… Но проверка пул-реквеста должна быть глубокой работой! То же самое относится к устранению багов и написанию дизайн-документов.

Выполнение этих задач во время совещания начинает порочный круг:

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

• Люди отвлекаются во время совещаний, поэтому качественные решения не принимаются → планируется ещё больше совещаний…

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

2. Разработчики не достигают состояния потока

Лишь для того, чтобы войти в темп, требуется 15 минут, и лишь через 45 минут (!) разработчик доходит до пика работоспособности, когда он полностью погружён в задачу[7].

Каждый раз, когда его отвлекают, из-за переключения контекста этот таймер сбрасывается. Исследование, проведённое компанией Meta*[8], продемонстрировало всю серьёзность проблемы — разработчикам удаётся выкроить всего две одночасовые сессии в неделю! (И мне кажется безумием, что трёхминутная сессия вообще считается «временем сосредоточения»). 

При этом теряется не только время, потраченное на совещания. Каждый отвлекающий момент отбрасывает разработчика назад на 15-45 минут, из-за чего даже в ЛУЧШЕМ случае он успевает набрать за день всего один-два часа продуктивной работы.

Мне нравится эта аналогия, которую я позаимствовал из комментария на Reddit[9]:

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

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

Поэтому, если вы хотите, чтобы они добывали вам бриллианты, оставьте их в покое.

Разработчикам ПО нужно как минимум по 4-5 часа работы без помех в день, а задача менеджера — обеспечить им это время.

Как можно создавать время для глубокой работы

Улучшать культуру совещаний в компании

Исправить её не так уж сложно — нужно «всего лишь» сделать так, чтобы все менеджеры придерживались простых правил:

1. Совещания должны быть эффективными. Казалось бы, это очевидно? Но так всё равно бывает редко… Совещанию нужны чёткая повестка и чёткие результаты.

2. Установите неизменное время для совещаний и оставляйте большие блоки времени, свободного от совещаний. Это могут быть дни или часы без совещаний. 

3. Приглашайте только тех, кто действительно необходим; особенно плохо это правило соблюдается при удалённой работе — сегодня стало слишком легко приглашать всех. Менеджеры думают так: «В худшем случае они будут работать в многозадачном режиме, зато окажутся доступными на случай необходимости».
   Это ужасный подход! Помните, что при многозадачности достичь состояния потока невозможно.

Каким же будет наилучшее решение? Избавляйтесь от максимально возможного числа совещаний! 

В течение двух лет мы изучали работу сотен команд разработчиков. Особенно нас впечатлила команда в компании Pylon. 

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

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

А если вы не можете избежать всех совещаний, то мы как минимум рекомендуем организовать в рамках всей компании блоки времени для сосредоточенной работы. Проанализировав данные более чем 600 тысяч пул-реквестов, мы выяснили, что большинство разработчиков продуктивнее всего в интервалах 09:00-11:00 и 14:00-16:00:

*Примечание: учитывалось только время отправки коммитов, и мы знаем, что люди, вероятно, работали в часы до этого (а ещё есть обеденный перерыв). Тем не менее, мы считаем, что существуют «кластеры» продуктивных временных интервалов и что дробить рабочий день сотрудников не нужно!

Пересмотрите свой процесс работы с пул-реквестами

На самом ли деле вам нужны все эти пул-реквесты?

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

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

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

Покажите пример

Разобравшись с совещаниями, можно начать разбираться с другими отвлекающими факторами.

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

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

Сегодня время сосредоточения становится крайне важным 

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

Примечания

[1] https://www.notta.ai/en/blog/meeting-statistics 

[2] https://paulgraham.com/makersschedule.html

[3] https://www.goodreads.com/book/show/25744928-deep-work

[4] https://hbr.org/2014/05/create-a-work-environment-that-fosters-flow

[5] https://www.cfo.com/news/remote-meetings-up-60-since-2020-weekly-stat/654749/

[6] https://www.flowtrace.co/collaboration-blog/50-meeting-statistics

[7] https://www.locationrebel.com/flow-state/#:~:text=The%20science%20shows%20us%20that,disturb%20you%20until%20after%20lunch.

[8] https://users.encs.concordia.ca/~pcr/paper/YChen2022ICSE-industry-preprint.pdf?utm_source=chatgpt.com

[9] https://www.reddit.com/r/programming/comments/1bbcoec/comment/ku9i16h/