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

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

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

2. Проектная задача может быть непосильна для нашей обезьяны. Если вы помните критерии хорошей формулировки задачи в списке задач, то понимаете, что вряд ли кто-то планирует проекты с такой гранулярностью. Элемент плана проекта для нашей внутренней обезьянки — это уже дело, а то и проект, и, скорее всего, каждая проектная задача будет поэтапно распадаться на несколько задач для обезьянки (рис. 38).

Рис. 38. План проекта и список задач

3. Проектная задача может быть заблокирована другой проектной задачей. Один элемент плана проекта может зависеть от другого. Например, в плане на рис. 38 видно, что задача «Возвести стены» должна начинаться после того, как выполнена задача «Залить фундамент». Если все эти задачи смешать в одну кучу и высыпать в наш список задач, то эти связи там пропадут[88] и полученный список задач перестанет экономить наше мыслетопливо, ведь каждый раз, вместо того чтобы без дополнительных размышлений начать выполнять очередную задачу, мы будем думать: «А все ли из того, что должно предшествовать этой задаче, я сделал? А все ли у меня есть, что требуется для ее выполнения?» Каждая задача в нашем списке должна быть разблокирована.

С нашей точки зрения план проекта — это не список задач, это справочная информация, с которой надо обращаться соответственно. И работа над делом или проектом будет происходить в различных режимах:

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

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

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

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

Часто возникает вопрос, как интегрировать план проекта со своим списком. Если кратко, то лучше никак, поскольку все, что попадает в наш список задач, должно быть осмысленно, а для осмысленности лучше, если записывать задачи будете лично вы, а не кем-то написанная программа. Некоторые дополнительные аспекты интеграции планов проектов (которые могут храниться в корпоративных системах) с личным списком задач я рассмотрю в параграфе 5.10.

Понятие рационального фланёра было введено Нассимом Талебом{45[90]:

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

Другими словами, рациональный фланёр — это тот, кто в работе над делами и проектами использует следующие принципы:

1. Сейчас мы не знаем всего о нашем проекте и признаём наличие неопределенности.

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

3. На основе этой информации мы будем пересматривать свои планы.

Майк Ротер описал схожий метод, использующийся в компании «Тойота» для управления проектами по совершенствованию производственных процессов{46[91]. В моей вольной интерпретации этот метод изображен на рисунке ниже.

.

Рис. 39. Подход к выполнению проектов

Для того чтобы успешно справляться с делами и проектами, нам необходимы три вещи:

1. Ви дение конечного результата. В самом начале это видение не обязано быть четким (и уж тем более не обязано быть описанным в соответствии с методом SMART или еще каким-нибудь методом, названным красивой аббревиатурой[92]).

2. Ближайшее целевое состояние. Это уже понятный промежуточный результат.

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

По словам Ротера, сотрудники компании «Тойота», начиная сложные и непредсказуемые проекты, даже не пытаются сделать так, чтобы все стало понятно с самого начала, — они признают наличие темных зон (или зон жизненного опыта, получаемого в процессе, согласно рис. 39).