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

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

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

Предисловие

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

  1. понять цель (что нам нужно сделать);
  2. поделить все на задачи – одну, другую, затем третью и следующую. Пока одни выполняют одну задачу, другие – другую, и т.д.;
  3. определить ответственных;
  4. регулярно контролировать, чтобы все исполнялось, и никто не разбежался.
  5. Эта логика хорошо работает для операционной деятельности - когда у вас работа постоянная и однотипная. Но проект, по своему определению - это работа ограниченная по времени (конечная) и связанная с высокими рисками (неопределенная).   

И если работе свойственна конечность и неопределенность одновременно, такой подход – спланировать все наперед – плохо работает. Почему: из-за конечности или неопределенности? Конечно же, из неопределенности. К примеру, вы потратили 2 недели, сделали прекрасный план для IT-проекта. Приступаете реализовывать - и тут, начинается… Ведущий разработчик у вас категорически не готов работать по предложенной технологии. Говорит, она не подходит, и план надо переделывать. А другой разработчик вообще уволился, а тут еще неожиданно появились проблемы с поставщиком, потом появляется ещё что-нибудь... Из-за неопределенности все время возникают непредвиденные трудности и сложности. Поэтому подход под названием «спланируем все детали наперед, а потом просто контролируем» плохо работает при высокой неопределенности.


 
Вообще, управление IT-проектом похоже на игру в шахматы, когда у вас ферзь ушел в декрет, а конь – заболел. А надо партию доигрывать, несмотря на это.
 

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

 
Первый принцип проектного управления. Принцип яйца.

Как ответ на эти два вызова - конечность и неопределенность, родилось проектное управление. Появился принцип яйца. Это, конечно, метафора. Но она отражает то, как менеджеры отреагировали на конечность и неопределенность.
 
Что символизирует куриное яйцо? Представьте, курица снесла яйцо и садится его высиживать. Яйцо сразу конечного размера, то есть скорлупа уже больше не увеличивается. И скорлупа – это аналог того, что называется «устав проекта». В каждом проекте обязательно есть такая вещь, как устав. В уставе фиксируются неизменные ограничения проекта - стоимость, сроки и кратко его суть (содержание). И сколько бы курица ни сидела, яйцо больше не растёт. Это жесткие рамки, в которые проект должен уложиться, и мы обязаны уложить его в эти рамки любой ценой.  


Под скорлупой яйца находится внутреннее содержимое. Но пока это только общие планы. Когда курица садится на яйцо, там есть белок и желток - размытые субстанции, а птица еще не угадывается. Так и на старте проекта пишется устав, а подробных планов нет. Они создаются очень примерно. То есть вы должны представить себе общую картину, а уточнять будете позже, чтобы не тратить каждый раз время на переписывание и уточнение. И чем дальше продвигается проект вперёд, чем дольше курица высиживает яйцо, тем явственнее проступают лапки, клювик, глазки и вообще наша будущая птица. Так и с проектом. Сначала планы примерные, а чем дольше он длится, тем больше уточнений вы вносите, и в этом заключается принцип яйца.
 
То есть на старте есть устав и примерные планы (белок и желток). На протяжении проекта устав неизменен, а планы меняются, расширяются. Это очень важное правило – скорлупу трогать нельзя. Если вы расковыряли пальцем скорлупу яйца, то результат у вас уже не получится, высидеть яйцо будет невозможно. Точно так же и с проектом: если вы устав нарушили, этот проект надо перезапускать. Если яйцо сначала высиживала курица, а потом вы решили, что это должен делать крокодил, то придется брать уже другое яйцо.
 
Задача менеджера проекта – обеспечить, чтобы внутреннее содержимое не переросло ограничения, чтобы белок и желток не стали больше самого яйца. Если скорлупа лопнет, проект тоже не получится. И PMBoK – это пособие о том, как впихнуть то, что не вмещается, как яйцо удержать в скорлупе.
 
