Наверх ▲

«Хороший» менеджер проекта + профессиональная сертификация по управлению проектами

Алексей Полковников Алексей Полковников Президент ассоциации управления проектами СОВНЕТ (представитель России в IPMA), генеральный директор и управляющий партнер ГК «Проектная ПРАКТИКА»

 

 

Алексей Полковников: Доброе утро! Спасибо всем, кто выбрал Зал № 2.

Я сегодня хочу поговорить в первую очередь о том, что вам интересно. Я рад, что зал небольшой, компактный – значит, мы можем и дискуссию какую-то организовать. Я на всякий случай флипчарт поставил: может быть, что-то нужно будет записать. Мне во многом интересно и ваше мнение на тему моей презентации. 

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

Здесь я представляю себя в двух ролях. 

С одной стороны, я являюсь управляющим партнером группы компаний "Проектная практика", которая уже почти 20 лет оказывает услуги нашим клиентам в области проектного менеджмента. Внедряя систему управления проектами в различных отраслях и помогая обучать менеджеров проектов. 

За это время где-то в 300-х проектах, по нашим подсчетам, мы участвовали. В первую очередь, крупные проекты, масштабные. Гораздо меньше удалось поработать с тем типом проектов, которые вы здесь обсуждаете: интернет-проекты. Хотя достаточно много IT-проектов мы тоже делали.

С другой стороны, как президент Ассоциации управления проектами, Российская ассоциация, представляющая Россию в Международной ассоциации управления проектами (IPMA). 

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

Такая небольшая вводная.

Рядом с моей фамилией есть две аббревиатуры – это как раз сертификация по двум стандартам (PMI и IPMA). 12 лет назад я поставил эксперимент на себе: прошел эту сертификацию – каким-то опытом тоже готов поделиться.

Презентацию решил построить из двух частей. 

Первая часть больше информационная: дать информацию краткую о существующих сегодня стандартах и сертификации в области управления проектами. 

Вторая часть больше дискуссионная: ответить на ряд вопросов. Нужна ли вам эта сертификация. В каком разрезе она нужна – обсудить. Я поделюсь своим опытом – с удовольствием выслушаю ваши мнения.

Первая часть будет достаточно краткой. 

Любую информацию сегодня можно найти в интернете: пара кликов, и вы ее имеете. Но чтобы искать что-то, нужно хотя бы понять, что именно искать. Какие-то такие моменты я расскажу (что может быть вам интересно), а уж остальную информацию можно будет найти в интернете.

Начну с информационной части: что касается стандартов. Первый слайдик достаточно простой, водный. 

Определение управления проектами. 

Есть много определений, некоторые из них очень формальные – применение знаний, навыков и так далее для достижения целей проекта. Я выбрал такое упрощенное определение. За время, что я работал, у меня сложилось мнение: не надо усложнять. 

Упрощаете ситуацию – вам проще будет ее решить.

Соответственно, простое определение, мне оно нравится. 

Управление проектами – искусство определения цели деятельности и организации группы людей для достижения поставленной цели.

Реально, все методики управления проектами направлены на решение ровно двух задач: 

1.правильно цели поставить, 

2.правильно организовать потом команду, мотивировать, организовать для достижения поставленных целей. 

Вроде бы, ничего сложного нет, но именно здесь бывает достаточно много проблем. Как правильно цели поставить (согласовать с заказчиком и так далее) и как мотивировать людей, как их организовать. 

Но все управление проектами, все стандарты направлены ровно на решение этих двух задач.

Управление проектами – достаточно практическая дисциплина (не зря я здесь на слайде нарисовал такой циклик), развивается по циклу. 

Сначала это практическая наработка на проектах передовых менеджеров, скажем так. Вас назначили менеджером проекта – вам деваться некуда, вы изобретаете. Вы изобретете: "как мне спланировать этот проект, как мне привлечь исполнителей, как мне их мотивировать". Вы изобретаете некий подход, который поможет вам проект реализовать.

Если то, что вы изобрели, удачное изобретение – хорошо бы, чтобы оно не осталось только в вашей голове, а его смогли применять и более широко. Конечно, здесь полезную роль играют те, кто занимаются обобщением (пишет книжки, статьи, стандарты и так далее). 

Наверное, это полезная роль. Но потом мы с вами (простые менеджеры) открываем эти стандарты и начинаем ломать себе голову: насколько вообще это все применимо к моему конкретному проекту. Может быть, там довольно далекая от реальности теория написана в этом стандарте? Такие подозрения нередко закрадываются. 

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

То, чем моя компания занимается – практически все эти годы мы каждый раз адаптируем эти методики под конкретный тип проекта, под заказчика и так далее. 

Это общая небольшая вводная.

Теперь что касается стандартов. Какие есть стандарты сегодня на рынке. Я думаю, многие аббревиатуры здесь вам знакомы: ISO, PMBOK. Знаком PMBOK? 

