Как стать автором
Обновить

Чем руководители проектов отличаются друг от друга (джун vs миддл vs синьор)

Уровень сложностиПростой
Время на прочтение5 мин
Количество просмотров12K
Всего голосов 16: ↑10 и ↓6+7
Комментарии37

Комментарии 37

знает и может объяснить, что такое ТЗ**. Сам писал какие-то функциональные требования

Нефункциональные требования в ТЗ не включаем, значит? А вы точно РП?

РП не будет участвовать в 400 собеседованиях. Это HR которому спихнули список вопросов и примерных ответов.

Зря вы так, другие мои статьи почитайте.

Я примерно каждый год выходил на рынок - просто интересно его было исследовать + ищу сам давно и много. Да, местами я работаю как HR, когда HR у меня нет, но это не мой профиль

по-моему для 15 лет опыта собеседований это абсолютно адекватная цифра

Да, точно. на небольших проектах NFR как правило не пишут. Или пишут одной строчкой.

Если вы джуна спросите про нефункциональные требования к системе, он, скорее всего, поломается. Если он отвечает бодро - я бы советовал брать.

Да, точно. на небольших проектах NFR как правило не пишут.

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

Ну тут я бы и сам с вами поспорил. Архитектура системы - это результат исполнения функциональных и нефункциональных требований.

non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours. They are contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture, because they are usually architecturally significant requirements.[1]

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

Про администратора - так можно. Но надо же кого то обучать :)

джун: 180-230

миддл: 230-350

то есть между человеком, умеющим делать минимум под присмотром, и средней крепости спецом разница по зп в 50к (а может и вовсе не быть?)

да. все зависит от дерзости, умения запудрить мозги на собеседовании и опыта интервьюера. не то, чтобы я настаиваю, мой опыт - такой.

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

  2. Жизненный цикл проекта далеко не всегда заканчивается сдачей в эксплуатацию, в части проектов жизненный цикл заканчивается, когда систему выводят из эксплуатации, а это значит, что РП должен уметь работать со сроками в 10-15 лет.

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

  4. Не увидел делегирования, РП может делегировать организацию работы разработчиков тимлиду и это тоже рабочая схема.

  5. Старт рассуждений начинается с ТЗ, хотя создание ТЗ это этап после предпроектного обследования, качество исполнения которого, как раз впрямую влияет на ТЗ. Я уж молчу, что половина компаний не понимает разницу между ТЗ и ЧТЗ.

  6. ПМИ - вторичный вопрос, на мой взгляд, интереснее спросить про этапы и типы испытаний, про регламент испытаний и взаимодействие с Заказчиком, потому, что эти вопросы показывают базовый юридический бэкграунд РП, без которого количество граблей в проекте кратно растет.

классные замечания, спасибо. по пунктам

  1. Да, я сам в шоке. На РП и аналитиков прямо сейчас нереальный спрос, я такого не видел никогда. Все ваши замечания для меня - уже синьор :) но тут надо понимать, что я говорю о проектах 20-50 человек. Но 100. Если смотреть на проекты 100+ человек, то там уровень будет другой, разумеется. Но я таких проектов в РФ знаю мало. Может быть выборка хромает, конечно

  2. Хм. Для меня у проекта есть четкие сроки. В госухе всегда есть развитие и эксплуатация. Есть капекс и опекс. Проект заканчивается там, где заканчивается капекс. И обычно это три года (что я знаю, проекты уровня создания ФГИС). Впрочем, Госуслуги уже 15 лет развиваются, так то. Тут надо почитать теорию, я не помню определения.

  3. Экономику ИТ проекта, если он не слишком большой, считать достаточно просто: есть оценка, есть план, есть запасы. Этому я и сам могу научить. Но обычно РП знают это, все таки :)

  4. Может. это в синьоре есть: "может организовать работу 20+ человек" - без делегирования лидам он этого как раз сделать не сможет. Вопрос на собеседовании "расскажите о процессе разработки команды 20 разработчиков и инструментах, где вы его автоматизируете"

  5. Согласен. Тут к вашему первому замечанию. Наверное, уровень упал. Часто РП бывают без опыта предпроектного обследования, оно же пресейл. Но делать "по ТЗ" в целом могут.

  6. Вы знаете, отличия предварительных и приемочных испытаний я сам использовал пару раз, когда надо было сдавать строго по ГОСТ, да и система была сложной. Тут вопрос масштаба. Для меня уже это, скорее, синьор

  1. Вы правы, проект имеет сроки начала и окончания. Дальше, как правило, проект переходит в продукт, но не остаётся проектом и управляется Продактами

