Публикации об экзаменах и новостях менеджмента

Профессиональная оценка для ПМа

Как оценивать навыки ПМа

Очередная статья цикла по организации процессов и по менеджменту в ИТ. Сперва мы говорили как измерять эффективность в ИТ. Затем - сфокусировались на роли менеджера (для большей сложности выбрали продуктовую компанию как пример). Продолжим цикл. Попытаемся определить какими качествами должен обладать в нашей компании этот самый менеджер (чтобы быть эффективным).
Расскажу на кейсе. Приведу реальный алгоритм оценки скиллов для менеджера, которым я пользуюсь в текущей компании, будучи Head of PM, чтобы:
  • Лучше понять кого ищем (и что не забывать проверять на собеседованиях), какие качества хотим развивать в коллегах (на чем не забывать акцентировать при ассессменте)
  • Сформировать “портрет” каждого менеджера и понимать с какой категорией проектов/продуктов и в каких командах он лучше справится
  • Помогать менеджеру с его зонами роста
  • Если захотим (опционально) - можем увязать результаты ассессмента с грейдами и повышением зарплат. Примечание: тут надо быть осторожным, грейды в ИТ сравнительно “хрупкая” тема
Дисклеймер
С 2012 я Head of PM (product & project management), Head of Delivery. Эта работа предполагает не только постановку процессов, но и формирование крепкой “команды менеджеров”. Для этого мне нужно уметь объяснять коллегам-менеджерам чего мы от них ждем, 1:1 проводить с каждым периодическую оценку его скиллов и сформировать план развития, помогать прокачиваться. Иногда меня привлекают и к оценке менеджеров как стороннего эксперта или для помощи в собеседованиях на топовые позиции. Постепенно у меня сложилась насмотренность - как результативно проводить подобные оценки и как не стоит это делать.
Подход и чек-лист использовался в очень похожем виде в двух компаниях где я работал (в одной использовался для 12 входивших в проектный офис продекжтов, в другой для ≈25).

А как делать не надо - мой опыт

Антипаттерн 1. “На глазок”

Отталкиваться лишь от убеждения что хороший руководитель отлично знает своих сотрудников и запросто скажет “кто из них тут middle, а кто senior” не стоит по двум причинам:
  • Склонность к когнитивным искажениями. Уж кто-кто, а менеджеры прекрасно знают как люди в команде, другие менеджеры и прочие стейкхолдеры “переобуваются в воздухе”, принимают решения на эмоциях, и/или судят о сотрудничестве по последним инцидентам. Хотите быть объективным? Напишите список важных навыков для любого вашего ПМа на бумажке и приучит себя прежде чем вынести суждение проходиться по нему.
  • Грибной метод. Этот термин упоминает Итан Рассел в “Метод МакКинзи”. Суть: чтобы грибы хорошо росли их надо покрыть навозом и оставить в темноте. Проблема в том что с людьми грибной метод не работает (нужно совсем противоположное). Подход “на глазок” едва ли понятен вашим сотрудникам также хорошо как и вам. Даже если аргументируете свою точку зрения, вы все равно не оставляете им надежной системы координат. Есть набор критериев? Зафиксируйте его и оба (вы и сотрудник) следуйте перечню при каждой оценке.
Подчеркну что метод “на глазок” годится когда вы только делаете первые шаги в компании и нужно “быстрое решение”.

Антипаттерн 2. “Мы щас PMBoK возьмем”

