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

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

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

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

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

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

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

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

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

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

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

.

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

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