В параграфе 3.4.3 мы рассмотрели метод волшебной феи. Этот метод предельно прост, но область его применения ограничена простыми и понятными проектами. Несмотря на то что подавляющее число всех проектов, с которыми нам приходится сталкиваться, довольно просты, иногда перед нами встают задачи, сложные настолько, что вначале мы даже не представляем, как к ним подступиться. Очень часто, кстати, подобные задачи прокрастинируются по следующему сценарию: мы смотрим на задачу глазами своей обезьянки, и она говорит: «Хм… какой сложный проект, но он важный и им надо заняться. Обязательно им займусь. Вот только сейчас быстренько с мелочью разберусь, чтобы она не отвлекала». Как вы понимаете, к тому моменту, когда вы разберетесь с мелочью, мыслетоплива у вас не останется совсем и единственное, что можно будет сделать с этим проектом, — отложить работу над ним на завтра. А завтра, скорее всего, повторится то же самое.

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

К нижеследующим мыслям меня подвели беседы с Анатолием Левенчуком. Как-то раз Анатолий рассказал мне, что у нас существует некоторая лингвистическая путаница (и в этой книге она тоже имеется). Мы путаем такие понятия, как дела, проекты и образ жизни. Проект — это частный случай дела, когда мы практически сразу можем составить план его выполнения. Дело — это более общий случай проекта, когда максимум того, что мы можем знать, — это желаемый результат дела и следующий шаг по его выполнению, при этом план достижения этого результата сначала нам еще совсем не ясен. Пример — уголовное дело. Когда следователь получает дело к расследованию, вряд ли он способен сразу же нарисовать диаграмму Ганта для всех следственных действий. От врача, к которому только что поступил новый больной, наивно ждать план лечения прежде, чем он проведет серию анализов. Когда служба технической поддержки получает жалобу от клиента, у которого «что-то почему-то не работает», нередко требуется несколько итераций получения диагностической информации, прежде чем хоть что-то станет ясно. Это все — дела (в английском языке — case). Очень часто, сталкиваясь с делами, мы хотим, чтобы они были проектами. Самый веский аргумент: «Мне же надо определить сроки». Действительно, очень часто от нас ожидают ответов на вопросы «когда?», «сколько?», «почему так долго?». Но далеко не всегда эти вопросы имеют точный ответ, да и сам процесс получения ответа может, в свою очередь, оказаться непростым делом (здесь дело — это тот самый case, с понятным результатом, но непонятным планом его достижения). Что страшного может произойти, если мы начнем обращаться с делом как с проектом? Для ответа на вопросы о сроках необходимо в том или ином виде составить план. Если в самом начале мы совсем немного знаем о деле, то и план будет весьма приблизительным и ответы о сроках будут содержать большую погрешность. Само по себе это не очень страшно, по крайней мере, если план не превратился в обязательство. Но очень часто именно это и происходит. По мнению Элияху Голдратта, это одна из коренных причин кратного увеличения сроков проектов{43. Механизм этого явления прост. С одной стороны, когда ко мне прилетает запутанное дело с вопросом «когда ты его завершишь?», в качестве ответа на этот вопрос от меня ожидают оценку. Оценка — это прогноз, догадка. Нечто, по своей природе содержащее ошибку в бо льшую либо в меньшую сторону. Но очень часто оценка начинает (явно или негласно) восприниматься как обязательство: «Мы, конечно, понимаем, что это оценка, она содержит ошибку и не обязана быть точной. Но если ты превысишь обозначенное время, то мы тебя накажем». В итоге мне необходимо назвать срок, к которому я точно успею. Но так как этот срок известен мне лишь приблизительно, мне нужно как можно лучше подстраховаться на случай непредвиденных обстоятельств. Само по себе наличие большой подушки безопасности в оценке времени никак не сказывается на сроке выполнения работы, но дальше в игру вступает студенческий синдром и закон Паркинсона, в результате чего возникает эффект выпрямления сроков из параграфа 2.3.5. Что мы имеем в итоге? Чем раньше мне приходится отвечать на вопросы о сроках, тем больше у меня неопределенности. Чем больше неопределенности, тем больше мне нужно времени для подстраховки. Чем больше времени для подстраховки я заложу, тем больше будет потеряно на эффекте выпрямления сроков. Конечно, выпрямление сроков играет здесь решающую роль, но усугубляется все как раз тем, что, явно или нет, планы имеют тенденцию восприниматься как обязательства.

Еще один неприятный момент, вытекающий из раннего составления планов, — это эффект установки (einstellung effect). Он заключается в том, что наличие у вас какой-то идеи препятствует появлению лучшей идеи{44. В итоге, составляя план на ранних этапах, вы поневоле принимаете ряд решений относительно пути, по которому вы будете идти к результату. Эти решения будут опираться на ту небогатую информацию, что доступна вам в самом начале. Позже, по мере приближения к результату, вы будете все больше и больше узнавать о проекте, но из-за эффекта установки вам будет намного сложнее заметить лучшие и более качественные решения. Подробные ответы на вопросы о сроках и планах — в параграфе 4.1.6 и параграфе 4.1.7.

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

Из-за путаницы между проектом и образом жизни могут возникать различного рода неприятности. Иногда мы подсознательно ищем нечто такое (пусть даже очень сложное), что стоит выполнить один раз — и наше желание исполнится. Сделали это «что-то» — и мы знаем английский, умеем рисовать или играть на гитаре, освоили технику личной эффективности, похудели и обрели хорошую физическую форму. Профит! Ура! Можно переходить к следующему пункту своего жизненного плана.

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

Даже такая привычная активность, как уборка дома, может рассматриваться как проявление немного неправильного образа жизни. Следите за ходом моих мыслей. Я хочу, чтобы дома у меня было чисто. Чтобы достичь этого, я планирую генеральную уборку. Так как это непростой проект, требующий от меня много сил и времени, то проходит некоторое время (иногда очень долгое) перед тем, как я все же решусь и проведу эту уборку. Скорее всего, первую неделю после этого у меня будет довольно чисто, но с большой вероятностью уже к началу второй недели необходимость в генеральной уборке опять замаячит на горизонте. Но если я не люблю убираться и при этом хочу жить в доме, где чисто всегда, то разумнее было бы начать жить так, чтобы каждый день у меня в доме становилось чуточку чище, чем было вчера (или как минимум не грязнее). Тогда уже в среднесрочной перспективе у меня в доме будет достаточно чисто, при этом мне придется тратить усилия сильно меньшие, чем требуются для генеральной уборки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.

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

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

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

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

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

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

К сожалению, в состоянии неопределенности многие чувствуют себя очень некомфортно, поэтому боятся начать выполнение дела до тех пор, пока все не станет понятным до конца. Однако в большинстве случаев этого не произойдет, пока не будет сделан хотя бы первый шаг, а то и вовсе до тех пор, пока большая часть пути не окажется пройденной. Из-за этого люди, обладающие определенным складом характера, склонны впадать в «паралич анализа». В психологии есть понятие «толерантность к неопределенности», показывающее, насколько комфортно человек себя ощущает в ситуации, когда не все понятно, и насколько он готов действовать в таких условиях. Экспериментально было показано, что среди испытуемых с высоким уровнем толерантности к неопределенности преобладали высокообразованные и весьма эффективные люди{47, отличавшиеся к тому же высоким уровнем межличностного эмоционального интеллекта и творческими способностями{48. Ричард Вайзман в своей книге{49 утверждает, что люди, более толерантные к неопределенности, склонны чаще других замечать благоприятные возможности и смотреть на мир с различных точек зрения. Непредсказуемость и неопределенность — это естественная черта окружающего нас мира. Есть люди, которые способны это принять и с комфортом жить и работать в ситуации, когда многое непонятно, а есть люди, которые стремятся создать хотя бы иллюзию определенности. Первым живется намного проще.

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

Это частный случай стратегии выполнения дел и проектов, изображенной на рис. 39. Похожий метод лежит в основе Agile-методологий разработки программных продуктов, а в методологии Lean Start-up он называется Minimal Viable Product.

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

Многим известен принцип Парето (он же принцип 80/20), гласящий, что 20 процентов усилий обеспечивают 80 процентов результата. Этот метод лег в основу одного из учений о личной эффективности{50, призывающего научиться концентрироваться именно на этих двадцати процентах.

Воспользоваться этим методом довольно просто: представьте себе конечный результат вашего проекта настолько четко, насколько сможете. А теперь представьте, что послезавтра проекту конец (или возьмите срок, который вам кажется более-менее разумным, и поделите его на 10, а лучше на 20). Понятно, что при таких ограничениях вам уже не до красот. Но если бы эти ограничения стали реальностью, что бы вы сделали в этих рамках такого, чтобы максимизировать потенциальную пользу или минимизировать потенциальные потери?

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

Рис. 40. О выборе между сделать хорошо и сделать плохо

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

На практике все обычно сводится к парадоксу филосораптора:

Рис. 41. Парадокс филосораптора

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

Примерно похожая стратегия была названа Нассимом Талебом стратегией штанги{51. Эта стратегия сочетает в себе две крайности — с одной стороны, нужно всевозможными способами обезопасить себя от последствий провала проекта и минимизировать вероятность неприемлемого результата, а с другой стороны, оставшиеся ресурсы нужно потратить на улучшение уже имеющегося результата, в том числе не брезгуя высокорискованными идеями, способными принести неожиданную отдачу (даже если наиболее вероятным исходом будет провал этой идеи).

Техники из этого параграфа прекрасно дополняют метод рационального фланёра и метод минимально приемлемого результата. Сейчас я расскажу, как выбрать лучшее решение или лучший путь достижения результата. Самое первое, что нужно для выбора, — сделать так, чтобы было из чего выбирать, то есть набрать много вариантов различной степени бредовости. Барбара Оакли{52 писала, что даже теорема Пифагора (казалось бы, не самая сложная на планете) имеет около трех сотен доказательств. Маловероятно, что вы столкнулись с проблемой, которую можно решить лишь одним-единственным способом. Но увидеть все разнообразие вариантов решений может быть не так уж просто, для этого потребуется навык переключения между различными режимами мышления. Барбара Оакли говорит о двух: сфокусированном и диффузном. В сфокусированном режиме мы можем думать о деталях какой-то конкретной идеи, оценивать ее. Но для того, чтобы увидеть все разнообразие идей, нам нужен диффузный режим мышления. В каждый момент времени мы находимся в каком-то одном из них, мало того, мы всегда тяготеем к сфокусированному состоянию. Именно поэтому, когда нам нечем заняться, взгляд сам ищет себе развлечения: мы начинаем читать рекламу на щитах, обращать внимание на передачу по радио или всматриваться в движущиеся картинки в телевизоре. К сожалению, сидеть, ничего не делая, для многих из нас — очень сложная задача.

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

Рис. 42. Схема вопросов для более детального определения результата

1. Что надо сделать? Это и есть ваш проект, опишите его одним-двумя предложениями.

2. Чтобы что? Какие выгоды вы ожидаете получить в результате выполнения проекта?

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

4. А не то? Что произойдет, если проект не будет выполнен?

5. И что? Насколько страшны и суровы последствия невыполнения этого проекта?

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

7. Как еще можно достичь «чтобы что»? Есть ли пути, альтернативные реализации исходного проекта, но дающие те же (а то и лучшие) результаты?

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

1. Как бы подошел к этому проекту:

А. Ребенок.

Б. Бэтмен.

В. Полный идиот.

Г. Эрик Картман.

Д. Ваш лучший друг.

Е. Василий Иванович Чапаев.

2. Придумайте и запишите две-три аналогии для проекта вида «это так же, как». Например:

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

Б. Завершить проект — это так же, как Белоснежке с семью гномами выиграть в баскетбол у Chicago Bulls.

В. Разобрать балкон — это так же, как игра в тетрис, только в обратном порядке.

Г. Записаться к стоматологу — это так же, как заказать по телефону суши с самовывозом.

3. Попробуйте изобразить проект при помощи простых геометрических фигур и человечков.

4. Какие ограничения есть у проекта? Попробуйте представить, что вы их нарушили. В каких случаях это будет даже к лучшему? Например:

А. Нужно выпустить релиз до отпуска — я в отпуске, а команда все делает сама без меня… (они так намного продуктивнее трудятся, тем более из отпуска я не смогу ничего сломать).

Б. Проект нужно завершить до конца месяца — через полгода мы еще работаем… (клиенту понравилась наша идея, и он с радостью согласился на дополнительные улучшения).

В. Для въезда страну мне нужна виза — я стою на пограничном контроле без паспорта… (меня депортируют на родину рейсом с пересадкой продолжительностью в три недели на тропическом острове без интернета).

5. Если у вас уже есть направление решения, можно ли выполнить проект, делая все наоборот?

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

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

В. Задавать головоломки кандидату на собеседовании? А пусть он нас тестирует!

6. Если ваше решение не идеально и приводит к нежелательным побочным эффектам, в каких ситуациях эти эффекты были бы очень даже желательны? Например:

А. Отпуск в декабре — холодно. Но вот если бы я катался на лыжах…

Б. Делать ремонт в квартире с мебелью — неудобно, хотя если белить потолок, лежа на шкафу, то можно не тратиться на стремянку…

7. Порвите шаблон, сделайте не так, как принято. Например:

А. Начать новую жизнь с понедельника? А давай со среды!

Б. Отвечать на e-mail? Может, отправить ответ на открытке обычной почтой?

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

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

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

В этом параграфе я изложу идею адаптивного планирования. Смысл ее заключается в том, что мы изначально признаем наличие неопределенности:

1. Мы не очень точно представляем объем работы, которую надо сделать.

2. Мы не очень точно знаем, с какой скоростью мы можем выполнять эту работу.

3. Нам постоянно добавляется новая работа, и мы не знаем, сколько ее еще будет добавлено.

Однако мы предполагаем, что:

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

2. Мы умеем измерять скорость нашей работы и оценивать объем приходящей новой работы.

3. Сама работа однотипна, то есть мы можем использовать данные о том, как работа выполнялась в прошлом, для прогнозирования выполнения работы в будущем (в общем случае это тоже не так. Например, если мы имеем дело с проектом, где за каждую фазу отвечает своя команда, то знание скорости, с которой работает команда 1, ровным счетом ничего не говорит нам о том, с какой скоростью будет работать команда 2).

В этом случае мы можем разбить всю работу на итерации (или отчетные периоды) и если:

1) итераций будет достаточно много (хотя бы десяток),

2) в течение каждой итерации мы будем завершать много (хотя бы штук пять) задач,

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

В деталях этот метод описан в моей статье{54 и на моем сайте{55, где также есть полезные Excel-шаблоны для описанного метода и дополнительные видеоматериалы. Основная идея метода заключается в следующем. Мы считаем, что изначально у нас есть объем работы B, измеренный в любых единицах работы, какие нам нравятся, но лучше, если это будут относительные единицы трудозатрат. Также мы считаем, что в каждую итерацию мы выполняем объем работы V и нам добавляют объем работы D (эти величины в общем случае могут быть случайными, в статье{56 говорится, как с этим быть; здесь же мы наивно предположим, что эти величины постоянны). Изначально ни V, ни D мы не знаем, но по прошествии двух-трех итераций (если мы аккуратно ведем учет выполненной и добавленной работы) мы уже можем сделать предположение об их значениях в будущем.

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

Рис. 43. Расширенная диаграмма сгорания работ

Через несколько итераций у нас появится достаточное количество данных, чтобы экстраполировать на будущее объем выполненной работы и объем добавленной. Если нам повезет, они будут пересекаться:

Рис. 44. Прогноз даты завершения проекта

Точка пересечения обозначает не точную дату завершения проекта, а «наиболее вероятную» дату его завершения. В свою очередь, наиболее вероятная дата может соответствовать 50 %, 40 %, а то и вовсе 20 %-ной вероятности завершения в эту дату, поэтому для определения приемлемой вероятности завершения проекта к точке пересечения нужно накинуть еще несколько итераций. Сколько именно, зависит от того, насколько непостоянны скорость выполнения работы и частота добавления новых задач. Здесь я не буду рассказывать, как посчитать эту добавку, — отсылаю читателя на свою страницу{57, где есть Excel-шаблон со всеми необходимыми формулами.

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

Очень часто мы попадаем в следующую ситуацию. Когда нам надо оценить срок завершения проекта, по тем или иным причинам мы считаем, что нам надо брать на себя обязательства успеть к обозначенному нами сроку. То есть мы ни в коем случае не должны опоздать. С другой стороны, практически любой проект влечет за собой неопределенность, и точный срок его завершения определить попросту невозможно. Но нам не нужно называть точный срок. Да-да, не нужно. Нам нужен срок, в который мы уложимся, чувствуете разницу?

Повторюсь: основная причина, по которой мы не можем назвать точный срок завершения проекта, заключается в том, что мы не знаем всего, что надо будет сделать для его завершения: в процессе работы может случиться много непредвиденного, требующего дополнительных затрат времени. А может и не случиться. Но так как нам нужен срок, в который мы уложимся, даже если что-то случится, то мы оцениваем проект так, как это показано на рис. 45а: к безрисковой оценке «успеем, если ничего не случится» добавляем буфер «на всякий случай». Очень часто этот буфер превышает саму безрисковую оценку. В принципе, в таком подходе нет ничего страшного или неправильного, от неопределенности мы можем защититься только избыточностью резервов. Страшное (или неправильное) начинается потом, на этапе выполнения…

.

Рис. 45. Оценка и выполнение проекта

Когда мы проводим оценку проекта, на временно й оси появляются три характерные точки (см. рис. 45а): A — точка начала работы над проектом, B — точка завершения проекта, «если не случилось ничего непредвиденного», С — точка завершения проекта, «если случились незапланированные неприятности». Чисто теоретически, если мы закладываем достаточно большой буфер (а мы обычно так и делаем), большинство проектов должны завершаться где-то на отрезке BC, то есть до названного крайнего срока.

Но на этапе выполнения нередко начинают происходить странные с рациональной точки зрения вещи (конечно, не со всеми и не всегда). Если при оценке проекта в точке A предполагалось начало работы над проектом, то в реальности на большей части отрезка A’B’ (рис. 45б) оказывается, что проект «не горит», в то время как, о ужас, есть много других «горящих» проектов, которые надо сделать в первую очередь. В итоге, если теоретически в точке B проект уже мог бы быть завершен, на практике в точке B’ над ним только-только начали работать (он уже начинает «дымиться»). Если ничего не случится, то мы можем уложиться к моменту C’, хотя в теории мы должны были успеть к этому сроку даже в том случае, если случилось бы многое из незапланированного. Однако если на практике случается что-то незапланированное, проект запаздывает и завершается где-то в окрестности точки D.

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

Итак, первое правило успевания в срок состоит из двух пунктов:

1. Закладывайте временной буфер на непредвиденные обстоятельства (с этим практически у всех все хорошо).

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

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

Если вы умеете начинать работу вовремя и грамотно расходуете заранее заложенный буфер на непредвиденные обстоятельства, и при этом у вас все равно наблюдаются трудности с соблюдением сроков, то, скорее всего, их решение лежит за пределами области личной эффективности. Проблема явно затрагивает работу всей вашей команды, решения для нее вам может подсказать, например, теория ограничений. Тут{58 рассматривается метод критической цепи, применимый для управления проектами, а тут{59 — производственное планирование на базе теории ограничений, применимое для операционной работы.

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

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

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

Аналогичным образом раннее завершение проекта очень часто не рассматривается его участниками как благоприятный исход: «В следующий раз нам не дадут заложить такой буфер», «Нас назовут трусами-истеричками, раздувающими сроки» или «Все равно это никому не нужно». Если это ваш случай, решите заранее, как вы будете себя вести, закончив проект раньше срока (если вы все делаете правильно и не выпрямляете сроки — это будет самый частый вариант). Если вы работаете в среде, где раннее завершение не приветствуется, вы можете использовать сэкономленное время в благих целях, например, экспериментируя и стараясь достичь выдающихся результатов за пределами ожиданий (естественно, если эти эксперименты будут обратимы и вы гарантированно не ухудшите то, что у вас уже есть). Это очень близко к тому, что Нассим Талеб называет «стратегией штанги»{60 — стратегией, позволяющей извлекать выгоду из хаоса и непонятностей.