Можно попросить поднять руку: здесь есть сертифицированные менеджеры проектов по международным стандартам? Две человека. PMI?

Наиболее распространенный и известный стандарт сегодня. Первые два стандарта, ISO (ISO 10066 сейчас используется) и стандарт PMBOK, построены по единому принципу. Там просто формально прописано, что нужно делать менеджеру проекта: в ходе инициации проекта (1), в ходе планирования проекта (2), организации исполнения проекта (3), контроля (4)  и завершения (5). Пять групп процессов.

ISO стандарт (ISO 10066) достаточно коротенький – 50 страниц всего, общие слова написаны. На него ссылаются иногда для солидности, если надо, но на практике редко применяют. 

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

Еще американцы – хорошие маркетологи, продвигают свой стандарт по всему миру, перевели на русский язык. Поэтому он становится таким популярным.

Должен сказать, вообще-то Международная организация по стандартизации поняла, что это тоже не совсем правильно, что де-факто американский стандарт становится международным. Они запустили свой проект (кстати, совместно и с PMI, и с IPMA – совместная рабочая группа) по разработке этого стандарта ISO 21500. Он уже практически написан, готов и в следующем году должен быть принят.

Это что касается такого подхода к стандартам, когда прописываются общие процессы управления проектом. 

Но есть другой подход – это, соответственно, Международная ассоциация управления проектами. То, что здесь на слайде показано внизу этого – Международная ассоциация управлении проектами IPMA (International Project Management Association). Они выпускают свой стандарт – аббревиатура ICB. Переводится как "International Competence Baseline" или "Международные требования к компетенции менеджеров проекта". 

В отличие от двух предыдущих стандартов (PMBOK и ISO) здесь во главе угла стоят не процессы, которым нужно следовать, а требования к человеку. Что должен знать и уметь человек, которому вы доверяете проект. На базе этого стандарта тоже построена определенная система сертификации. 

В России есть разработанные на базе этого стандарта свои национальные требования к компетенции менеджеров проекта. Эта международная сертификация в России также присутствует.

Это если кратко. Не хочу дальше вам этим голову забивать. В принципе, любую аббревиатуру можно набрать в интернете и – соответственно, информацию найти.

Опять же кратенько по сертификации. 

Если говорить о PMI. Три основных сертификации сегодня предлагает PMI на рынке. Больше 90% – это PMP. Больше 90% желающих пройти сертификацию – это PMP (Project Management Professional) / "Профессиональный менеджер проекта".

Формальные требования здесь написаны. Такие немаленькие, на самом деле: 4500 часов за 6 лет вы должны показать своего опыта, что вы занимались планированием, организацией исполнения. 

На самом деле, это не очень сложно. По статистике где-то 70% времени у менеджера проекта занимают функции, связанные с организацией исполнения. На организацию исполнения вы можете потратить довольно много времени. Это когда вы общаетесь с исполнителями, когда вы ставите им задачу, когда вы координируете их. Это съедает много времени, поэтому не так уж сложно набрать за 6 лет деятельности 4,5 тысяч часов опыта. 

Когда вы решаете, на какую сертификацию пойти (есть вариант Associate in Project Management \ "Специалист в области управления проектами" или полноценный "Менеджер проекта"), как показывает статистика, выбирают PMP. Все равно опыт показывать надо, собственно говоря, разница не большая – экзамен тоже сдавать надо.

Есть еще сертификация "Управление программами" (но это больше для руководителей высшего звена). Люди, которые имеют уже достаточно приличный опыт: 4 года управления проектами, 4 года управления программами. Это сертификация "Program Management Professional". Единицы ее пока проходят.

Я уже сказал,  американцы – хорошие маркетологи. Они смотрят, а что же нужно рынку: какие еще сертификации могут быть полезны. Поэтому сейчас запущен еще ряд новых сертификаций (запускается, в процессе). Уже есть отдельные специализации: "Специалист в области управления рисками", "Специалист в области планирования". Есть такие сертификации. В ближайшее время должна быть запущена сертификация "профессиональный менеджер проектов, использующих методики agile" – Agile Project Management. 

Значит, есть спрос на это. Американцы, наверное, не зря это изучили. Эта сертификация (как обещают) должна уже в конце года появиться. Может быть, в начале следующего.

Что касается IPMA (Международной ассоциации управления проектами), там примерно похожий подход. Четырехуровневая система сертификации. 

Базовый уровень (уровень D, Level D – специалист в области управления проектами) не требует опыта. На этот уровень могут идти и достаточно молодые люди, что они и делают. Сдается экзамен – люди получают уже сертификат "Специалист в области управления проектами".

Более высокие уровни требуют определенного опыта. 

Level С – 3 года управления проектами плюс сдача экзамена. Не обязательно сложными, можно и не очень сложные проекты.

Level B – 5 лет управления (из них обязательно 3 года сложные проекты должны быть – надо показать свой опыт). Есть аналог управления программами Certified Project Director – человек, который 5 лет управляет группой проектов.

