GTD Дэвида Аллена целиком: пять шагов, контексты, честный разбор

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

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

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

Откуда взялся метод

Дэвид Аллен — не учёный и не программист. Он консультант по управленческой продуктивности, работавший с руководителями крупных компаний в 1980–1990-х. Метод вырос не из теории, а из практики: Аллен годами наблюдал, как менеджеры теряют обязательства, и собрал набор процедур, которые эмпирически работали на его клиентах. Книга «Getting Things Done: The Art of Stress-Free Productivity» вышла в 2001 году, переработанное издание — в 2015-м (Penguin Books). Официальный сайт метода — gettingthingsdone.com.

Ключевой исторический контекст: книга написана до смартфона, до Slack, до постоянного пуш-уведомления. Мир, для которого проектировался GTD, — мир бумажного инбокса, голосовой почты, факса и лотка «входящие» на столе. Это объясняет многое в устройстве метода, в частности систему контекстов, к которой мы вернёмся.

Модель внутри: «разум как вода»

Центральная метафора Аллена — mind like water: сознание реагирует на входящее ровно настолько, насколько нужно, и возвращается в покой. Всё, что мешает этому, — открытые петли (open loops): любые обязательства, взятые, но не зафиксированные во внешней системе, которой вы доверяете.

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

Отсюда — главный тезис GTD, который часто теряется за списками и тегами:

Система нужна не чтобы делать больше. Она нужна, чтобы голова была свободна, когда вы думаете.

Это тезис про качество мышления, а не про пропускную способность. Инженеру он подходит лучше, чем менеджеру, потому что мы платим за когнитивную загрузку напрямую: усталая голова пишет баги, которые потом стоят дней.

Что говорит наука

Аллен опирается на психологию довольно вольно, поэтому важно отделить проверенное от риторики.

Первый научный разбор метода — статья Francis Heylighen и Clément Vidal «Getting Things Done: The Science behind Stress-Free Productivity» (Long Range Planning, 2008, т. 41, вып. 6). Она объясняет GTD через теорию распределённого познания: внешняя система — это когнитивное расширение, снимающее нагрузку с рабочей памяти. Важно понимать: это теоретическое обоснование, а не эксперимент. Контролируемых испытаний GTD как целостной системы, по сути, нет до сих пор.

Эффект Зейгарник (незавершённые задачи лучше вспоминаются и «дёргают» внимание) — то, на что часто ссылаются фанаты метода. Проблема в том, что современные метаанализы дают слабый и нестабильный эффект. Гораздо надёжнее выглядит работа E. J. Masicampo и Roy Baumeister «Consider It Done! Plan Making Can Eliminate the Cognitive Effects of Unfulfilled Goals» (Journal of Personality and Social Psychology, 2011, 101(4)): незавершённая цель мешает текущей задаче, но конкретный записанный план устраняет помеху — даже если план ещё не выполнен. Это буквально механизм шагов «зафиксировать» и «прояснить». Оговорка: часть работ этой лаборатории пострадала в кризисе репликации (история с ego depletion), так что относиться стоит как к правдоподобной, а не доказанной опоре.

Самая доказанная часть GTD — не пять шагов и не контексты, а формулировка следующего действия. Это почти дословно implementation intentions Петера Гольвитцера: план вида «в ситуации X я сделаю Y». Метаанализ Gollwitzer и Sheeran (2006) по 94 исследованиям даёт средний размер эффекта d ≈ 0,65 — крупный по меркам поведенческой психологии. То есть если из всего GTD вы возьмёте только «конкретное действие, привязанное к контексту», вы возьмёте самое надёжное.

Против GTD работают два наблюдения. Первое: Victoria Bellotti с коллегами (CHI 2004, «What a to-do: studies of task management towards the design of a personal task list manager») показали, что реальные люди ведут задачи совсем не так, как предполагают формальные системы — списки фрагментарны, задачи живут в почте, а полнота системы недостижима. Второе: Cal Newport в The New Yorker (2020) формулирует главную структурную претензию — GTD оптимизирует индивидуальную обработку потока задач, но сам поток порождается организацией. Персональная система не чинит сломанный процесс команды, она лишь позволяет дольше терпеть его.

