С детских лет меня очень интересовали всякие канцелярские и «бюрократические» вещицы. Я мог часами простаивать у прилавков магазина канцтоваров, глядя на витрины с разнообразными притягательными и волшебными предметами. Особое уважение мне внушали солидные блокноты большого формата, ежедневники, календари-планеры и другие подобные издания, в которых нужно было что-то заполнять и записывать. Помню, что особенно меня поражала страница, которая называлась «Дела на год». Я всё думал: как же можно что-то планировать на целый год вперёд? В юном возрасте мы не особенно склонны к планированию. Каждый день настолько насыщен событиями, что продумывать планы на следующий — бесполезное занятие. Но взрослея мы всё чаще задумываемся о том, что будем делать в ближайшее время и как эти дела получше спланировать. В школе у нас появляется дневник — все мы помним его стандартный классический разворот с расписанием уроков на неделю. Слева — предметы, в центре — домашние задания, справа — оценки. А ведь по сути дневник — это самый настоящий список задач с отметками о выполнении. Если хотите, наша школьная бумажная Jira. Затем таблицы задач всё больше входят в нашу жизнь. Мы всё чаще составляем списки дел и расписания. Задачи окружают нас повсюду — и дома, и на работе, и во всяческих аспектах нашей повседневной жизни. У каждого со временем появляются собственные приёмы и методики работы со списками задач. Кто-то предпочитает модные приложения и продвинутые программы, кто-то по старинке всё записывает в бумажный ежедневник. А некоторые вообще не занимаются специальным планированием, но при этом чудесным образом всё успевают. За долгие годы работы в IT такие методики и принципы выработались и у меня. Они проверены временем и помогают мне успешно ориентироваться в окружающем потоке задач. В этой статье я хочу поделиться с вами этими принципами. Возможно, какие-то из них покажутся вам полезными и пригодятся. Я уже довольно давно воспринимаю папку «Входящие» в почтовом клиенте как список задач. С любым письмом, попавшим в эту папку, я обращаюсь как с задачей, которую нужно выполнить. Когда задача обработана, например, я ответил на письмо, я тут же перемещаю это письмо в архив. Если по нему ничего делать не надо и это просто информационное сообщение, я перемещаю его в архив сразу после прочтения. Таким образом, в папке «Входящие» у меня остаются только те письма, с которыми я что-то должен сделать. Такой подход даёт несколько дополнительных бонусов: Я никогда не забуду о письме, по которому я должен что-то сделать. Оно не будет погребено под ворохом новых писем, поступивших за последующие дни. Я наглядно вижу, сколько писем мне ещё нужно обработать, какие дела нужно выполнить по этому списку задач. Папка «Архив» превращается в единый поток входящих и исходящих писем, в котором легко искать нужную информацию и просматривать историю переписки. Задачи имеют одно важное свойство — они самоорганизуются в деревья. Когда я работаю над какой-то очередной более или менее сложной задачей, почти всегда появляются дочерние задачи, которые тоже нужно вписать в мой список. Например, разработка какой-то процедуры может потребовать реализации нескольких дополнительных функций или оптимизации какого-то уже существующего кода. Эти новые задачи в свою очередь порождают свои дочерние подзадачи, дерево разрастается и ветвится. Тут важно то, что ветви и структура дерева задач заранее неизвестны — они возникают только при работе над одним из узлов. При работе с такими деревьями я стараюсь соблюдать основное правило: главное — не отвлекаться на дочерние задачи. Когда они возникают, я аккуратно фиксирую эти задачи в списке. При этом их внутренние связи — структура дерева — не так важны. Главное — внести их в список, чтобы потом не забыть сделать. При необходимости вместо ещё не существующих объектов, например процедур и функций, можно поставить временную заглушку. Но при этом я продолжаю работать над узловой задачей, не переключаясь на подзадачи. Наш мозг любит всё простое и понятное. Поэтому я всегда стараюсь декомпозировать большие задачи — поделить их на более мелкие. Так проще работать. Ведь куда приятнее работать над задачей длительностью 10 минут, чем день за днём корпеть над задачей длительностью в несколько недель. Именно поэтому я стараюсь соблюдать следующие правила: Сложные большие задачи нужно делить на более мелкие. Маленькие задачи должны быть простыми и понятными. Сделал и перешёл к следующей. И так шаг за шагом. Чем ближе время начала выполнения задачи, тем более подробно она должна быть декомпозирована. Далёкие задачи — крупные. Близкие задачи — маленькие. Вечером нужно спланировать маленькие задачи на начало следующего рабочего дня. Для многих утро — самое напряженное время, когда нужно быстро включиться в работу. Именно поэтому такое планирование позволяет просто прийти на работу и начать работать, а не раздумывать долго над тем, что и как ещё нужно сделать. Также это позволяет отключить мозг от работы в конце рабочего дня — планирование на следующий день позволяет поставить условную точку в дне сегодняшнем и временно забыть о рабочих проблемах. В итоге я всегда знаю, что мне нужно сделать и какой я должен получить результат. При необходимости мне легко переключиться на другую задачу, а затем вернуться к предыдущей. А ещё при выполнении маленькой задачи я могу забыть про все остальные — не держать их в голове, а просто делать свою работу. Любая дополнительная информация помогает сократить время решения задач. Проще говоря, полезно всё записывать. Нас в IT окружает море информации. Мы работаем со сложными системами, документами, алгоритмами. Для решения той или иной задачи мы используем различные источники данных и знаний. В процессе работы вся эта информация прочно сидит в нашей голове. Кажется, что мы её никогда не забудем. Но обычно это не так: поток задач не прерывается, новые задачи постепенно заслоняют собой старые, и уже через пару месяцев мы забываем большинство подробностей реализации давно завершённых задач. Максимум, что мы можем вспомнить — это то, что мы работали над этой задачей. Может быть, ещё пару характерных моментов. Но детали и тонкости будут вычищены из нашей оперативной памяти следующими задачами. Именно поэтому я предпочитаю всё записывать. Благо, что современные трекеры задач предоставляют для этого удобные инструменты. В комментариях к задаче Jira можно записывать подробности реализации. В приложенных файлах можно хранить переписку с вашими вопросами. В комментариях к коду можно подробно описывать особенности работы алгоритмов. Дополнительную текстовую информацию можно сохранять везде — много места она не занимает. Главное — не лениться это делать. Я уже много раз говорил «спасибо» себе из прошлого, когда мне по разным причинам приходилось возвращаться к своим собственным старым задачам. А ещё такой подход позволяет не держать в голове информацию о завершённых задачах — её всегда легко найти при необходимости. Многолетняя привычка всё сохранять и записывать впоследствии сэкономила мне многие и многие часы работы. С задачами можно работать по-разному. Можно шаг за шагом постепенно двигаться к цели. Пока задача не завершена, результат будет недоступен. Я предпочитаю другой способ — двигаться от сырого, но работоспособного прототипа к полноценному решению. Это похоже на постепенное проявление бумажной фотографии. Уже в самом начале процесса можно разобрать, что на ней будет изображено. Ещё больше это похоже на то, как художник рисует картину — сначала карандашный набросок, потом чёткие контуры, затем основные цветовые области и в самом конце — прорисовка мельчайших деталей. Процесс работы над задачей делится на небольшие итерации, каждая из которых вносит дополнительное уточнение и улучшение в итоговое решение. Проще говоря, я всегда готов скомпилировать и показать результат своей работы, даже если я нахожусь в середине пути. При этом я по необходимости всегда могу передать задачу своему коллеге. Это сделать проще, если что-то уже работает. Также мне легче переключаться между задачами, хотя я и не очень люблю это делать. Всегда проще возвращаться к готовому прототипу, чем к набору разрозненных неработающих деталей. Это, пожалуй, наиболее индивидуальный принцип. Я стараюсь правильно распределять задачи в течение дня с учётом моих личных особенностей. Вот мои правила: Самое ценное для меня время — это первые три часа рабочего дня. В эти часы я стараюсь решать самые сложные задачи. Если выполнять задачи короткими интенсивными интервалами по 2–3 часа, то результаты будут лучше. Нужно периодически менять вид деятельности. Задачи, на решение которых нужно меньше 5 минут, я предпочитаю выполнять немедленно. Понимаю, что эти правила подойдут не всем. Например, если вы классическая «сова» и с трудом просыпаетесь по утрам, то первое правило — совсем не для вас. Тут важен принцип — главное, последить за собой, за своей эффективностью в течение рабочего дня и попытаться сформулировать свои собственные правила распределения задач во времени. Человек не многозадачен — это иллюзия. Многочисленные научные исследования это доказывают. Например, эксперименты учёных Лондонского университета показали, что одновременное решение нескольких когнитивных задач приводит к резкому падению IQ. Иногда, в особо запущенных случаях — до уровня 5-летнего ребёнка. Постоянное прерывание мысленного потока приводит не только к риску упустить что-то важное в решении текущей задачи. Гораздо важнее то, что это существенно увеличивает время работы. После каждого отвлечения приходится тратить время на то, чтобы вернуться в контекст основной задачи. И с каждым разом это время увеличивается. В конце дня вы всё чаще будете после очередного необязательного входящего звонка «подвисать», мучительно раздумывая: «Что же я сейчас хотел сделать?». В условиях современного IT-ландшафта бороться с такими отвлечениями сложно. Но можно попытаться минимизировать их последствия. Каждый раз, когда ко мне поступает прерывающий внешний запрос, я действую по следующему алгоритму: Оцениваю важность и срочность запроса. Если запрос не важный и (или) не срочный, то вношу его в один из своих списков. Если запрос важный и (или) срочный, то я не бросаюсь его немедленно выполнять. Сначала я «фиксирую буфер» текущей задачи. Для этого я стараюсь аккуратно и тщательно записать все те мысли и идеи по задаче, которые находятся в моей голове. Это позволит мне в дальнейшем ускорить и упростить возвращение к работе над задачей. Я предпочитаю вести заметки по задаче на отдельном листе. Я записываю туда всю справочную и полезную информацию по задаче: названия переменных, куски алгоритма, определения, формулы. Тут же, например, можно записать имена и контакты сотрудников, которым можно задать вопросы по задаче. Этот лист подходит также для записи дополнительно возникающих дочерних задач. При этом все заметки по задаче хранятся в одном месте, их легко окинуть взглядом и найти нужную информацию — она всегда перед глазами. Кстати, это не обязательно должен быть лист бумаги. Можно использовать любое приложение для ведения заметок. Главное, чтобы всё было в одном месте. После завершения работы над задачей лист можно будет отсканировать и сохранить. В первом пункте про пустой почтовый ящик я описал, как перемещаю обработанные письма в архив. Точно так же я стараюсь поступать с любой другой исходной информацией, которую я использую при работе с задачей. Например, в процессе разработки основным источником информации является техническое задание. Этот документ может быть достаточно обширным, и при его постепенной обработке очень высок риск что-то упустить. Особенно учитывая то, что информация из исходного документа обычно используется не последовательно, а частями, вперемешку. Поэтому я предпочитаю каким-то образом выделять уже обработанную информацию. В документах для этого можно использовать цветовой маркер. В других системах — ставить метки, менять местоположение объекта или использовать любой другой подходящий способ выделения. Главное — не забывать отмечать то, что вы уже учли и то, что вам уже больше не понадобится. При таком подходе на финальном этапе работы над задачей вы сможете ещё раз просмотреть все исходные материалы и проверить, не забыли ли вы учесть что-то важное. Те задачи, которые я выполнил, я всегда помечаю, но никогда не удаляю. Вам никогда не казалось обидным, что в Тетрисе собранные ряды просто исчезают? Вы потратили определённые усилия на то, чтобы правильно уложить фигуры, но аккуратно собранный ряд исчезает в никуда. В какой-то момент я понял, что мозг может так же отрицательно реагировать и на удаление задач. Чтобы сделать моему мозгу приятно, я предпочитаю не удалять задачи из списка, а помечать их как выполненные. Например, один из моих основных списков задач — это простой текстовый файл. В его начале есть раздел «Сделать», в котором каждая строка — это задача, которая ещё не выполнена. За ним через пустую строку идёт раздел «Сделано», где содержатся уже завершённые задачи. Когда я заканчиваю работу над какой-то задачей из верхнего списка, я просто переношу её в нижний список. Раздел «Сделано» — это как личная таблица рекордов. Всегда приятно смотреть на то, как он пополняется и расширяется. У такого подхода есть приятный бонус — всегда можно проследить последовательность выполнения задач. Это своего рода журнал вашей работы. При необходимости всегда можно «посмотреть логи». Все описанные в этой статье несложные принципы помогают мне оптимизировать работу с постоянным потоком задач, не отвлекаться на сложные процессы планирования и получать удовольствие от своей работы. Главное: В список задач можно превратить любой объект: программу, текстовый файл, лист бумаги. Списков может быть несколько. Задачи естественным образом объединяются в деревья. Нужно стараться декомпозировать задачи — делить их на более мелкие. Нужно правильно распределять задачи в течение дня. Нужно по возможности минимизировать число частых переключений между задачами. В последнее время наивный вопрос из детства, с которого я начал эту статью, — «Как же можно что-то планировать на целый год вперёд?», — неожиданно обрёл новый смысл. Горизонт планирования сократился даже не до месяцев, а до недель или дней. Строить долгосрочные планы стало совершенно бессмысленно. Мы оказались в мире, где действуют иные правила. И в этой новой реальности мои принципы продолжают надёжно работать, ведь они основаны не на планировании, а на оперативном управлении постоянно изменяющимся турбулентным потоком задач.  Сформулируй гибкие универсальные правила, действуй по обстоятельствам, структурируй поток информации, подруливай в нужную сторону и решай задачи по мере поступления. Мне кажется, что такой подход эффективен на всех уровнях: от личного менеджмента до управления задачами на уровне команды, подразделения и организации. Прав был мудрый даос Лао-Цзы: «Лучшее правило в жизни — это не строить планов».  Техлид, технический писатель, программист