Автор статьи — программист с шестнадцатилетним стажем работы — был поставлен перед невозможностью подолгу сидеть за компьютером (как поступают многие из нас). В этой статье он рассказывает о том, как организовать свою рабочий процесс так, чтобы частые перерывы не вредили возможности сосредоточиться на работе и эффективности труда. В принципе достаточно известные вещи, но лично для меня стали новостью инвертирование приоритетов и сам факт того, что можно работать отвлекаясь и при этом не терять ход мысли.
Я не могу безболезненно сидеть за столом дольше часа подряд, и я не могу работать больше, чем стандартный восьмичасовой день. Проблема в том, что последние 15 лет моя стратегия работы заключалась в том, чтобы поймать «поток» и после этого кодить очень долго без перерывов. Эта стратегия очень популярна у кодеров, любящих запираться на сутки, надевать наушники и отключаться от внешнего мира — и именно поэтому они так болезненно реагируют, когда их отвлекают. Программирование требует концентрации, а концентрация работает по принципу клапанного механизма — на разогрев и запуск требуется время, поэтому уже запущенный механизм лучше не останавливать.
Я не думал, что существуют другие способы программирования, и уже начал было смиряться с тем, что обречен на низкую производительность. Но за последние 6 месяцев я обнаружил, что «медленный разогрев и долгая работа без перерывов» — поведение приобретенное, а не врожденное, и вполне возможно переучиться на другие ритмы активности. Это похоже на многофазный сон — как только вы привыкли делать вещи определенным образом, любые изменения очень трудоемки, но возможны — при наличии достаточной мотивации и времени на привыкание.
Итак, моей целью было научиться работать небольшими подходами с сохранением эффективности. Фокус в том, как научиться возвращаться в «поток» как можно быстрее — так же, как люди, практикующие многофазный сон, быстрее достигают фазы быстрого сна. Какие же способы я использовал, чтобы этого добиться?
Это не столько техника, сколько психологический настрой, красной нитью проходящий через все следующие советы. Вместо того, чтобы любой ценой избегать перерывов, принимайте их и научитесь с ними обращаться. Это непросто — первое время вам будет казаться, что вы все время отвлекаетесь, ничего не успеваете, и вам будет хотеться бросить это и вернуться к привычной модели поведения. Этот этап нужно перетерпеть и научиться принимать перерывы как часть вашего ритма.
Самое неприятное в том, чтобы отвлекаться от работы, — это потеря контекста. Когда вы «в потоке», вы держите в голове большую часть контекста, постоянно ее меняя и подстраивая под то, что вы делаете. Стоит вам отвлечься, картина утеряна, и ее восстановление требует изрядного времени. Мой рецепт для борьбы с этим — выносить наружу как можно больше деталей на как можно большем числе уровней.
Я — свой собственный хроникер. Я все время записываю, что я делаю, будь это комментарий к тикету, частые коммиты с подробными комментариями или просто записки на бумаге. Для ориентира, примерно каждые полчаса у меня появляется новый фрагмент внешнего контекста, иначе после перерыва его будет уже сложнее восстановить. Это не так обременительно, занимает совсем немного времени, и имеет и другие плюсы — например, способствует систематизации мыслей и лучшему отслеживанию процесса принятия решений.
Вы, должно быть, заметили, что в предыдущем пункте я использовал «задание» в единственном числе. Правильно. Нет никаких «текущих заданий» — только текущее задание и отвлекающие факторы. Мы все используем баг трекеры для контроля того, что нужно сделать, но когда работаем над чем-то одним, очень часто замечаем другую ошибку, или возможное улучшение, или классную новую фишку. Как часто мы отвлекаемся от текущей работы и переключаемся на новую мысль, потому что это тривиально, или мы уже в теме, или просто это так здорово, что хочется попробовать прямо сейчас? Я больше так не делаю; любые мысли, не относящиеся к текущему заданию, независимо от их важности и размера, отправляются в баг трекер и немедленно выбрасываются из головы до тех пор, пока я не заканчиваю текущее задание. Выигрыш такого подхода в том, что любой новый вопрос добавляет один уровень к контексту, который вы поддерживаете, и усложняет его восстановление после перерыва. Это звучит просто и очевидно, и может даже быть официальной процедурой в вашей компании, но попробуйте сказать, что вы действительно так делаете!
Это пункт из Getting Things Done, но он стоит того, чтобы его повторить. Половина эффективной работы — это точное знание, что делать дальше. Когда вы возвращаетесь с перерыва, вы не должны тратить время на выяснение того, что вы делаете дальше. Если у вас несколько текущих заданий, вам придется потратить время на выбор между ними — а это потерянное время. Здесь вам должен помочь ваш баг трекер и те комментарии, которые вы ведете по текущему заданию. Если вы были вынуждены переключиться на другой проект, внешний контекст должен помочь и здесь — для каждого проекта должен быть свой контекст и свое текущее задание. Более того, в каждый момент времени должно быть не только одно текущее задание, но и одно следующее действие по этому заданию.
Как решить, что делать дальше? На выяснение приоритетов у меня уходило множество времени: я исходил из того, что я хочу выполнить все, что есть в списке, и должен только оценить, что делать прежде всего. Со временем я обнаружил, что инвертирование процесса выбора уменьшает время, потраченное на планирование, и дает более четкие приоритеты. Для этого нужно предположить, что я не сделаю ничего из списка, и оценить негативные последствия невыполнения каждого пункта. Вместо «А или Б важнее сделать?» я решаю вопрос «А или Б дает худшие последствия, будучи невыполненным?». Разница может казаться незначительной, но второй подход дает более точные оценки.
В этой статье речь идет о негативных аспектах перерывов и отвлечений от работы. На самом деле у них не меньше и положительных следствий. Могу поспорить, что все кодеры когда-то засиживались допоздна или и вовсе на всю ночь, безрезультатно пытаясь исправить какую-то проблему, и обнаруживали, что утром это же делается за 15 минут, или придумывали решение где-нибудь в душе или в дороге. Это объясняется очень просто — длительные периоды сосредоточения кажутся продуктивными, и даже могут быть такими для действий, требующих последовательного мышления, но для творческого мышления и решения нестандартных задач все ровно наоборот. Усталый мозг работает нечетко, а решение вашей задачи часто лежит не на том же пути, по которому вы пробивались последние несколько часов, а в стороне, и требует взгляда с нового ракурса. Периоды сосредоточения обычно ограничивают мысль рамками текущего хода мысли, и приступы вдохновения и гениальные озарения становятся исчезающе редки. Именно поэтому прерывание сосредоточения может быть полезнее, чем мучительное продление еще на пару часов.
Я не могу безболезненно сидеть за столом дольше часа подряд, и я не могу работать больше, чем стандартный восьмичасовой день. Проблема в том, что последние 15 лет моя стратегия работы заключалась в том, чтобы поймать «поток» и после этого кодить очень долго без перерывов. Эта стратегия очень популярна у кодеров, любящих запираться на сутки, надевать наушники и отключаться от внешнего мира — и именно поэтому они так болезненно реагируют, когда их отвлекают. Программирование требует концентрации, а концентрация работает по принципу клапанного механизма — на разогрев и запуск требуется время, поэтому уже запущенный механизм лучше не останавливать.
Я не думал, что существуют другие способы программирования, и уже начал было смиряться с тем, что обречен на низкую производительность. Но за последние 6 месяцев я обнаружил, что «медленный разогрев и долгая работа без перерывов» — поведение приобретенное, а не врожденное, и вполне возможно переучиться на другие ритмы активности. Это похоже на многофазный сон — как только вы привыкли делать вещи определенным образом, любые изменения очень трудоемки, но возможны — при наличии достаточной мотивации и времени на привыкание.
Итак, моей целью было научиться работать небольшими подходами с сохранением эффективности. Фокус в том, как научиться возвращаться в «поток» как можно быстрее — так же, как люди, практикующие многофазный сон, быстрее достигают фазы быстрого сна. Какие же способы я использовал, чтобы этого добиться?
1. Приветствуйте перерывы
Это не столько техника, сколько психологический настрой, красной нитью проходящий через все следующие советы. Вместо того, чтобы любой ценой избегать перерывов, принимайте их и научитесь с ними обращаться. Это непросто — первое время вам будет казаться, что вы все время отвлекаетесь, ничего не успеваете, и вам будет хотеться бросить это и вернуться к привычной модели поведения. Этот этап нужно перетерпеть и научиться принимать перерывы как часть вашего ритма.
2. Храните контекст во внешней памяти
Самое неприятное в том, чтобы отвлекаться от работы, — это потеря контекста. Когда вы «в потоке», вы держите в голове большую часть контекста, постоянно ее меняя и подстраивая под то, что вы делаете. Стоит вам отвлечься, картина утеряна, и ее восстановление требует изрядного времени. Мой рецепт для борьбы с этим — выносить наружу как можно больше деталей на как можно большем числе уровней.
2.1. Комментируйте текущее задание
Я — свой собственный хроникер. Я все время записываю, что я делаю, будь это комментарий к тикету, частые коммиты с подробными комментариями или просто записки на бумаге. Для ориентира, примерно каждые полчаса у меня появляется новый фрагмент внешнего контекста, иначе после перерыва его будет уже сложнее восстановить. Это не так обременительно, занимает совсем немного времени, и имеет и другие плюсы — например, способствует систематизации мыслей и лучшему отслеживанию процесса принятия решений.
2.2. Безжалостно игнорируйте соседние вопросы
Вы, должно быть, заметили, что в предыдущем пункте я использовал «задание» в единственном числе. Правильно. Нет никаких «текущих заданий» — только текущее задание и отвлекающие факторы. Мы все используем баг трекеры для контроля того, что нужно сделать, но когда работаем над чем-то одним, очень часто замечаем другую ошибку, или возможное улучшение, или классную новую фишку. Как часто мы отвлекаемся от текущей работы и переключаемся на новую мысль, потому что это тривиально, или мы уже в теме, или просто это так здорово, что хочется попробовать прямо сейчас? Я больше так не делаю; любые мысли, не относящиеся к текущему заданию, независимо от их важности и размера, отправляются в баг трекер и немедленно выбрасываются из головы до тех пор, пока я не заканчиваю текущее задание. Выигрыш такого подхода в том, что любой новый вопрос добавляет один уровень к контексту, который вы поддерживаете, и усложняет его восстановление после перерыва. Это звучит просто и очевидно, и может даже быть официальной процедурой в вашей компании, но попробуйте сказать, что вы действительно так делаете!
2.3. Всегда знайте, что делать дальше
Это пункт из Getting Things Done, но он стоит того, чтобы его повторить. Половина эффективной работы — это точное знание, что делать дальше. Когда вы возвращаетесь с перерыва, вы не должны тратить время на выяснение того, что вы делаете дальше. Если у вас несколько текущих заданий, вам придется потратить время на выбор между ними — а это потерянное время. Здесь вам должен помочь ваш баг трекер и те комментарии, которые вы ведете по текущему заданию. Если вы были вынуждены переключиться на другой проект, внешний контекст должен помочь и здесь — для каждого проекта должен быть свой контекст и свое текущее задание. Более того, в каждый момент времени должно быть не только одно текущее задание, но и одно следующее действие по этому заданию.
3. Устанавливайте отрицательные приоритеты
Как решить, что делать дальше? На выяснение приоритетов у меня уходило множество времени: я исходил из того, что я хочу выполнить все, что есть в списке, и должен только оценить, что делать прежде всего. Со временем я обнаружил, что инвертирование процесса выбора уменьшает время, потраченное на планирование, и дает более четкие приоритеты. Для этого нужно предположить, что я не сделаю ничего из списка, и оценить негативные последствия невыполнения каждого пункта. Вместо «А или Б важнее сделать?» я решаю вопрос «А или Б дает худшие последствия, будучи невыполненным?». Разница может казаться незначительной, но второй подход дает более точные оценки.
4. Осознайте выгоды перерывов
В этой статье речь идет о негативных аспектах перерывов и отвлечений от работы. На самом деле у них не меньше и положительных следствий. Могу поспорить, что все кодеры когда-то засиживались допоздна или и вовсе на всю ночь, безрезультатно пытаясь исправить какую-то проблему, и обнаруживали, что утром это же делается за 15 минут, или придумывали решение где-нибудь в душе или в дороге. Это объясняется очень просто — длительные периоды сосредоточения кажутся продуктивными, и даже могут быть такими для действий, требующих последовательного мышления, но для творческого мышления и решения нестандартных задач все ровно наоборот. Усталый мозг работает нечетко, а решение вашей задачи часто лежит не на том же пути, по которому вы пробивались последние несколько часов, а в стороне, и требует взгляда с нового ракурса. Периоды сосредоточения обычно ограничивают мысль рамками текущего хода мысли, и приступы вдохновения и гениальные озарения становятся исчезающе редки. Именно поэтому прерывание сосредоточения может быть полезнее, чем мучительное продление еще на пару часов.
