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

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

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

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

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

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

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

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

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

.

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

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

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

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

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

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

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

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