Хуже чем метод “на глазок” может быть только оттолкнуться от максимально абстрактного списка навыков, возможно не подходящего вам - в котором возможно не уверены вы сами, и логику которого не понимают и не разделяют сотрудники.
Краш тест для списка навыков 1: если в вашей менеджерской команде люди будут обладать именно этими скиллами (и не будут обладать всеми остальными которые в списке не перечислен) - станете ли вы как хед менеджеров абсолютно счастливы и спокойны?
Краш тест 2: вспомните своих самых сильных руководителей проектов, деливери менеджеров и прочих - тех что на голову сильнее остальных. Они бы получили высокую оценку оценку в вашем опроснике? Насколько заметно их оценки выделялись бы на фоне других “просто достаточно хороших” менеджеров? Можно заметить “бриллиант” только по этим оценкам? Или в теории руководитель может так пройти опросник что превзойдет проджектов которыми вы дорожите больше всего? Если так, то список релевантных навыков у вас пока не получился - вы проверяете им не то что действительно ищете в людях.
Не все что описано в PMBoK (или любом другом стандарте) нужно чтобы хорошо управлять проектами в вашей компании. И наоборот, некоторые действительно важные вещи, специфичные для вас там не описаны (см. краш-тест выше).
Чтобы работать дальнобойщиком не обязательно знать как работает двигатель внутреннего сгорания. Впрочем если ваша работа связана с риском поломок в безлюдных краях - возможно базовые навыки “как согреть замерзшее масло”, “как оживить сдыхающий генератор и помочь ему дотянуть до сервисного пункта” могут вам пригодиться. Но они нужны не всем. Для других дальнобойщиков важнее будет навык выбирать маршрут, подгадывать “тайминг” проезда через крупные города, заранее договариваться о погрузке и разгрузке и вообще умение чередовать езду и отдых так чтобы добираться до пункта назначения безопаснее и эффективнее.
Если вы вынашивали мысль (позвольте я максимально ее утрирую): взять оглавление / перечень доменов из “PMBoK” любой редакции и за 15 минут получить список скиллов на проверку - не делайте так. PMBoK - отличный справочник, плохой учебник, но главное - это своеобразный “супермаркет” хороших практик в управлении. Своего рода россыпь подходов, инструментов, алгоритмов. Нецелесообразно “прокачивать” в менеджерах все то что изложено на страницах PMBoK (от управления закупками до метода освоенного объема (EVA) имитационного моделирования в риск-менеджменте).

Как нам структурировать оценку?

Окей, как не надо обсудили. А как стоит оценивать проджектов? Опишем пару ограничений.

Ограничение 1. В оценках менеджеров мы вынуждены быть субъективными

Анализируя уровень шахматиста или футболиста, можно опираться на статистику сыгранных партий / матчей, на количество эффективных передач, скорость с которой он возвращается в штрафную или прорывается к воротам, число “ассистов” и т.п. Безусловно есть и нематериальные (intangible) характеристики - отношение к партнерам по команде, умение быть лидером на поле и т.п. Но в спорте нам проще привлечь математику на помощь.
С менеджером, в эпоху когда больше половины сотрудников проводит в одной компании не больше 2-3 лет - мы часто не имеем возможности ждать пока он завершит статистически значимое количество проектов. И в отличие от шахмат и футбола у нас нет информации о партиях и матчах сыгранных за другие сборные.
Порой цифры которые менеджеры пишут в своих резюме (бюджеты проектов, экономическая выгода или количество потраченных человеко-дней) - непроверяемы ни один NDA на свете не позволит вам раскрыть внутреннюю кухню компании, расписать детали по проектам. А главное все эти размеры и прибыльность проектов мало что говорят о реальных навыках менеджера.
Так что доверять мы можем только собственным оценкам. Важно и нужно опираться на цифры (см. статью об эффективности в ИТ), но будем готовы что не каждый навык можно оцифровать и не по каждому у нас есть достоверная статистика.

Ограничпение 2. Кто везет на том и едут