Чего уж вы мелочитесь, напишите уже, что синёр получает от 350 до секстиллион_до_неба.
Откуда срез - хз, снова графоманские приколы хабра)
Пойди займись делом
(я, если кто спрашивал, head of PMO, буквально месяц как закрыл 2 вакансии РП - больше сотни резюме перелопатил).

  1. не надо грубить

  2. я и сам head of pmo уже много лет и перелопатил больше 100.

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

Вы нанимаете джунов за 180к? Очень интересная информация.

Я порядка 3.5 лет работал руководителем не в ИТ, в прошлом году стал искать первую ИТ работу в проектном менеджменте. Долго искал, очень много отказов, отказы на позиции помощник координатора младшего ПМа за 10к рублей. Вместо этого куча бесплатных стажировок и пет-проектов, обучений самостоятельных, у менторов, на курсах, чтобы потом чудом по знакомству устроиться на 300€ в месяц.

Я тоже не собирал статистику, но возможно реальность всё-таки ближе к моему опыту, судя по сотням и тысячам откликов на вакансии за 50-70к.

Возможно. Одна из целей статьи - это обменяться опытом. Сам я отбором не занимаюсь, последние несколько лет это делают HR. За ними есть грешок: они могут поднимать зарплаты кандидатов, потому что получают % от зарплаты кандидата в итоге. Так что завышение может быть.
Но я также вижу, когда хорошие кандидаты уходят, не приняв наш оффер. Так что вопрос дискуссионный.

По вашему кейсу скажу следующее: мне в линкед ине писали несколько кандидатов, мы как то даже собеседовали СЕО закрывшегося ИТ интегратора на позицию РП. Я не взял никого. Причины разные: или человек вообще не владеет предметом (как в статье про джуна - этого нет), обещая, что научится (но у меня нет столько денег и времени), или психологические особенности кандидатов.

Если хотите - киньте мне ваше CV в ТГ (в профиле), я погляжу и скажу свое мнение.

Про зарплаты на момент августа 2024 года:

джун: 180-230

миддл: 230-350

синьор: 350-500

А вы уверены? Максимальный оффер на миддла, что получала, был 150 до налогов.

вы знаете, я последние полгода ищу менеджеров. HR подгоняют таких. И несколько человек отказались от наших офферов в пользу других.

Мои менеджеры получают офферы со стороны на схожие суммы. Я сам пару раз выходил на рынок, чтобы прикинуть свою цену. Мои выводы такие.

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

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

Мне самому очень интересно, что на рынке, так что можете в личку мне написать, я погляжу.

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

не спора ради, я просто поделился тем, что я вижу на рынке. Если у вас другой опыт - буду рад если поделитесь. Но не за 10 лет, а последний год-полтора. Потому что сейчас на рынке бум.

Я в 2019 году искал работу и не могу найти. Сейчас за нормальными РП очередь.

Моего ведущего РП (по факту он классный миддл конечно) уже год закидывают офферами от 300 тыс. Если вам интересно - напишите в личку, мне интересно, что у вас. Я смотрю на рынок, мне интересно, что происходит и статья - попытка это понять.

Дорогой автор, тема действительно интересная. Я понимаю, что многое зависит от конкретных проектов и сферы их применения.

После прочтения у меня возникли некоторые вопросы, и было бы замечательно, если бы вы смогли на них ответить:

1. Что побудило вас написать эту статью?

2. Какую «боль» решает эта статья?

3. Какой ваш проект вызывает у вас наибольшую гордость и почему?

4. В какой основной сфере применяются ваши проекты?

5. Сколько сотрудников может контролировать руководитель портфеля проектов и каких?

Здравствуйте. Цель статьи: разобрать отличия джунов миддлов и синьоров, чтобы начинающие и не очень РП могли поглядеть, чего им не хватает, чтобы расти дальше.

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

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

Если вы - руководитель, и видите тут лажу, просто напишите. Без проблем, обсудим :)

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

Давай конструктивнее, получается что критикуешь, но ничего не предлагаешь. Это очень низкий уровень зрелости.

спасибо, я понял.

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

Для конструктивного обсуждения или спора , как угодно, нужна фактура. Ваше мнение я понял, фактуру дадите? У вас другие критерии отбора? Расскажите.

Критикуя - предлагай, как верно заметили уже

Благодарю вас за статью! Теперь понятно в какую сторону двигаться.

Вопрос: все навыки и знания, перечисленные в статье, получаются потом, кровью и неудачами в процессе работы или существует хотя бы базовая литература? Имею ввиду кризис-менеджмент, определение сроков, планирование и тд.

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

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

вам становится мало одного проекта, вы берете несколько - я такое видел только если по факту тащит проект кто-то другой. Не верю короче

зависит от размера проекта и сложности коммуникаций на проекте.

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

