С детских лет меня очень интересовали всякие канцелярские и бюрократические вещицы. Я мог часами простаивать у прилавков магазина канцтоваров, глядя на витрины с разнообразными притягательными и волшебными предметами. Особое уважение мне внушали солидные блокноты большого формата, ежедневники, календари-планеры и другие подобные издания, в которых нужно было что-то заполнять и записывать. Помню, что особенно меня поражала страница, которая называлась «Дела на год». Я всё думал: как же можно что-то планировать на целый год вперёд?

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

Затем таблицы задач всё больше входят в нашу жизнь. Мы всё чаще составляем списки дел и расписания. Задачи окружают нас повсюду — и дома, и на работе, и во всяческих аспектах нашей повседневной жизни. У каждого со временем появляются собственные приёмы и методики работы со списками задач. Кто-то предпочитает модные приложения и продвинутые программы, кто-то по старинке всё записывает в бумажный ежедневник. А некоторые вообще не занимаются специальным планированием, но при этом чудесным образом всё успевают.

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

1. Принцип пустого почтового ящика

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

Такой подход даёт несколько дополнительных бонусов:

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

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

3. Папка «Архив» превращается в единый поток входящих и исходящих писем, в котором легко искать нужную информацию и просматривать историю переписки.

2. Принцип обхода дерева задач

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

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

3. Принцип декомпозиции задач

Наш мозг любит всё простое и понятное. Поэтому я всегда стараюсь декомпозировать большие задачи — поделить их на более мелкие. Так проще работать. Ведь куда приятнее работать над задачей длительностью 10 минут, чем день за днём корпеть над задачей длительностью в несколько недель. Именно поэтому я стараюсь соблюдать следующие правила:

1. Сложные большие задачи нужно делить на более мелкие.

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

3. Чем ближе время начала выполнения задачи, тем более подробно она должна быть декомпозирована. Далёкие задачи — крупные. Близкие задачи — маленькие.

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

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

4. Принцип расширения метаинформации

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

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

Многолетняя привычка всё сохранять и записывать впоследствии сэкономила мне многие и многие часы работы.

5. Принцип постепенного проявления

С задачами можно работать по-разному. Можно шаг за шагом постепенно двигаться к цели. Пока задача не завершена, результат будет недоступен. Я предпочитаю другой способ — двигаться от сырого, но работоспособного прототипа к полноценному решению. Это похоже на постепенное проявление бумажной фотографии. Уже в самом начале процесса можно разобрать, что на ней будет изображено. Ещё больше это похоже на то, как художник рисует картину — сначала карандашный набросок, потом чёткие контуры, затем основные цветовые области и в самом конце — прорисовка мельчайших деталей. Процесс работы над задачей делится на небольшие итерации, каждая из которых вносит дополнительное уточнение и улучшение в итоговое решение.

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

6. Принцип планирования рабочего дня

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

1. Самое ценное для меня время — это первые три часа рабочего дня. В эти часы я стараюсь решать самые сложные задачи.

2. Если выполнять задачи короткими интенсивными интервалами по 2–3 часа, то результаты будут лучше.

3. Нужно периодически менять вид деятельности.

4. Задачи, на решение которых нужно меньше 5 минут, я предпочитаю выполнять немедленно.

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

7. Принцип отсутствия многозадачности

Человек не многозадачен — это иллюзия. Многочисленные научные исследования это доказывают. Например, эксперименты учёных Лондонского университета показали, что одновременное решение нескольких когнитивных задач приводит к резкому падению IQ. Иногда, в особо запущенных случаях — до уровня 5-летнего ребёнка.

Постоянное прерывание мысленного потока приводит не только к риску упустить что-то важное в решении текущей задачи. Гораздо важнее то, что это существенно увеличивает время работы. После каждого отвлечения приходится тратить время на то, чтобы вернуться в контекст основной задачи. И с каждым разом это время увеличивается. В конце дня вы всё чаще будете после очередного необязательного входящего звонка «подвисать», мучительно раздумывая: «Что же я сейчас хотел сделать?».

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

1. Оцениваю важность и срочность запроса.

2. Если запрос не важный и (или) не срочный, то вношу его в один из своих списков.

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

8. Принцип буферного листа

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

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

9. Принцип выделения обработанной информации

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

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

10. Принцип пометки выполненных задач

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

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

У такого подхода есть приятный бонус — всегда можно проследить последовательность выполнения задач. Это своего рода журнал вашей работы. При необходимости всегда можно «посмотреть логи».

Краткое резюме

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

Главное:

• В список задач можно превратить любой объект: программу, текстовый файл, лист бумаги. Списков может быть несколько.

• Задачи естественным образом объединяются в деревья.

• Нужно стараться декомпозировать задачи — делить их на более мелкие.

• Нужно правильно распределять задачи в течение дня.

• Нужно по возможности минимизировать число частых переключений между задачами.