Предисловие
Сначала немного истории, чтобы было понятно, откуда появился первый принцип. Аналогии слишком упрощены, но они хорошо объясняют суть. Допустим, у вас регулярный менеджмент, возникает очередная работа. И вы подходите к ней, как обычно: вам нужен коллектив, нужно задачи между его членами раскидать и цели достичь. Порядок ваших действий будет следующим:
- понять цель (что нам нужно сделать);
- поделить все на задачи – одну, другую, затем третью и следующую. Пока одни выполняют одну задачу, другие – другую, и т.д.;
- определить ответственных;
- регулярно контролировать, чтобы все исполнялось, и никто не разбежался.
- Эта логика хорошо работает для операционной деятельности - когда у вас работа постоянная и однотипная. Но проект, по своему определению - это работа ограниченная по времени (конечная) и связанная с высокими рисками (неопределенная).
И если работе свойственна конечность и неопределенность одновременно, такой подход – спланировать все наперед – плохо работает. Почему: из-за конечности или неопределенности? Конечно же, из неопределенности. К примеру, вы потратили 2 недели, сделали прекрасный план для IT-проекта. Приступаете реализовывать - и тут, начинается… Ведущий разработчик у вас категорически не готов работать по предложенной технологии. Говорит, она не подходит, и план надо переделывать. А другой разработчик вообще уволился, а тут еще неожиданно появились проблемы с поставщиком, потом появляется ещё что-нибудь... Из-за неопределенности все время возникают непредвиденные трудности и сложности. Поэтому подход под названием «спланируем все детали наперед, а потом просто контролируем» плохо работает при высокой неопределенности.
Вообще, управление IT-проектом похоже на игру в шахматы, когда у вас ферзь ушел в декрет, а конь – заболел. А надо партию доигрывать, несмотря на это.
Как с этим справляются менеджеры проектов? В Айти сфере все большей популярностью пользуется такой подход, как скрам. Говоря очень упрощенно, последователи скрама решили отказаться от детальных планов наперед, и больше их никогда не составлять. К примеру, айти-специалисты делают интернет-магазин. В первую очередь команда проекта идет к клиенту, он рассказывает свои пожелания. Все его требования записываются, и кладутся, условно говоря, в виртуальное «ведро»: дизайн главной страницы, форма поиска, каталоги, личный кабинет, возможность отслеживать скидки, возможность онлайн оплаты – все, что попросит клиент. Потом скрам команда начинает работать. Сначала берутся за 2-3 приоритетные задачи (хотелки) и решают их в первые две недели (первый спринт). В конце спринта результат показывают клиенту и спрашивают, нравится ли ему. Допустим, клиенту нравится. Отлично. Команда берется за следующие задачи, которые могут выполнить за две недели, а потом снова показывают клиенту. Но тут заказчик не доволен, и объясняет, что ему на самом деле требуется немного другое. Разработчики уточняют запрос, и в следующем спринте переделывают еще раз. И на следующей демонстрации клиент уже оказывается доволен. Таким образом, команда постепенно опустошает «ведро» с задачами (в скраме оно называется бэклогом продукта). Промежуточные результаты все время показываются клиенту, и в итоге интернет-магазин становится таким, каким его себе представил заказчик.
Но и этот подход к управлению проектами не всегда годится. Где кроются главные проблемы: в конечности или в неопределенности? Очевидно, что в конечности. Потому что заказчик может восхищаться подходом, но он, скорее всего, еще в начале проекта задаст маленький вопрос – когда вы закончите, и сколько это будет стоить? Но на этот вопрос скрам ответить не может. Когда разработчики получат промежуточные результаты, они оценят свою скорость, и только потом смогут приблизительно оценить, когда проект закончится и в какие деньги обойдется (и точность этих прогнозов будет по ходу проекта постепенно возрастать). Но на старте полная стоимость и продолжительность проекта не известны.
Я однажды поинтересовался у моего коллеги, идеолога скрама в России, что он отвечает, когда клиент интересуется общей стоимостью проекта. Его ответ потенциальным клиентам меня удивил: “Тебе не нужно этого знать”. Аргументация следующая - у клиента возникает вопрос про общие деньги и сроки, потому что он не доверяет исполнителю. Переживает, что время пройдет, деньги потратят, а он ничего не получит или результат не будет соответствовать его ожиданиям. Но в скраме заказчик защищен от этой ситуации: ведь в каждом спринте вы будете все время увеличивать функциональность продукта. Вовлекаясь в процесс регулярно, заказчик будет видеть работающий продукт на промежуточных этапах, и уверится, что в конце концов, он получит ровно то, что ему и нужно. В этой ситуации заказчик расслабится и перестанет задавать дурацкие вопросы о деньгах и сроках.
На мой взгляд, это очень странный тезис, потому что в жизни такой подход не работает. Скрам и аналогичные ему методы очень хороши, но они работают там, где нет конечности (четких ограничений проекта, заданных изначально). А там, где они есть, подобный подход, к сожалению, не применим.
Первый принцип проектного управления. Принцип яйца.
Как ответ на эти два вызова - конечность и неопределенность, родилось проектное управление. Появился принцип яйца. Это, конечно, метафора. Но она отражает то, как менеджеры отреагировали на конечность и неопределенность.
Что символизирует куриное яйцо? Представьте, курица снесла яйцо и садится его высиживать. Яйцо сразу конечного размера, то есть скорлупа уже больше не увеличивается. И скорлупа – это аналог того, что называется «устав проекта». В каждом проекте обязательно есть такая вещь, как устав. В уставе фиксируются неизменные ограничения проекта - стоимость, сроки и кратко его суть (содержание). И сколько бы курица ни сидела, яйцо больше не растёт. Это жесткие рамки, в которые проект должен уложиться, и мы обязаны уложить его в эти рамки любой ценой.
Под скорлупой яйца находится внутреннее содержимое. Но пока это только общие планы. Когда курица садится на яйцо, там есть белок и желток - размытые субстанции, а птица еще не угадывается. Так и на старте проекта пишется устав, а подробных планов нет. Они создаются очень примерно. То есть вы должны представить себе общую картину, а уточнять будете позже, чтобы не тратить каждый раз время на переписывание и уточнение. И чем дальше продвигается проект вперёд, чем дольше курица высиживает яйцо, тем явственнее проступают лапки, клювик, глазки и вообще наша будущая птица. Так и с проектом. Сначала планы примерные, а чем дольше он длится, тем больше уточнений вы вносите, и в этом заключается принцип яйца.
То есть на старте есть устав и примерные планы (белок и желток). На протяжении проекта устав неизменен, а планы меняются, расширяются. Это очень важное правило – скорлупу трогать нельзя. Если вы расковыряли пальцем скорлупу яйца, то результат у вас уже не получится, высидеть яйцо будет невозможно. Точно так же и с проектом: если вы устав нарушили, этот проект надо перезапускать. Если яйцо сначала высиживала курица, а потом вы решили, что это должен делать крокодил, то придется брать уже другое яйцо.
Задача менеджера проекта – обеспечить, чтобы внутреннее содержимое не переросло ограничения, чтобы белок и желток не стали больше самого яйца. Если скорлупа лопнет, проект тоже не получится. И PMBoK – это пособие о том, как впихнуть то, что не вмещается, как яйцо удержать в скорлупе.
Попробуйте ответить, можно ли назвать успешным проект, если сроки были превышены в 50 раз, а бюджет – в 40 раз, но продукт получился хорошим? Речь идет, в частности, о продуктах Microsoft – Word и Excel – очень популярных, очень хороших продуктах. Являются ли они успешными проектами?
На самом деле это провальные проекты, но все довольны. И надо эти две вещи разделять и не путаться: это очень хорошие продукты, которыми все довольны, но провальные проекты. Почему это не просто придирки? Если бы это была не Microsoft, а совершенно другая компания, то:
- проект никогда бы не завершился,
- компания разорилась бы.
По сути, эти проекты не обладали конечностью. Руководству на самом деле было все равно, сколько денег уйдет на проекты и когда они выйдут. Главное – чтобы продукты вышли и покорили рынок.
И таких компаний немало, тот же Яндекс или Google. Они не очень переживают, сколько будет стоить их новый сервис или обновление. Их не очень интересуют сроки. Для них важно, чтобы получился очень хороший продукт.
Когда у вас такая ситуация – скрам работает прекрасно, ничего лучше не бывает. Если у вас бесконечное число денег и времени, и вам просто нужен хороший продукт, то ничего лучше, чем спокойненько делать и все время показывать клиенту промежуточные результаты, никто не придумал. Но если вы работаете в боевых рыночных условиях, если у вас бюджет ограничен, и хороший продукт – не единственное, что вас волнует, то для этого есть проектное управление.
Второй принцип. Принцип удава.
Любой проект имеет жизненный цикл. Он начинается с инициации (этап определения границ и формального запуска проекта) и заканчивается закрытием (этап формального завершения работ), а в середине у него клубок процессов. Абсолютно у каждого проекта, даже если вы его не закончили, провалили, есть начало, конец и середина: инициация, закрытие и клубок процессов. Если на этот цикл натянуть смешной контур, то получится удав. Такой сытый удав, который что-то переваривает. К этому принципу мы вернемся чуть позже, в следующих публикациях.
Третий принцип. Принцип командности и проактивности.
Как вы считаете, должен ли быть менеджер проекта экспертом в том, в чем у него проект, должен ли он разбираться в этом?
С одной стороны, должен, иначе его просто обманут. Но с другой, менеджеру проекта не просто быть экспертом, потому что непонятно, где именно должна находиться зона его экспертизы. Вот конкретный пример. Представьте себе проект по разработке томографа. Давайте попробуем разобраться, какими должны быть компетенции менеджера этого проекта. Томограф - сложный прибор со сложным софтом, над ним трудится инженер-электронщик, с одной стороны, программист – с другой. Проектирование с последующей сборкой - примерно столь же трудоемкая задача, как и написание для томографа программного обеспечения. При этом томограф делается для врачей, поэтому необходимо участие врача, для уточнения, что имеет диагностическую ценность, а что - нет. А еще томограф – прибор, который проходит строгую сертификацию, потому что при неправильном применении он может человека убить. И процедура его сертификации длительная и сложная, требует участия отдельных компетентных специалистов. И в какой из упомянутых сфер должен быть экспертом менеджер проекта? Понятно, что он не может быть одновременно и электронщиком, и программистом, и врачом, и специалистом по сертификации.
Это универсальная ситуация: проекты – всегда задачи с конечностью и неопределенностью, когда стыкуются разные сферы и нужны разные специалисты. Поэтому менеджеру проекта не обязательно быть экспертом, потому что непонятно, в какой это должно быть области.
Другая ситуация, когда мы смотрим на работу какого-либо отдела. Обычно начальники отделов – это бывшие эксперты. Сначала он был простым инженером, потом дорос до начальника отдела инженеров. Он самый умный инженер, поэтому его назначили всеми руководить. Начальники отделов, конечно, не всегда вырастают из рядовых сотрудников, но чаще всего ситуация именно такая. Но здесь вряд ли речь пойдет именно об управлении проектами. Если у вас вдруг проект внутри отдела, и в него вовлечены только сотрудники отдела, это наверняка не проект. Это просто задачи в рамках вашей операционной деятельности. Проект предполагает конечность и неопределенность. А откуда возьмется неопределенность, если ваши люди делают дело, которое и вы, и они хорошо знают? Проекты, как правило, предполагают кросс-функциональность. Это верно даже для тех IT-проектов, в которых команды маленькие. Все равно в них есть программисты, тестировщики, аналитики, дизайнеры, люди других профессий. Во всех этих сферах нельзя быть экспертом, поэтому менеджер не может быть экспертом во всем. Конечно, грамотность нужна, понимание предмета проекта, например, в нашем последнем примере знать что-то про томограф обязательно. Иначе команда вас не примет как руководителя. Но быть экспертом во всем невозможно.
И отсюда берется принцип командности. Очень простая логика: проектное управление не предполагает, что вы, как руководитель, можете взять и сделать проект самостоятельно. Понадобятся знания большого количества экспертов в разных доменах, которые вам нужно объединить. Вы – интегратор в первую очередь. Принцип командности говорит о том, что вся команда участвует в формировании планов. Планы пишутся всей командой – вами и вашими сотрудниками. Один вы не сможете учесть все нюансы, хотя соблазн самому построить план проекта всегда велик.
Проактивность – это антоним реактивности. Что такое реактивность? Когда что-то загорелось, побежали – потушили. А проактивность – это мы сидим и думаем, как бы так сделать, чтобы не загорелось никогда, а если загорится, чтобы мы быстро справились. Фактически, проактивность - это управление рисками. Превентивное.
А управление проектом – это, во-первых, умение увлекать команду формированием планов и управление этими планами. А во-вторых, проактивность – вы должны думать про риски, управлять ими, всячески их оценивать.
Предыдущая часть курса: Что можно назвать проектом, а что нельзя, и каковы критерии успеха менеджера. Курс по управлению проектами, часть 1
Следующая часть курса: Роли в проектном управлении. Курс по управлению проектами, часть 3
Если вас интересует тема "Управления проектами" и вы хотите самостоятельно подготовиться к экзамену на сертификат Project Management Professional, то приглашаем пройти новый видеокурс Ивана Селиховкина "Подготовка к экзамену РМР"
