Пирамида планирования
Как рождаются продуманные, коварные, умные и любые другие планы? Как составить план? Как пошагово осуществить гениальный замысел и не сойти с ума?
Без чёткого плана не обойдётся ни один серьёзный проект. Но реальность вносит свои коррективы в любой, даже самый продуманный сценарий.
Специалист по управлению проектами Сергей Колганов о том, как пошагово осуществить гениальный замысел и не сойти с ума.
План — штука сложная. Знаменитые полководцы, — а именно им приходилось чаще всего планировать работу других людей, — любили высказаться в том духе, что планы, конечно, нужны, но не стоит полагаться только на них. «Ни один план не переживает встречи с противником», — говорил Хельмут фон Мольтке, один из основателей Германской империи и видный военный теоретик.
Но и без планов в проекте не обойтись — чтобы куда-нибудь прийти, нужно хотя бы в общих чертах представлять, какие шаги для этого надо предпринять.
Для того чтобы повысить качество планов, существует универсальный подход, который очень легко понять и еще легче применять на практике. Этот подход используется во многих крупных компаниях-разработчиках софта, в консалтинговых и прочих продвинутых компаниях.
Сначала формируется видение проекта. Это представление о конечной точке, в которую мы хотим попасть по завершении проекта.
Видение не затрагивает никаких измеримых величин, оно живет в идеальном мире. Предположим, вы собираетесь хорошо провести отпуск. Воображение рисует прекрасную картину — вы с любимой встречаете закат на берегу теплого моря, попивая мартини.
Это и есть видение — картинка появилась, но конкретики еще нет (мартини не в счет).
Чтобы конкретика появилась, кроме распаленного воображения нужно еще декомпозировать видение и определить цели проекта и критерии их достижения. Что нужно, чтобы воплотить видение в жизнь?
Как мы определяем, что видение воплотилось (читай, что цели достигнуты)? Куда конкретно мы идем? В отличие от видения, цели описываются измеримыми величинами.
В нашем примере это могут быть географические, ценовые, временные, погодные, технические параметры. Например, целями проекта может быть поездка на своей машине с палатками в окрестности Туапсе на неделю в июле, приобретение бутылки мартини в «Пятерочке», совмещение отпусков двух участников, покупка шезлонгов и т. д. А могут быть и другие цели — полет на частном самолете на Сицилию, аренда виллы на месяц и заполнение бассейна самым дорогим мартини.
Цели разные, а видение практически не поменялось — удовольствие от отпуска и романтическая обстановка присутствуют в обоих случаях. Благодаря такой инвариантности целей, появляются альтернативные пути развития проекта, чем активно пользуются консультанты, показывая клиентам эти альтернативы и направляя проект в нужное русло.
Когда цели определены и согласованы участниками проекта, можно переходить к еще большей конкретике — формировать требования. Требования — это те характеристики, которыми должен обладать конечный результат проекта, чтобы цели были достигнуты.
В нашем отпускном примере требования звучали бы так: «Температура воздуха не ниже 28 градусов», «Температура воды не ниже 25 градусов», «Дождя нет», «C любимой не поссорился» и т. д. Критерии — количественные характеристики достижения целей. Например, «Дождя нет» = на ладонь, расположенную параллельно земле, за три минуты не упало ни одной капли.
Когда требования и критерии формализованы и согласованы, можно переходить к формированию WBS (Work Breakdown Structure). По-русски это называется «структура декомпозиции работ» . WBS — это список работ, которые нужно выполнить для достижения целей проекта и удовлетворения его требований.
Работы в WBS связаны друг с другом, самая распространенная связь «старт-финиш» — для начала одной работы нужно завершить одну или несколько других. В WBS работы иерархичны — есть крупные фазы проекта, которые состоят из более мелких этапов, которые, в свою очередь, состоят из задач, а те из подзадач, результатов и контрольных точек.
Такая «матрешка» поддерживается всеми инструментами планирования и позволяет отслеживать как проект в целом, так и отдельные его детализированные части.
Замечу, что на этапе построения WBS еще ничего не сказано о связи работ к исполнителям и сроками, сначала важно нарисовать саму структуру. Составляя WBS, нужно очень разумно подойти к детализации работ.
Если расписывать каждую мелочь, на составление плана уйдет много времени, но к цели нас это не приблизит и рисков проектных не снимет, зато мы обязательно в деталях запутаемся. Не стоит писать такую WBS:
* Открыть водительскую дверь машины
* Перенести через порог правую ногу
* Ступить на пол машины
* Сесть в водительское кресло
* Поставить левую ногу рядом с правой
* Перенести правую ногу на педаль тормоза
И т. д.
Достаточно написать:
* Отправиться в путь на машине
Когда работы детализированы, можно привязывать к ним исполнителей и сроки. Удобнее планировать (и дело не только в удобстве) от конечной даты проекта, двигаясь к его началу.
Итак, мы получили следующую картинку:
В этой пирамиде все кирпичики связаны. Захотел поменять график — меняй WBS.
Понадобилось скорректировать требования — получай изменения и в WBS, и в графике проекта. Ну а тому, кто изменил в середине проекта видение, можно только посочувствовать.
Догадайтесь, что будет с его проектом и сколько это будет стоить.
Ну и последнее. Черчилль как-то сказал, что любой умный человек может составить план победы в войне, если он не отвечает за осуществление этого плана.
Менеджерам проектов не повезло (да нет, конечно же им повезло!) — они отвечают не только за планирование, но и за претворение этих планов в жизнь. И они нуждаются в методах, которые позволили бы сделать путь исполнения плана менее тернистым. И такие методы есть.
Но это уже другая история.
