Управление проектами – ТОП 10 терминов

Топ 10 терминов по управлению проектами

Давайте разберем 10 топ терминов, которые используются в Управлении проектами. Причем, эти термины встречаются достаточно часто. Самое интересное, что у них очень разная интерпретация, я постараюсь дать наиболее частую и правильную интерпретацию с моей точки зрения. Если у вас будут вопросы – пишите в комментариях – разберемся. Будем с вами разбираться, активнее участвуйте в обсуждениях. Я думаю, основной смысл в том, что мы с вами можем найти совместное решение. Чем больше вопросов вы задаете – тем лучше оно получается.

1. Первый термин у нас WBS (ИСР, СДР) – work breakdown structure. Потому что на русском языке существует множество различных переводов: иерархическая структура работ, структурная декомпозиция работ, структура декомпозиции работ. Но смысл достаточно простой, тут реализация не такая простая. По хорошему счету, вам нужно ваш проект поделить на маленькие кусочки, и на конечном уровне ответить на вопрос: что же делать-то. Что должен делать конкретный конечный исполнитель. И здесь есть разные подходы к вот этому дроблению иерархическому, как вы это будете делать. То есть, вы можете это сделать с точки зрения, например, деления на основные этапы проекта, потом работы, пакеты работ – вот это все меньше, меньше, меньше, меньше. А можете сделать так называемый scope-ориентированный. Вот это новое слово scope – содержание. Чуть попозже мы поговорим. Вы исходите из того, что вы хотите создать. И потом декомпозируете. Но это отдельная тема, и есть отдельный курс по управлению, как и по планированию. Если интересно – в описании есть, можете посмотреть.
2. Базовый план проекта. Часто встречаю, когда в том же самом MS project, да и в принципе, когда есть утвержденный план проекта, он постоянно меняется, постоянно что-то движется, но не с чем сравнивать. То есть, получается так, что у нас все время актуальный план. И мы не можем с вами никак разобраться, а вот эти изменения, какие они были. Потом-то интересно посмотреть. То есть, проект завершился, подвести какие-то итоги, понять для себя, где были какие-то сделаны ошибки. Поэтому, очень важно: тот план, который был утвержден в самом начале, вы его фиксируете. Вот, он у вас есть, вы его зафиксировали, а потом все остальные изменения идут относительно этого плана. Все отклонения – относительно этого плана. У вас могут быть отклонения по содержанию, отклонения по началу, завершению, по длительности, по стоимости. Вот это все попадает в изначальный базовый план, и все отклонения смотрятся относительно него.
3. Продукт проекта. Наиболее значимый результат, который потом поставляется заказчику. Причем, он не отвечает на вопрос: зачем проект запускается? Он отвечает на вопрос: что должно быть создано? Ну, самый у нас очевидный пример – мы с вами строим какой-то объект, у нас есть договор на подряд, на строительство, и нашим продуктом проекта будет сданный объект. Или же вы, например, внедряете какую-то IT-систему. Вашим продуктом проекта может оказаться «железо», софт установленный, обученные люди, написанные программы – там по-разному может быть. Но это тот результат материальный, то, что появилось в материальном мире, что вы передаете заказчику, и что потом он будет использовать. От чего у него будут потом определенные эффекты наступать. Поэтому, продукт отвечает на вопрос: что создаем. И вот, возвращаясь, кстати, к самому первому термину WBS, бывает здорово планировать от продукта проекта. Потому что, помимо WBS, есть еще РBS – product breakdown structure, когда вы берете ваш продукт, разбиваете на много маленьких составляющих, как легко такой получается. И к каждому элементу привязываете те работы, которые должны быть выполнены. И здесь здорово, кстати, с вот этого РBS идет переход – мы с вами будем говорить по поводу… к контрольным событиям – к вехам. Потому что, по сути, каждый элемент вашего продукта – это контрольное событие. Но это отдельный курс по планированию, его нужно смотреть, разбираться. Но сейчас, я думаю, картинка у вас так немножко собралась. Мы даже знаем с вами: под продуктом проекта – результат.
4. Требования. «ТЗ не равняется ХЗ». Требования к чему? Требование к продукту. Вопрос: откуда эти требования берутся? Эти требования берутся изначально из потребностей. Потребностей чьих? Из потребностей стейкхолдеров, о них чуть попозже поговорим, то есть, заинтересованных участников проектов. Ваш заказчик зачем-то запускает проект. Правильно? То есть, он хочет удовлетворить какую-то свою потребность. Что-то у него не получается, что-то у него не ускоряется. И под это дело мы предлагаем некое решение, которое мы привнесем в его жизнь. Это решение – продукт проекта начнет работать, и появятся некие эффекты, которые будут удовлетворять его потребности. Так вот, получается так, что вам вначале надо выявить, хотя бы его потребности, что в его жизни должно измениться. Редко случается, но постоянно, когда заказчик в одном лице – там много участников разных, вы из всех них собираете потребности. Потом эти потребности увязываете между собой, они противоречивы, и из этих потребностей появляются уже требования к создаваемому продукту. То есть, заказчик хочет, чтобы система делала что-то, чтобы было удовлетворено какое-то требование. Дальше мы с вами смотрим.
5. Жизненный цикл проекта. И вот здесь знаете, по поводу жизненного цикла, надо для себя понимать: жизненный цикл проекта и жизненный цикл управления проектом. Вот больше мы с вами говорим про жизненный цикл управления проектом. Вы помните, 5 групп процессов у нас с вами.

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

   Дальше мы с вами планируем

   После этого организуем исполнение

   Вот здесь у нас идет мониторинг и контроль, она крутится.

   И завершение.

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

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