Пять шагов

Аллен описывает не список правил, а конвейер из пяти этапов. Критично, что этапы разделены во времени: смешивать их — самая частая ошибка.

1. Зафиксировать

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

Инженерная реальность: инбоксов у нас всегда больше, чем хочется. Почта, Slack, упоминания в PR, алерты дежурства, Jira, заметки с созвонов, «вот эта мысль про рефакторинг, пришедшая в душе». Задача не в том, чтобы свести их к одному — это невозможно, — а в том, чтобы знать полный список своих инбоксов и иметь для каждого правило опустошения.

# Минимальный захват из терминала: одна строка в один файл.
# Смысл — чтобы мысль не стоила переключения контекста.
inbox() { printf '%s | %s\n' "$(date -Iseconds)" "$*" >> "$HOME/gtd/inbox.md"; }

# Использование прямо посреди отладки:
# inbox после релиза выпилить фичефлаг legacy_router

Правило: захват не оценивает. Никаких «а стоит ли это записывать». Фильтрация — работа второго шага, и попытка фильтровать на первом убивает привычку.

2. Прояснить

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

Три вопроса, на которых обычно спотыкаются:

«Каков желаемый результат?» Пока вы не сформулировали, как выглядит «готово», задача будет висеть. «Разобраться с флаки-тестами» — не результат. «Тест TestPaymentRetry проходит 200 запусков подряд в CI» — результат.

«Каково ближайшее физическое действие?» Не «этап», а именно физически видимое действие, которое можно начать делать без дополнительного думания. Разница огромна:

Заметьте: правая колонка почти всегда длиннее и содержит имя файла, команду или имя человека. Это не педантизм. Это разница между задачей, которую вы начнёте в 14:20 между встречами, и задачей, которую вы будете откладывать три недели.

«Проект это или действие?» У Аллена проект — любой результат, требующий больше одного действия и достижимый в пределах года. По этому определению у инженера почти каждый тикет — проект. И это нормально: проект в GTD не требует плана, ему требуется ровно одно — определённое ближайшее действие.

Правило двух минут и почему для нас оно опасно

Аллен: если действие занимает меньше двух минут, сделай его сразу — заводить его в систему дороже, чем выполнить.

Для менеджера с бумажным инбоксом логика безупречна. Для инженера в середине отладки — нет. Sophie Leroy (2009, «Why is it so hard to do my work?», Organizational Behavior and Human Decision Processes) описала attention residue: после переключения на другую задачу часть внимания остаётся на предыдущей, и производительность падает даже после возврата. Работы Gloria Mark по прерываниям дают тот же вывод с другой стороны: возврат к прерванной задаче стоит гораздо дороже длительности самого прерывания.

Практическая поправка для разработчика:

• Правило двух минут применяется только во время обработки инбокса, а не круглосуточно. Это шаг конвейера, а не режим жизни.
• Внутри блока глубокой работы двухминутных дел не существует. Всё уходит в инбокс, даже если «займёт 30 секунд».
• Порог полезно снизить до одной минуты: у нас «две минуты» превращаются в двадцать подозрительно часто (открыл PR посмотреть — остался комментировать).

3. Организовать: семь мест, куда попадает результат

После прояснения элемент обязан оказаться ровно в одном из мест. Никаких «пока полежит в инбоксе».

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

Список «Жду ответа» для инженера — самый недооценённый. У нас огромная доля работы заблокирована другими людьми: висящий PR, ответ безопасников, релизное окно, доступ к проду, ответ соседней команды в другом часовом поясе. Без этого списка блокировки всплывают случайно и поздно.

## Жду ответа
- 2026-07-13 · @kate — ревью PR #4471 (rate limiter)  → пингануть, если тишина к 17-му
- 2026-07-14 · SRE — доступ к grafana prod ro (тикет INF-882)
- 2026-07-15 · платёжный вендор — подтверждение sandbox-ключей
- 2026-07-16 · @lead — решение, выносим ли нотификации в отдельный сервис

