Каталог решений - Тест для самопроверки руководителя проекта: как отличить падавана от рыцаря-джедая?

Полная модель компетенций слишком сложная, чтобы ее можно было использовать. Есть профстандарт, например, я неоднократно его изучала, и даже применяла в своих курсах. Но дочитать его от начала и до конца, не заснув по дороге, мне не удалось ни разу. Есть модель компетенций от PMI — там всего 30 с небольшим инструментов, и они более привязаны к реальной жизни (по-крайней мере, про людей там говорят почти столько же, сколько про процессы — в отличие от Профстандарта, где про людей максимум процентов 10). Но оценить себя по более чем 30 компетенциям — это тоже задача для усидчивых (на Продвинутом курсе мы их рассматриваем, но здесь не буду).

Сокращенная модель предполагает упрощенный взгляд на вещи. Наши маркетологи призывают меня предложить решение в формате “Ответь на 10 вопросов теста, и поймешь, насколько ты крутой руководитель проекта”. А я не могу. Потому что, честно скажем, это будет попросту говоря фикция. 
Потому что проекты бывают разные, контексты бывают разные и практически ни на какой вопрос теста “как стоит вести себя руководителю проекта?” нельзя дать однозначно “правильный” и “неправильный” ответ. 
Типичный вопрос из этой серии был опубликован на сайте белорусской Школы управления Алексея Минкевича. Я иногда даю его на своих курсах, и он сразу вызывает бурную дискуссию:

Вопрос. Вы руководите новым проектом по созданию продукта онлайн заказов быстрого питания. Проект имеет распределенную структуру. Одна из команд проекта находится в Новосибирске и отвечает за разработку серверной части приложения. Сегодня утром вы узнали, что два ведущих архитектора в этой команде не могут прийти к общему решению по набору технологий, которые нужно применить для построения сложной системы отчетов управленческого учета. Каждый из специалистов провел исследование и доказывает, что нужно выбрать именно его набор технологий. Сегодня утром на собрании команды разгорелись жаркие споры и в итоге собрание было сорвано. Из 8 пунктов повестки не удалось принять решение ни по одному пункту, хотя обсуждение набора технологий для отчетов вообще не входило в повестку собрания. Для решения этого вопроса наилучшим образом вы должны:

Варианты ответа:

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

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

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

А. Попросить архитекторов сосредоточится на вопросах, имеющих более высокий приоритет, чем система отчетов. Напомнить им, что вопрос о системе отчетов встанет только в следующем квартале.
Действительно, мы же не можем позволить себе обсуждать неактуальные вопросы! Тем более, что почти наверняка дедлайны жесткие, команда работает, возможно, в авральном режиме.
 
Б. Поговорить с архитекторами о важности единства и командного духа, похвалить их профессионализм и снять напряженность, проведя командообразующее мероприятие.
Важно переключить людей с больной темы, на что-то другое!

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

Г. Выслушать точки зрения, понять разницу в предлагаемых решениях, попросить архитекторов обсудить вопрос вместе и помочь прийти к согласованному мнению.
С точки зрения авторов теста, именно этот вариант ответа является правильным. 
Аргументация: здесь мы предлагаем участникам прийти к консенсусу, то есть найти решение, которое устроит обе стороны. Как гласит первый закон фасилитации (да простят мне это ругательное слово), люди гораздо охотнее реализуют решения, проработанные и принятые с их участием. Поэтому вариант “найти решение проблемы” (Г) оказывается более выигрышным, чем А (уклонение), Б (сглаживание), В (принуждение). Вариант А, на самом деле, выглядел бы логичным (если проблема правда встанет только в следующем квартале), если бы не одна деталь в тексте:  “Из 8 пунктов повестки не удалось принять решение ни по одному пункту, хотя обсуждение набора технологий для отчетов вообще не входило в повестку собрания” — команда уже потеряла работоспособность, ждать следующего квартала не вариант.

Пожалуй, я согласна с тем, что последний вариант наиболее выигрышный (если он сработает — честно скажем, гарантии совсем нет). Но, повторюсь, я легко могу представить себе контекст, в котором скорее сработают другие варианты ответа. И так будет с практически любым вопросом по существу управления проектами. Разумеется, если не брать вопросы типа “Что относится к принципам Скрам?” или “Какие процессы в управлении рисками выделяет 6-ой PMBOK Guide?” которые прямо не проверяют умение решать рабочие задачи.

