А что мы действительно пишем в список задач?

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

1. У нас реальные проблемы с планированием применительно к себе.

Последний раз я вспоминал о чем-то подобном, когда в чате задали вопрос про страдательный залог в формулировке задач. Мы не можем детально представить свое будущее, если мы в нем действительно заинтересованы. Поэтому мы планируем себе задачи на будущее так, будто их должен делать кто-то другой. Об этом писала Келли МакГонигал в книжке "Сила Воли".
Отсюда вытекает история про то, что мы не можем предположить, сколько времени у нас займет та или иная задача с ходу, не привлекая логику и практики планирования (типа оценки по трем точкам или оценки по аналогам). А оценка задач из списка с применением этих прекрасных инструментов (оценки по трем точкам или аналогичных) приведет к росту накладных расходов на ведение такой системы.
Я лично пробовал оценивать задачи так. Заканчивалось все тем, что в список задач смотреть не хотелось.

2. Мы не всегда можем распознать проект заранее.

Например, Максим в своей статье пишет:

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

С другой стороны есть Дэвид Аллен, с его поределением проекта:

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

С третьей стороны мы пишем задачи в список для себя, предполагая, что мы большие молодцы и сейчас быстро все сделаем достигнем результат за одно действие (привет, п. 1), а
получаем забавную матрешку из задач. Но если их все записывать, то может возрастать "налог" на обслуживание системы, т.е. увеличение затрат "головы" или "мыслетоплива" на работу системы, а не на её использование. А это приводит к уже известной ситуации, что смотреть в спиок задач противно.

3. Не так страшен проект в списке задач, как попытки распилить этот проект до конца.

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

4. Не получается избежать винегрета в списке задач, и?

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

5. Небольшие выводы

1. Оценка задач из списка (любого: сегодня, на неделе, когда-нибудь) сильно увеличивает затраты головы на поддержание системы.
2. Мешать проекты и задачи в один список неизбежное зло.
3. Для того, чтобы проекты в списке не протухали стоит попробовать формулировать задачи как спусковые крючки для начала действий.
4. Если мы понимаем, что процесс работы в ходе выполнения задачи не стартовал и результат не получен, то стоит подумать над формулировкой задачи.
5. Оценки по времени задач из списка не выстреливают, если использовать задачи как спусковые крючки, а не как список детальных указаний.
6. Затраты времени на глубокую, больше одного-двух действий, детализацию проекта увеличивают затраты на ведение системы и уменьшают пользу от её использования.