Дата — не украшение. Она позволяет на еженедельном обзоре механически найти всё, что висит дольше недели, и решить: пингануть, эскалировать или отпустить.

4. Обозреть

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

Канонический обзор состоит из трёх фаз: Get Clear (опустошить все инбоксы), Get Current (пройти списки, актуализировать), Get Creative (посмотреть выше — на проекты и «когда-нибудь»).

Практический вариант для инженера, 45–60 минут, пятница после обеда:

### Разгрузка (15 мин)
- [ ] Инбокс-файл до нуля
- [ ] Почта: до нуля непрочитанных, всё превращено в действия
- [ ] Slack: пройти сохранённые сообщения и упоминания
- [ ] Заметки с созвонов за неделю — вытащить обязательства
- [ ] Черновики веток и локальные TODO: git status по рабочим репозиториям

### Актуализация (20 мин)
- [ ] Список проектов: у каждого есть ровно одно ближайшее действие?
- [ ] Мои открытые PR: что висит, что нужно пингануть
- [ ] Чужие PR, где я ревьюер: что просрочено
- [ ] Жду ответа: что старше 7 дней
- [ ] Календарь назад на неделю: что не доделал из запланированного
- [ ] Календарь вперёд на две недели: к чему надо готовиться заранее

### Взгляд выше (15 мин)
- [ ] Когда-нибудь: что-то стало актуальным? что можно удалить навсегда?
- [ ] Области ответственности: где я не касался ничего месяц
- [ ] Одна честная строка: что на этой неделе съело время без результата

Последний пункт делает больше, чем весь остальной обзор, если отвечать на него честно.

Смысл картинки: в день дежурства глубокая работа не планируется вообще. Не «планируется и срывается» — не планируется. Это единственный способ, при котором система не начинает врать.

5. Действовать

Здесь GTD традиционно слабее всего, и Аллен это признаёт: он даёт не приоритизацию, а фильтры. Четыре критерия выбора того, что делать прямо сейчас:

1. Контекст — что вообще возможно здесь и сейчас.
2. Доступное время — 15 минут между встречами или 3 свободных часа.
3. Доступная энергия — способны ли вы сейчас на архитектурное решение или только на обновление зависимостей.
4. Приоритет — и только теперь, из оставшегося.

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

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

Контексты: главная часть, которую нужно переписать

Оригинальные контексты Аллена: @звонки, @компьютер, @офис, @дома, @поручения, @повестка для человека X. В 2001 году это работало: чтобы позвонить, нужен телефон, чтобы напечатать документ — компьютер.

Для инженера в 2026-м эта схема мертва. У нас 95% действий — @компьютер, и такой список бесполезен. Но идея контекста — фильтр «что вообще возможно прямо сейчас» — остаётся ценной. Её нужно переопределить по осям, которые для нас реально ограничивают.

Ось 1: сколько нужно непрерывного времени и головы.

Ось 2: чего мне не хватает физически.

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

Ошибка при внедрении контекстов: заводить их двадцать штук. Работающее число — пять-семь. Контекст полезен ровно до тех пор, пока вы можете без раздумий сказать, в каком вы сейчас.

Жизненный цикл задачи в системе инженера

Два перехода на этой диаграмме делают всю работу и оба игнорируются на практике. Первый: В_работе → Жду_ответа, когда вы отправили PR. Если после отправки задача просто исчезает из головы, вы обнаружите её через десять дней. Второй: Готово → Проект, когда действие выполнено, а проект жив. Если не создать новое ближайшее действие немедленно, проект зависает — это самая частая причина «мёртвых» проектов в любой GTD-системе.

Горизонты фокуса

GTD часто воспринимают как чисто операционную систему, но у Аллена есть и вертикаль — шесть горизонтов фокуса, от текущих действий до смысла.

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

• Области ответственности (H2) — это чеклист против выпадения. У разработчика типичный набор: свои сервисы, дежурство, ревью, наставничество джунов, техдолг, отношения с продуктом, собственное развитие, здоровье, семья. Если на обзоре видно, что к какой-то области вы месяц не прикасались, это сигнал — иногда сигнал о перекосе, иногда о том, что область пора отдать.
• Цели уровня H3 — это единственный честный критерий, по которому можно закрывать проекты. Без него список проектов растёт монотонно.

