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