(с)

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

Конечно, в такие дни вы начинаете трудиться сверхурочно, чтобы удержать в руках расползающуюся ткань реальности. Довольно скоро такой график становится нормой, и все привыкают, что вам можно писать письма (и требовать ответы) в любое время. Наступает момент выгорания. И тогда вы начинаете задумываться о практиках тайм-менеджмента.

Сотни людей вокруг, кажется, только и делают, что учат других. Давайте будем честны друг с другом: все курсы управления временем пишут психологи, менеджеры, кто угодно, только не разработчики. Но ведь многие основополагающие вещи контроля времени и управления проектами придумали именно программисты (Фредерик Брукс: «Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше»).

Теория, дофамин, бег времени

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

В 1962 году спелеолог Мишель Сифр провел эксперимент, в ходе которого он находился два месяца в одиночестве в пещере. Эксперимент закончился 14 сентября, в то время как Сифр думал, что еще только 20 августа.

Периоды бодрствования и сна «пещерного исследователя» в сумме составили 24,5 часа. Однако субъективные оценки временных промежутков, как продолжительных (сутки), так и кратковременных (120 с), изменились — время словно замедлилось. В более поздних экспериментах испытуемые переходили с 24-часовых суток на 48-часовые (36 часов бодрствования и 12 часов сна).

В другом исследовании, которое длилось полгода в пещере, испытуемый смог без всякого сна и дискомфорта для себя провести около 50 часов. Просто для него это время «текло» гораздо быстрее.

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

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

[Нейромедиатор дофамин является одним из химических факторов внутреннего подкрепления и служит важной частью «системы вознаграждения» мозга, поскольку вызывает чувство удовольствия (или удовлетворения). Естественным образом вырабатывается в больших количествах во время положительного, по субъективному представлению человека, опыта.(c)]

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

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

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

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

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

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

Практика, время, разработка

Itamar Turner-Trauring, главный инженер-программист Datawire, написал большую статью о продуктивности, из которой мы выбрали главные тезисы.

«Станьте более продуктивными, работая меньше часов.

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

Более короткая рабочая неделя улучшает вашу способность фокусироваться.

Долгая работа контрпродуктивна. Вы говорите себе вечером: «Мне нужно закончить одну маленькую проблему, просто нужно еще полчаса». Но, будучи усталым, на самом деле вы потратите еще три часа. На следующий день вы идете на работу усталым и не сфокусированным и на решение проблемы тратите еще больше времени.

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

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

Если выбрать путь наименьшего сопротивления, то вы просто сядете работать по ночам и в выходные.

Но есть и другая возможность — впереди 2 недели, много работы. Задумайтесь над тем, что нужно сделать для оптимизации этого времени. Вы можете выделить несколько часов только на то, чтобы тщательно обдумать проблему.

Возможно, решение будет заключаться в том, чтобы сделать задачу на 80%, написав такую функциональность, которая оставит клиента счастливым, пока вы не закончите все остальное.

Как установить границы короткой продуктивной недели?

Вы станете более эффективны, если сможете объяснить руководству, где находятся границы вашей рабочей недели, а затем будете придерживаться их: «Я собираюсь работать 40-часовую рабочую неделю, если не возникнет чрезвычайная ситуация».

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

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

Мелисса Грегг, главный инженер Intel, автор книги «Контрпродуктивный», в которой основное внимание уделяется управлению временем на работе, добавляет полезную информацию о связи между культурой работы и продуктивностью:

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

Demian Turner, автор PHPKitchen.com, работает с веб-проектами с открытым исходным кодом с 1996 года:

«Прочтите код опытных разработчиков; всегда есть лучший, более чистый и быстрый способ делать что-то. Не изобретайте снова колесо.

Убедитесь, что ваш код доступен для чтения; если вы не можете понять его через шесть месяцев, как это будет выглядеть для других разработчиков?

Всегда старайтесь упрощать интерфейсы; гораздо сложнее написать более простой код, но последовательный рефакторинг сэкономит вам много времени».

Элиот Горовиц, технический директор и сооснователь MongoDB, делится мнением о затратах времени на руководящих должностях:

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

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

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

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

Mickey W. Mantle разрабатывает программное обеспечение уже более 40 лет для Evans & Sutherland, Pixar, Broderbund, Gracenote и других компаний. Ron Lichty разрабатывает программное обеспечение уже 30 лет для Apple, Fujitsu, Razorfish и Schwab. Их точка зрения изложена в статье:

«Дэйв Уилсон, руководивший разработкой в Apple, Sun, HP, Portal и ParcPlace, поделился правилом, помогающим найти отличных программистов: «Нанимайте людей, которые занимаются разработкой в свободное время просто для удовольствия».

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

Другое правило, которому мы всегда следуем: проекты должны запускаться как марафоны. Вы должны установить правильный, здоровый темп, который поможет выиграть гонку и продержаться до финиша. Это время должно быть ограничено какими-то рамками: иногда программисту нужно много работать, быстро двигаться к финишной черте проекта, но вы не должны ждать, что программист будет работать в таком же темпе всегда».

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

Настоящие шедевры в области тайм-менеджмента для программистов вообще штучный продукт. Рекомендуем книгу Фредерика Брукса «Мифический человеко-месяц или как создаются программные системы», которая вышла в далеком 1975 году, но для многих, возможно, будет актуальна и сегодня.

Другая признанная «классика» вышла в 1999 году — это «Собор и Базар» Эрика Рэймонда. Эссе основано на анализе разработки ядра Linux и рассматривает недостатки различных моделей разработки свободного программного обеспечения, в том числе с точки зрения временных затрат.