Как распланировать рабочий день разработчика 

Михаил Брычкин

технический директор digital-агентства iBRUSH

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

Для начала с чего вообще начинать составление любого плана? В первую очередь, с формирования списка задач, которые нужно сделать, и их оценки. Тут никаких открытий: все слышали про SMART, спринты, бэклог и прочее, поэтому не будем задерживаться на этом этапе. Предположим, задачи поставлены, они оценены и как-то в общих чертах приоритезированы. Потом часто происходит примерно следующее: берём разработчика, даём ему полученный список, после чего пусть дальше сам разбирается. А через неделю придём и спросим.

Вот именно в этот момент начинается тот этап планирования, про который я хотел бы поговорить. Как распределить эти задачи по дням, а лучше вообще в пределах одного дня, чтобы от этого был максимальный толк? Наш мозг — штука довольно однозадачная, но с парой интересных фишек типа состояния потока и пассивной работы. Посмотрим, какие есть способы задействовать их.

SJF и все-все-все

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

Начнём со второго варианта, потому что на мой взгляд, к нему прибегают несколько чаще, особенно если разработчик не сам по себе, а к нему регулярно бегают менеджеры, которым страшно важно узнать, когда же будут сделаны их задачи. Сам процесс подозрительно напоминает алгоритм SJF/SJN (когда самая короткая из поступивших задач выполняется следующей, а длинные в итоге могут зависнуть в очереди надолго) и имеет в целом те же достоинства и недостатки. В первую очередь, велика вероятность увлечься мелочами, и не сделать то, что было на самом деле более приоритетно. Во вторую — когда ты уже в 4-5 задачах написал, что всё готово, начинаешь чувствовать себя молодцом заранее, и соблазн расслабиться становится очень велик. Ведь в конце дня можно сказать: «да я сегодня столько задач переделал», и выглядеть героем.

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

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

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

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

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

На самом деле про этот механизм знают все и очень давно (поговорку «утро вечера мудренее» не вчера придумали), но обычно это применяют именно к кардинальным перерывам или смене деятельности, например, сон, медитация или физические упражнения. Нейрофизиологи даже нашли участки мозга, которые этим занимаются, и назвали их сетью пассивного режима работы мозга (она же default mode network, одна из resting state networks). Так вот эта система работает не только при полном отключении от задач, но и в случае, если текущая задача просто не требует особого напряжения. Если сформулировать или просто взять из списка несколько небольших задач, выполнение которых не потребует умственных усилий, то такое переключение вполне способно дать мозгу передышку перед новой попыткой штурма сложной проблемы.

Как это устроено у нас

Конкретно в нашей компании эта проблема работы одного разработчика сразу над несколькими проектами решается вот так:

1. Мы делим день на две части, в каждой из которых есть список задач, отсортированный по приоритету.
2. Первая задача в этом списке должна быть решена, даже если остальные в этой половине дня из-за этого сдвинутся.
3. Менеджер проекта оповещается о проблеме и дальше уже корректирует для себя время завершения сдвинутых задач.
4. Обед служит большим перерывом, когда можно отвлечься от монитора подольше, а потом вернуться к работе со свежим взглядом.
5. При удачном стечении обстоятельств получаем в каждой половине дня одну большую задачу и опционально несколько мелких с меньшим приоритетом, которые можно использовать для переключения, если возникает необходимость.

Что в итоге?

В своём плане на день желательно иметь одновременно и крупную задачу или несколько, чтобы занять процентов 70% времени, и несколько «тупых» задач или просто перерывов, которые равномерно распределены внутри этих крупных задач.

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