Обработка входящих в GTD
Обработка это второй этап разбора входящих в GTDopen in new window. Один из принципов обработки: "Никогда не перекладывайте дела обратно в корзинку".
Ключевой момент и основная сложность при выполнении этого принципа в классификации входящих. Чем яснее понимания различий между видами входящих, тем быстрее их классифицировать. Рассмотрим виды входящих из GTD:
Мусор
Самый простой случай. Ничего делать не надо.
Например, сообщение в массовом чате по которому не требуется реакции (если такое проходит часто то следует выйти из чата или отключить нотификациюopen in new window).
Информация
Входящее требует занесение информации в подходящий раздел информационной системы.
Например, звонок в котором сообщили что приём к стоматологу переносится на час. При обработке входящего достаточно изменить время приёма в календаре. Конечно, если новое время свободно.
Задача
Входящее требует действий. Необходимо сформировать следующее действие. Следующее действие должно быть максимально простым и конкретным.
Если сразу понятно, что выполнение следующего действия занимает меньше 2х минут, то его можно выполнить сразу. Если следующее действие занимает больше времени то оно добавляется в Список задачopen in new window (нужно сделать сегодня) или в календарь (нужно сделать в другой день).
Например, прислали ранее запрошенный документ. В этом случае входящее разбивается на два элемента: задача "Прочитать документ x" записанная в Списке задач и сам документ помещённый в подходящее место (может быть специальный каталог в системе контроля версий или любое другое заранее организованное хранилище).
Как видно из примера, входящее может попадать под несколько категорий одновременно.
Проекты
Проект это большая задача. Для выполнение задачи требуется одно следующее действие, а для выполненя проектов несколько. Варианта куда поместить проект два: либо сформировать только следующее действие и поместить его в Список задач, либо дополнительно к этому поместить проект в отдельный Список проектов.
Я думаю, что помещать проект в отдельный список не имеет смысла если сразу понятно что проект продолжится по времени не больше одного-двух дней.
Например, руководством поставлена задача организовать совещание. Для этого нужно выполнить несколько действий: описать повестку, предупредить участников, получить ответ от участников. Достаточно добавить эти действия в список задач.
Если проект более долгосрочный то стоит поместить его в отдельный список. Причём в списке задач или календаре должна находится задача для переодического просмотра этого списка.
Примером долгосрочного проекта может быть требование руководства произвести интеграцию программы со сторонней программой. Такая "задача" разделяется на множество различных задач в течении длительного периода времени.
Непонятное
Существуют элементы входящих с которыми трудно сразу определить что делать. Примерами являются идеи или задачи для принятия решения по которым сейчас недостаточно информации.
В этом случае их можно разместить либо в отдельный список либо в календарь и рассмотреть позже. Важно различать такие элементы от задач в Списке задач. Задачи точно нужно сделать и они сформулированы в виде следующего действия. А идеи требуют решения о том нужно ли их делать или нет.