Аллен рекомендует внедрять снизу вверх: пока инбокс не пуст и списки не ведутся, разговор о пятилетнем видении — самообман. Проверять же систему полезно сверху вниз. Про верхние горизонты подробно — в статьях про горизонты планирования и цели.

Реализация: как это выглядит в файлах

GTD не привязан к инструменту. Ниже — минимальная реализация на обычных markdown-файлах, потому что она делает структуру видимой; в Todoist, Obsidian, org-mode или Things получится то же самое другими средствами. Про выбор инструментов — отдельная статья трека, инструменты.

# projects.md
## Вынести rate limiter в общую библиотеку
- next: @code — вытащить интерфейс Limiter в internal/ratelimit/api.go
- цель: H3 «убрать дублирование инфраструктурного кода»

## Стабилизировать флаки в payments
- next: @deep — прогнать TestPaymentRetry 200 раз под -race, собрать статистику
- waiting: ответ SRE по таймаутам в staging (с 2026-07-14)

## Онбординг Максима
- next: @agenda/максим — обсудить план на первые 30 дней на 1:1 в четверг

Инвариант системы прост: у каждого активного проекта есть ровно одно ближайшее действие либо запись в «жду ответа». Его можно проверять машинно, и это единственная автоматизация, которая реально окупается.

"""Проверка целостности GTD-системы в plain markdown.

Инвариант: у каждого проекта есть next или waiting.
Плюс: waiting старше N дней требует решения.

Сложность: O(n) по числу строк файла, O(p) памяти по числу проектов.
"""
import re
import sys
from datetime import date, timedelta

WAITING_LIMIT = timedelta(days=7)

def check(path: str, today: date) -> list[str]:
    problems: list[str] = []
    project: str | None = None
    has_action = False

    def close_project() -> None:
        # Проект без ближайшего действия — мёртвый проект.
        if project is not None and not has_action:
            problems.append(f"нет ближайшего действия: {project}")

    for raw in open(path, encoding="utf-8"):
        line = raw.rstrip()
        if line.startswith("## "):
            close_project()
            project, has_action = line[3:], False
        elif line.startswith("- next:"):
            has_action = True
        elif line.startswith("- waiting:"):
            has_action = True
            # Дата в формате (с 2026-07-14) — считаем возраст ожидания.
            found = re.search(r"(\d{4})-(\d{2})-(\d{2})", line)
            if found:
                since = date(*map(int, found.groups()))
                if today - since > WAITING_LIMIT:
                    days = (today - since).days
                    problems.append(f"ждём {days} дн.: {line[10:].strip()}")
            else:
                problems.append(f"ожидание без даты: {line[10:].strip()}")
    close_project()
    return problems

if __name__ == "__main__":
    issues = check(sys.argv[1], date.today())
    for item in issues:
        print(f"[gtd] {item}")
    sys.exit(1 if issues else 0)

Скрипт вешается на cron перед еженедельным обзором. Он не заменяет обзор — он показывает, где система уже прогнила, чтобы вы не тратили на поиск живое внимание.

Где GTD ломается

Теперь честная часть. Метод имеет вполне конкретные границы применимости, и большинство разочарований — это выход за них.

1. Метод не приоритизирует

Это архитектурное решение, а не недоработка. Аллен доверяет «интуитивному суждению» в моменте, отвергая жёсткие схемы. Результат: система прекрасно гарантирует, что вы ничего не потеряете, и никак не гарантирует, что вы делаете важное. Инженеру с сотней элементов в @code это не помогает выбрать. Лечится дополнением извне — матрицей Эйзенхауэра, явными целями квартала, или простым правилом «одна главная задача дня», о чём в следующей статье.

2. Стоимость обслуживания системы

GTD — не бесплатный слой. Начальная настройка по книге — это выходные (Аллен прямо предлагает выделить два дня). Дальше — 45–90 минут еженедельно плюс ежедневная обработка инбоксов. Если ваша рабочая неделя честно занята на 110%, ровно это время вы и не найдёте — и система начнёт разлагаться первой.

