Почему мы отказались от списка дел

Последнее обновление: 19 августа 2026 г.

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

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

У длинного списка дел есть когнитивная причина давить на психику. Психологи Э. Дж. Мазикампо и Рой Баумейстер обнаружили, что незавершённые задачи продолжают вторгаться в наши мысли и отвлекают от того, чем мы занимаемся, пока мы не составим для них конкретный план, и только тогда навязчивое напоминание стихает.

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

Для чего служит список дел?

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

Проще говоря, список дел помогает нам запоминать (отслеживать) и сравнивать (ранжировать) наши задачи.

Когда список дел перестаёт справляться со своей задачей?

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

При огромном числе одинаково важных задач в списке отслеживать и ранжировать их снова становится трудно.

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

Например, если в списке дел стоят одновременно «Прочитать n страниц Книги X» и «Получить лицензию пилота», они станут сопоставимыми только если мы понимаем контекст, к которому относится задача про чтение.

Допустим, мы вспоминаем, что «проект, срок сдачи которого завтра» требует сначала усвоить материал тех n страниц Книги X, — тогда мы можем взвесить приоритет между «проектом, срок сдачи которого завтра» и «Получить лицензию пилота».

Неоднородный список поэтому требует, чтобы мы помнили все контексты, связанные с каждой задачей, а это оказывается непросто.

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

Сталкиваются ли задачи в наших привычных системах управления задачами с этими ограничениями?

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

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

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

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

Как программы для управления задачами справляются с ограничениями списка дел?

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

Более гибкая система может позволить подзадаче иметь собственные подзадачи, что фактически означает бесконечное присоединение ещё одного списка к самому себе. Такая схема создаёт иерархическую структуру, изображённую ниже:

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

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

Что такое вложенный чек-лист?

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

Но как показать вложенные списки задач?

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

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

«Получить отчёт B2–1» в разделе «Завершить A» требует, чтобы «Сделать отчёт B2–1» в разделе «Завершить B» был выполнен. Но из-за ограничений при отображении вложенных списков компромиссный вид покажет:

или

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

Ни один из вариантов не передаёт контекст, который скорее указывал бы, что одна подзадача одной иерархии задач зависит от подзадачи другой.

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

Как древовидная структура сохраняет естественную иерархию задачи?

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

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

При такой структуре задачи и их зависимости чётко представлены в системе управления задачами. Мы подробнее разбираем, как это работает с пакетами задач и вложенными списками, в статье Всё о пакете задач и концепции вложенности в Quire, а применение на реальных командах можно увидеть в статье 6 реальных сценариев использования подсписков Quire.

Как Quire обрабатывает вложенные списки задач?

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

Именно в этом разница между наслаиванием списков и выращиванием дерева, и именно поэтому дерево задач, а не список, стало основой Quire.

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

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

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

Список дел помогает делать наши цели более «осязаемыми», но он никогда не задумывался как основа для программного обеспечения по управлению задачами.

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

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

Дерево задач служит лучшей основой для системы управления задачами. Нам было бы интересно узнать, работает ли эта идея для вас; начните бесплатно с Quire и попробуйте дерево задач в деле.

Древовидная структура — лишь часть общей картины: узнайте, как она сочетается с GTD, Kanban и тайм-блокингом в статье постройте систему управления задачами, которая работает.

Часто задаваемые вопросы

Для чего на самом деле нужен список дел?

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

Почему списки дел перестают работать по мере накопления задач?

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

Почему вложенные списки не решают проблему полностью?

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

Чем древовидная структура лучше плоского списка?

Она сохраняет естественную иерархию задачи, поэтому открытие задачи также показывает её родительские и дочерние узлы. Зависимости остаются видимыми, а ветки можно перетаскивать или сворачивать, чтобы сохранять фокус.

Что такое вложенный чек-лист?

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

Как Quire обрабатывает вложенные списки задач?

Любая задача может содержать подзадачи, а каждая подзадача — свои собственные, поэтому проект образует одно дерево. Откройте задачу — и её родители с потомками придут вместе с ней; перетаскивайте или сворачивайте целые ветки прямо в процессе работы.