Вот если кратенько. Если говорить про IPMA-сертификацию, то большая часть как раз на нижний уровень идет, большая часть у нас сейчас сертифицируется на Level D.

Что из себя представляет эта сертификация. Какие навыки в данном случае проверяются. 

Эта сертификация, как я сказал, построена на стандартах ACB (Международные требования компетенции менеджеров проектов) и их аналогах НТК (Национальные требования компетенции). Три блока компетенций должен представить менеджер проекта.

То, что называется "технические элементы знаний" – проверяют компетенции, знания в области технических моментов. Планирование, разработка планов, контроль, анализ рисков. Всё-всё, что связано с процессами управления проектов. Проверяется 20 основных технических элементов знаний. 

Что важно в этой сертификации (я считаю, это большой плюс) – добавлены еще поведенческие элементы. 

Лидерские качества – как их проверить? На самом деле сложно. Но, по крайней мере, формально они добавлены. Лидерские качества, уверенность в себе, умение быть убедительным, умение мотивировать команду и так далее. Немало здесь тоже наработано.

Еще что важно. 11 последних (третий блок) – это так называемые контекстуальные элементы. 

Менеджеру проекта очень важно понимать, как правильно взаимодействовать не только внутри проекта, но как правильно взаимодействовать с менеджерами внутри своей компании: с функциональными руководителями, с высшим руководством. 

Надо понимать, как проект вписывается в бизнес-процессы компании. Поэтому отдельно был добавлен этот блок контекстуальных элементов, связанных с контекстом интеграции проекта в бизнес организации. Общая картинка такая.

Есть отдельный слайдик, где перечислены эти элементы. Я уж не буду их детально рассматривать – я уже охарактеризовал эти элементы.

На этом я завершил информационный блок, постарался достаточно быстро его проговорить. Если будут вопросы – с удовольствием лучше отвечу на ваши вопросы.

Следующий блок дискуссионный. Здесь я для себя поставил несколько вопросов. У меня есть на них свои ответы, которые моим опытом продиктованы. Мне интересно вместе с вами обсудить.

Первый слайдик – он для разогрева, простой. Соотношение двух понятий: "эффективное управление проектом" и "успешный проект". 

Понятно, что ответ очевиден: равенство здесь провести нельзя. Эффективное управление проектом не значит, что у вас будет успешный проект. Вы можете прекрасно управлять проектом, но в итоге иметь проект провальный. Почему? 

От каких факторов зависит успех проекта. 

Здесь мне хотелось бы поставить с вами маленький эксперимент (к счастью, есть флипчарт). Давайте, для начала вы мне назовете десяток факторов, от чего зависит успех проекта из вашего опыта. Я их напишу, а потом мне интересно сделать вывод. Будет ли он соответствовать тому, к чему я привык. Или, может быть, чем-то отличаться от ответов других менеджеров, с которыми мне пришлось общаться.

Давайте навскидку. Вы начнете? (Ответ из зала). Это уже критерий успеха, это показатель, по которому измеряют, что проект успешный. Вы уложились в срок – молодец! Вы сделали успешный проект. А критические факторы – что вам позволило в срок уложиться. Это условия. От чего зависит успех проекта. (Ответ из зала). Эффективная команда. Что еще команда? Профессиональная команда. Что еще команда? Мотивированная команда. Здесь про команду можно несколько прилагательных добавить. Давайте, я запишу.

Команда. Под этим мы понимаем, по крайней мере, две вещи. Команда – вам нужна профессиональная команда плюс мотивированная. Одно без другого смысла не имеет. Вам не нужны профессионалы без мотивации. С другой стороны, мотивировать непрофессионала смысла тоже большого нет. 

(Ответ из зала).

Поддержка высшего руководства. Отлично! Давайте напишем.

Поддержка высшего руководства. Вообще часто наши менеджеры это на первое место ставят, понимая под этим некую прямую поддержку. Когда руководитель на совещании не забывает еженедельно упомянуть: "проект важный, нужно собраться, нужно сделать". Всех немножко прессуют по поводу какого-то значимого проекта.

Американцы тоже это называют. Американцы тоже такие опросы проводят. Они немножко другое понимают. Они под поддержкой высшего руководства понимают делегирование полномочий: руководство дало нам четкий приказ, в котором прописаны полномочиями. Это тоже важно.

Хорошо. Записали.

Я услышал слово "ресурсы". Давайте отдельно напишу, хотя это пересекается с командой, но ресурсы… Что мы понимаем под ресурсами кроме людей?

Реплика из зала: Деньги.

Алексей Полковников: Для вас самое важное, конечно, люди, но деньги тоже не помешают. Команда + ресурсы. 

Еще?

Реплика из зала: Идея.

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

