Полная модель компетенций слишком сложная, чтобы ее можно было использовать. Есть профстандарт, например, я неоднократно его изучала, и даже применяла в своих курсах. Но дочитать его от начала и до конца, не заснув по дороге, мне не удалось ни разу. Есть модель компетенций от PMI - там всего 30 с небольшим инструментов, и они более привязаны к реальной жизни (по-крайней мере, про людей там говорят почти столько же, сколько про процессы - в отличие от Профстандарта, где про людей максимум процентов 10). Но оценить себя по более чем 30 компетенциям - это тоже задача для усидчивых (на Продвинутом курсе мы их рассматриваем, но здесь не буду).
Сокращенная модель предполагает упрощенный взгляд на вещи. Наши маркетологи призывают меня предложить решение в формате “Ответь на 10 вопросов теста, и поймешь, насколько ты крутой руководитель проекта”. А я не могу. Потому что, честно скажем, это будет попросту говоря фикция.
Потому что проекты бывают разные, контексты бывают разные и практически ни на какой вопрос теста “как стоит вести себя руководителю проекта?” нельзя дать однозначно “правильный” и “неправильный” ответ.
Типичный вопрос из этой серии был опубликован на сайте белорусской Школы управления Алексея Минкевича. Я иногда даю его на своих курсах, и он сразу вызывает бурную дискуссию:
Вопрос. Вы руководите новым проектом по созданию продукта онлайн заказов быстрого питания. Проект имеет распределенную структуру. Одна из команд проекта находится в Новосибирске и отвечает за разработку серверной части приложения. Сегодня утром вы узнали, что два ведущих архитектора в этой команде не могут прийти к общему решению по набору технологий, которые нужно применить для построения сложной системы отчетов управленческого учета. Каждый из специалистов провел исследование и доказывает, что нужно выбрать именно его набор технологий. Сегодня утром на собрании команды разгорелись жаркие споры и в итоге собрание было сорвано. Из 8 пунктов повестки не удалось принять решение ни по одному пункту, хотя обсуждение набора технологий для отчетов вообще не входило в повестку собрания. Для решения этого вопроса наилучшим образом вы должны:
Варианты ответа:
- А. Попросить архитекторов сосредоточится на вопросах, имеющих более высокий приоритет, чем система отчетов. Напомнить им, что вопрос о системе отчетов встанет только в следующем квартале.
- Б. Поговорить с архитекторами о важности единства и командного духа, похвалить их профессионализм и снять напряженность, проведя командообразующее мероприятие.
- В. Выслушать обе точки зрения, определить лучшую из них и запустить ее в работу.
- Г. Выслушать точки зрения, понять разницу в предлагаемых решениях, попросить архитекторов обсудить вопрос вместе и помочь прийти к согласованному мнению.
Я настоятельно рекомендую тех, кто читает эту статью сначала попробовать выдать свою версию ответа и ее обосновать, и уже потом читать дальше. Так будет гораздо интереснее.
Так вот. Когда мы с руководителями проектов, как начинающими, так и опытными (повышать квалификацию приходят самые разные слушатели), начинаем обсуждать этот вопрос, каждый участник с пеной у рта начинает доказывать, какой вариант правильный.
А. Попросить архитекторов сосредоточится на вопросах, имеющих более высокий приоритет, чем система отчетов. Напомнить им, что вопрос о системе отчетов встанет только в следующем квартале.
Действительно, мы же не можем позволить себе обсуждать неактуальные вопросы! Тем более, что почти наверняка дедлайны жесткие, команда работает, возможно, в авральном режиме.
Б. Поговорить с архитекторами о важности единства и командного духа, похвалить их профессионализм и снять напряженность, проведя командообразующее мероприятие.
Важно переключить людей с больной темы, на что-то другое!
В. Выслушать обе точки зрения, определить лучшую из них и запустить ее в работу.
Это самый реалистичный из вариантов. Работать как-то надо, а уже видно, что договориться у участников не получается. А руководитель проекта скорее всего наиболее компетентен из членов команды.
Г. Выслушать точки зрения, понять разницу в предлагаемых решениях, попросить архитекторов обсудить вопрос вместе и помочь прийти к согласованному мнению.
С точки зрения авторов теста, именно этот вариант ответа является правильным.
Аргументация: здесь мы предлагаем участникам прийти к консенсусу, то есть найти решение, которое устроит обе стороны. Как гласит первый закон фасилитации (да простят мне это ругательное слово), люди гораздо охотнее реализуют решения, проработанные и принятые с их участием. Поэтому вариант “найти решение проблемы” (Г) оказывается более выигрышным, чем А (уклонение), Б (сглаживание), В (принуждение). Вариант А, на самом деле, выглядел бы логичным (если проблема правда встанет только в следующем квартале), если бы не одна деталь в тексте: “Из 8 пунктов повестки не удалось принять решение ни по одному пункту, хотя обсуждение набора технологий для отчетов вообще не входило в повестку собрания” - команда уже потеряла работоспособность, ждать следующего квартала не вариант.
Пожалуй, я согласна с тем, что последний вариант наиболее выигрышный (если он сработает - честно скажем, гарантии совсем нет). Но, повторюсь, я легко могу представить себе контекст, в котором скорее сработают другие варианты ответа. И так будет с практически любым вопросом по существу управления проектами. Разумеется, если не брать вопросы типа “Что относится к принципам Скрам?” или “Какие процессы в управлении рисками выделяет 6-ой PMBOK Guide?” которые прямо не проверяют умение решать рабочие задачи.
Но наглядную модель компетенций сделать все-таки хочется. Конечно, сразу предупреждаю, что она будет упрощенной и неоднозначной. Важно понимать все ограничения такого упрощенного теста - что он описывает не все ситуации. Но по принципу Паретто “80 на 20”, полагаю, что в 80% он все-таки попадет. То есть в большинстве случаев позволит отличить чайника от профи.
И в предложенной модели компетенций я предлагаю танцевать от проблем, которые возникают, и инструментов, которыми вы владеете для решения указанных проблем.
В чём фокус?
Поскольку (как утверждал Козьма Прутков) нельзя объять необъятное, то важно понять, в каких сферах компетенции стоит развивать в первую очередь. И для этого нам важно понимать, с какими проблемами вы сталкиваетесь в первую очередь. Например, у кого-то самая больная тема - это конфликты в команде проекта. А у кого-то - пользователи, которые не готовы к сотрудничеству. Или разрастание требований подобно снежному кому.
Потому что это тоже не будет универсальным ответом, в каждом контексте и у каждого руководителя проблемы будут свои.
Поэтому в предлагаемом тесте я предлагаю делать следующее:
Определить, какие проблемы являются самыми больными
Оценить, насколько с какими проблемами вы умеете справляться и какими инструментами в этой сфере владеете
Сравнить первое и второе.
В качестве основы модели я взяла 8 доменов исполнения из 7-ого PMBOK Guide (Руководство к Своду знаний по управлению проектами).
В качестве вариантов - путь развития джедая:
- Младший джедай
- Падаван
- Рыцарь-джедай
- Мастер джедай
А в качестве проблем - то, с чем сталкиваются многие руководители проектов. В частности:
Команда
- В команде не очень понятно, кто за что отвечает
- Люди разбегаются из команды
- Конфликты в ходе работы
- Информация теряется в ходе работы
- Новые лидеры не вырастают, команда требует микроменеджмента
- Люди незамотивированы в проекте
- Обмена знаниями в команде не происходит
Заинтересованные стороны
- Бизнес-заказчик не доволен результатом проекта
- По итогу понятно, что за проект вообще не нужно было браться
- Проекту вставляют палки в колеса
- Пользователи не заинтересованы во внедрении
- Пользователи не готовы ставить требования
- Конфликты между бизнес-заказчиком и разработчиками
- Разные ожидания у разных участников
Подход к управлению проектом и жизненный цикл проекта
- Происходит много отклонений от составленного в начале подробного ТЗ
- Приходится делать много лишней работы из-за смены требований
- Проект не укладывается в сроки и бюджет
Планирование
- План проекта не соответствует действительности
- Проект выбивается из расписания
- Проект не укладывается в бюджет
- Возникают конфликты из-за ресурсов
Измерение
- Не очень понятно, на какой стадии какие работы находятся
- Одни и те же ошибки повторяются по несколько раз
- Отчеты содержат недостоверную информацию
Работы по проекту
- Не всегда понятно, какие задачи уже выполнены, а что еще нужно сделать
- Люди перегружены задачами
- Результат оказывается несогласованным
Поставка
- Требования нарастают как снежный ком
- Заказчикам не нравится результат даже когда их требования выполнены в полной мере
- Заложенным в системе бизнес-процессам потом никто не следует
- Результат оказывается никому не нужным, так как выдается слишком поздно
Риски
- Про риски никто не задумывается, пока они не наступят
- Бюджет и расписание рассчитаны на идеальную ситуацию, и не содержат резервов на случай, если что-то пойдет не так
- Проект плохо выдерживает выбывание кого-то из членов команды
В качестве формы проведения - мы взяли лепестковую диаграмму.
Указываешь, какие проблемы наиболее актуальны, какие из них умеешь решать, какими инструментами в каждой сфере владеешь. И, ву-а-ля - получаешь картинку.
Вот, например, видно, что у РП из этой диаграммы всё круто с работой, планированием и поставкой, но полный провал с умением управлять рисками. И так далее…
А теперь интрига - а где же сам тест? А его мы пришлем по итогам участия в открытом вебинаре. Вот ссылочка на вебинар, записывайтесь.
Почему так? Потому что я не случайно прожужжала всем уши про прототипы и инкрементную поставку. И на вебинаре мы еще раз отточим предлагаемую схему - те проблемы, которые возникают по итогам совместного обсуждения. Чтобы результат получился логически законченным.
Но если вам интересно не дожидаясь вебинара - тоже есть вариант. Выступить в качестве бета-тестера первой версии теста.
Для этого оставьте в комментариях самую больную проблему, с которой вы сталкиваетесь на проектах (не повторяя то, что уже было озвучено ранее). И 10 комментаторов, первыми оставивших свои примеры проблем, получат первую версию теста. Чтобы построить свою лепестковую диаграмму, и понять - как у вас-то с управлением проектами?
