Project management: определяем вашу крутость!

Меня давно просили написать про качества и умения проектных менеджеров в применении к уровням seniority. Пришло время об этом поговорить!

Осторожно! Длинный и очень специализированный пост для тех, кто в теме.

Вводная

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

Учитывайте, во многих случаях проектный менеджер это еще и scrum master или business analyst. Специальные вопросы по этим компетенциям не входят в scope этого поста.

Вхождение в профессию

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

Почти не важно откуда вы пришли и чем занимались до этого. IT-шный background важен и очень поможет, но есть много случаев успешных управленцев, кто только вчера пришел из психологии, HR или журналистики. Найдите себе ментора и активно учитесь, а практика добавит знаний со временем.

Проектный менеджер это

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

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

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

Итак, список без приоритезации:

• Может донести вижн продукта и компании в команду. И убедить почему это важно для команды
• Имеет влияние на принятие решений внутри команды
• Знает фазы формирования команды и может предпринимать шаги для эволюции команды. Storming-norming-performing и вот это все. Оно правда работает!
• Уточняет роли и ответственность между членами команды если есть сложности
• Распознает индивидуальный вклад членов команды и общие достижения
• Знает кому дать задачу или у кого спросить
• Знает какие задачи нельзя делегировать в условиях отдельно выбранной команды / продукта
• Способен проконтролировать выполнение задач в рамках одной команды и поставить задачу наружу когда надо
• Фокусируется на решении проблем отдельно взятой команды
• Способен следовать существующим процессам управления изменениями
• Способен отследить зависимости между требованиями после того как их определит команда
• Способен составить краткосрочный project timeline и скоммуницировать с основными заказчиками
• Фасилитирует идентификацию рисков и может их дальше отследить. Знает атрибуты рисков и способы что с этими рисками дальше делать. Mitigation - accept - transfer и все остальное
• Составляет проектную документацию по существующим шаблонам
• Понимает и может посчитать метрики качества того что делает команда. Сюда же про метрики из Agile
• Учитывает эмоциональную составляющую в коммуникациях
• Может выявить ожидания заказчика от процессов и результата работы команды
• Знает разные методологии и их применимость: Scrum / Kanban / Scrumban/ PMP практики / SAFe / LESS / PRINCE2 / что там еще понаизобретали
• Регулярно и понятно отчитывается по проекту, хотя бы по существующему шаблону
• Может скоординировать командировку, в том числе к внешнему заказчику
• Может внедрить улучшения процессов, которые набрейнштормил с командой
• Способен скоординировать UAT и выкатку нового сервиса в прод + post-production support, скорее всего с консультацией команды
• Может перевернуть конфликт из эмоционального в конструктивное русло
• Обладает навыками переговорщика. Желательно позаниматься переговорными поединками.
• Внешне спокоен даже когда паника и мы в огне
• Команда до 10 FTE (человеко- единиц на фултайме)
• Ведет проекты в разных фазах. Не ожидается опыт управления полного цикла. Закрывал и начинал проекты - получи плюсик в карму
• Знает разные техники оценки проектов и способен объяснить разницу. Story point / человекочасы / PERT / уверенность к дате / футболки и все остальное
• Держит команду сфокусированной на общей цели и не позволяет растекаться мыслю по древу
• Ему нужен регулярный супервижн на тему что он делает и как, хотя бы для моральной поддержки

Хочу промоушн!

Итак, вы поняли что уже можете все что описано выше и вам даже не сложно. Или кажется что хочется лычку Senior помидор. Или меняете работу. Или денег захотелось за выслугу лет. Ниже критерии для Senior Project Manager.

Warning! От компании к компании требования к синьорам будут меняться. Ниже описано скорее среднее по больнице. Кстати, часто ожидается что Senior управляет еще и людьми. На практике это не всегда обязательно, но может меняться от конторы к конторе.

Список в дополнение к предыдущему:

