Вводные

  • Должность – руководитель проектов в IT (руководитель проектов = менеджер проектов = РП)

  • Стаж – от 5 лет (если начинать не с нуля, а, например, перейти с роли аналитика, то можно и за 3 года)

Кто я такой, чтобы говорить о подобном? Я уже 12 лет работаю в IT, из них уже более 7 лет в сфере управления проектами. Последний год занимаюсь развитием менеджеров проектов – составление индивидуальных планов развития, помощь в реализации поставленных целей, найм и адаптация новых сотрудников и тд. То есть я хорошо знаю, что нужно бизнесу, знаю, что из себя представляет рынок в сфере управления проектами в IT, и отлично понимаю, какими скилами должен обладать опытный РП, который претендует на зп 300к+.

Навыки, которыми должен обладать руководитель проектов в IT

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

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

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

  4. Менеджер должен уметь принимать правильные решения в условиях неопределенности. Сложные IT-проекты – синоним неопределенности. Не ясны требования, не ясны функциональные возможности вендорского решения, непонятно, что там у Заказчика с инфраструктурой, какие есть ограничения от смежных подразделений и тд. И во всем этом многообразии неопределенностей нужно быстро и правильно принимать решения. Много. Каждый день. Если менеджер принял неправильное решение – с него спросят. Если принял правильное – никто даже не заметит.

  5. Менеджер должен брать на себя ответственность за проект. За то, насколько он получился успешен, за то, превышен ли бюджет, за то, всё ли удалось реализовать и в какой срок, за то, доволен ли Заказчик результатом работы и будет ли продолжать с вами дальнейшее сотрудничество. Именно с менеджера спросит и руководство, и Заказчик, если что-то из перечисленного выше пошло не так.

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

  7. Менеджер должен уметь грамотно работать с рисками. В голове должны автоматом срабатывать связи между какими-то действиями и потенциальными рисками, к которым эти действия могут привести. Пример – Заказчик прислал письмо о том, что к команде присоединился новый сотрудник с их стороны. Менеджер должен сразу понимать, что от этого человека могут начать поступать новые требования, причём совершенно непонятно, в каком месте (к функционалу, к процессам, к документам, к чему угодно). Более того, у этого человека могут быть свои ожидания от результатов проекта. Это значит, что задача номер один – рассказать ему, что мы делаем, какие цели проекта, зоны ответственности и сформировать правильные ожидания. В работе с рисками главное не просто выявлять эти риски, а правильно их обрабатывать – в каком-то случае нужно предусмотреть план Б, в каком-то случае нужно сформировать правильные ожидания у Заказчика, как в примере выше, в каком-то случае принять решение потратить больше трудозатрат сейчас, чем потенциально потом потратить их в 2 раза больше, в каком-то случае своевременно эскалировать проблему и тд.

  8. Менеджер должен уметь правильно работать с ожиданиями. Это значит сделать так, чтобы картинка в голове у Заказчика совпадала с картинкой в голове у менеджера и проектной команды по всем вопросам. Если с ожиданиями не работать, то весь проект вас будут сопровождать фразы «всё фигня, переделывайте», «это вообще не то, что мы хотели», «мы думали вы эксперты, а вы делаете такую фигню» и тд.

  9. Менеджер должен обладать хорошим техническим бекграундом и техническими знаниями в своей предметной области. Во-первых, без этих знаний не получится принимать правильные решения на проекте. Во-вторых, это один из факторов, который отличает лидера, которому и команда, и Заказчик доверяют. В-третьих, менеджер должен быть в состоянии разговаривать на одном языке и с командой, и с представителями Заказчика. Любое отсутствие главного технического специалиста на проекте не должно тормозить проект, и менеджер должен в состоянии один провести встречу с Заказчиком и объяснить ему какое-нибудь техническое решение (тут в пределах разумного, конечно). Или наоборот, задать нужные вопросы для уточнения требований. Также технически подкованный менеджер может сразу на этапе идеи обосновать Заказчику возможность реализации того или иного функционала, а не тратить время на уточнение такой возможности у технических специалистов.

  10. Менеджер должен понимать, где у Заказчика «болит» и как ему в этом помочь. Это значит уметь правильно собирать требования, обрабатывать их, находить пути решения проблем, описывать их, рассчитывать стоимость и защищать. Другими словами, участвовать в пресейле и расширять присутствие в Заказчике.

    (в пресейле, конечно, работают не только РП)

  11. Ещё один из немаловажных софт скиллов руководителя проекта – проактивность. Это значит предотвращать пожары, а не тушить их. Появился вопрос, что-то непонятно, появился риск, требуется согласование – сразу действуешь. То есть не тогда, когда появилась возможность спросить, риск реализовался, а согласование требований уже просрочено, а заранее. Звучит просто и логично, но этим навыком обладает меньше 20% менеджеров (среди других ролей этот процент ещё меньше).

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

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

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

  15. Требование о «стрессоустойчивости» в описании вакансии на должность руководителя проектов – не дань моде. Менеджер отвечает за весь проект, с него спрашивает и руководство, и Заказчик (см. п.5), а ресурсов для реализации всегда не хватает (см. п.6). А ещё в условиях такого перманентного стресса надо правильные решения принимать, когда ничего непонятно (см. п.4). Так что уметь правильно справляться со стрессом – это рабочая необходимость.

  16. Руководитель проекта должен обеспечивать работоспособный и эффективный рабочий процесс. Понятно, что аналитик может сам собрать требование у Заказчика, и вместе с архитектором поставить задачу разработчику. А когда нужно приступить к реализации какого-то функционала? А когда нужно начать обследование и согласование требований? А как учесть, в какой момент кто из исполнителей освободится, чтобы привлечь его к той или иной задаче? Взаимосвязей в проектах очень много. Особенно, если речь идёт о длительных и сложных проектах. И именно менеджер должен отслеживать все эти взаимосвязи и делать так, чтобы команда не буксовала, работала слаженно и эффективно.

  17. Менеджер должен уметь правильно расставлять приоритеты. От этого очень сильно могут зависеть, как сроки, так и успех всего проекта. Почему сейчас инженер должен делать именно эту задачу, а тех.пис работать именно над этим документом? Как выбрать, над каким инцидентом работать в первую очередь? Как понять, почему сначала надо показать Заказчику одну задачу, а потом другую? Для того, чтобы правильно расставлять приоритеты, надо понимать весь объем задач, их взаимосвязи, ближайшие цели, понимать, что срочно и какие текущие ожидания у Заказчика, а также загрузку команды текущую и потенциальную.

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

