Накопленный опыт взаимодействия с командами и смежными руководителями проектов все больше отражает печальную картину, что многие специалисты не понимают различие между рабочими, календарными и человеко-днями (часами). Попробую разобрать действительно простые понятия, в качестве достоверного источника для определений буду ссылаться на PMBoK.

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

На основе личного опыта и проектных фреймворков выполнить проект успешно (сроки, качество, бюджет, удовлетворенность заказчика) можно только при постоянном проактивном управлении проектом, в рамках которого почти 80% времени должно уделяться прогнозированию. При этом любое планирование и прогнозирование необходимо производить методом набегающей волны а успешным прогнозированием можно заниматься только при выстроенных и устоявшихся процессах. В противном случае менеджер проекта вместо прогнозов и планов в конечном итоге будет заниматься налаживанием процессов управления команды и создания продукта(ов) проекта. Процентное соотношение времени, затрачиваемое на управленческие процессы, очень хорошо отражает зрелость проектного менеджмента в команде/компании и в целом самого менеджера.

В настоящее время в РФ и на просторах СНГ существует фиксированный пул сертификаций руководителей проектов, включающий международные и российские стандарты. Принято считать, что сертификация руководителей проектов – один из способов подтверждения своих знаний и навыков, а также повышения своего профессионального уровня.

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

В продолжение статьи о классическом PRINCE2 по запросу из комментариев попробовала сравнить ключевые методики управления проектами. Надеюсь, что получилось что-то полезное и при выборе подхода управления у читающих часть вопросов будут снята.

Краткие вводные:

PRINCE2 (Projects in a Controlled Environment) – структурированный метод управления проектами, разработанный в 1989 году Central Computer and Telecommunications Agency (CCTA) в Великобритании.

PMBoK – фреймворк (свод знаний) по управлению проектами, разработанный в 1996 году Project Management Institute (PMI) в США.

ISO 21500:2012 «Guidance on project management» - международный стандарт, разработанный проектным комитетом ISO/PC 236 «Управление проектами».

Дано:

1. Корпоративное iOS-приложение, реализованное только под форм-фактор Apple iPad с устаревшим дизайном (особенно, если изучать гайдлайны Apple).

2. Заказчик = крупное российское полукоммерческое предприятие. Со стороны Заказчика участвуют 4 департамента (с одинаковым влиянием друг на друга), один из департаментов является функциональным заказчиком (ФЗ) и владельцем бюджета. Остальные отвечают за безопасность и ИТ-сопровождение.

3. Распределенная на 2 города команда со стороны Исполнителя, проблемы с коммуникациями отсутствуют.

Найти:

1. iOS-приложение под iPhone с современным интерфейсом и доп. функционалом

Ограничения:

1. Заказчик на момент проекта никогда ранее не работал по Agile-методологиям, но их руководство на основе последних трендов повсеместно пыталось запустить использование Agile;

2. Договорные отношения между Заказчиком и нами были FixedPrice (оформить T&M было невозможно).

В эпоху продуктовой разработки с постоянным использованием гибких методологий и «насаживанием» их везде (порой даже не к месту) хочется напомнить об одной из классических методологий проектного управления. Вопрос классических методологий всё еще актуален для договорных отношений Заказчик – Исполнитель и проектов с каскадной формой управления. 

Упомянутый в заголовке статьи стандарт PRINCE2 также актуален и для проектов с гибкими методологиями, так как Agile-методы очень четко и структурировано рассказывают, как правильно разрабатывать продукт (и управлять именно процессом разработки продукта), но как именно управлять проектной деятельностью (а это, как известно, не только один процесс производства продукта) гибкие методологии покрывают не всегда и не полностью. 

В силу своей разрекламированности PMBOK всегда был более востребованный и популярный, вместе с этим очень перегруженный по группам процессов (например, для IT-проектов). Многим руководителям проектов использование проектной методологии PRINCE2 в сравнении с PMBOK (в силу лаконичности и структурированности первого) позволяет более изящно управлять проектами разного масштаба и структур.