Попробуйте ответить, можно ли назвать успешным проект, если сроки были превышены в 50 раз, а бюджет – в 40 раз, но продукт получился хорошим? Речь идет, в частности, о продуктах Microsoft – Word и Excel – очень популярных, очень хороших продуктах. Являются ли они успешными проектами?
 
На самом деле это провальные проекты, но все довольны. И надо эти две вещи разделять и не путаться: это очень хорошие продукты, которыми все довольны, но провальные проекты. Почему это не просто придирки? Если бы это была не Microsoft, а совершенно другая компания, то:

  • проект никогда бы не завершился,
  • компания разорилась бы.

 
По сути, эти проекты не обладали конечностью. Руководству на самом деле было все равно, сколько денег уйдет на проекты и когда они выйдут. Главное – чтобы продукты вышли и покорили рынок.
 
И таких компаний немало, тот же Яндекс или Google. Они не очень переживают, сколько будет стоить их новый сервис или обновление. Их не очень интересуют сроки. Для них важно, чтобы получился очень хороший продукт.
 
Когда у вас такая ситуация – скрам работает прекрасно, ничего лучше не бывает. Если у вас бесконечное число денег и времени, и вам просто нужен хороший продукт, то ничего лучше, чем спокойненько делать и все время показывать клиенту промежуточные результаты, никто не придумал. Но если вы работаете в боевых рыночных условиях, если у вас бюджет ограничен, и хороший продукт – не единственное, что вас волнует, то для этого есть проектное управление. 


Второй принцип. Принцип удава.

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

 

 

Третий принцип. Принцип командности и проактивности. 

 

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

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

Статья написана на основании видео учебного курса по управлению проектами. 
 