300к в месяц – это уровень начального Senior Project Manager (около 5 лет опыта в качестве РП). Ещё более прокачанные могут получать и до 350-400к в месяц. Но обычно на этом уровне уже говорят о руководителях программ и портфелей проектов (следующая ступень после РП).

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

Что же получает работодатель за такие деньги? Если коротко:

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

  2. Заказчик останется доволен проектом и будет готов работать с нами дальше.

  3. Команда проекта не разбежится, приобретет новый опыт и никто не выгорит.

Многие считают, что РП не нужны и это бесполезная прослойка между Исполнителями и Заказчиком. Если даже после прочтения этого поста вы продолжаете считать так же, то это только потому, что у вас РП нормального не было) Подумайте тогда ещё о том, что для создания любого продукта, которым вы пользуетесь (телевизор, машина, приложение на телефоне и тп) и о котором вы читаете новости (запуск ракет Space X, создание магазинов с ИИ без кассиров и тп) был создан проект и назначен на него руководитель этого проекта. И именно руководитель этого проекта отвечал за то, чтобы этот проект был успешным.

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

Комментарии (19)


  1. BuHHTuK
    29.05.2024 06:25
    +1

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


    1. ilyagot Автор
      29.05.2024 06:25

      Я перешёл на позицию РП с нулевым знанием предметной области. Самый тяжелый был первый год - я и как РП не до конца понимал, что делать, и предметную область не знал.

      Через 3 года ушёл в другую компанию тоже на роль РП. Соответственно, тут уже было проще - опыт РП большой, но предметная область была совершенно другая. Через месяц я уже неплохо ориентировался, а через 3 спокойно проводил встречи без технических специалистов.

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


  1. CBET_TbMbI
    29.05.2024 06:25

    И почему, увидя заголовок, я ждал ссылки на канал...

    И где ответ на вопрос "Как руководителю проектов зарабатывать от 300.000 в месяц".

    Я вижу только требования к его навыкам. Ну, так и назвали бы статью "Каким должен быть РП, чтобы претендовать на 300 000 ₽/мес".


    1. ilyagot Автор
      29.05.2024 06:25

      Это две крайности одной и той же сущности (с)

      Как руководителю проектов зарабатывать от 300.000 в месяц? Обладать навыками, которые перечислены в посте.


  1. kagarich
    29.05.2024 06:25
    +8

    Вот это все как средняя температура по больнице.

    Одно дело РП в заказчике, другое в интеграторе. Разное ВСЁ.

    Одно дело РП в разработке, другое в услугах/консалтинге. Разные методологии, знания, темп работы.

    Много лет назад я составил скрипт для РП в интеграторе. Он не содержит правильных ответов, он грубый и в большой степени типа стресс-интервью (что ругают в последние годы), он далёк от совершенства, но он дает хоть какую конкретику того как проверять реальные коммуникативные, лидерские и прочие софт-скилы:

    1. О себе, опыте и достижениях (10 минут)
      1.1. Обращать внимание на описание личного вклада (что делал именно ты?), попросить убрать из рассказа «мы / они», максимум детализации, максимум «я», никаких общих слов.
      1.2. По ходу рассказа менять модель слушателя – от полной вовлеченности, до полного безразличия (смотреть на часы, в телефон), отслеживать ответную реакцию. Перебить несколько раз, рассказать свою байку, смотреть как слушает. Вернуть слово, сменить тему, вернуть обратно к прошлой теме, устроить «качели».
      1.3. Перейти на «ты». Извиниться. Снова сбиться. Попросить обращаться к себе на «ты». Если после этого будет больше двух «вы» - в топку.

    2. Софт-скилз (10 минут)
      2.1. Как РП входит в проект? Если это новый проект / если это проект в середине реализации?
      2.2. Расскажите типичную неделю РП – количество и охват встреч, время выделенное для работы с планами и отчетностью. Насколько четкий и жесткий график должен быть у РП?
      2.3. Самодостаточность, один в поле воин: на входе дедлайн, ограниченные ресурсы, описание цели – что делать дальше?
      2.4. Нам поставлена задача посчитать площадь всех поверхностей, покрашенных кузбас-лаком в Казани, как это сделать?

    3. Знание профессиональной области (20-25 минут)
      3.1. Что такое водопад, чем каскадное планирование отличается от итерационного? Есть предпочтения между традиционными методами планирования и гибкими? Чем эджайл отличается от скрам? Что такое спринт?
      3.2. Что такое иерархическая структура работ? Что такое задача, какие у нее есть атрибуты? Накидайте ИСР по вот такому проекту.
      3.3. Сколько областей знания существует в управлении проектами? Можете их перечислить? Читали PMBoK? Сколько процессов есть в УП по PMBoK?
      3.4. Что такое SMART? Любая цель должна быть измеримой? Как часто РП должен отслеживать достижимость цели?
      3.5. Как посчитать требуемые на проект ресурсы? Что такое покер планирование? Как контролировать трудозатраты на проекте, собственный опыт? Что делать при расхождении факта с планом?
      3.6. Что такое риск? Расскажите своими словами. Риск может быть положительным? Какие свойства/артефакты есть у риска? (что такое вероятность, какая может быть степень влияния). Что такое митигейшен-план и континженси-план? Расскажите о своем опыте управления рисками.
      3.7. Сертификаты курсов РП есть? Как относитесь к сертификации? Какие книги по профессии читали за последний год? Как развиваете свои навыки?
      3.8. Как набирать ресурсы? Опыт проведения собеседований? Какие наиболее важные качества кандидатов отметите? Как важные качества зависят от роли? Что такое команда проекта, насколько важна командная работа?
      3.9. Как управлять конфликтами в проекте? Что делать с «результативным психом» в проекте? Что делать если заказчик неадекват? Что делать если два акционера просят делать противоположные вещи? Когда надо включать эскалацию? Эскалация это норм, или типовой кейс?
      3.10. Должен РП участвовать в пресейле проекта? Какая роль РП на пресейле? Как распределяется ответственность РП и сейла на этапе пресейла?
      3.11. Что РП должен делать после успешного завершения проекта? Как можно отметить вклад члена команды в проект (а помимо финансов?)

    4. Знание предметной области (5-10 минут)
      4.1. Какие предметные области знаете хорошо? Насколько важно РП знать предметную область?
      4.2. Насколько вы в айти? Что такое DNS? Чем хороший код отличается от плохого? Что такое ООП? Что такое паттерн? Опыт работы с CVS?
      4.3. Какие ГОСТ / РД знаете? Чем ФТТ отличается от ТЗ? Какие этапы проектирования ИС существуют?
      4.4. Чем 44ФЗ отличается от 223ФЗ? Какие виды конкурсных процедур существуют? Что такое голландский аукцион? Как развалить конкурс по 44ФЗ?

    5. Управление бюджетом (10 минут)
      5.1. Что такое капекс / опекс / финекс?
      5.2. Какие статьи бюджета есть в типовом проекте?
      5.3. Что такое КС-2 / КС-3? Чем списание денежных средств отличается от освоения?
      5.4. Какие виды учета средств знаете? Основы бухгалтерского учета? Что такое амортизация?
      5.5. Как работает банковская гарантия? Как работает авансирование (что такое оплата по освоенному объему)? Когда нужно гарантийное письмо (от заказчика? от исполнителя?)
      5.6. Был опыт подписания финансовых документов по доверенности? Что нужно сделать перед использованием доверенности? Как согласовывать использование доверенности с ГД?

    6. Управление составом работ (5 минут)
      6.1. Что такое RFP / RFC?
      6.2. Новое требование в середине проекта это норм, или инцидент?
      6.3. Как оценить влияние нового требования на освоенный объем? Как провести декомпозицию требования? Что такое дерево требований?
      6.4. Что такое IDEF / DFD?

    7. В конце встречи спросить про тайминг встречи – сколько времени было потрачено на каждый из блоков вопросов?