Вообще, я бы рядом с целями в скобочках написал "SMART". Это все как бы в себя впитывает. SMART – цели не просто четкие, но еще и достижимые, реальные и так далее. Могут быть очень интересные идеи, очень интересные цели, но нереально. Не достигнешь в те сроки, в которые вам нужно этого достичь и с теми ресурсами, которые вам предлагаются.

Что еще?

(Ответ из зала). 

Очень хорошо! Поддержка высшего руководства плюс адекватный заказчик. А если он не адекватный, что делать? Значит, надо постараться его сделать адекватным. Если возможно…

Реплика из зала: Время.

Алексей Полковников: Время: адекватные сроки. Хорошо. Давайте здесь напишем: адекватные сроки. 

Интересно пока. Я специально здесь среднюю часть оставил для ряда факторов, которые мне важны. Пока вы их не называете.

(Ответ из зала). 

Четкие задачи. Вот. Да! Очень правильно! Как понять, сроки адекватные или нет? Четкие задачи. Я бы написал другое слово – четкий план. Потому что задачи в виде плана у вас есть. Четкий план проекта.

Есть у вас четкий план проекта – но это "мертвая бумага", можно сказать. Что дальше с ним делать, чтобы он, в конце концов, превратился в результат?

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

Что это за процессы? 

Один – я услышал. Вы сказали: эффективный контроль. Эффективный контроль нужен за исполнителями. Что еще?

(Ответ из зала). 

Да! Это называется "организация исполнения" – то, что как раз отнимает большую часть времени. Вы с этим планом должны прийти к исполнителю, сказать: "Возьмешься, не возьмешься: в эти сроки, такая-то задача". И так далее…

Эффективная организация исполнения. Давайте, я перед "контролем" напишу. Сначала – эффективная организация исполнения. Потом уже – контроль того, о чем договорились.

Есть еще третий процесс. Он, может быть, на поверхности не лежит – но на это у менеджера проекта уходит очень много времени. Что это за процесс?

Реплика из зала: Мотивация?

Алексей Полковников: Мотивация. Согласен, важно. Давайте напишем мотивацию. Хотя мы уже написали (давайте, просто подчеркну). Да, это важно – мотивированная команда. Чтобы она была мотивированная, надо этим постоянно заниматься. Но я немножко другое имел в виду. Конечно, можно много чего еще добавить. Я три самых важных выделяю сейчас: надо всех организовать, надо их контролировать. Что еще?

(Ответ из зала)

Примерно, да. Близко, близко. Это как раз ключевые идеи agile менеджмента. Я думал,  для вас это будет самое четкое. Менеджер проекта: организует всех на основании плана, контролирует. Но этого не достаточно. Потому что по ходу проекта планы меняются. Соответственно, всплывают какие-то непредвиденные задачи, о которых мы даже не подумали в начале. 

Это называется "риски", это называется "управление изменениями" и так далее. То, что постоянно приходится делать. 

Большинство менеджеров говорят: "Для меня еще важно для успеха проекта, как поставлен это процесс". Насколько быстро удается решать какие-то непредвиденные задачи, какие-то проблемы и так далее. 

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

Этот процесс называют еще "эффективное управление проблемами".

Есть еще что добавить?.. 

Еще две вещи я бы, на самом деле, дописал. Но если нет – достаточно и этого.

То, что вы сказали, очень сильно пересекается с тем, что говорят менеджеры других проектов: создание каких-то объектов инфраструктуры, стройка, IT, проекты реорганизации и так далее. Видите, все очень похоже. Не сильно выбивается за рамки традиционного project management'а.

На самом деле, чтобы ваш проект был успешным, вам нужно выделить три типа факторов и их проанализировать. Я обычно рисую это в виде домика: есть крыша у этого домика, есть 2-й этаж, и есть 1-й этаж.

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

Это понятно, с этим никто не спорит.

Второй этаж – это эффективное управление проектом. Это как раз все, что связано с эффективным управлением проекта: 

нужно разработать план, 

нужно понять, адекватны ли сроки и ресурсы этому плану, 

нужно на базе плана поставить процессы управления. 

Это эффективное управление проектом.

Кстати, обратное бывает и спорно. У меня были случаи, когда отдельные менеджеры мне говорили: "А мне не надо управление проектом, мне не надо. Я только за счет своих технологических знаний могу проект сделать". Я, в принципе, ему верю. Некоторым – верю. 

Если это проект не сложный, и он уже десять или пятнадцать таких проектов делал, то он примерно понимает, куда движется его проект от текущей ситуации. Это обычно строители так говорят (открою секрет). 

Но как только проект становится чуть сложнее – он его сделает, но сделает гораздо дольше и дороже, чем мог бы сделать. Что-то будет делать в авральном режиме, что-то будет переделывать и так далее. 

Поэтому и это хорошо иметь, и это.

Верхушка – тоже понятно. Четкие, обоснованные цели, согласованность с заказчиком, поддержка руководства компании. Это для вас как для менеджера очень важно. 

Вот получается три элемента.