Типичный цикл: три недели эйфории, две недели дисциплины, потом пропущенный обзор, потом система становится источником вины, потом её бросают. Это настолько распространённый сценарий, что у него есть имя в сообществе — «GTD fall off the wagon». Единственная работающая профилактика — резать систему до минимума, который вы точно выдержите: инбокс, проекты, ближайшие действия, жду ответа. Остальное — потом.

3. Исследовательская работа плохо декомпозируется

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

Рабочий приём: для таких задач ближайшим действием делается артефакт, а не результат. «Написать в research.md три гипотезы, почему падает latency в p99, и способ проверить каждую». Артефакт всегда достижим, и он двигает исследование.

4. Bottom-up и системная слепота

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

Практический вывод: если на еженедельном обзоре одна и та же категория мусора всплывает третий раз подряд, это не задача для вашей системы — это задача для ретроспективы команды.

5. Метод не лечит перегрузку и тем более выгорание

Здесь нужно быть аккуратным. GTD снижает тревогу от неопределённости — от ощущения «я не знаю, что забыл». Это реальный и ценный эффект. Но GTD ничего не делает с объёмом работы. Более того, повышая вашу пропускную способность, он позволяет вам взять на себя больше, а окружению — попросить у вас больше.

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

Выгорание — не проблема дисциплины и не следствие плохого планирования. ВОЗ описывает его в МКБ-11 как профессиональный феномен, связанный с хроническим рабочим стрессом, который не был успешно преодолён; ключевые факторы там организационные — перегрузка, отсутствие контроля, несправедливость, конфликт ценностей. Никакая персональная система это не компенсирует, а попытка «взять себя в руки с помощью GTD» в таком состоянии обычно ухудшает дело: список задач превращается в список доказательств собственной несостоятельности. Если вы узнаёте себя в устойчивом истощении, циничном отстранении от работы и ощущении бесполезности — это разговор с руководителем и, при необходимости, со специалистом (врачом, психотерапевтом), а не вопрос выбора таск-трекера. Подробно и бережно — в статье про выгорание и устойчивый темп.

6. Слабая доказательная база

Стоит проговорить прямо: GTD как целостная система не проверялась в контролируемых исследованиях. Есть теоретическое обоснование (Heylighen и Vidal), есть доказательные отдельные механизмы (implementation intentions, эффект записанного плана), есть огромный корпус личных свидетельств. Этого достаточно, чтобы попробовать, и недостаточно, чтобы утверждать «метод работает». Относитесь к нему как к инженерной эвристике с хорошей внутренней логикой, а не как к доказанной технологии.

Типичные ошибки внедрения

1. Инбокс как свалка. Захват без обработки — худший из миров: элементы копятся, доверие к системе падает, тревога растёт. Если не успеваете обрабатывать — сначала чините обработку, потом расширяете захват.
2. Формулировки-заголовки. «Нотификации», «Проект X», «Ира» — это не действия. Через неделю вы не вспомните, что имелось в виду, и элемент будет пролистываться вечно.
3. Календарь-помойка. Складывание «хорошо бы сегодня» в календарь ломает главное свойство календаря — его достоверность.
4. Двадцать контекстов и пять уровней тегов. Оверинжиниринг системы — способ прокрастинировать, ощущая продуктивность. Merlin Mann, во многом сделавший GTD популярным в IT через 43 Folders, позже сам публично критиковал эту ловушку: людей затягивает настройка системы вместо работы.
5. Проекты без ближайшего действия. Механическая проверка на обзоре решает; без неё список проектов тихо превращается в список сожалений.
6. Пропуск еженедельного обзора. Первый пропуск почти безболезнен, второй разрушает доверие к системе. Обзор надо ставить в календарь как встречу с собой и защищать как встречу с директором.
7. Одна система для рабочего и личного. Спорный пункт: Аллен настаивает на единой системе, и логика в этом есть — голова у вас одна. Но при жёстких требованиях компании к данным разделение вынужденно. Компромисс — единый инбокс для захвата, разные хранилища для организации.
8. Внедрение всего сразу. Полный GTD с семью списками и шестью горизонтами с понедельника не выживает. Работающая последовательность — ниже.