26

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. Alien_job 161 20.08.18 11:03 Сейчас в теме
У вас у удава стрелочки не в ту сторну
zqzq; o.nikolaev; Sla; +3 Ответить
2. dock 34 22.08.18 15:26 Сейчас в теме
(1) Почему не в ту ? Адаптация по текущие реалии: всё делается через Ж.!
MariaTemchina; zqzq; o.nikolaev; Kochergov; smit1c; +5 Ответить
5. MariaTemchina 405 27.08.18 11:18 Сейчас в теме
(1) Почему не в ту? Любая схема - она условная. Можно считать, что удав лежит в направлении мечты движется в сторону успешного завершения проекта.
9. Alien_job 161 27.08.18 12:01 Сейчас в теме
(5) А можно не считать. Если ваша теория объясняет любой исход, то она на самом деле не объясняет ничего. Вся статья - бессодержательная вода, поэтому и комментарии не конструктивные.
15. Marina29 03.09.18 10:21 Сейчас в теме
(1) Если стрелочки нарисовать в противоположную сторону, получится еще хуже - сразу понятно, куда идет проект и его результаты...
3. o.nikolaev 232 22.08.18 20:34 Сейчас в теме
Принцип "яйца", как-то тухловат. Стоимость и сроки неизменны, ок. Но "суть" неизменна? По ходу дела заказчик может "усугубить" свое понимание и изменить "суть" или, как минимум, очень сильно скорректировать ее. Несколько раз. Новый проект? Каждый раз? Каждый раз переписываем устав (ведь "суть"-то поменялась)? Вангую: после 3-го переписывания и пересогласования "устава" генеральное руководство поинтересуется что за "х..ней" вы там маетесь?
6. MariaTemchina 405 27.08.18 11:27 Сейчас в теме
(3) Я здесь соглашусь с автором (хотя с некоторой оговоркой, ибо сама являюсь сторонником более гибких методологий). Классическое проектное управление (о котором пишет Иван) предполагает, что основная цель проекта в процессе не меняется. Если меняется - проект перезапускается. Перезапуск проекта - это не страшно, и не предполагает обесценивания уже сделанного. Это просто рефлексия того факта, что мы облажались, и поменяли наш подход. Почему это важно? Чтобы подмена целей и расползание содержания не происходила незаметно ("давайте искупаем лошадь в шампанском... ну хотя бы кошку пивом обольем" (С) Поручик Ржевский). Знаменитый Chaos Report от the Standish Group International показывает, что на 100 стартов проектов приходится 94 перезапуска (когда как раз приходится заменять, скажем, куриное яйцо на страусиное). Это не значит, что 94% проектов перезапускается, на один проект может приходиться несколько перезапусков.
Резюме - классическое проектное управление предполагает неизменность яйца. А вот Agile - нет, об этом читайте в моих публикациях ))).
4. o.nikolaev 232 22.08.18 20:38 Сейчас в теме
Насчет аналогии шахматной... Все конечно зависит от конкретной позиции, но, если при прочих равных, у вас "конь ушел в декрет" а "ферзь заболел", то увы, по правилам шахмат вы не выиграете. Ну или если только заявить что на самом деле это вот мы сейчас в шах-бокс играли и попытаться врезать противнику.
7. MariaTemchina 405 27.08.18 11:28 Сейчас в теме
(4) С шахматами, говорите, аналогия неудачная? Тогда вот вам еще одна близкая аналогия: "управление проектами - это не сложно. Это как езда на велосипеде. Только велосипед горит. И вы горите. И все горит"...
8. o.nikolaev 232 27.08.18 11:58 Сейчас в теме
(7) Ну, хорошо. Автор правда привел пример для шахмат. Ну, давайте тогда с велосипедом разберемся. Начнем с вопроса, куда вы едете? Ну, видимо куда-то. И к какому-то времени надо успеть (пока не сгорит велосипед? вы? надо ли чтобы велосипед дошел до точки назначения? надо ли чтобы вы дошли в живых до точки назначения? или какое-то иное ограничение? Вообще, замечу, что маловато исходных данных, вот в шахматах пример очень емкий - там почти сразу все условия описаны). Хорошо. Сажаем вас на велосипед, пусть это в лесу будет. Поджигаем вас, поджигаем велосипед, поджигаем лес вокруг. Вы едете. Осмелюсь предположить, что "управления проектом" не будет. И что вы будете просто визжать. Это вот вы такой какой-то странный пример имели в виду? Или что? Ну или я может вообще чего-то не знаю, и где-то есть видео где вы+горящий велосипед. Извините за возможно неуважительный тон, но право же, пример с "велосипедом", не очень, на мой взгляд.
10. MariaTemchina 405 27.08.18 12:04 Сейчас в теме
(8) Про велосипед - это, конечно же, шутка ))).
Но, замечу, после аналогии с велосипедом вы уже не столь бурно протестуете против шахматной аналогии ))).
11. o.nikolaev 232 27.08.18 12:29 Сейчас в теме
(10) Мария, скорее всего у вас другой взгляд на мир. Вы видите его иначе чем я. В сообщении выше я лишь указал что шахматная аналогия "с дыркой", и, вроде бы, обычным образом, а не "бурно". Также указал на дыры в аналогии с "велосипедом".
12. profiprog1c 178 27.08.18 13:19 Сейчас в теме
Из прочитанного я не понял, зачем нужен проект менеджер, при создании того же томографа? То есть выглядит это приблизительно так. Есть организация, которая хочет создать томограф. Эта организация должна обладать фин. ресурсами, так как томограф сложный аппарат и требует вовлечения разных людей для своего создания. В такой организации есть руководство, которое и будет руководить проектом. Где в создании томографа появляется проект менеджер, который к тому же полный профан??? Статья из серии: все и ничего толком!
13. MariaTemchina 405 27.08.18 18:23 Сейчас в теме
(12)
В такой организации есть руководство, которое и будет руководить проектом.
- это и есть руководитель проекта - представитель руководства, который будет руководить проектом. О чем мы дискутируем? ))
14. profiprog1c 178 27.08.18 18:59 Сейчас в теме
(13) Дискутируете вы, а я спрашиваю, где в статье появляется проект менеджер в примере с созданием томографа?
Оставьте свое сообщение