Согласен с автором в отношении уровня зарплат РП. Единственное, конкретизирую свое виденье главного отличительного признака РП - это человек, который лично отвечает за итоговый результат работы других сотрудников. Некоторые уверены, что РП - это человек который может талантливо делегировать свою ответственность (не работу, а именно ответственность). Это не РП - это рафинированный менеджер. Иногда, такая должность звучит как <администратор проекта>. Зарплата таких "РП" действительно может стартовать с гораздо меньших уровней.

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

Опять, же дело в контексте. Что называть проектом? У меня основная система над которой трудится проектная команда как бы одна. Но в ней 14 подсистем которые решают разные задачи (на каждой из них раньше специализировалась своя группа разработчиков). По этой системе одновременно может быть в работе 3-4 договора разного размера и срочности: на базовое сопровождение (решение возникающих инцидентов и консультации), на расширенное сопровождение (небольшие доработки по заявкам), на развитие (серьезная модификация подсистем, переход на новые технологии, создание новых подсистем). Это один проект или программа или портфель проектов? Кроме того в проектной команде у нас есть пара внутренних проектов заточенных на создание перспективных продуктов (решение важных, но несрочных задач - по матрице Д.Эйзенхаура). Один из таких проектов описан на Хабре. На эти проекты я стараюсь ежедневно планировать не менее 30% рабочего времени штатных сотрудников. На этих внутренних проектах решаются проблемы превентивного освоения и апробации перспективных технологий, а так же выравнивания неравномерности нагрузки сотрудников (ликвидация mura). Эти же проекты служат "песочницей" для апробации стажеров. Эти же проекты служат буфером (по Э.Голдрату), в случае необходимости решения более срочных задач по заключенным контрактам.
При всем при этом моя должность звучит как <РП> (в прямом подчинении 12 сотрудников, для решения отдельных задач возможно привлечение внешних экспертов). Было бы интересно узнать, как должна звучать моя должность, с точки зрения читателей этой статьи... ;)

Тут вопрос, кто отвечает за общий бюджет? Если маржа по всей истории ваша и за ФОт и мотивацию команды отвечаете вы - попахивает руководителем направления.

Если ФОТ не ваш, но у вас есть несколько РП - Директор.

Если РП в подчинении нет, то надо поглядеть, как вы лидами обходитесь. 12 лидов в целом на грани, на мой взгляд :) Мне 7-8 хватало и я просил еще РП

Маржу я бы, конечно, взял... Да кто ж ее даст... ФОТ и состав команды обосновываю я, исходя из бюджетов договоров (кстати, которые тоже я обосновываю) и текущей ситуации на рынке труда, но окончательное решение принимает вышестоящее начальство. И я не прошу дополнительных РП у начальства, я выращиваю их самостоятельно. Что касается управления, у меня в команде выстроен определенный порядок достижения целей. Любое входящее требование (не только от представителей заказчика, но в том числе и требования вышестоящего руководства и мои требования тоже) регистрируется, на него назначается ответственный, как правило, из числа аналитиков (на текущий момент в группе три аналитика). Ответственный выступает как РП в рамках этого требования (или группы связанных требований). Он отвечает за организацию работ и сдачу результата решения заказчику. Я сам, как правило, осуществляю утверждение и контроль исполнения сроков и выступаю в роли рецензента отдельных проектных решений и командных процессов. Иногда, при необходимости, включаюсь в прямое управление и разработку, но стараюсь этого избегать. Недавно мне задали вопрос: "А что если аналитик не хочет решать управленческие задачи?" Я в свою очередь порекомендовал своему визави познакомится с содержанием соответствующего профессионального стандарта. С определенного времени, ссылки на соответствующие профессиональные стандарты я вписываю в трудовые договора своих сотрудников... Такая ссылка легитимно устраняет массу лишних вопросов... Так сказать, на берегу.... Однако многие руководители почему-то ограничивают полномочия своих сотрудников фантазиями чужих HR-специалистов публикуемыми на hh... Или думают, что решат все проблемы фразой в трудовом договоре о том, что "сотрудник должен выполнять все распоряжения руководителя"...
Результаты своих управленческих экспериментов над живыми людьми я иногда публикую на Хабре и на своем pet-проекте aimsmart.ru. Эти же статьи использую как неформальные, но вполне действующие, регламенты для своей проектной команды...

Стили подправить...

Спасибо, поправлю! Что скажешь... Сеанс кодотерапии выровнял кривые руки РП, исковерканные менеджментом, не до конца... ;)

Спасибо. У меня в списке статей в блокнотике есть проект статьи под названием "РП администратор или РП помощник", надо будет ввернуть эту неприятную для некоторых новость. Я в свое время болезненно воспринимал то, что я отвечаю вообще за все косяки на моем проекте.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории