Comments 13
Я всегда поражался дубовости менеджеров, выросших из программистов. Теперь знаю, что это — недостаток Soft Skills. Век живи — век учись.
Я отчасти столкнулся с похожей ситуацией, когда после позиции техлида на одном направлени меня назначили ПМ-ом на другое направление, где я был не очень сильно подкован в деталях реализации. То есть, если смотреть на табличку, у меня хромал пункт 1. Выручали как раз технари-союзники, благо я их всех давно знал.
По-моему, акценты расставлены не совсем верно, хотя по сути выводы и рекомендации верные. Управление проектами в IT, как и в любой подобной сфере, это управление (по убыванию важности) а) рисками, б) коммуникациями, в) ожиданиями заказчика. Все остальное — в т.ч. методологии разработки, жизненные циклы и пр. — всего лишь
Управление рисками означает заранее знать и понимать, что может пойти не так, где, почему и, соответственно, принимать либо упреждающие, либо корректирующие воздействия. Соответственно, без знания специфики и нюансов IT-разработки тут делать нечего — неофит будет просто не знать, что именно может пойти не так.
Управление коммуникациями — это вообще классика (см. известную картинку с качелями «Как хотел заказчик»). Если не знать, где и почему один член проекта может не так понять другого — опять же ничего не сделаешь.
И только управление коммуникациями более-менее нормально ложится на предыдущий опыт — естественно, если он из хотя бы как-то приближенной сферы.
Поэтому, лично мне видится единственная рекомендация — роль помощника PMа или аналогичная. Покрутиться на проектах, посмотреть как дела делаются и что может идти не так — и уже после этого думать о соло.
Управление рисками означает заранее знать и понимать, что может пойти не так, где, почему и, соответственно, принимать либо упреждающие, либо корректирующие воздействия. Соответственно, без знания специфики и нюансов IT-разработки тут делать нечего — неофит будет просто не знать, что именно может пойти не так.
Управление коммуникациями — это вообще классика (см. известную картинку с качелями «Как хотел заказчик»). Если не знать, где и почему один член проекта может не так понять другого — опять же ничего не сделаешь.
И только управление коммуникациями более-менее нормально ложится на предыдущий опыт — естественно, если он из хотя бы как-то приближенной сферы.
Поэтому, лично мне видится единственная рекомендация — роль помощника PMа или аналогичная. Покрутиться на проектах, посмотреть как дела делаются и что может идти не так — и уже после этого думать о соло.
«listem & understand, Opennes to other points of view» может listen и Openness?
А я не доверяю PM, кто предметную область не знает. Ну серьезно как ты можешь управлять моей работой, ставить приоритеты, если ты не знаешь из чего вообще работа состоит.
Все так, единственное что наличие «союзников» в УП можно узаконить ;) В уставе проекта прописать иерархию ответственных за предоставление тех. информации. Понятно что это не гарантирует её, информации, предоставление, но софт скиллс на то и софт, чтобы подать такое назначение как крутую штуку: «в этом важном для компании проекте необходимо задействовать все наши навыки в полной мере и для этого в уставе прописано, что ты Вася, теперь будешь организовывать предоставление актуальной технической информации блаблабла».
Если не-айтишный да еще внешний менеджер будет сам набирать команду — это отличный способ абортировать любой проект.
Поэтому рассматривается только случай, когда менеджера приставляют к более-менее готовой команде, не так ли?
Айтишникам (в силу специфики) крайне важно, чтобы менеджер был уважаемым опытным экспертом. Они гораздо более чувствительны (кто-то даже может сказать — разбалованы) и не станут в полную силу работать под человеком, которого не уважают. Некоторые из них вообще предпочтут уволиться.
И вот как пришедшему снаружи менеджеру не-айтишнику завоевать уважение? Даже если каким-то чудом он не будет путать UML и XML, отсутсвие знаний предметной области вызовут у спецов лишь раздражение. И чем круче спец — тем больше его раздражение незнайкой, которого посадили на его голову.
Т.е. неформальные лидеры внутри команды, на которых, по идее, должен опираться менеджер, как раз-таки сходу будут отторгать технически неграмотного начальника.
Я даже представить не могу, насколько феноменальные должны быть у такого менеджера Soft Skills, чтобы привлечь на свою сторону крутых технарей и возглавить команду.
Поэтому рассматривается только случай, когда менеджера приставляют к более-менее готовой команде, не так ли?
Айтишникам (в силу специфики) крайне важно, чтобы менеджер был уважаемым опытным экспертом. Они гораздо более чувствительны (кто-то даже может сказать — разбалованы) и не станут в полную силу работать под человеком, которого не уважают. Некоторые из них вообще предпочтут уволиться.
И вот как пришедшему снаружи менеджеру не-айтишнику завоевать уважение? Даже если каким-то чудом он не будет путать UML и XML, отсутсвие знаний предметной области вызовут у спецов лишь раздражение. И чем круче спец — тем больше его раздражение незнайкой, которого посадили на его голову.
Т.е. неформальные лидеры внутри команды, на которых, по идее, должен опираться менеджер, как раз-таки сходу будут отторгать технически неграмотного начальника.
Я даже представить не могу, насколько феноменальные должны быть у такого менеджера Soft Skills, чтобы привлечь на свою сторону крутых технарей и возглавить команду.
Тема завоевания уважения — это тема отдельной статьи. Разве IT-управленец уважение команды получает автоматом? Нет. Ему точно также приходится его завоевывать. И в данной ситуации на старте все равны. Кому-то будет легче в процессе, а кому-то труднее. В то же время знание и умение отличать UML от XML — никак на уважении не сказываются, ибо зоны ответственности менеджера и разработчика — сильно отличаются. Это разработчику как раз положено понимать такое отличие, а начальник за другое отвечает (к примеру за своевременную выплату зарплаты этому разработчику). И для зоны ответственности руководителя — отличать XML от UML — зачастую не требуется. Да, такое знание поможет говорить на одном языке с подчиненными, но только поможет. А может и не помочь, как мы можем наблюдать в сотнях и тысячах проектных команд.
И вот ровно для того, чтобы технические лидеры команды не отторгали начальника — он как раз и должен обладать просто обычными Soft Skills и быть вменяемым и толковым человеком (грамотность в тех-части — не является критически обязательной для такого отторжения или принятия).
Думаю, нужны еще статьи на эту тему…
И вот ровно для того, чтобы технические лидеры команды не отторгали начальника — он как раз и должен обладать просто обычными Soft Skills и быть вменяемым и толковым человеком (грамотность в тех-части — не является критически обязательной для такого отторжения или принятия).
Думаю, нужны еще статьи на эту тему…
А что на счет такой же подробной инструкции, как перейти из разраба в ПМ?
Sign up to leave a comment.
Как стать руководителем проектов в IT