Реально нужно посмотреть – как? Все-таки первое – все ли у меня в порядке с целями. Они достижимы? Они увязаны со стратегией развития рынка и компании?

Второе, наверное: все ли у меня в порядке с ресурсами. Если здесь и здесь у вас в порядке – можно уже думать об управлении проектами.

Управление проектами я отнюдь не ставлю на первое место. Это (исходя из моего опыта) важный кирпичик всего здания – но у него есть свое место.

Кстати, про цели. Буквально маленькая такая история по поводу обоснованных целей. 

Наверное, знаете: американцы любят выбирать лучший проект года с точки зрения управления. Американский институт управления проектами любит выбирать лучший проект года с точки зрения управления. Оценивают, как он планировался, организовывался, исполнялся.

Был такой запоминающийся факт, когда в 2003-м году они в качестве лучшего проекта выбрали проект компании " Kodak ". Компания " Kodak ", выпускающая пленки, решила вдруг перейти на новый формат пленок (с больших на маленькие). Решили запустить маленький формат пленок, что давало возможность оживить рынок, запустить производство новых маленьких фотоаппаратов и так далее.

Что значит сделать такой проект – это огромная организационная работа.

 Нужно убедить большинство производителей фотоаппаратов спроектировать и выпустить фотоаппараты под этот стандарт пленок. Нужно убедить лаборатории, которые печатают фотографии, закупить новое оборудование под этот стандарт пленок. Они все это сделали, все спланировали, в короткие сроки выполнили – проект получил приз. Лучший проект года! 

Но история показала, что проект реально был провальный для компании: чуть ли не на грань банкротства их поставил. Потому что цели не вписывались в движение рынка. Когда конкуренты занимались "цифрой", они немножко пошли не в ту сторону.

Как иллюстрацию небольшую к этой крыше, шапке, всей картиночке я добавил. 

Ну да ладно. Это в качестве разминки. Моя задача была, собственно говоря, проиллюстрировать то, что написано здесь на слайде.

Хорошее управление проектом не гарантирует достижение целей проекта, но повышает вероятность, что вы эту цель достигнете.

Следующий слайдик. Здесь два понятия, я тоже хотел сравнить. "Хороший менеджер проекта…" Вообще у меня в заголовке было написано не так. В заголовке презентации не просто было "хороший менеджер проекта плюс сертификация". Там было написано "плюс-минус". Плюс-минус: нужна или не нужна.

Я хотел бы здесь сравнить эти два понятия. Почему "хороший" в кавычках? Потому что понятие расплывчатое. Что такое "хороший менеджер проекта"? Тот, кто регулярно делает успешные проекты, или какие-то более сложные критерии должны быть.

Что такое сертифицированный менеджер проекта, в чем его плюсы. 

Сейчас в России, по моей оценке, около 4000 менеджеров прошли эту международную сертификацию. Где-то 900 человек – это PMP. Примерно 3000 – по стандартам IPMA у нас прошли сертификацию. 

Лет 12 назад ни одного не было.

Мне запомнилось. К нам приезжали гордые американцы и говорили такие вещи: "Я PMP – Project Management Professional". 

Что это значит? Это значит, что я обладаю определенными ноу-хау управленческими, знаниями, компетенциями, которые мне помогут прийти на неизвестный, незнакомый для меня проект в незнакомую для меня область, формально там все организовать, определить цели, выстроить команду, поставить им задачи, запустить процесс, мониторить – и этот проект я сделаю.

Как-то так получилось, что я несколько раз встречался с одним менеджером, американцем, который несколько раз рассказывал одну и ту же историю, как он был менеджером проекта модернизации службы "911" в городе Новый Орлеан (еще до потопа это было). Там нужно было реализовать проект, согласуя работу трех ведомств: "Полиция", "Скорая помощь" и "Пожарная охрана". 

Сначала менеджером проекта поставили человека из полиции – но проект не двигался. Не хватало этому человеку и управленческой компетенции, и мешали межведомственные барьеры. Тогда решили взять внешнего управляющего. Поставили внешнего менеджера проекта. По его рассказам: "Я все формально организовал, хотя ничего не понимаю ни в полиции, ни в скорой помощи (как это работает), но формально организовал. Мы проект сделали, сделали вовремя". 

Как к этому относиться? Я многие вещи подвергаю сомнению, на самом деле, – такой принцип. Обычно говорю: "Где-то, может быть, работает – а где-то не очень". Да, я верю, что это могло быть. Но работает это (во многом) для не сложных, скажем, организационных проектов. Это возможно. 

Есть большой срез проектов, где очень важна именно технологическая основа и знание менеджером предметной области. 

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

Я к этому не отношусь так однозначно. Да, хорошо, сертификация что дает? Умение построить систему управления проектом, умение выстроить систему. Но очень важно к этому добавить еще и знание предметной области. 

Мы с нашими заказчиками, как я сказал, более 300 проектов прошли на своем пути в разных областях. Довольно часто с заказчиком садимся и обсуждаем: кого лучше поставить менеджером того или иного проекта. 

