Инструменты управления проектами

1.   Waterfall. Начать описание инструментария нужно с классической технологии Waterfall. Часто она упоминается под названием "каскадная модель". Эта модель стала эталоном проектного менеджмента и была зафиксирована в стандарте ANSI, известном под названием PM BOK (Project Management Base Of Knowledge). Останавливаться детально на этой технологии не буду. Ее знают все, кто профессионально занимается управлением проектами. И даже те, кто не знает стандарта, часто используют два основных инструмента этой технологии - WBS (work breakdown structure) и диаграмму Ганта.

2.   Agile. Родом из ИТ. Долгое время PM BOK был практически единственным признанным стандартом проджект-менеджмента. Однако, в ИТ-сфере зародилось недовольство. При разработке новых ИТ продуктов было сложно на старте определить путь решения задачи. Разработчикам ПО казалось, что классический подход Waterfall очень зарегламентирован и существенно увеличивает сроки разработки. В 90-е годы представители ИТ отрасли пытались предложить вариант «легкой» системы управления проектами. В 2001 году эта идея оформилась в виде Agile-манифеста. Упрощенно основную идею можно сформулировать так – результат все, процедуры ничто.

3.   Agile vs PERT. Популярность нового метода быстро набирала обороты. Одним из основных преимуществ нового подхода, в противовес модели Waterfall называлась возможность быстро менять решения для достижения цели. Утверждалось, что в модели Waterfall команда проекта становится заложником исходного плана. На самом деле это не так. В технологии Waterfall, как в любой качественной системе менеджмента, предусмотрены корректирующие действия. В данном случае они реализуются в модели PERT (Program Evaluation and Review Technique). Но противники классического подхода этого не знали и вообще хотели уйти от четких процедур. С учетом того, что большинство руководителей (особенно в РФ) не любят порядок и организованные процессы, считая, что они убивают творчество, под красивым название Agile начали распространяться бардак и волюнтаризм в проектной деятельности.

4.   Agile vs Scrum. Несмотря на то, что проблемы неорганизованности в проектной деятельности, возникающей под прикрытием Agile-подходов ярко проявились за рамками ИТ сферы, в разработке ПО тоже стали задумываться о низкой эффективности неуправляемого гибкого подхода. В противовес полной свободе Agile появился Scrum. Это было стремление сторонников гибкого подхода создать более четкую регламентированную канву, устраняющую произвольные метания и направляющую процесс в заданное русло. Обратите внимание, что хотя многие считает Agile и Scrum практически синонимами, на самом деле, фактически, это чуть ли не противоположные концепции. Полная свобода пути в виде «перебежек» в Agile и жесткий алгоритм коротких спринтов в Scrum.   

5.   Расширение PM BOK. Чтобы не отставать от жизни, на волне популярности Agile-подходов и модели Scrum, соответствующие разделы управления проектами были включены и в базовый стандарт PM BOK

6.   Возврат к классике. К началу 20-х годов возникло разочарование в гибких системах управления проектами из-за крайне низкой итоговой результативности. Как всегда, возникла новая тенденция – «все эти модные подходы это ерунда и нужно работать по технологии Waterfall».

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

7.   SECRET. Формально, в каждом из подходов к управлению проектами есть разделы, определяющие запуск проекта. Однако, в большинстве случаев эти разделы рассматривают организационную составляющую запуска проекта. Его суть остается за рамками рассмотрения и не проверяется на адекватность, нужность, полноту и т.д. Т.е. достаточно слабо проработаны вопросы релевантности проекта, а также его валидация и верификация.

Именно этим вопросам посвящена модель SECRET. Фиксация орг структуры, устава проекта и других технических моментов остается в рамках все того же PM BOK и аналогичных руководств. Но вот вопросы осмысленности проекта, полноты его проработки и реализуемой сути рассматриваются именно в модели SECRET. И пренебрежение этим инструментом может привести к тому, что мы выполним большой объем работы и даже получим запланированный результат, но потом поймем, что этот результат нам не нужен.

8.   PSCG, Нужно упомянуть и еще один важный инструмент управления проектами. Уже описанные модели Waterfall, или Scrum – это технические инструменты движения к цели. Правильный набор задач, правильная последовательность, контрольные процедуры. Но что делать, если все вроде делаем правильно, а результат плохой? Почему он плохой? За ответ на этот вопрос отвечает отдельный инструмент – система управления успешностью проекта PSCG. Этот инструмент дает ответы на вопрос, какие задачи нужно решить в эмоциональной и информационной подготовке команды проекта, чтобы удалось выполнить планы и достичь запланированной цели.