• Имеет влияние на принятие решений еще и заказчиками. Особенно актуально для аутсорса!
• Вдохновляет команду на инновационные идеи
• Знает как построить команду из разношерстной группы
• Непрерывно анализирует перформанс команды и находит точки роста
• Способен развивать poor performers даже если ими напрямую не управляет.
• Может передоговориться про сроки и бюджеты или поменять коней на переправе, без ущерба репутации команды. Сюда же про переубедить заказчика бежать в неправильную сторону.
• Определяет критерии успеха достигнутых договоренностей = как мы поймем что цель достигнута. Это не так просто как кажется!
• Избегает прогнозируемых конфликтов
• Определяет ресурсы, необходимое оборудование, материалы и людей, нужное в будущем
• Управляет активностями, затрагивающими внутренних и внешних stakeholders, а не только одного продуктолога и полтора заказчика.
• Делегирует с учетом индивидуальных планов развития членов команды, а не просто вбрасывает задачи. Может делигировать проектно-менеджерские задачи если кого-то выращивает.
• Контролирует выполнение задач в том числе за пределами своей команды и может предусмотреть сценарии задержек
• Часто у него уже больше одной команды, но он все еще может погрузиться в детали когда надо
• Фокусируется на решении проблем за пределами команды и способен влиять на внешних для конторы заказчиков
• Способен создать с нуля процессы управления изменениями и разбора косяков
• Способен определить метрики для backlog monitoring, тестирования, перформанса команды и чего-нибудь еще
• Способен определить зависимости между требованиями самостоятельно. Исключение: если менеджер нетехнический, а проект очень технический, но об этом мы поговорим отдельно.
• Способен оценить проект не только про срок, но и про бюджеты. Понимает что такое P&L и способен его как минимум прочитать
• Способен составить project timeline долгосрочно и скоммуницировать изменения чтобы не больно
• Способен определить риски scope, schedule, budget and resources, дополнить их с командой и регулярно отслеживать их вероятности. В деньгах тоже может посчитать (хотя почему-то это очень редко реально нужно)
• Составляет проектную документацию по шаблонам, придумывает шаблоны и может аргументированно выбрать нужный именно этому проекту набор документов. Это не про бизнес-анализ!
• Делает онбординг документы для команды / проекта и менторит новичков
• (Если технический менеджер) Может аргументированно обсудить с тест-лидом вопросы качества и метрики. И поговорить с техлидом про архитектуру
• Emotional intelligence всегда и везде
• (Если управляет людьми) Мотивирует подчиненных с учетом их долгосрочных целей
• Обсуждает нужные и потенциальные ротации людей в команде и имеет на них влияние
• Может определить разницу ожиданий заказчиков и реальности, а затем ее починить
• Может выбрать и внедрить методологию, подходящую именно для этого проекта
• Настраивает процессы репортинга по проекту, в зависимости от аудитории
• Может обосновать командировку / закупку оборудования / бонусы команде
• Способен придумать и внедрить процессы как выкатывать сервис в прод и потом поддерживать
• Участвует в pre-sale, RFP / RFI, может написать scope statement или SoW
• Может аргументированно предугадать последствия действий и решений команды / заказчика
• Отслеживает особенности аудитории и может по-разному вести себя. Пример: суровые олдскульные stakeholders из Англии требуют совершенно другого подхода чем архитектор из соседней команды
• Формулирует критерии принятия решений в зависимости от ситуации
• Примерно три года опыта и команда 7-25 FTE, но это зависит от сложности предыдущего опыта
• Управлял проектами полного цикла и на всех фазах
• Способен выбрать способ оценки и единицы измерения для проекта в зависимости от ситуации
• Ему уже не нужен регулярный супервижн, но он придет с вопросами сам когда приспичит

Если здесь вам показалось что вы уже все умеете, не спешите с выводами, а поотвечайте на вопросы ниже. А лучше обсудите свои ответы с более опытным коллегой. Большинство менеджеров переоценивают свои навыки!

Вопросики

Для проверки всего этого у меня выработался набор вопросов. Часть подходит только для собеседований, часть - только для комитетов на промоушн. Однако если у вас получится переформулировать вопросы в микро-кейсы, вы сможете понять как человек думает. А это - самое важное в оценке "тянет vs не торт". Перед тем как оценивать ответы, как можно четче сформулируйте кто вам нужен. Иначе будет очень субъективно.

На большую часть вопросов нет правильных ответов и это прекрасно. У нас тут творчество, а не по учебнику!