В 80% случаев выбор падает на "предметника". Давайте возьмем человека, который работает в вашей компании уже не первый год и знает предметную область. Обучить его управленческим вещам – не проблема. Там все на уровне здравого смысла. Очень важно все-таки, я считаю, знание предметной области.

Единственное, надо избегать другой крайности. 

Какая другая крайность? 

Человек говорит (он уже закрыт для новых знаний, закрыт для того, чтобы общаться с людьми): "Я все знаю лучше всех. Я 20 лет в отрасли. Мне никто не нужен. Я знаю, как будем делать – я вам все расскажу". 

Этого стараемся избежать. Взять человека, который видит: вокруг него есть люди, что у них в головах есть что-то, чего нет у него. Он  изначально должен себе это сказать. Нужно сделать что-то, что позволит ему эту информацию собрать из голов разных людей, обобщить в виде моделей, которые он имеет в ведении его проекта, а потом вернуть на них же уже в виде задач. 

Вот искусство менеджера проекта.

Если расставлять по приоритетам  – я бы поставил так.  Что такое хороший менеджер проекта. Это хороший коммуникатор, человек, который понимает других людей, видит их, знает, что у них в голове, и как их мотивировать поделиться знаниями. 

На второе место поставил бы технологические знания – это тоже очень важно. Скажем так. Второе и третье места делят уже технологические знания и компетенция в области менеджмента. Без компетенции все-таки трудно бывает, придется барахтаться.

Примерно это я и написал на этом слайдике – что такое хороший менеджер проекта. 

Единственное, добавил еще этические моменты. Как показывает моя практика, этика – это важный момент.

Есть еще один слайдик на эту же тему, но он лишь графически показывает примерно то, что я сказал. 

Три составляющих. Это жесткие методы, которые опираются на стандарты, технологии, методики, использование IT-систем. Этому можно обучиться, это проще контролировать, это проще сертифицировать. Как раз сертификация во многом позволяет оценить знания человека в этой области.

Второй блок – это то, что называется soft skills (это лидерство, харизма и так далее). Последние модели сертификации претендуют на то, чтобы это тоже оценивать. Это тоже оценивается, это тоже входит в требования компетенции менеджера проекта. Но мой опыт асессора показывает, что это оценивать бывает сложно.

Человек говорит: "Я лидер. Хороший лидер". Докажи! Он рассказывает какую-нибудь историю красивую. Хорошо, я ему верю, ок. На самом деле, это важный момент. Мы сейчас говорим на самооценку: "Оцени себя сам: мы тебе доверяем". Уже то, что человек сам себя оценивает, это позволяет ему, может быть, свои слабые стороны увидеть, где-то для себя поставить галочку, что вот это надо подтянуть, над этим надо поработать.

Как показывает мой опыт, люди очень много тратят времени именно на жесткие, формальные методы (отработка hard skills) и забывают о soft skills. Это важный момент. Те 15 компетенций, которые в стандарте описаны, о них надо задуматься.

Третье – знание проблемной области. Это я уже сказал.

Еще один момент, который я хотел обозначить. Вы можете быть прекрасным менеджером проекта (обучились где-то, отработали на практике, знаете, как управлять, знаете, что нужно устав написать в начале проекта, знаете, как план разработать). Приходите с этими своими знаниями в компанию, где никто кроме вас ничего этого не знает и не применяет. 

Будете ли вы это применять на практике? 

Нет. Скорее всего, вы это применять не будете. Или будете очень локально применять, чтобы просто свои мозги поставить на место. Вам это будет полезно: для себя где-то написать эти документы. 

Вообще говоря, эффективность этих документов именно в командном использовании. 

Эффективность документов управления проектами в том, что все члены команды ими пользуются, говорят на одном языке – в этом большой плюс.

Поэтому я и вставил такой слайд: для эффективного управления проектами нужны две составляющие. Да, важна индивидуальная компетенция. Люди должны уметь правильно цели ставить, правильно ограничения определять, риски и так далее. 

Но это заработает только тогда, когда в компании есть некие корпоративные требования – то, что мы называем корпоративный стандарт. Если мы запускаем новый проект или подписываем контракт с заказчиком – мы делаем: 1)... 2)… 3)… Все знают, как и что мы делаем. Если мы планируем – мы делаем: 1)... 2)… 3)…

Это очень важная составляющая – инфраструктура, в которой живет эффективный менеджер. Ее нужно ставить. Соответственно, одно от другого отрываешь – не работает. Система без компетенций не работает индивидуальных, индивидуальные компетенции без системы тоже не работают. 

Это важный момент.

Сегодня Международная ассоциация управления проектами выпустила на рынок еще одну сертификацию, которая начала пользоваться очень большой популярностью. Это сертификация по модели "Delta", когда оценивается не только индивидуальная компетенция менеджеров, но оценивается еще готовность компании к реализации проектов. 