6. Стейкхолдеры проекта. Вообще, вот так, положа руку на сердце, все крутится вокруг них. Стейкхолдеры – то есть, кто-то чем-то не удовлетворен, заказчик чем-то не удовлетворен – внешний заказчик, внутренний заказчик. И он инициирует этот проект. Или кто-то сказал, что было бы здорово, то есть, появляется инициатор: «Ребята, нам нужно решить эту проблему, использовать вот эту возможность». Стейкхолдеры – заинтересованные участники проекта, на которых проект может повлиять, и которые могут на сам проект повлиять. Они могут позитивно, негативно относиться, они активны, у них активный интерес. И очень важно, вот выявлять стейкхолдеров, выявлять их потребности. Из потребностей появляются требования, из требований у вас появляется описание продукта, который вы хотите создать. И после этого, вы можете, когда у вас есть продукт, сделать структурную декомпозицию вначале продукта, потом работ, потом у вас появляется возможность сделать (бэк…). Оно все со всем взаимосвязано, одно идет от другого. Но начинает все со стейкхолдеров, которые дают первый «пинок», чтобы оно сдвинулось дальше, у которых есть некоторый интерес. Нет интереса – нет проекта, вот, в чем дело.
7. Риски проекта. По поводу рисков – много, чего говорят, но в целом, там процедура достаточно простая. Вам риски нужно выявить, есть набор мероприятий и курс (я внизу его пропишу). Дальше, их нужно оценить. Потому что из множества странных рисков у вас далеко не все риски – те, которыми не стоит заниматься. Есть технология, как их оценивать. Дальше. Вам нужно продумать мероприятия по предотвращению (их там целый набор), и по реагированию – что будете делать, если оно произойдет. И продолжать мониторить. Поэтому, с рисками – это постоянный текущий процесс, и по хорошему счету – он встраиваться вообще в деятельность компании. Это должно постоянно происходить. Управление рисками в проекте – это частный случай управления рисками в организации. В целом, вообще, по хорошему счету – любое принимаемое решение в организации, оно должно делаться с учетом управления рисками. Поэтому, сейчас даже получается так, что управление рисками, оно не выделяется как отдельная дисциплина, оно встроено вообще во все это дело.
8. Треугольник ограничений. Любят эту штуку на курсах управления проектами, и долго там про нее, там «пляски с бубнами» водят. Идея простая: у вас есть три базовых ограничения.

