Итог по Форстеру

В прошлом году я опубликовал конспект по книге “Do It Tomorrow and Other Secrets of Time Management”. Сегодня хочу дополнить его своими соображениями.

Я попробовал применять в реальной жизни принципы, которые он советует, и вышло у меня как-то дерьмово. Столкнулся с двумя проблемами:

  1. Остаются невыполненными какие-то задачи, которые планировались.
  2. Сложно оценить, сколько в действительности задач влезет в день.

Расскажу сперва про каждую.

Не выполняется

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

В теории это выглядит красиво. На практике не работает.

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

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

И дело тут не в том, что «поход в магазин» — это особенная задача, а в том, что Форстер не учитывает предметную область. Но посмотрим пока на другую проблему.

Не влезает

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

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

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

И в итоге задачи постоянно не влезают. И рабочий день растягивается. А задачи всё равно не помещаются.

Влезает и выполняется

И вот, глядя на обе эти проблемы, я со временем допёр, что:

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

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

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

В результате я пришёл к одному простому решению. Планировать не день, а неделю.

Как это работает у меня:

  1. Сажусь в воскресенье и прикидываю, что нужно сделать за неделю.
  2. Выбираю 5-6 больших задач и запихиваю каждую в свой отдельный день.
  3. Если есть какие-то неотложные дела в эти дни, запихиваю их туда же (что поделать, задаче не повезло, ей достанется меньше времени в итоге).

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

Почему это работает для меня:

  1. Исчезает иллюзия того, что время резиновое, и в день можно впихнуть много всего. Сложно планировать день, когда ты точно не знаешь во сколько встанешь, и, более того, когда не знаешь, во сколько ляжешь (потому ложишься каждый раз позже обычного). В неделе же всегда 7 дней, а погрешности в 2-3 часа каждый день не сильно важны.
  2. Необходимость тех или иных задач видна более чётко. Одно дело, когда у тебя есть возможность выделить на задачу «часок-другой, если получится». Другое, когда всего два варианта: выдать ей весь день или отжать время для неё у какой-то более приоритетной задачи.
  3. Поскольку переключений между проектами и типами задач меньше, устаёшь тоже меньше. Возможно, так работает только у меня, но в основном время и энергия терялись между задачами: или переключиться было сложно, и приходилось долго въезжать, что же вообще происходит; или время уходило на что-то вообще иное, просто потому что «одну задачку сделал, можно и отдохнуть чуть-чуть».
  4. Когда делаешь одну задачу, легче понять, что устал. В момент переключения между задачами ты немного отдыхаешь, и потому теряешь ощущение того, что устал сидеть, болят глаза, гудит голова. Когда работаешь только в одной предметной области, ты это замечаешь. И потому принимаешь самое правильное решение (одно из): пойти подремать или, наоборот, размяться.

Занимательно, что при таком подходе я понял, что работаю не 8 часов в сутки, а 12-16. Просто раньше они размазывались на несколько проектов + сильно терялись при переключении между ними, и было незаметно, что так происходит. Сейчас потерь нет, и простое логирование времени позволяет сложить два и два. Это не страшно, и что-то такое я представлял. Но одно дело представлять, а другое дело видеть.

К слову, КПД тоже повысился.

Единственное, о чём важно помнить: больших задач всегда будет много, но нужно время ещё и на то, чтобы делать всякую мелочь, и отдыхать. Потому нужно выделять им хотя бы один день недели (у меня это воскресенье), а то так и помереть можно.

А остальные принципы Форстера вполне норм.

Такие дела ¯\_(ツ)_/¯.

∗∗∗

На всякий случай. Этот рассказ не про то, что вам нужно делать так же. И не про то, что Форстер не работает. И не про то, что он работает. И не про то, что я начал шарить в тайм-менеджменте. И не про то, что я в нём не шарю. Хотя ладно, последнее всё же правда.

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

Если чайник быстро закипает и подолгу кипит, то рано или поздно он прогорит. Потому нужно выпускать пар почаще, регулировать температуру и подливать ещё водички. Чайник-то, он один такой. Другого не выдадут.

2018
1 комментарий
Maksym Prokopov

Привет, я рекомендую не на задачах фокусироваться, а на их важности для достижения целей.

Вот здесь я описал свой опыт.
http://nexusnotes.ru/2013/01/taskpaper-getting-results-agile-way/

Вот здесь подробно http://betteri.ru/post/agile-results---novyy-podhod-k-lichnoy-effektivnosti-opisanie-osnovnyh-priemov-i-principov.html

Удачи!

Популярное