1. Как вы обрабатываете change requests если у вас Agile, а проект с внешним заказчиком?
2. Чем fix-price проект отличается от time&materials, с точки зрения проектного управления? Какие единицы измерения и методику оценки примените для fix-price проекта?
3. Для какого проекта вы бы применили оценки в человеко-часах, а когда story points? Почему? Как это было в вашей практике?
4. Что делать если заказчик игнорирует ваши сообщения / не принимает решение по важному вопросу? Осторожно, это вопрос со звездочкой и эскалация это ответ джуниора.
5. Почему отчеты по проекту это важно? Зачем они нужны? Как вы строите практику проектной отчетности у себя и почему именно так?
6. Как вы знаете что проект on track и зеленый? Универсальный маркер проверки на seniority, обожаю этот вопрос
7. Что такое успешный проект? Как вы поймете что он успешный? Приведите пример своего успешного проекта?
8. Приведите пример stakeholders вашего проекта и опишите их интересы. Как вы управляете их ожиданиями?
9. Какой самый сложный конфликт вы решили? Почему он сложный?
10. Пример хорошей и плохой эскалации из вашей практики?
11. Какие стратегии реакции на риски вы применяете на нынешнем проекте и почему?
12. Как вы считаете риски в цифрах? Почему и когда этого делать не нужно?
13. Как используете роадмапы на Agile проектах?
14. Возможно ли использовать Agile на fix-price проектах и почему?
15. Что такое SAFe и на каком проекте вы бы его применили? Какие метрики уникальны для этой методологии? (задавайте вопросы про SAFe только если это релевантно - не все должны его знать)
16. Что будете делать если член команды демотивирован скучными для него, но обязательными для проекта задачами?
17. Какая основная проблема с распределенными командами и что с этим делать чтобы было не так больно?
18. В чем разница управления командой на 5 и 25 человек? Какой ваш опыт?
19. Как справиться с культурными различиями в команде / с заказчиками?
20. Какие задачи вы никогда не делегируете и почему?
21. Что такое follow-the-sun концепт в контексте распределенных команд?
22. Какая ваша основная проблема с неформальным лидерством в команде и что вы с этим делаете?
23. Вы управляете четырьмя командами с проектами, которые все длятся примерно год и сейчас находятся в разных фазах. Как будете планировать ротации между ними, особенно для технических лидов?
24. Какой ваш опыт работы с бюджетами проекта и P&L? Если да, то какие пути снижения стоимости ресурсов вы знаете? Сюда же: как вы поймете что ваш P&L зеленый?
25. (Аутсорс онли) Опишите жизненный цикл контракта в вашей компании. Где и как вы вовлечены? Сюда же: что вы включите в SoW? Почему?
26. Какие основные метрики для проекта с фиксированным бюджетом?
27. Опишите разницу между проектными и командными метриками?
28. Представьте что вы завтра начинаете новый проект. Вам спустили сверху дедлайн и если его завалить, контора попадает на деньги. Ваши действия в первые две недели? Вы не участвовали в оценке проекта.
29. Ваши действия когда нужно набрать людей в команду на новый проект?
30. Какие цели у project kick-off meeting? Другими словами, что нужно сделать на старте проекта?
31. Ваши действия при закрытии проекта? Разница в процессе закрытия проекта если продукт запустили / проект просто отменили?

Я стар. Я супер-стар.

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

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

Всегда есть зоны роста. Вопрос только когда вам надоест. Мне вот надоело спустя 10 лет. Часто бывает что проектник уходит в Delivery и там доучивается про домен / аналитику / технарство / что там у вас. Бывает, уходят в продакты и там учатся совсем другому.

Однако навыки проектного управления что одной, что десятком команд очень полезны. Даже если вы не планируете становиться директором проектного офиса, навыки из этого текста вам пригодятся. Хотя бы просто навести порядок в календаре и голове.

Что там за горизонтом?

Я не описываю критерии / атрибуты для супер-опытных директоров и программных менеджеров. Потому что как вы могли догадаться, там все то же самое. Разве что повышается уровень абстракции и усложняются политические игрища. Ну и руки по локоть уже не засунуть, все сплошные презентации да и только. И митинги. Конечно, куда же без них!

Выводы

А не будет их. Вы просили длиннопсто - я написала. Давайте обсуждать. А то вдруг бабушка Юля оторвалась от реальности и оно все совсем не так.

Этот пост закрыт от внешнего мира, что-то не хочется бесплатно делиться в этот раз :)