Иерархическая структура работ (ИСР). Курс по управлению проектами, часть 9

29.11.18

Управление проектом

Следующий этап планирования содержания – декомпозиция собранных в матрицу и описанных в концепции требований. В чем смысл иерархической структуры работ? Мы помещаем главный результат работы наверх, и потом задаем вопрос, что надо сделать, чтобы к этому прийти.  То есть дробим на составные части. Это и называется создать иерархическую структуру – разбить главный результат на компоненты.

Продолжение моего учебного курса по проектному управлению. Предыдущие материалы: 

1. Что можно назвать проектом, а что нельзя, и каковы критерии успеха менеджера 

2. Три фундаментальных принципа проектного управления

3. Роли в проектном управлении

4. Управление заинтересованными сторонами 

5. Устав проекта - это скорлупа яйца

6. Алгоритм управления содержанием проекта

7. Сбор требований

8. Создание концепции проекта (project scope statement)

Что такое иерархическая структура?Проект создания велосипеда

Это иерархический список, своего рода "майнд мэп" (mind map), в котором первоначальный, родительский узел находится наверху, а все дочерние - под ним.

Поясним на примере.

Представьте, что мы делаем велосипед - у нас  такой проект, его условное название "создать велосипед". Это название мы помещаем в верхнюю часть ИСР.

Затем спускаемся на уровень ниже. Что надо сделать, чтобы создать велосипед? Сделать основные компоненты детали – раму, колеса, руль, седло и т.д. Их мы описываем на втором уровне, из них "состоит" наше создание велосипеда.

А что, в свою очередь, нужно предпринять, чтобы сделать колесо? Создать или раздобыть его элементы (обод, камеру, шину, спицы и прочее). Из них состоит колесо (обозначим их как узлы третьего уровня, из которых состоит колесо).

И так далее, уровней может быть много - можем спускаться все ниже и ниже. Картинка, которая в итоге получится - и есть ИСР.
 
С ИСР есть сложность, когда ее изучаешь или о ней рассказываешь. Она интуитивно понятна. Тем не менее, когда мы создаем ИСР, нужно следовать определенным правилам.
 
Первое правило: наверху находится главный результат проекта, то, чего вы должны достичь. И это обязательно коррелирует с целью проекта. Например, создать велосипед.
 
Второе правило: все работы должны иметь единообразные наименования. Вы можете использовать существительные (это самое лучшее) или фразы с глаголами, но смешивать их нельзя. Почему важно использовать единообразные наименования? Допустим, у вас везде работы названы именами существительными, например, рама, колеса, педали. А какая-нибудь работа не хочет именоваться в этом же стиле, ее не получается сформулировать, хочется поставить глагол. Почти всегда причина того, что вы не можете подобрать существительное, заключается в том, что вы где-то ошиблись, где-то поторопились. Либо вы работу неправильно формулируете, либо надо подняться на уровень выше - может быть, эту работу надо отнести к другому узлу. То есть где-то имеется смысловая ошибка, вы декомпозируете некорректно. Надо попробовать перестроить этот или соседний узел. Почти всегда, если вы не можете все узлы именовать одинаково, проблема либо в самом узле, либо рядом. Почему сложность с наименованием является признаком проблемы - непонятно. Но это работает. Поэтому надо стараться называть этапы однообразно, и будет меньше ошибок.

Правила создания ИСРТретье правило: второй уровень самый важный в ИСР, и он должен давать представление о проекте в целом, чтобы была понятна цель. Достаточно посмотреть только на первый уровень и второй, чтобы понять нормальная ли вообще получается структура. Например, на первом уровне у нас велосипед. Смотрим на второй уровень, у нас там – сделать раму, колесо и руль, купить седло. Если вы или сторонний наблюдатель посмотрите на второй уровень, станет ясно, что будет происходить на проекте. Если вы решили велосипед не создавать с нуля, а заполучить иным способом, например похитить, то второй уровень у вас будет совершенно другим: купить маску и кусачки, дождаться ночи, выполнить другие работы. Результат тот же – у вас появился велосипед. Если же вы решили заказать велосипед в Китае, то вообще надо сделать только 2 вещи: заказать и забрать.

Другой пример – мы делаем томограф. Это сложный прибор, и к нему нужен очень сложный софт. И огромный блок работ связан с программным обеспечением.Что значит сделать томограф в общем случае? Это значит – сделать одну часть, потом другую, закупить какие-то части, которые мы сами не производим, сделать софт. Все эти работы надо перечислить на втором уровне – что-то разрабатываем, что-то закупаем, что-то собираем. В таком варианте более-менее понятно, что надо делать на проекте.

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

 


 

Важно: ИСР – основа для будущих планов, расписания, бюджета. Нет ИСР – нет нормального управления. Многие вещи из управления можно выкидывать, но устав и ИСР (планы) – нельзя. Если вы их выкинете, контроля не будет.

Предыдущая часть курса: Создание концепции проекта (project scope statement). Курс по управлению проектами, часть 8

Следующая часть курса: Управление качеством – ключевые термины. Курс по управлению проектами, часть 10

Начало курса: Что можно назвать проектом, а что нельзя, и каковы критерии успеха менеджера. Курс по управлению проектами, часть 1

 

Если вас интересует тема "Управления проектами" и вы хотите самостоятельно подготовиться к экзамену на сертификат Project Management Professional, то приглашаем пройти новый видеокурс Ивана Селиховкина "Подготовка к экзамену РМР"

См. также

10 типовых рисков срывов проекта. Памятка для внедренцев и заказчиков

Кейсы проектов Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    2773    0    1СERP    21    

31

Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

Кейсы проектов Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    14304    0    ASchekachev    37    

55

Организация работы внутренней команды 1С с помощью Канбан

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    5852    0    stnslv    5    

25

Технология проекта внедрения 1С:ERP – как управлять большим проектом

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

Предыдущие мои статьи на тему управления проектами носили концептуальный характер – ради чего мы делаем проекты, почему мы не получаем поддержку от коллектива пользователей, где найти помощь и мотивацию, как победить сложного заказчика. Теперь от концепций перейдем к технологии. Первая часть будет посвящена вопросам декомпозиции проектных задач на подзадачи для выявления узких мест нашего проекта.

10.02.2023    4701    0    andironenko    2    

31

На что похож ваш продукт: на Аквариум или на Муравейник? 

Инструменты управления проектом Бесплатно (free)

Давайте поиграем в метафоры в лучших традициях экстремального программирования. А заодно проведем новогодний конкурс - на лучшую метафору для автоматизированного продукта

27.12.2022    2749    0    MariaTemchina    28    

23

ТРИЗ. Решение нерешаемых проблем в бизнесе

Управление проектом Бесплатно (free)

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    4187    0    user1576201    10    

17

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Бизнес-анализ Управление проектом Команда Управление ИТ Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Цикл статей о том, почему акушер-сантехник широкого профиля - это ПЛОХО. Расскажу плюсы специализации на одной предметной области. Рассмотрим понятные аналогии из других областей. Проанализируем пару вакансий, естественно без указания компании.

09.09.2022    10672    0    biimmap    79    

75

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Архитектура Бесплатно (free)

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

05.08.2022    13093    0    Evil Beaver    17    

117
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. gradi 5 29.11.18 16:15 Сейчас в теме
Иван, в этих статьях вы повторяете материал своей книги об управлении проектами в ИТ?
2. MariaTemchina 1594 30.11.18 11:19 Сейчас в теме
(1) Эти статьи - транскрибация видеокурса по управлению проектами.
Оставьте свое сообщение