Хм, мне странно что с MBA вы такое говорите. Если он не руководит то это не менеджер, это координатор — другая роль.
Тут важно не перефразировать, в моем комментарии PM обозначен как не полноценный руководитель.
Проект в целом временное явление
В точку, при этом работа с персооналом является постоянной обязанностью и привелегией руководителя — что и является для меня доводом что PM не совсем руководитель.
Влиять на качество — очень просто, управлением.
Что бы управлять — нужно понимать чем управляешь, особенно когда мы говорим о специфичных отраслях. В противном случае любой достаточно хитрый подопечный в легкую одурачит подобного «руководителя».
но при той же матричной структуре руководит и ПМ
Отчасти да, в теории все красиво работает. Но думаю вы согласитесь что это своего рода костыль в системе управления. 2 руководителя у одного подопечного? Кто приоритетнее? За кем идти? Что делать? Неоднозначности ни в процессах, ни в задачах, ни в приоритетах не должно быть.
но вопрос хотят ли этого сами разработчики — выстраивать коммуникацию, принимать общие решения по проекту, общаться с заказчиком по бизнес-вопросам, заниматься досками, тасками, решать проблемы. И еще более важно — могут ли, есть ли у них навыки общения, управления, насколько они клиентоориентированы.
На самом деле это очень хороший вопрос, не все хотят, не все могут.
Навыки общения и управления — развиваются, вопрос возможности и времени.
Мой посыл был в том что у разработчиков из за профессиональной специфики шансы стать профессиональным руководителем чуть выше. То что большинство не захочет — скорее всего.
Но это уже личный выбор.
Мне как человеку так же получившему MBA, только имеющему серьезный бэкграунд в разработке некоторые вещи бросаются в глаза.
«В случае конкретно ПМ-ов — еще я считаю важным понять, реально ли вы будете руководить проектом, или только координировать его.» — а собственно чем PM собирается руководить?
PM это не полноценный руководитель, как по мне так эта роль переоценена.
PM не отвечает за конкретную команду/подразделение — его скоуп это «проект».
PM не влияет на рабочие процессы — он временное явление рядом с командой.
PM не имеет профильного технического опыта — в следствие чего вопрос, а как подобный менеджер может повлиять на качество и сроки?
«Руководить» должен руководитель команды/подразделения, формальный и не формальный лидер, имеющий видение и стратегию развития своей команды, инструменты для мотивации и стимулирования, опыт работы в сфере и самое главное имеющий доверие своих людей.
Без этого все желания «поруководить» приводят к «чайка» менеджменту, разваленым командам и не выполненным обещаниям перед людьми.
По моему мнению PM не нужен команде разработчиков, его вполне может заменить секретарь/секретарша выполняющий административные функции. Грамотный тимлид в легкую убирает PM и растет вместе со свеой командой.
К слову большинство разработчиков имеют серьезные перспективы в росте в руководители и MBA может помочь в этом. Бизнес — это framework, MBA — документация и bootcamp
Тут важно не перефразировать, в моем комментарии PM обозначен как не полноценный руководитель.
В точку, при этом работа с персооналом является постоянной обязанностью и привелегией руководителя — что и является для меня доводом что PM не совсем руководитель.
Что бы управлять — нужно понимать чем управляешь, особенно когда мы говорим о специфичных отраслях. В противном случае любой достаточно хитрый подопечный в легкую одурачит подобного «руководителя».
Отчасти да, в теории все красиво работает. Но думаю вы согласитесь что это своего рода костыль в системе управления. 2 руководителя у одного подопечного? Кто приоритетнее? За кем идти? Что делать? Неоднозначности ни в процессах, ни в задачах, ни в приоритетах не должно быть.
На самом деле это очень хороший вопрос, не все хотят, не все могут.
Навыки общения и управления — развиваются, вопрос возможности и времени.
Мой посыл был в том что у разработчиков из за профессиональной специфики шансы стать профессиональным руководителем чуть выше. То что большинство не захочет — скорее всего.
Но это уже личный выбор.
«В случае конкретно ПМ-ов — еще я считаю важным понять, реально ли вы будете руководить проектом, или только координировать его.» — а собственно чем PM собирается руководить?
PM это не полноценный руководитель, как по мне так эта роль переоценена.
PM не отвечает за конкретную команду/подразделение — его скоуп это «проект».
PM не влияет на рабочие процессы — он временное явление рядом с командой.
PM не имеет профильного технического опыта — в следствие чего вопрос, а как подобный менеджер может повлиять на качество и сроки?
«Руководить» должен руководитель команды/подразделения, формальный и не формальный лидер, имеющий видение и стратегию развития своей команды, инструменты для мотивации и стимулирования, опыт работы в сфере и самое главное имеющий доверие своих людей.
Без этого все желания «поруководить» приводят к «чайка» менеджменту, разваленым командам и не выполненным обещаниям перед людьми.
По моему мнению PM не нужен команде разработчиков, его вполне может заменить секретарь/секретарша выполняющий административные функции. Грамотный тимлид в легкую убирает PM и растет вместе со свеой командой.
К слову большинство разработчиков имеют серьезные перспективы в росте в руководители и MBA может помочь в этом. Бизнес — это framework, MBA — документация и bootcamp