PERT, AGILE, PMBOK, PRINCE2 -- и это еще не все! Так какие инструменты начинать внедрять, если ничего о них не знаешь?
Если вы приняли решение наконец-то заняться в своем бизнесе проектным управлением - половина дела позади. Признание проблемы, как говорится, первый шаг на пути борьбы с ней. Но любого здравомыслящего руководителя сразу посещает сомнение, а какой из обилия существующих методов выбрать -- AGILE, PRINCE2 или PMBOK?
Поможет нам разобраться в этой ситуации наш вымышленный друг и товарищ -- Алексей Георгиевич.
Алексей Георгиевич -- профессиональный внедряльщик проектного управления. Когда большой босс поставил задачу разобраться с просрочкой заказов, несоответствием качества продукции корпоративным стандартам и вечным выходом за рамки бюджета, наш друг незамедлительно внедрил AGILE.
Через три недели, когда процесс дальше цветных стикеров на доске так и не пошел, Алексей Георгиевич записал всех руководителей на сертификацию PRINCE2, а сам начал описывать рабочие процессы. Через три месяца упорных трудов, перебрав пару-тройку корпоративных таск-менеджеров, поняв, что треть подразделений, имеющих налаженные процессы не имеют никакого отношения к фактическому производству продукта, наш герой пошел ва-банк, объявив на совете директоров о начале внедрения метода критического пути PERT.
Коллеги восприняли инициативу без должного энтузиазма, большой босс глубоко и разочарованно вздохнул, а Алексей Георгиевич лишился работы.
В последствии наш герой напишет в своем блоге:
Подходы в проектном управлении -- это не панацея, не секретные технологии, которые придумал кто-то более умный, чем мы с вами. Это системы, которые построили такие же менеджеры как мы, чтобы выстроить работу в тех условиях, в которых они находились.
Когда мы берем на работу топ-менеджера, мы стараемся, чтобы его опыт был максимально похож на те задачи, которые предстоит решать у нас, не говоря уже о наличии историй успеха.
Сложно не согласиться! Главная ошибка нашего героя заключалась в том, что вместо оценки сути подходов, Алексей Георгиевич хватался за яркие инструменты, которые создавали у него иллюзию систематизации и управления. При этом какой-то эффект компания, безусловно, получала, что могло давать ощущение следования правильной дорогой.
С таким же успехом можно было внедрять не AGILE, а устав Римского Легиона. Даже он позволит упорядочить дела в бизнесе (чем больше бардак, тем больше станет порядка), только если вы не решаете те же самые задачи, что и войны Римской Империи -- будет весело, но бессмысленно.
Чтобы не повторить ошибок нашего героя, давайте разберемся для каких условий, проектов и задач были разработаны следующие методы проектного управления:
- PERT (метод критического пути)
- AGILE (гибкая методология разработки)
- PMBOK
- Методы инновационных проектов
- PRINCE2 (процессно-ориентированное управление)
Если не вдаваться глубоко в детали каждого метода, то при поверхностной оценке может показаться, что все они про одно и тоже. Причина этого проста. Какое бы определение "проекта" мы не взяли, оно всегда будет крутиться вокруг одних и тех же характеристик -- рисков, качества продукта, ограниченных сроков и ресурсов. Но в каждом проекте всегда какой-то из параметров более критичен, чем другой.
Меняя фокус внимания с одного параметра проекта на другой, ваши подходы меняются до неузнаваемости. Вспомните старые добрые RPG игры, где вам предлагали выбрать героя - грубого и мощного воина, ловкую лучницу или мудрого мага. Настолько разные герои получались лишь крайней степенью перераспределения трех ключевых характеристик -- сила, ловкость и интеллект.
PERT (метод критического пути)
Метод критического пути (PERT) был разработан по заказу Подразделения специальных проектов ВМС США для создания ракетной системы "Поларис", которая в свою очередь должна была стать ответом на запуск СССР первого космического спутника.
Нетрудно догадаться, что разработчики находились в ситуации, когда конкретно неизвестно ничего -- никто не знал сколько нужно ресурсов для успешной разработки, не существовало конкретного технического задания с требованиями к результату. Известно было одно -- из Белого дома будут звонить каждый божий день и поторапливать.
Именно поэтому подход PERT нацелен на планирование крупных проектов, для которых самое важное -- максимально сократить время на реализацию проекта или попасть в срок. При этом требования к качеству и стоимости продукта не предъявляются.
Честно говоря, мне сложно представить себе проект, в котором имеют значение только сроки. Подозреваю, что такие проекты канули в лету вместе с гонкой вооружений, а от всей системы PERT остался именно метод критического пути, используемый для анализа времени, минимально необходимого для реализации проекта.
AGILE (гибкая методология разработки)
Знаменитый "Грефовский" AGILE пришел к нам из разработки программного обеспечения. На мой взгляд, AGILE незаслуженно оброс стереотипами "проектной анархии", а для противников любых управленческих систем, отличающихся от патриархальной иерархии, стал именем нарицательным по той же самой причине -- все подчиняются всем, все работают над одним, босс не босс, а босс -- "хозяин продукта". Тьфу. Бардак! Но сейчас не об этом.
Представьте себе ситуацию: клиент заказывает ПО у разработчика, разработчик уходит "в нору", возвращается через полгода, сдает проект, который как бы и соответствует техническому заданию, но... во-первых, клиент под рядом понятий понимал другое, во-вторых, визуально представлял себе всё иначе, а, в-третьих, задача устарела, мир изменился и именно такой продукт уже никому не нужен.
А если вы пишите приложение для международной медицинской компании, прогнозирующее самочувствие пользователя в зависимости от погоды? Над таким проектом надо работать не только программистам, дизайнерам, маркетологам, но и консультантам-терапевтам, метеорологам да и, вообще, черт знает кому еще! Какова вероятность успеха проекта, если вся эта братия разойдется по кабинетам и будет эти самые полгода работать параллельно (что, например, метод критического пути вам и посоветует сделать)?
Именно в ответ на этот вызов и появился подход AGILE, держащий в главном фокусе продукт и снижение рисков, связанных с его разработкой. Если вы делаете работу, требующую постоянной "сверки часов" с заказчиком, если над проектом одновременно трудятся специалисты из разных подразделений, если ваш коллектив вынуждено пронизывают горизонтальные связи между сотрудниками и отделами, а вы усилено держитесь за вертикаль власти -- ваш бизнес созрел к AGILE. Дозревайте!
PMBOK
Ключевое отличие классических методов PMBOK в том, что они исходят из предположений о неизменности требований.
Да, наверное, эти методы идеальны на рынке государственных контрактов, где требования измениться не могут даже теоретически, план работ прописан уже в условиях закупки, а вам остается только правильно провести ваш проект сквозь всю проектную бюрократию. Но если описанная ситуация никак не напоминает вашу, это совсем не значит, что классические методы вам знать не надо.
PMBOK - это хороший фундамент для любой проектной работы, включающий в себя главные основы проектного управления. Рано или поздно, вы в любом случае узнаете все описанные методы, разве только ценой собственных шишек и финансовых потерь. Но жить и работать по этому методу рекомендую только если в вашем проекте собрались разом все необходимые требования: зафиксированное техническое задание, низкие риски и жесткие сроки.
Методы инновационных проектов
Инновационные проекты отличаются самыми высокими рисками из всех видов проектов.
Знаете ли вы, что в фармакологии один проект занимает в среднем 7 лет, а нормой считается вероятность успеха в 5%? Другими словами, если вы проработали 35 лет в фармакологическом НИОКР и хотя бы один раз поучаствовали в проекте, который дошел до аптечных полок - вы счастливчик!
Все остальные подходы подразумевают высокую вероятность успеха, в противном случае, браться за проект не следует. Методы инновационных проектов нацелены на выискивание иголки в стоге сена.
PRINCE2 (процессно-ориентированное управление)
PRINCE2, принятый за стандарт проектного управления в Великобритании (жаль только Великобритания не считается колыбелью ярких и эффектных проектов), признается наиболее нейтральной системой проектного управления, пусть и платящей за свою универсальность мелкими недостатками в деталях. С одной стороны PRINCE2 слишком бюрократична для малых команд, но с другой позволяет крупным командам внедрять элементы других подходов в "серых зонах" методик PRINCE2.
PRINCE2 совмещает фундаментальную базу PMBOK, требователен к четкости изначальной структуры проекта, но при этом содержит алгоритмы по его изменению. Если AGILE для огромных команд (500 человек и более) большинству проектных менеджеров видится не берущейся вершиной, а решения -- существующими только на бумаге, то внедрение PRINCE2 может стать той идеальной целью, к которой могут стремиться крупные компании, в которых наведен относительный порядок с функциональными процессами каждого подразделения.
Вместо заключения
Важно понимать, что выбор подхода проектного управления -- это не игра в "угадайку" с единственным правильным ответом. Скорее, это напоминает подбор курса лечения под имеющиеся у вашего бизнеса симптомы.
Глядя на истории успеха компаний, применявших те или иные подходы, обращайте внимание на условия, в которых они находились, и проблемы, которые они решали. Если вы чувствуете, что находитесь в тех же самых условиях, берите метод и пробуйте! Пробуйте и ошибайтесь! И помните, у них тоже получилось не сразу!
-ЛК