• Вам нужно в определенный срок что-то создать – временное ограничение
• Вам дали какое-то ограниченное количество ресурсов или денег, можно так сказать
• У вас описано, что вы должны создать.

Три вещи: время, деньги и scope – содержание, что мы с вами создаем. И вы интуитивно понимаете, что все они между собой взаимосвязаны, и они постоянно ползут, они постоянно расползаются в разные стороны. И задача руководителя проекта – как раз удерживать их вот в тех изначальных параметрах, которые были заложены. А как он это может удерживать? Выстраивая коммуникации, общаясь с заказчиком, общаясь с участниками команды – постоянно удерживает. Потому что бывает, что изменения, которые происходят, они необратимые. И вы вынуждены пересматривать новые условия, фиксировать. То есть, этот треугольник, он в какой-то степени уже больше похож на колесо. Потому что он постоянно движется, постоянно шевелится. И за счет организации коммуникации, за счет организации взаимодействия, его можно удерживать в актуальном состоянии для всех участников, а не только для одного руководителя проекта, который вначале запомнил это, и живет с этой печалью, которая у него была.

9. Команда проекта. Это ваш основной актив. Без команды проекта проект не будет реализован. Вообще, команда может без вас реализовать. Но вот вы без команды точно не сможете. Команда, по хорошему счету, она берет на аутсорс ваши способности к организации всего вот этого. Это всё инструменты по организации, то есть, по-хорошему счету, им нужно, чтобы их организовали. Худо-бедно – они это могут сами сделать. Худо-бедно – сделают, с большими издержками. Без них вы не сделаете, потому что каждый участник команды – это человек с определенной компетенцией, то есть, человек, который несет определенную дисциплину, определенные знания. У вас этих знаний нет, и вот ваша команда проекта – это группа экспертов, совместно с которыми вы реализуете проект, создаете продукт, который удовлетворяет потребности стейкхолдеров. Оно вот так выстроено. И вот здесь выстраивается тема, связанная с тем, что вам нужно уметь взаимодействовать с людьми. Вот то, что перед этим было – это все про администрирование. И администрировать-то быстро можно научиться: делай раз, делай два, делай три. Вопрос: как сделать так, чтобы люди захотели сделать раз-два-три. Вот в этом искусство управления проектами часто и состоит. Потому что по бумажке-то мы все знаем, по pmbok мы все знаем. Ребята, как сделать так, чтобы люди захотели это сделать, чтобы они дошли до конца, и чтобы они «не выгорели». Вот в этом искусство, это большая область знаний, как работать с командой.
10. Вехи проекта. С вехами у нас здесь следующая ситуация. Вехи – это, по сути, контрольные события проекта. И вехи формулируются в прошедшем времени совершённой формы глагола: «приказ о запуске проекта подписан», «акт о вводе в эксплуатацию…». Видите, я документы подкладываю. Это удобно, потому что документ дает однозначность понимания. Поэтому вехи, они важны как для заказчика – есть уровень вех заказчика, есть уровень руководителя проекта – интересы заказчика и его в том числе. Очень интересно, вехи появляются из-за структуры продукта, когда вы разбираете. Ну, по сути, каждый элемент, как я говорил, каждый элемент продукта – это контрольное событие. Только есть определенный подход, как его перевести, это контрольное событие. И главное вам – отслеживать, что продукт создается. И плюс еще – есть административные вехи: всякие закупочные процедуры, всякие процедуры, связанные с оформлением договоров, согласование, и так далее, и так далее. Поэтому вехи, как минимально мы с вами можем определить, – это важный элемент продукта, который должен быть доставлен, создан к определенному моменту времени по качеству, и плюс еще контрольные события, которые связаны с администрированием.

Собственно, это небольшой обзор терминов топ 10 управления проектами. Если у вас есть вопросы по каким-то терминам – пишите в комментариях.