Блог

БЛОГ

Я – менеджер проекта! Проекты и окружение (Управление проектами)

Сегодня мы завершаем публикацию первой главы руководства «Я — менеджер проекта» Сергея Вратенкова! (Управление проектами по стандарту PMBOK)

Вы узнаете:

— Что такое «продукт проекта»

— И причем тут «заинтересованные стороны»

— Узнаете, какая модель проекта — рабочая

— Определите, что это вообще такое — управление проектом

— И какие процессы включены в это понятие

Для наглядности в руководстве использованы ясные поясняющие картинки.

Если вы пропустили начало, то вот ссылка на первую главу и введение.

1.7 ПРОДУКТ ПРОЕКТА

Все, наверное, согласятся, что продукты, услуги, системы проходят единый жизненный путь – они создаются, функционируют и выбывают из бизнес-оборота. В стандарте управления конфигурацией (EIA649) приводится такой типовой жизненный цикл продукта:

РИСУНОК 1.1: Жизненный цикл продукта (Стандарт EIA649)

Продукт на своем жизненном пути проходит шесть стадий, из которых только одна, предпоследняя, которую называют «Оперирование», является основной, той стадией, ради которой продукт создается. Это собственно есть стадия бизнес-жизни, для товаров и услуг это – удовлетворение потребностей владельца, для систем – функционирование, впрочем, с той же целью. Чтобы добраться до основной стадии, продукт должен пройти целых четыре стадии своей разработки и создания: «Концепция», «Определение», «Производство» и «Запуск». Эти четыре стадии обычно являются чисто проектными.

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

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

Не надо также думать, что мир несправедлив к проектам. Мир таков, каков есть. Лучше предусмотреть подобные ситуации и включить в проектную документацию спецификации на использование продукта проекта, достаточные для обеспечения нормального функционирования. И, конечно же, согласовать и утвердить у Заказчика, как у будущего владельца продукта.

1.8 ЗАИНТЕРЕСОВАННЫЕ СТОРОНЫ

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

Давайте разбираться в проблеме. Если результат – это главное в проекте, то стремление сделать результат как можно лучше выглядит достаточно естественным. Но ведь лучше – это дороже и дольше! А вот «дороже и дольше» — это уже не так естественно и очевидно! Согласны?

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

Пока мы можем дать такое уточнение определения проекта:

— Проект – это производство результатов для удовлетворения чьих-то потребностей.

Сделать лучше для заказчика результата можно только за счет исполнителя. И хотя отношения заказчик-исполнитель очень сложны, они, тем не менее, в основных аспектах достаточно понятны. Мы пока не упоминаем многообразные и многочисленные другие стороны, чьи интересы могут быть затронуты проектом и которые могут потребовать соблюдения своих интересов. И не только потребовать, но и добиться! Причем так, что мало не покажется! За примерами далеко ходить не надо – включайте телевизор, лезьте в интернет, историй про блокирование больших проектов небольшой группой жителей предостаточно.

Спрашивается, как быть со всеми этими проблемами? Мы детально обсудим эти вопросы позже, а сейчас можно сказать одно – надо отказаться от представления, что проект – это производство продукта. От очень опасного представления, от опасного для самого проекта, и, в первую очередь, для менеджера и исполнителей проекта. Гораздо правильнее и безопаснее считать, что проект – это производство продуктов для каждой заинтересованной стороны. Или, если кому-то больше нравится, то же самое, но с другой стороны: проект – это производство сложного, составного продукта, по кусочку для каждого интересанта.

Проект – это начинание, которое:

— производит согласованные результаты с целью удовлетворения потребностей заинтересованных сторон

— ограничено во времени, ресурсах и стоимости

— имеет существенную уникальность

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

Резюме: главным звеном в проекте являются интересы и потребности заинтересованных сторон, среди которых интересы заказчика если не важнее, то первичнее, а значит, все же важнее.

1.9 РАБОЧАЯ МОДЕЛЬ ПРОЕКТА

Предшествующее обсуждение приводит вот к такой модели проекта:

РИСУНОК 1.2: Модель проекта

Согласно этой модели, проект есть набор подобных ветвей для каждого участника. Каждая ветвь начинается с требований участников и завершается результатами, которые должны удовлетворить эти требования. Результаты производятся работами, которые для производства результатов потребляют ресурсы.

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

Результаты, работы и ресурсы определяют показатели – сроки, стоимость, качество, которые являются основными характеристиками состояния проекта. Благодаря декомпозиции модели по участникам мы можем рассчитать финансово-экономические показатели проекта по каждому участнику – затраты, доход, возврат инвестиций и т.д. Согласитесь, это неплохо!

Другая хорошая весть заключается в том, нашу модель можно декомпозировать дальше. Каждая ветка модели четко делится на два фрагмента, существенно разных по своим задачам, а значит, и по характеру управления. Вот эти фрагменты:

РИСУНОК 1.3: Две области управления в модели проекта

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

Второй, правый фрагмент каждой ветви, включает в себя четыре правых звена: результаты–работы-ресурсы-показатели. Его основное назначение – выявить в процессе планирования работы и ресурсы, необходимые для производства требуемых результатов и убедиться в процессе реализации, что результаты соответствуют спецификациям.

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

Таким образом, рабочая модель проекта разбивается на две разные под-модели – аналитическую и технологическую, объединяемые результатами проекта. И эти под-модели управляются своими специфическими способами и зачастую даже разными специалистами.