Этим (откровенно токсично звучащий) лозунгу в заголовке хочу подчеркнуть - осторожнее с показателями.
Проверьте себя. Вы согласны с тем что у сильных менеджеров проектов больший % проектов завершается в срок, не выходит за рамки бюджета и достигает целей? У крутых деливери-менеджеров запуск продуктов происходит более гладко, доставка ценности осуществляется гарантированно и без проблем. И у тех и у других срабатывает меньше рисков (благодаря проактивным действиям) а стейкхолдер гораздо больше удовлетворен сотрудничеством. Верно?
Правильный ответ - нет, не факт. Возможно, выражаясь заумно можно сказать - в большинстве компаний выборка таких наблюдений будет скомпрометирована “скиллами” сотрудника.
И я, и мои коллеги хеды / операционные директора обычно хорошо понимают пределы возможностей своих сотрудников, уровень их компетенций. Самые сложные проекты, экстремальные портфели, самые проблемные заказчики и рискованные инициативы нередко поручаются не произвольно “кому попало / кто был свободен”, а тем кому такое по зубам.
Классные проджекты (senior PM) в моих командах почти всегда ведут более сложные и рискованные проекты со сложными заказчиками. Потому что поручать такой проект middle-PM без видимой причины - это повышать риски провала.
К тому же senior PM чаще отвлекают - они помогают коллегам, активно участвуют в развитии проектного офиса, а начинающие менеджеры обычно больше сфокусированы на порученном проекте / продукте и собственных скиллах и только на этом.
Если смотреть на “голые цифры” получится что senior PM приводят проекты к завершению или продукты к успеху не чаще начинающих коллег. Но лишь потому что имеют дело с более сложными задачами и мы должны это учитывать.
К решению проблемы “кто везет на том и едут” существуют разные подходы. Кто-то добавляет каждому проекту несколько абстрактных параметров вроде “совокупная сложность”, “уровень рисков” или (реже) даже что-то типа “адекватность заказчика”.
Я чаще поступаю проще - разделю отслеживание эффектвности команд и оценку ПМов.
Организация процессов, работа с метриками, поиск корневых причин, умение работать с обратной связью, устранять блокеры, управлять ожиданиями - это все навыки и по ним я оцениваю профессионализм менеджера.
Другими словами - мы бы очень хотели чтобы во всех командах метрики были на хорошем уровне (все три группы метрик - “работы”, “комфорта” и “бизнеса” о которых писал в статье об эффективности). Но отклонения в метриках мы рассматриваем не как “менеджер плохой”, а как сигнал “в команде не все ладно. И садимся разбираться. Если причина в том что проект изначально был сложен или случилось что-то неподконтрольное менеджеру (переформатировали команду, перезапустили продукт, сменился заказчик и т.п.), то главное что имеет значения - насколько целесообразной и проактивной была реакция проджекта, насколько своевременны его усилия и бьют ли он “в цель”. А простое арифметическое число проблем (или сокращение метрик команды) напрямую на “грейд” ПМа не влияют.
Такой подход вселяет всем чувство уверенности. Опытные ПМы перестают шарахаться от сложных проектов и фокусируются на решении сложных проблем. Вместо того чтобы заниматься очковтирательством и подделывать цифры (наш CT не хуже чем месяц назад) они фокусируются на решении проблем, причем по-возможности “в долгую”. А вот уже эти навыки - основа моих грейдов.

Так как же нам оценивать проджектов?

Я вам просто покажу пример опросника. Основа для присвоения грейдов - три группы навыков. Таких которые надежно отличают опытного проджекта от “мидла” и “начинающего”.
В моем примере это:
- “hard skills” (применительно к менеджеру - это знание методологий, инструментов, техник, понимание трех ключевых подходов в ИТ-менеджменте (Scrum, Kanban и классический проектный подход), умение быстро и по делу выбирать нужный подход с учетом особенностей проекта, заказчика и команды), масштабировать, “дорабатывать напильником”, сочетать с другими
- soft skills (эмоциональный интеллект, эмпатия, лидерство, знание теорий мотивации, умение грамотно проводить 1:1, ретро, мозговые штурмы так чтобы вовлекать всю команду, владение конструктивной конфронтацией и прочее)
- общеменеджерские скиллы (знаете поговорку “менеджер и в баре - менеджер”, в том смысле что часто заметно кто может и столик забронировать, и дополнительный стул найти, и с барменом договориться, и проконтролировать что все такси себе вызовут) - иногда чрезвычайно важно чтобы проджект умел быть менеджером не только в рамках канбан-доски, но и на него можно было бы положиться при планировании командировки, в случае организации релокации коллег и т.п. Именно “общеменеджерские” скиллы - та область которая помогает “проджектам” перерасти свою роль и выйти, например, на директорские позиции. Так что мы прокачиваем и эту область тоже.
Подобное разделение на три группы скиллов можно найти во многих профессиональных источниках.
Например, PMI описывает навыки менеджера через так называемый PMI Talent Triangle. В этом фреймворке можно видеть много пересечений с моим списком ниже, правда нашей группе “общеменеджрских скиллов” в PMI соответствует Strategic & Business Management (or Business Acumen). У нее другое смысловое значение.
Я также считаю для для проджекта важно понимание бизнеса, нашего продутка, конкурентов - но в рамках ассмесента и проставления грейдов я его обычно не оцениваю. Все наши сотрудники проходят в ходе испытательного срока “онбординг”, частью которого является обретение этой самой бизнес-грамотности. Те кто не осваивается с продуктом , не понимает нашего места на рынке на должном уровне - просто не проходят испытательный срок, так что этой группой скиллов я пренебрегаю.
Вы в своей компании должны сами решить - на чем делать акцент.
PMI Talent Triangle - одна из версий:
PMI Talent Triangle - другая версия:
Итак, у нас есть три группы скиллов: hard skills, soft-skills и общеменеджерские навыки.
В каждой группе от 7 до 20 навыков (группы не должны быть симметричными, одинаковыми - я наполняю их в зависимости от компании и от того “что там болит сильнее, на чем важнее делать акцент). В разных компаниях списки навыков менеджеров будут отличаться.
Сам список (ссылку на него) я приведу в конце статьи.