Там есть три составляющих.

Собственно говоря, модуль "индивидуумы" – оценивается индивидуальная компетентность менеджеров проектов.

Дальше оценивается, как они реально это на проектах применяют – оценивается степень успешности проектов в организации.

Третий блок – оценивается инфраструктура, созданная в компании, для того, чтобы менеджеры проектов жили в этой инфраструктуре. Насколько в компании есть, прописаны стандарты процесса, настроены какие-то методики, системы под данную компанию.

Такой, я считаю, тоже важный шажок в области внедрения управления проектами.

Заключительные слайды. Буквально два коротких слайда. 

Я попытался взвесить для себя на весах плюсы и минусы сертификации. 

Плюсов, вроде как, визуально больше оказалось.

Вообще говоря, сертификация не делает из плохого менеджера хорошего. 

Сертификация – это инструмент подтверждения хорошим менеджером уже имеющихся у него компетенций неким независимым органом. Относиться к ней надо как к некой фиксации результатов: "Я работал несколько лет в области управления проектами, я кое-чего достиг – почему бы это не зафиксировать формально в виде сертификата".

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

Поэтому сам процесс – это тоже некое подведение промежуточных итогов, само-аудит. Это очень полезно бывает сделать, а сертификация вас к этому просто подтолкнет.

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

Это плюсы. Это бы я отнес в копилку плюсов сертификации.

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

Еще я бы такой момент обозначил: усилия по форматированию собственного опыта. У вас наработался опыт, у вас сложилось мировоззрение. У вас все по полочкам. Вы берете стандарт – и вам нужно свой опыт запихнуть в этот стандарт. Не всегда это бывает легко. 

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

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

Об этом надо думать и смотреть, что из этого будет получаться.

Это что касается сертификации. 

Еще один слайдик как заключение. Я расставил знаки восклицательные потому, что моя практика меня подталкивает к этим выводам.

Каждый раз применение общих походов – это адаптация. Поймите свой проект, как объект управления, поймите его особенности. Поймите, что для вас на этом проекте важнее. Вам нужно сделать собственный рецепт из ингредиентов, описанных в стандарте. 

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

Но надо понимать: адаптировать вы можете тогда, когда у вас есть база. Когда у вас уже все по полочкам разложено – тогда гораздо проще адаптировать. Если у вас нет базы, вы занимаетесь не адаптацией – а изобретением. Может быть, изобретением велосипеда (что, на самом деле, неправильно – тратить свою жизнь на это).

Второй восклицательный знак. К тому, что написано в стандарте, нужно относиться как к такому широкому описанию требований к процессам управления. 

Реально они заработают только тогда, когда вы наложите их на жизненный цикл вашего проекта. У проектов разные жизненные циклы, разные точки принятия решений. Это может быть "водопад", это может быть "спираль". То, что там написано (общие подходы) – это не значит, что сначала надо заниматься инициацией, потом планированием, потом организацией. 

В параллель. Витки спирали не отрицают, что вы можете применять классические подходы управления проектами. То, что мы делаем с нашими заказчиками: каждый раз накладываем точки принятия решений управленческих на жизненный цикл проекта. Это важно понимать и использовать.

Последнее, я уже сказал. 

Коммуникации, коммуникации и еще раз коммуникации. Ставлю их на первое место. Знаете, что информация, которая вам нужна, находится в головах разных людей (заказчика, исполнителей, ваших специалистов, экспертов). Умеете это увидеть, собрать. И вы будете героем этого проекта.

Это основные выводы. А в заключении, может быть, еще вы может быть, добавите, с чем-то не согласитесь. Я очень хорошо отношусь, когда встает кто-то и говорит: "А я с вами не согласен по тому-то и потому-то". Очень полезная вещь – не соглашаться.

А я бы еще добавил. Что касается хорошего менеджера проектов, рецепт, на самом деле, простой. 

Чтобы стать хорошим менеджером проекта, надо просто сказать: "Я хороший менеджер проектов!" 

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

Спасибо. 

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

 

Вопросы и Ответы

Реплика из зала: У меня касательно сертификации вопрос. Звучал термин "сложные проекты". Критерий сложности, он же как-то определен. Расскажите, пожалуйста.

Алексей Полковников: Есть целый список критериев сложности. Во-первых, у IPMA (у Ассоциации) есть на две странички список критериев сложности. Каждая компания для себя прорабатывает. По большому счету, такие критерии можно сгруппировать в несколько блоков.

Сложные с точки зрения содержания работ. Масштаб, необходимость интеграции результатов из разных функциональных областей, необходимость координации большого количества людей, подчиняющихся разным функциональным руководителям. Это все, что связано с содержанием, можно добавлять. 

Многоцелевые проекты бывают. Бывают одноцелевой, бывает многоцелевой. Многоцелевой сложнее сделать, чем одноцелевой. Это одно. Второе. Критерии сложности, связанные с ограничениями. У проекта есть дополнительные жесткие требования внешней среды. Требования каким-то процедурам, регламентам тендерным, еще каким-то и так далее. 