И еще одно замечание. Конечно, любая модель есть упрощенный взгляд на реальность. Модель выявляет только существенные аспекты явления и отбрасывает многочисленные менее существенные. Нужно это для того, чтобы сосредоточиться на главном и не утонуть в частностях.

Наша модель – не исключение. Наверное, главным упрощением является то, что в реальных проектах каждый элемент модели является иерархией. Например, считать Заказчика цельной единой заинтересованной стороной со вполне определенными требованиями – это, зачастую, прямой путь к провалу проекта. Если в организации Заказчика явно присутствуют группы и лица с разными требованиями к проекту, то все эти требования должны быть отражены. А это означает, что вместо одного интересанта появляется иерархия интересантов. Более того, это означает тиражирование этой иерархии вправо по ветке модели – появление соответствующих иерархий в требованиях, результатах, работах, ресурсах и показателях. Страшно? На самом деле – не очень. На помощь всегда придёт лучший друг менеджера – компьютер! Гораздо страшнее – не учесть существенное требование. Тут уж на помощь никто не придет…

1.10 ЧТО ТАКОЕ УПРАВЛЕНИЕ ПРОЕКТОМ?

Теперь, когда мы согласовали наше представление о проекте, давайте договоримся, что мы будем понимать под словами «управление проектом». Именно «правильное» управление является нашей основной задачей и любые недосказанности и непонятки ведут в тот же тупик проблем, что и непонятки с продуктом проекта или самим проектом.

Попробуем порассуждать от простого к сложному. Пусть у нас есть очень простой объект управления, скажем – тележка на колесах, которую можно передвигать туда-сюда.

Управление в таком простом случае выглядит так:

— Определяем цель управления, то есть желаемое положение тележки

— Определяем воздействия, которые приведут тележку куда нужно

— Производим воздействия

— Оцениваем фактическое положение тележки и, если надо, повторяем все сначала

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

Если внимательно присмотреться к «тележкам» проекта, то есть к тем многочисленным объектам управления, или, как мы их называли ранее, «звеньям» проектной цепи, то в исполнении проекта основная роль и основной фокус внимания принадлежит работам, которые собственно и производят требуемые результаты. Конечно, кроме работ в проекте всегда есть иные объекты управления, например, персонал, риски, контракты, … Управление ими не менее важно, чем управление работами, но есть одна принципиальная вещь: управление работами – это базовая, первичная и обязательная часть управления проектом, это суть управления проектом. Все остальные объекты управления могут присутствовать или отсутствовать в конкретном проекте, могут быть более или менее существенными для успеха проекта. Но работы присутствуют в проекте всегда и они всегда существенны для успеха проекта. Поэтому управление работами – это основа профессионализма менеджера проекта и обязательная часть его знаний и умений.

Множество «тележек» — это не подарок, но есть более принципиальная сложность – в проекте не один, а множество «толкателей», усилия которых надо координировать, и усугубляется все множеством «не пущателей», усилия которых надо нейтрализовывать. Подарком можно считать то, что несмотря на эти сложности, управление проектом происходит полностью согласно классическому циклу, но с особенностями, характерными для любого сложного производства, в котором задействовано множество участников. А именно, в управлении проектами доминируют два элемента цикла: планирование — для координации действий участников и контроль – для отслеживания и корректировки любых отклонений или сбоев, основными источниками которых являются опять же участники.

С учетом этого мы можем говорить об управлении проектом достаточно конкретно. Мы видим, что:

Основа управления проектом – это управление работами проекта путем планирования и контроля.

1.11 ПРОЦЕССЫ УПРАВЛЕНИЯ ПРОЕКТОМ

Согласно нашей рабочей модели проекта есть два основных процесса управления проектом: планирование и реализация.

Процесс планирования проекта преобразует требования в результаты, работы и ресурсы, но не физически, а информационно. Его основная задача – преодолеть неопределенности и риски проекта путем анализа и прогнозирования будущего исполнения.

Процесс реализации является обратным к процессу планирования. Он реализует две важнейшие функции: во-первых, преобразует ресурсы в результаты и удовлетворение требований, на этот раз – физически, а во-вторых, контролирует соответствие исполнения плану. Этот процесс обычно разбивают на два под-процесса: исполнение и контроль.

Процесс исполнения — это, безусловно, главный процесс проекта, собственно, тот процесс, ради которого проекты затеваются. Он заключается в производстве результатов проекта, то есть является чисто технологическим исполнением работ. Но без планирования процесс исполнения для «истинных» проектов гарантированно будет сверх-затратным и сверх не эффективным. «Истинные» проекты – это те проекты, у которых, как мы говорили выше, все «жестко» в смысле уникальности, сроков и ресурсов.

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

Процесс исполнения является чисто технологическим и специфичным для каждого вида работ. Работы исполняются профессионалами-исполнителями, которые несут первичную ответственность за работы и их результаты. В силу этого мы исключим процесс исполнения из области ответственности управления проектов. И сосредоточимся далее на двух управленческих процессах – планирования и контроля работ проекта.

ЧТО ДАЛЬШЕ?

На этом минимально необходимое введение в проекты завершено. Основная часть книги является пошаговым руководством по составлению плана работ проекта. Вторая часть книги, посвященная контролю работ, короче первой, но, конечно же, не менее важна. Оставшиеся части книги посвящены особенностям управления другими важными аспектами проектов, такими, как: команды, риски, контракты, качество и другие. В книге вы найдете не только рекомендуемые способы и методы управления, то есть ответы на вопросы «как это делать?», но и ответы на вопросы «почему нужно делать так?».

[ratings id=»»]

Телеграм канал