Как организована оценка навыков проджекта - по шагам

Шаг 1. Один раз в год для каждого менеджера я создаю свою копию списка (этот список приватен и видеть его будем только мы вдвоем - я и коллега-менеджер кто проходит ассессмент). Сам список одинаковый для всех ПМов. Но заполнение его, обратная связь - это личное дело. Каждый ассесмент я начинаю с того что даю гарантии своему сотруднику что происходит:
  • Задача этого списка и дальнейшей работы с ним - помочь тебе сформировать представление о твоих навыках
  • Я гарантирую что никто не увидит содержание этого списка кроме нас двоих. Все что мы пишем и комментируем в этом списке - остается в этом списке. “Наружу” пойдет только грейд (и то если мы будем его определять) :)
  • Этот список - основа дальнейших планов персонального развития (обсудими что тебе стоит прокачать, чем и как я лично могу тебе помочь и чем помогут другие коллеги)
Все это помогает снять некоторый “зажим” и общаться далее более откровенно.
Шаг 2. Дополнительно собираю информацию с “заинтересованных сторон” - с членов команды, лидов, хедов, заказчиков - словом всех с кем работает менеджер и прошу дать оценку NPS (подробнее о ней писал в статье об эффективности) и добавить пару комментариев (анонимно) о том что у менеджера получается особенно хорошо (так и пишу - похвалите менеджера), что можно улучшить, +- комментарий в свободной форме - все что посчитаете нужным). Эти оценки и комменты я некоторым образом усредняют по разным группам опрошенных, анонимизирую и тоже добавляю в опросник. Часто такой фидбек помогает коллегам реалистичнее оценивать свои навыки (причем в первую очередь речь о том, чтобы не слишком “загоняться” и понять что твоя команда тебя ценит, даже если тебе сложно в это поверить).
Шаг 3. Когда список сформирован и установочная беседа проведена - выдаю доступ и прошу коллегу пройтись по каждому пункту (навыку) и оценить свой уровень. Меня интересует оценка в терминах junior, middle, senior и краткий комментарий коллеги (почему оценка именно такая). Это что называется self-assessment (самооценка). На нее дается примерно неделя. Я на этом этапе не участвую.
Шаг 4. Коллега сигнализирует когда закончит заполнять опросник. Тут начинается моя работа - напротив каждого навыка я добавляю свою оценку уровня junior, middle, senior и свой краткий комментарий. Таким образом каждый пункт списка содержит самооценку от менеджера и отметки о том как навык коллеги оценил бы я.
Шаг 5. Список навыков с оценками с двух сторон готов к работе - можно планировать 1:1 (на такую встречу скорее всего уйдет 1,5 - 2 часа). Это важнейший момент оценивания. Мы созваниваемся с коллегой, оба открываем документ и проходимся последовательно по всем пунктам. Обсуждаем каждый. Обращаем внимание совпали ли наши оценки и комментарии (если да - просто идем дальше). Расхождения - обсуждаем и аргументируем. Тут важно чтобы мы услышали друг друга и пришли к согласию. По моему опыту большинство менеджеров недооценивают себя (ставят навыки ниже реального уровня). Предполагаю что виной этому - синдром самозванца (imposter syndrome), бич профессии. Хотя примерно в 10% случаев приходится сталкиваться с противоположным явлением - выраженной переоценкой своих навыков.
Повторюсь, каждый пункт мы обсуждаем, аргументируем. Формально последнее слово остается за мной, как за более опытным экспертом и руководителем, но старюсь этим правом не золупотреблять. Очень важно чтобы коллега принял мои аргументы, согласился с ними под воздействием фактов (а не формальной власти). Если это получается (а получается почти всегда), то дальнейшее очень просто работать с выявленными проблемами, формировать планы развития.
Шаг 6. Определив текущий уровень навыка, если тот не находится на уровне senior, то мы обсуждаем “что можно сделать чтобы прокачать навык дальше”. Тут начинается моя работа как наставника. Коллега не обязан понимать, условно, что именно ему предпринять чтобы научиться лучше работать с рисками, или конструктивной конфронтацией, или лучше выступать публично (в одной из последних компаний где я работал это был значимый навык для менеджеров, ввиду того что компания активно привлекала инвестирование и уделяла большое внимание внешним и внутренним коммуникациям). Обычно я накидываю варианты как что именно можно предпринять в ближайшие полгода - год, чтобы навык вырос. И чтобы на следующем ассесменте мы бы это зафиксировали. Коллега предлагает встречные идеи и мы тут же в документе фиксируем “что выбрали”. Среди идей могут быть “командировки” в другие команды (например кто-то из коллег великолепно проводит ретро и стоит поприсутствовать на парочке таких чтобы перенять опыт), участие в каких-то доп. проектах и активности со мной как с наставником, участие в работе проектного офиса, участие в собеседовании других менеджеров проектов (чрезвычайно полезный навык для собственной прокачки и саморефлексии), прохождение тренингов и сертификаций в конце концов.
Кстати, получение сертификатов и званий я чрезвычайно поощряю, особенно с уровня middle и выше. Очень рекомендую чтобы сертификат был международным и с оптимальным балансом сложности / полезности. Многие соображения на эту тему - в статье о сертификации.
В итоге для конкретного проджекта мы получаем “индивидуальный план развития”.
Шаг 7. После этого мы повторяем встречи в очень сокращенном режиме 1 раз в квартал.
- через 3 и через 9 месяцев мы проводим буквально 20-и минутные созвоны чтобы уточнить “Как дела с индивидуальным планом развития? Что получилось? До чего не дошли руки? Что не сработало? Есть ли новые идеи? Чем еще я могу помочь?”
- через 6 месяцев мы проводим более “длинную” встречу, когда бегло пробегаемся по всем некогда проблемным пунктам и подробнее обсуждаем прогресс. В некоторых случаях через 6 месяцев уровень навыка может быть пересмотрен.
Шаг 8. Через год ассессмент полностью повторяется.
Таким образом, для команды небольшого проектного офиса, скажем, из 10 проджектов- для прохождения первого этапа оценки и составлении индивидуального плана развития мне по каждому требуется: 1 час на вычитку опросника и его комментирование + 2 часа на 1:1 встречу. В сумме (1+2)*10 = 30 часов. Т.е. 4 полных рабочих дня + 2 дня еще через пол года + небольшие усилия каждый квартал.
Словом, вполне посильная нагрузка. И главное, на мой взгляд, целесообразная. Результаты полезны в первую очередь для самого сотрудника.

