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

4.1.7. Главные условия, чтобы успевать в срок

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

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

, чувствуете разницу?
Повторюсь: основная причина, по которой мы не можем назвать точный срок завершения проекта, заключается в том, что мы не знаем всего, что надо будет сделать для его завершения: в процессе работы может случиться много непредвиденного, требующего дополнительных затрат времени
[110]

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

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

Когда мы проводим оценку проекта, на временн
о

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

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

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

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

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

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

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

 — производственное планирование на базе теории ограничений, применимое для операционной работы.

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

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

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

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

{60
[113]
 — стратегией, позволяющей извлекать выгоду из хаоса и непонятностей.

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