Но наглядную модель компетенций сделать все-таки хочется. Конечно, сразу предупреждаю, что она будет упрощенной и неоднозначной. Важно понимать все ограничения такого упрощенного теста — что он описывает не все ситуации. Но по принципу Паретто “80 на 20”, полагаю, что в 80% он все-таки попадет. То есть в большинстве случаев позволит отличить чайника от профи. 

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

В чём фокус?

Поскольку (как утверждал Козьма Прутков) нельзя объять необъятное, то важно понять, в каких сферах компетенции стоит развивать в первую очередь. И для этого нам важно понимать, с какими проблемами вы сталкиваетесь в первую очередь. Например, у кого-то самая больная тема — это конфликты в команде проекта. А у кого-то — пользователи, которые не готовы к сотрудничеству. Или разрастание требований подобно снежному кому. 
Потому что это тоже не будет универсальным ответом, в каждом контексте и у каждого руководителя проблемы будут свои. 

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

В качестве основы модели я взяла 8 доменов исполнения из 7-ого PMBOK Guide (Руководство к Своду знаний по управлению проектами). 

В качестве вариантов — путь развития джедая:

• Младший джедай
• Падаван
• Рыцарь-джедай
• Мастер джедай

А в качестве проблем — то, с чем сталкиваются многие руководители проектов.  В частности:

Команда    

• В команде не очень понятно, кто за что отвечает
• Люди разбегаются из команды
•     Конфликты в ходе работы
•     Информация теряется в ходе работы
•     Новые лидеры не вырастают, команда требует микроменеджмента
•     Люди незамотивированы в проекте
•     Обмена знаниями в команде не происходит

Заинтересованные стороны    

•     Бизнес-заказчик не доволен результатом проекта
•     По итогу понятно, что за проект вообще не нужно было браться
•     Проекту вставляют палки в колеса
•     Пользователи не заинтересованы во внедрении
•     Пользователи не готовы ставить требования
•     Конфликты между бизнес-заказчиком и разработчиками
•     Разные ожидания у разных участников

    
    
    
Подход к управлению проектом и жизненный цикл проекта    

•     Происходит много отклонений от составленного в начале подробного ТЗ
•     Приходится делать много лишней работы из-за смены требований
•     Проект не укладывается в сроки и бюджет

    
    
Планирование    

• План проекта не соответствует действительности
•     Проект выбивается из расписания
•     Проект не укладывается в бюджет
•     Возникают конфликты из-за ресурсов

    
    
    
    
Измерение    

• Не очень понятно, на какой стадии какие работы находятся
•     Одни и те же ошибки повторяются по несколько раз
•     Отчеты содержат недостоверную информацию

    
    
Работы по проекту    

• Не всегда понятно, какие задачи уже выполнены, а что еще нужно сделать
•     Люди перегружены задачами
•     Результат оказывается несогласованным

    
Поставка    

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

    
Риски    

• Про риски никто не задумывается, пока они не наступят
•     Бюджет и расписание рассчитаны на идеальную ситуацию, и не содержат резервов на случай, если что-то пойдет не так
•     Проект плохо выдерживает выбывание кого-то из членов команды

В качестве формы проведения — мы взяли лепестковую диаграмму.
Указываешь, какие проблемы наиболее актуальны, какие из них умеешь решать, какими инструментами в каждой сфере владеешь. И, ву-а-ля — получаешь картинку. 
Вот, например, видно, что у РП из этой диаграммы всё круто с работой, планированием и поставкой, но полный провал с умением управлять рисками. И так далее…

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

Но если вам интересно не дожидаясь вебинара — тоже есть вариант. Выступить в качестве бета-тестера первой версии теста. 
Для этого оставьте в комментариях самую больную проблему, с которой вы сталкиваетесь на проектах (не повторяя то, что уже было озвучено ранее). И 10 комментаторов, первыми оставивших свои примеры проблем, получат первую версию теста. Чтобы построить свою лепестковую диаграмму, и понять — как у вас-то с управлением проектами?