Не торопитесь - сперва сработайтесь с коллективом!

На мой взгляд, провести такую оценку эффективно можно только если вы успели узнать своих коллег, понять как они работают. Важно “притереться” друг к другу на десятках митов, пройти несколько срочных ситуаций и конечно познакомившись лично (если работаете дистанционно - используйте любую возможность, не пренебрегайте “корпоративнами”).
Другими словами - если вы только что присоединились к компании и только возглавили проектный офис, я не рекомендую проводить такую оценку сразу. Мне, со всей моей насмотренностью обычно требуется 3-4 месяца, чтобы хорошо понять навыки коллег, их психотип, понять как они справляются с разными типами задач, со стрессом, с перегрузкой, с собственной командой, увидеть какие инструменты используют, выстраивают диалог и уловить отношение к ним окружающих и понять что можно менять к лучшему, а что уже сейчас особенно хорошо и надо это “не потерять”.
В противном случае люди смогут оценить себя, но вот у меня-то как руководителя и эксперта своего “ответного” мнения еще не сложилось.
Не проводите ассессмент раньше чем через 3-4 месяца после начала работы в компании, пока не узнаете лучше свою команду.

Считать ли грейды по итогам оценки?

Грейды это очень скользкая тема в ИТ. Возможно этому стоит уделить отдельную статью.
Плюсы грейдов - они позволяют задать понятные правила для зарплатных “вилок” и дать людям прозрачную мотивацию “что мне нужно сделать чтобы моя зарплата увеличилась с X до Y”.
Из минусов - грейды часто “не гибкие” и всегда имеют свой потолок.
Если в фирму очень срочно нужен middle но на рынке сейчас рост и мидлов разобрали, то что делать? Давайте дадим мидлу больше денег и таки наймем (но при этом “новые” мидлы у нас, вероятно, будут получать больше чем старые сеньоры - звучит несправедливо).
Или вот еще вызов - как вы будете мотивировать сотрудника который уже давно senior? Повысите ему зарплату выше вилки сеньора (т.е. либо сломаете свою же систему)? Либо введете дополнительный грейд (супер-синьор)? А потом что, супер-супер-синьор и так до бесконечности?
В общем система грейдов, на мой взгляд, работает только в одном случае - когда сотрудники сами считают ее одновременно прозрачной и справедливой. И не работает во всех остальных.
Не смотря на все сложности - я склоняюсь к грейдам, в них все же больше плюсов чем минусов.
На основании нашего опросника - после первого 1:1 с проджектом мы получаем документ в которым сообща определили уровень каждого из навыков.
В качестве заключения мы можем сказать, например:
  • в группе hard skills у тебя - уверенный senior
  • по части soft skills между junior и middle (это ни хорошо, ни плохо, это просто говорит что навык ты пока не прокачал, мы поможем)
  • по общеменеджерским скиллам middle

