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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.1.6. Техника прогнозирования сроков завершения

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

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

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

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

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

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

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

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

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

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

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

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

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

то мы сможем корректировать нашу исходную оценку (полученную любым доступным нам способом) на основе полученных данных.

В деталях этот метод описан в моей статье {56} (#lit56) и на моем сайте {57} (#lit57), где также есть полезные Excel-шаблоны для описанного метода и дополнительные видеоматериалы. Основная идея метода заключается в следующем. Мы считаем, что изначально у нас есть объем работы B, измеренный в любых единицах работы, какие нам нравятся, но лучше, если это будут относительные единицы трудозатрат[55 - Практика использовать относительные оценки трудозатрат широко распространена в Agile-методологиях и основывается на том, что при оценке люди склонны сравнивать задачи друг с другом и ошибка носит мультипликативный характер. То есть если я задачу А оценил в 2 часа, то при оценке задачи Б я буду соизмерять ее с задачей А. И если я задачу Б оценю в 6 часов, а потом задачу А выполню за три часа вместо двух, то это будет означать, что я ошибся не на один час, а в полтора раза. И задача Б скорее потребует 9 часов, а не 7 (как было бы, если бы оценка носила аддитивный характер).]. Также мы считаем, что в каждую итерацию мы выполняем объем работы V и нам добавляют объем работы D (эти величины в общем случае могут быть случайными, в статье {56} (#lit56) говорится, как с этим быть; здесь же мы наивно предположим, что эти величины постоянны). Изначально ни V, ни D мы не знаем, но по прошествии двух-трех итераций (если мы аккуратно ведем учет выполненной и добавленной работы[56 - Если учета выполненной и добавленной работы у нас нет или мы за один отчетный период ни про одну из задач не можем сказать, что она сделана, то есть мы вроде работали-работали, почти сделали, но еще «надо кое-что доделать» (при этом это «кое-что» может занимать огромное и непредсказуемое количество сил и времени), то ни о каких прогнозах тут и речи идти не может.]) мы уже можем сделать предположение об их значениях в будущем.

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

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

Через несколько итераций у нас появится достаточное количество данных, чтобы экстраполировать на будущее объем выполненной работы и объем добавленной. Если нам повезет, они будут пересекаться[57 - Если работы систематически добавляется больше, чем выполняется, то эти прямые будут расходиться и точка их пересечения окажется, что символично, в прошлом. Почему-то вспоминается излюбленное определенной категорией менеджеров высказывание о сроках проектов: «Это нужно сделать вчера!»]:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если вы умеете начинать работу вовремя и грамотно расходуете заранее заложенный буфер на непредвиденные обстоятельства, и при этом у вас все равно наблюдаются трудности с соблюдением сроков, то, скорее всего, их решение лежит за пределами области личной эффективности. Проблема явно затрагивает работу всей вашей команды, решения для нее вам может подсказать, например, теория ограничений. В {58} (#lit58) рассматривается метод критической цепи, применимый для управления проектами, а в {59} (#lit59) – производственное планирование на базе теории ограничений, применимое для операционной работы.

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

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

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