Продолжение моего учебного курса по проектному управлению. Предыдущие материалы:
1. Что можно назвать проектом, а что нельзя, и каковы критерии успеха менеджера
2. Три фундаментальных принципа проектного управления
3. Роли в проектном управлении
4. Управление заинтересованными сторонами
5. Устав проекта - это скорлупа яйца
6. Алгоритм управления содержанием проекта
8. Создание концепции проекта (project scope statement)
Что такое иерархическая структура?
Это иерархический список, своего рода "майнд мэп" (mind map), в котором первоначальный, родительский узел находится наверху, а все дочерние - под ним.
Поясним на примере.
Представьте, что мы делаем велосипед - у нас такой проект, его условное название "создать велосипед". Это название мы помещаем в верхнюю часть ИСР.
Затем спускаемся на уровень ниже. Что надо сделать, чтобы создать велосипед? Сделать основные компоненты детали – раму, колеса, руль, седло и т.д. Их мы описываем на втором уровне, из них "состоит" наше создание велосипеда.
А что, в свою очередь, нужно предпринять, чтобы сделать колесо? Создать или раздобыть его элементы (обод, камеру, шину, спицы и прочее). Из них состоит колесо (обозначим их как узлы третьего уровня, из которых состоит колесо).
И так далее, уровней может быть много - можем спускаться все ниже и ниже. Картинка, которая в итоге получится - и есть ИСР.
С ИСР есть сложность, когда ее изучаешь или о ней рассказываешь. Она интуитивно понятна. Тем не менее, когда мы создаем ИСР, нужно следовать определенным правилам.
Первое правило: наверху находится главный результат проекта, то, чего вы должны достичь. И это обязательно коррелирует с целью проекта. Например, создать велосипед.
Второе правило: все работы должны иметь единообразные наименования. Вы можете использовать существительные (это самое лучшее) или фразы с глаголами, но смешивать их нельзя. Почему важно использовать единообразные наименования? Допустим, у вас везде работы названы именами существительными, например, рама, колеса, педали. А какая-нибудь работа не хочет именоваться в этом же стиле, ее не получается сформулировать, хочется поставить глагол. Почти всегда причина того, что вы не можете подобрать существительное, заключается в том, что вы где-то ошиблись, где-то поторопились. Либо вы работу неправильно формулируете, либо надо подняться на уровень выше - может быть, эту работу надо отнести к другому узлу. То есть где-то имеется смысловая ошибка, вы декомпозируете некорректно. Надо попробовать перестроить этот или соседний узел. Почти всегда, если вы не можете все узлы именовать одинаково, проблема либо в самом узле, либо рядом. Почему сложность с наименованием является признаком проблемы - непонятно. Но это работает. Поэтому надо стараться называть этапы однообразно, и будет меньше ошибок.
Третье правило: второй уровень самый важный в ИСР, и он должен давать представление о проекте в целом, чтобы была понятна цель. Достаточно посмотреть только на первый уровень и второй, чтобы понять нормальная ли вообще получается структура. Например, на первом уровне у нас велосипед. Смотрим на второй уровень, у нас там – сделать раму, колесо и руль, купить седло. Если вы или сторонний наблюдатель посмотрите на второй уровень, станет ясно, что будет происходить на проекте. Если вы решили велосипед не создавать с нуля, а заполучить иным способом, например похитить, то второй уровень у вас будет совершенно другим: купить маску и кусачки, дождаться ночи, выполнить другие работы. Результат тот же – у вас появился велосипед. Если же вы решили заказать велосипед в Китае, то вообще надо сделать только 2 вещи: заказать и забрать.
Другой пример – мы делаем томограф. Это сложный прибор, и к нему нужен очень сложный софт. И огромный блок работ связан с программным обеспечением.Что значит сделать томограф в общем случае? Это значит – сделать одну часть, потом другую, закупить какие-то части, которые мы сами не производим, сделать софт. Все эти работы надо перечислить на втором уровне – что-то разрабатываем, что-то закупаем, что-то собираем. В таком варианте более-менее понятно, что надо делать на проекте.
На рынке томографов есть достаточно большое количество компаний, которых называют негативным термином "перешильдовщики" (замаскированные перекупщики). Это компании, которые сами томографы не делают, а покупают их в Китае и вносят минорные правки, чтобы с полной уверенности указать "сделано в России". У таких компаний потенциальный проект тоже, возможно, будет носить название «Сделать томограф», но он будет проще. В ИСР будут значиться такие этапы, как заказать прибор, изменить страну производителя. И по второму уровню ИСР понятно, делаете вы томограф самостоятельно или занимаетесь перекупкой.
На втором уровне может быть множество шагов, но должен присутствовать здравый смысл (не стоит заводить их больше двух десятков, иначе он станет нечитаемым).
Следующее правило – правило 100%. Если вы что-то потеряли в ИСР на втором уровне, значит, оно выпало из проекта совсем. Например, если на втором уровне вы забыли про педали, то у вас уже получится не велосипед, а самокат. Понятно, что есть элементы, состоящие из множества деталей, например, седло состоит и из пружин, и из самого сиденья, и из прочих деталей. Но педали не являются частью чего-то, поэтому получится совершенно другой продукт.
Следующее правило – ориентированность на поставки. В этом правиле часто ошибаются. Каждый узел дает ответ на вопрос, что будет, когда закончится эта работа. Условно говоря, надо выкопать яму. Сделал – покажи яму. В этом смысле плохие узлы – «подумать над архитектурой». Подумал или нет, не проверишь. Поэтому надо правильно формулировать названия работ. Если надо подумать над архитектурой, то наименование узла может быть записано так: «подумать над архитектурой и предложить какой-то вариант». То есть обязательно должен быть результат по факту.
Еще одно правило - узлы не перекрываются по содержанию. Это, в принципе, понятно. Спицы не могут относиться и к рулю, и к колесу. Даже если у руля есть спицы, они какие-то другие, не такие как у колес. Тут трудно ошибиться. Хотя и бывают общие работы. Например, покраска. Может быть, покраска рамы, а может быть покраска руля. Но в данном случае покраску надо написать дважды и к одному, и к другому. Иначе потеряется структура вообще.
Обсудим вопрос по глубине декомпозиции. Психологи любят такой тезис: они говорят, что все люди любят колоть дрова. Это простая работа, и ее результат виден сразу. Иерархическая структура это такая же штука – это простая деятельность, особенно если вы понимаете свой проект. И очень приятно нарезать деятельность на куски. Но не надо увлекаться. Все должно быть очень четко, надо описывать конкретные идеи. А какие есть критерии, ориентиры, чтобы было понятно, в какой момент пора остановиться?
Самый простой способ это понять – спросить у исполнителя. Поскольку планы пишутся командные, удобно об этом просто спросить. Первый критерий – исполнителю понятно, что надо делать. Тут тоже многое зависит от разных факторов. Например, надо сделать какую-то операцию. Хирургу только ее название скажешь, и он уже поймет, что надо делать. А если исполнитель – интерн, то ему нужно будет еще детально все разъяснить. Также это зависит от сложности проекта: чем сложнее работа, тем подробнее ее надо описывать. Но когда исполнителю понятно, дальше дробить не надо. Второй критерий – когда исполнителю не только понятно, что надо делать, а он еще может определить, сколько времени это займет. То есть он должен определить срок выполнения работы. И быть уверенным в нем. И дальше не надо декомпозировать. Исключение – когда исполнителю понятно, что надо делать, и он знает, сколько времени надо, но сама работа занимает много времени. Например, надо выкопать длинный ров и копать придется долго – 6 месяцев. Но это будет очень сложно контролировать. Поэтому менеджеру в такой ситуации желательно нарезать эту работу на дополнительные узлы, например, человек будет копать и через каждый 100 м менеджер проверяет, как продвигается работа. Потому что через полгода или год, непонятно будет, что сделали, выполнили проект или нет. В остальных случаях, когда исполнителю ясно, что делать, и он может указать сроки, декомпозировать задачи больше не надо.
Еще одно правило: использовать принцип набегающей волны. Когда мы говорили про проект, мы говорили, что в нем сочетается конечность и неопределенность. Неопределенность не дает вам сразу построить планы очень детально – от начала до конца, и здесь вам поможет прием набегающей волны. То есть надо выбрать первые этапы, потом следующие, следующие. Чтобы не плодить планы, надо сначала декомпозировать, а уже потом дополнительно расписывать подробно все работы. Прием набегающей волны – это постепенное планирование. Когда проект дойдет до работ, тогда мы их и распишем, а пока мы просто укрупненно их оцениваем на втором уровне.
Итак, мы попытались уточнить грани треугольника, в частности, грань «содержание». В уставе есть все, но в общих чертах. А нам нужно понимать, что конкретно мы будем делать. Поэтому сначала мы собираем требования, потом пишем концепцию, а затем создаем иерархическую структуру работ. Последние два шага – концепция и ИСР – принято называть базовым планом содержания. Матрица требований – это промежуточный этап, на ее основе пишут концепцию и больше к ней не возвращаются. Если только не придется что-то уточнить. Но в целом менеджер работает с двумя вещами – концепцией и ИСР.
Зачем вообще рисовать иерархическую структуру работ? Ведь есть подробное ТЗ, где подробно описана задача, со схемами, рисунками, разделами? У ИСР две функции:
- можно визуально заметить какие-то ошибки, вы могли что-то упустить или, наоборот, продублировать;
- менеджеру нужно управлять проектом, отслеживать прогресс, а для этого прогресс нужно измерять. Представьте, что вы не создавали ИСР, а ограничились техническим заданием. По ТЗ очень трудно определить, на сколько процентов "мы продвинулись за сегодня". А с ИСР (и планах сделанных на его основе) - это сравнительно легко. Вы отмечаете, что сделано, что начали делать, к чему еще не приступили на сегодняшний день. Оценивая все это в сумме, можно определить процент завершения проекта, насколько вы продвинулись или отстаете.
Важно: ИСР – основа для будущих планов, расписания, бюджета. Нет ИСР – нет нормального управления. Многие вещи из управления можно выкидывать, но устав и ИСР (планы) – нельзя. Если вы их выкинете, контроля не будет.
Предыдущая часть курса: Создание концепции проекта (project scope statement). Курс по управлению проектами, часть 8
Следующая часть курса: Управление качеством – ключевые термины. Курс по управлению проектами, часть 10
Начало курса: Что можно назвать проектом, а что нельзя, и каковы критерии успеха менеджера. Курс по управлению проектами, часть 1
Если вас интересует тема "Управления проектами" и вы хотите самостоятельно подготовиться к экзамену на сертификат Project Management Professional, то приглашаем пройти новый видеокурс Ивана Селиховкина "Подготовка к экзамену РМР"