Итого, смотри, в целом ты по моим оценкам крепкий middle. Но если мы качнем “тут” и “тут”, то похоже что в течение от года до двух реально добраться до senior (смотря как пойдет, тут мы можем отдельно обсудить сколько у тебя возможностей и желания для интенсивной прокачки). Так что давай двигаться согласованным планом развития. Если что-то будет нужно - приходи. Раз в квартал я сам к тебе приду и спрошу “как дела и чем помочь”. И очень надеюсь что в горизонте 1-2 года мы с тобой после очередного 1:1 согласимся что твой общий грейд вырос до senior и пора повышать зарплатную вилку.

Пример опросника - для оценки навыков проджекта

В завершении статьи я оставлю ссылку на свой опросник (копия придет на e-mail).
Подчеркну - настоящий опросник я адаптировал к реалиям совершенно определенной компании (быстро выросшей, с замечательной командой проджектов, некоторым из них порой решительно недоставало насмотренности, а порой и просто хладнокровности). Так что я дотачивал опросник так чтобы не слишком акцентируя на тех сильных чертах что уже были у наших ребят, прокачать недостающие навыки. Словом - опросник нацелен на то чего недоставало нашей команде и написан так чтобы без дополнительных пояснений было понятно нашим же коллегам. В "чистом виде" вам он вряд ли подойдет - привожу его именно для примера (и в качестве возможного вдохновения). Думаю, что взяв за основу, вы сможете сделать такой опросник который будет полезен именно вашей команде и поможет вам как хеду развить в коллегах нужные навыки.
Обратите внимание:
- группа hard skills - синий цвет
- группа soft skills - желтый цвет
- группа общеменеджерских навыков - зеленый цвет
В нижней части списка: итого (summary) по каждой группе навыков и NPS и обобщенный фидбек от разных групп (опять же адаптировано к реалиям конкретной компании) от разных групп стейкхолдеров.

Не видите форму прямо под этой записью? Включите vpn (или напишите мне напрямую с темой "Пришлите опросник") :)

Пришлите мне pdf-экземпляр опросника для оценки навыков проджект-менеджера

 Предоставлено SendPulse
Надеюсь, статья оказалось вам полезной!
Удачи на проектах!
Иван Селиховкин: https://www.linkedin.com/in/selikhovkin/ и телеграм-канал: https://t.me/selihovkin
2024-03-05 10:46 Эффективность и ИТ-менеджмент