Что взять, если не хочется внедрять целиком

Честный ответ: большинству инженеров не нужен полный GTD. Нужны четыре его элемента, и они дают, по ощущениям практиков, большую часть эффекта:

1. Один надёжный инбокс и привычка выгружать в него всё, не оценивая.
2. Формулировка ближайшего действия через глагол, с именем файла, командой или человеком. Самая доказанная часть метода.
3. Список «жду ответа» с датами. Дёшево, а для нашей работы с её постоянными блокировками — критично.
4. Еженедельный обзор 45 минут в фиксированное время.

План внедрения на две недели, который обычно доживает до конца:

• Дни 1–3: только захват. Один файл или один проект в трекере. Ничего не организуем.
• Дни 4–5: первая обработка по дереву решений. Заводим projects.md и список ближайших действий с 3–5 контекстами.
• Конец первой недели: первый обзор, 45 минут, по чеклисту выше.
• Вторая неделя: добавляем «жду ответа» и чистим календарь от всего, что не является жёстким обязательством.
• Конец второй недели: второй обзор. Если он состоялся — система, скорее всего, приживётся. Если нет — сокращайте её, а не себя.

Мини-итог

• GTD — система про освобождение головы, а не про повышение производительности. Метрика успеха — спокойствие и отсутствие потерянных обязательств, а не число закрытых тикетов.
• Пять шагов разделены намеренно: захват не оценивает, прояснение не делает, обзор чинит систему. Смешивание этапов — главная причина, по которой метод «не работает».
• Ближайшее физическое действие — сердце метода и его самая обоснованная часть.
• Контексты Аллена устарели; для инженера их нужно переопределить через длительность блока, уровень энергии и требуемый доступ.
• Еженедельный обзор — несущая конструкция. Без него всё остальное разваливается за две-три недели.
• GTD не приоритизирует, стоит времени на обслуживание, плохо ложится на исследовательскую работу, не чинит организационные проблемы и не имеет отношения к лечению выгорания.

Источники

• David Allen. Getting Things Done: The Art of Stress-Free Productivity. Penguin Books, revised edition, 2015. Официальный сайт метода — gettingthingsdone.com, обзор системы — en.wikipedia.org/wiki/Getting_Things_Done.
• Francis Heylighen, Clément Vidal. «Getting Things Done: The Science behind Stress-Free Productivity». Long Range Planning, 41(6), 2008.
• E. J. Masicampo, Roy F. Baumeister. «Consider It Done! Plan Making Can Eliminate the Cognitive Effects of Unfulfilled Goals». Journal of Personality and Social Psychology, 101(4), 2011.
• Peter M. Gollwitzer, Paschal Sheeran. «Implementation Intentions and Goal Achievement: A Meta-analysis of Effects and Processes». Advances in Experimental Social Psychology, 38, 2006.
• Victoria Bellotti и др. «What a to-do: studies of task management towards the design of a personal task list manager». CHI 2004.
• Sophie Leroy. «Why is it so hard to do my work? The challenge of attention residue when switching between work tasks». Organizational Behavior and Human Decision Processes, 109(2), 2009.
• Gloria Mark. Attention Span: A Groundbreaking Way to Restore Balance, Happiness and Productivity. Hanover Square Press, 2023.
• Cal Newport. «The Rise and Fall of Getting Things Done». The New Yorker, 2020.
• Merlin Mann. 43 Folders — архив ранней IT-адаптации GTD и последующей критики «продуктивности ради продуктивности».
• Oliver Burkeman. Four Thousand Weeks: Time Management for Mortals. Farrar, Straus and Giroux, 2021 — аргумент против идеи, что систему можно догнать до состояния «всё под контролем».
• Всемирная организация здравоохранения. Burn-out an «occupational phenomenon»: International Classification of Diseases, 2019.

Что дальше

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

Приоритизация: матрица Эйзенхауэра, ABC, MoSCoW, «съешь лягушку»