Жесткие ограничения по срокам (вы могли бы легко этот проект сделать за два года, а вам надо его сделать за год). Соответственно, вам нужно очень сильно запараллеливать. Как только вы запараллеливаете – у вас сложность принятия решений резко повышается.

Что еще очень важно (я бы это в отдельную категорию) – это степень уникальности. Насколько вы раньше делали такой проект? Нет, не делали – для вас сложнее. Насколько вообще в вашей компании кто-то похожие проекты делал? Никто не делал – сложнее. Насколько вообще в России… 

Уровень уникальности очень важно уметь оценивать. Есть целая классификация проектов по разным срезам, с точки зрения уникальности. Это накладывает тоже серьезные дополнительные требования на процесс управления. Это если кратко.

Реплика из зала: Вопрос вам как президенту Ассоциации. Вы не наблюдаете тенденцию, что современному менеджеру требуется не только управленческая… Зависит успех проекта как успех продукта. Получается, это знать и предметную область, и успех продукта на рынке. Как бы не ассоциировали… Видите ли вы тенденцию, что есть со стороны заказчика доверие к области как к продуктовому менеджеру? Реклама, анализ конкурентов и прочее.

Алексей Полковников: Ответ: да. Такая тенденция жестко прослеживается. Если раньше менеджер проекта – исполнитель. Он сдал продукт в срок в рамках бюджета – молодец, получил премию. 

Сейчас заказчик не хочет брать на себя риски, связанные с тем, что тот продукт, который он создал, еще будет продаваться, эффективно работать и так далее. Основные проблемы начинают всплывать, когда продукт сделан, когда он начинает эксплуатироваться. Кто-то должен это все дорабатывать.

Это зависит сильно от отрасли. Я думаю, для IT-проектов это очень сильно играет роль, в других отраслях, может быть, в меньшей степени. Но есть и реальный сектор, когда мне руководство компании говорит: "У нас менеджер проекта отвечает от идеи, монтаж оборудования, потом еще полгода должен поработать в позиции начальника цеха, чтобы вывести все это на нормальное функционирование – тогда только получает свою премию". В IT это 100%.

Менеджеры проекта не очень любят, когда на них вешают дополнительную ответственность без того, чтобы давать понятную мотивацию эту ответственность брать на себя. Заказчику это очень правильно понимать: до какой точки отвечает менеджер проекта. Плюс это меняет систему мотивации менеджера проекта. Такая тенденция есть 100%.

Реплика из зала: Вопрос неразборчиво. 

Алексей Полковников: Вы должны написать, во-первых, список своих проектов (в которых вы участвовали за предыдущие пять, шесть, три года – в зависимости от того, на какой вы идете уровень), чем вы занимались, какой получен результат и телефон или адрес того, кто это может подтвердить – заказчика проекта. Это формальное подтверждение, но выборочно могут проверить. Скажем так, один из ста случаев проверяют.

Естественно, вы пишете правду. Вспоминая, как это было пять лет назад – это выглядит красиво обычно.

Реплика из зала: Вопрос неразборчиво. 

Алексей Полковников: Часы берутся из головы. 

Так, по-моему, я занимался планированием 50 часов. Похоже на правду. Тогда организация исполнения, скорее всего, 500 часов. Организация исполнения больше планирования в 10 раз обычно. Примерно. Все примерно.

Мужской голос: Спасибо.

Мужской голос: Большое спасибо. Мы готовимся к следующему докладу. Если вопросы есть, можно в кулуарах задать.

Алексей Полковников: Спасибо.

 

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Александр Горник

Александр Горник

Окончил факультет Кибернетики МИФИ, 7 лет опыта работы в индустрии. Несколько десятков успешно выполненных проектов как в роли разработчика, тим-лида и архитектора, так и как PM.

Как посчитать реальные финансовые показатели разработки в условиях множества проектов? Ценообразование и финансовая модель.

Дмитрий Тарахно

Дмитрий Тарахно

В Webprofiters руководит проектированием и разработкой сайтов, занимается технической частью аналитических проектов. До прихода в компанию в течение 6 лет работал в ряде софтверных компаний и системных интеграторов (ЛАНИТ, Upscale Soft, Optima) на проектах по разработке и внедрению корпоративных информационных систем федерального масштаба.

Доклад о систематизации опыта в области того, как жить с клиентами, с которыми мы уже начали работать, чтобы не было нам самим печально. Интересно это будет компаниям, которые оказывают какие-то услуги – консалтинг, разработка и т.п.

Андрей Пантюхин

Андрей Пантюхин

В 2010–2012 построил Dream Industries в качестве первого CTO. Последние годы работает с ранними стартапами в России и за рубежом над продуктом и стратегией роста.

Андрей Пантюхин рассказывает об особенности работы с сообществами Open Source с применением коммерческого подхода.