Sunday, July 26, 2009

Должен ли PM быть техническим специалистом?

Я уже не первый раз сталкиваюсь с вопросом, должен ли PM быть технически подкованным человеком или нет. Иными словами, должен ли у него быть опыт работы программистом или QA, для того, чтобы успешно вести проекты, связанные с разработкой ПО. И собственно, вопрос здесь даже не в том, возможно это или нет - опыт показывает, что есть нетехнические PM, которые с разной степенью успешности ведут проекты. Но в то же время тот же опыт показывает, что а) таких людей довольно мало, б) им иногда бывает сложнее, в) общественное мнение в лице различных IT-специалистов иногда отрицает эффективность такого PM. Столкнувшись с этим вопросом, я решил провести небольшой опрос среди моих друзей и сотрудников (бывших и нынешних). Выборка была порядка 20 человек (знаю, нерепрезентативная, но я и не старался делать соцопрос, скорее, получить дополнительную пищу для размышлений), люди абсолютно разного уровня и позиций: программисты, QA, BA, девлиды/тимлиды различного плана, и несколько ребят, которые так или иначе выполняют функции PM на своих проектах или ими являются. Задавал я, как правило, один и тот же вопрос, в краткой форме приведенный в заголовке данной заметки, а потом, по ходу дела, спрашивал детальнее, уточнял подробности, иногда дискутировал :) Ответы были разными, некоторые совпадали с моим мнением, некоторые - нет. Но в любом случае, я благодарен всем, кто согласился ответить на эти вопросы, в независимости от точки зрения, т.к. вы помогли мне увидеть бОльшую картину, чем была у меня в голове до опроса. Все-таки опыт у разных людей разный, поэтому одна голова - хорошо, а двадцать лучше. Также я немного потерроризировал гугл, а также сайты вроде www.stackoverflow.com, www.rsdn.ru и прочие уважаемые ресурсы.

Если очень коротко, то результаты опроса были следующими: где-то 40% людей так или иначе высказывались в пользу идеи, что у PM должен быть технический опыт, и что технический PM лучше нетехнического, причем неоднократно подчеркивались 2 мысли: лучший PM - PM-бывший программист, и лучший PM - PM-бывший QA. Я думаю, не стоит уточнять, у кого какое мнение ;) Остальные говорили, что либо технический опыт не имеет никакого значения, а иногда даже мешает, либо нетехнический PM способен эффективно руководить проектом, но все же не любым. Я же хотел бы высказать свои мысли по этому поводу, в том числе навеянные и общением на эту тему.

Чем занимается менеджер проекта

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

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

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

В разных проектах, с использованием различных методологий менеджеры могут выполнять все эти активности или только часть их, но в любом случае они в какой-то степени организовывают команду, мотивируют, помогают достичь результата и успеха. В идеале, работа менеджера должна быть вообще не видна. Процитирую своего хорошего друга: "Класснее всего когда работа ПМ явно не заметна, проект как бы сам собой выполнился. Там Вася постарался, тут Петя что-то классное придумал, а потом все само получилось. А ПМ _как-будто_ ничего не делал". Спольски тоже об этом писал в одной из своих статей.

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

Чем отличается должность от роли на проекте

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

PM, менеджер проекта - это как должность/позиция, так и роль, и это часто сбивает людей с толку. Еще более сбивает с толку наличие кучи других лидерских позиций: Project Lead, Team Lead, Tech Lead, Dev Lead, QA Lead, Software Architect, можете продолжить сами. Я тоже раньше не мог точно сказать, кто за что отвечает, чем отличается, и вообще, кто все эти люди и что они здесь делают. Связано это с тем, что в разных компаниях и даже на разных проектах люди на этих позициях выполняют зачастую различные обязанности, а единого реестра как бы и нет... Расскажу, как я это понимаю, а вы если что поправляйте. Проще всего разобраться с Dev Lead и QA Lead - это явно выраженные технические позиции, которые четко совпадают с соответствующими ролями: они отвечают за техническую сторону реализации проекта, то есть разработку и проверку качества продукта. Программируют и тестируют они при этом или нет - не так важно, хотя чаще всего да. Позиции Tech Lead и Team Lead более размыты, человек на этих позициях может выполнять как чистую роль Dev Lead, так и несколько ролей: DL, QAL, иногда также PM, SA, BA. К тому же должность Team Lead может относится и к совсем другим сферам деятельности, по сути, это просто руководитель команды: системных администраторов, технических писателей, дизайнеров, бизнес-аналитиков и т.д.

Позиции Project Lead и Project Manager - самые интересные в этом списке, так как человек на каждой из этих позиций может выполнять кучу ролей: PM, DL, QAL, BA, SA, и др., в зависимости от проекта, и того, что понимается под этой позицией в отдельно взятом государстве, в данной конкретной компании, на конкретном проекте и т.д. Но все же разница здесь тоже присутствует. Обычно PL все-таки является техническим товарищем, объединяющим в себя как управляюще-аналитические роли (PM, BA), так и технические (DL, SA, иногда QAL), а вот PM'ами называют зачастую либо людей, играющих только роль PM, либо роли PM и BA, хотя в общем и целом это тоже далеко не гарантия.

Факторы, влияющие на то, может ли PM быть "нетехническим"

Таким образом, активности роли PM очень слабо связаны с техническими умениями. Но означает ли это, что можно взять классного нетехнического PM, поставить его на проект и тот приведет его к успеху? Нет, не всегда.

Для успешного выполнения проекта в команде должны быть представлены все роли, необходимые для этого. Здесь мы подходим к первому фактору, который влияет на ответ на наш вопрос - специфика проекта. Если на проекте есть готовые требования, скорее всего, вашей команде не нужен человек, выполняющий роль BA (это не значит, что для успеха проекта совсем не нужен BA, просто его работа уже выполнена кем-то другим выше вашей команды), если вам прислали готовые документы по архитектуре и дизайну, значит, вам скорее всего не нужен SA, если проект технически не слишком сложен, возможно, вам достаточно не самой сильной команды, но роль DL все равно придется на кого-то возложить, и этот "кто-то" должен соответствовать уровню этой роли.

Таким образом, если в команде есть кому занять роли DL, QAL, SA, BA (а также роли программистов и QA :)), то на должность менеджера проекта можно поставить человека, у которого нет опыта программирования, тестирования, бизнес-анализа, написания документации, но который будет заниматься исключительно менеджерскими активностями, которых тоже очень много. И, как показывает практика, профессионализм и сильный уровень в этих активностях зачастую еще более редки, чем профессионализм и желание постоянно повышать свой уровень у программиста.

Еще один немаловажный фактор, который определяет, какие роли будет выполнять человек на должности менеджера проекта - это размер проекта. На небольшом проекте особо не разгуляешься. Если каждому человеку в команде назначить одну роль, то будет, как на картинке, где один копает, а остальные смотрят :), потому что объем "чистых" активностей одной роли невелик или продолжается незначительный период времени, а работы по разработке или тестированию продукта очень много. Поэтому очень часто на небольших проектах PM (или уже скорее PL) выполняет не только менеджерские функции, но еще и является основным техническим специалистом на проекте, который и анализирует требования, и пишет спецификации, и продумывает архитектуру, и руководит тестированием, в общем, и швец, и жнец. Не говоря уже о том, что в таком случае разработка выходит намного дешевле, т.к. достаточно взять одного самородка, дать ему в команду 25 джуниоров - и дело пойдет ;) Шучу, конечно, но в каждой шутке, как известно, доля шутки - я такие ситуации видел не раз. Поэтому это тоже нужно учитывать.

Кроме того, не стоит забывать, что в оффшорном аутсорсинге, которым многие из нас занимаются, есть такая проблема, как общение с клиентом. Безусловно, клиенту намного удобнее иметь одного человека, с кем он будет общаться по всем вопросам, начиная от требований и заканчивая обсуждениями технических решений. Конечно, клиенту можно объяснить, что по разным вопросам нужно обращаться к разным людям, но это его зачастую смущает. Поэтому нередки ситуации, когда нетехническому PM приходится "общаться" с клиентами на технические темы, по сути, являясь прокси между клиентом и техническими специалистами, что не доставляет удовольствия ни PM'у, ни этим самым техническим специалистам.

Таким образом, нетехническому PM часто приходится так или иначе вникать в технические детали, но если он умеет правильно наладить коммуникации и работать с людьми, это не должно создавать для него особых проблем. И это подводит нас к следующему вопросу.

Есть ли минимальный набор "технических" знаний, необходимых PM?

На мой взгляд, хороший менеджер проекта, при условии заполнения остальных ролей другими членами команды, не обязан знать программирование или тестирование даже на минимальном уровне. НО (!) он все-таки должен хотя бы на каком-то уровне понимать, что такое разработка ПО, какие процессы в него вовлечены, в каком порядке и почему, что такое требования и запросы на изменение функциональности (change requests), как с ними работать, что такое качество продукта, что делают те или иные члены команды, в конце-концов. То есть, по сути, понимать специфику разработки ПО. Во всем остальном ему помогут другие члены команды.

Это же помогает найти ответ и на другой вопрос: можно ли взять успешного менеджера проектов, скажем, в рекламе, и поставить менеджером проекта по разработке ПО? Или можно ли научить человека проектному менеджменту в университете, а потом взять на работу? Можно, но этот человек все-таки должен для начала разобраться в "предметной области" IT-индустрии, прочитать кучу книг, статей, возможно, сдать определенные экзамены, а еще лучше своими глазами увидеть реальные IT-проекты и потренироваться на небольших и не особо критичных. Если у человека есть опыт и он умеет думать и учиться, то все возможно.

Так, может, лучше взять DL или QAL и сделать менеджера проекта из них?

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

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

Насколько мне известно, на западе сейчас довольно активно пытаются внедрять в работу "нетехнических" менеджеров, поскольку у людей, обогащенных техническим опытом, точно такое же количество проблем при переходе на медеджерские должности, что и у "нетехнических" менеджеров проектов, которые сталкиваются с техническими вопросами. Более того, у PM вообще своя карьерная лестница, идущая параллельно технической лестнице. Так 100% работает Microsoft, наверняка, и другие крупные (и не только) компании. В таком случае у технического специалиста есть возможность развиваться технически по-максимуму, в том числе и по зарплате, а вот как раз выход на параллельную лестницу, как правило, означает снижение зарплаты, потому что твой текущий менеджерский уровень еще очень низок по сравнению с теми, кто имеет в этом вопрос намного больше опыта.

Поэтому в случае с переходом технического специалиста в менеджеры нужно понимать, что роль управления проектами довольно слабо связана с теми активностями, которые выполнял этот специалист раньше. И, в первую очередь, это нужно понимать самому этому специалисту. Кроме того, у бывших программистов и QA (хоть у последних и в меньшей степени) есть свои проблемы с выполнением менеджерских обязанностей. Не все хорошие технические специалисты становятся хорошими менеджерами - это давно известно, но об этих проблемах мы поговорим как-нибудь в другой раз - это тоже обширная тема. Но если Вы - именно тот человек, у которого это получается, и это вам интересно, то почему бы и не попробовать? Не получится - всегда можно вернуться в техническую сферу :) И тем более стоит пробовать, если вы нетехнический PM - у вас также есть хорошие шансы.

Успехов вам!

PS. Еще раз спасибо всем, кого я доставал своими глупыми вопросами :)

22 comments:

  1. Спасибо за интересную и развернутую статью. Тоже задумывался о подобном вопросе.
    Мне кажется, вопрос технических знаний у ПМ возникает скорее в наших реалиях. Когда тим\тех лид небольшой команды 3-10 чел получает больше свобод в общении с заказчиком и начинает приписывать себе "титул" проджект менеджера. Представить такого вот ПМ без технического опыта довольно сложно. Потому как нередко ему же и приходится "тянуть" джуниоров.
    В то же время если говорить о проектах из нескольких команд на хотя бы 50-100-150 человек, то ПМу такого проекта вряд ли обязательно быть бывшим программистом\тестировщиком. По идее ему просто будет не до этого в череде вопросов планов, сроков, бюджетов и бесконечных митингов...

    ReplyDelete
  2. Вообще-то если подойти формально, то поль ПМ не требует технических знаний не то у нее предназначение. Другое дело DTL (он же DevLead). А у нас почти постоянно эти две роли смешиваются, отсюда и возникает путанница.

    ReplyDelete
  3. Vladimir: Согласен, что роль PM вообще не техническая. Должность - да, может требовать технических знаний, если PM выполняет не только роль PM, но также роль DL. Правда, в такой ситуации, это уже скорее Project Lead, а не Project Manager... Я вроде бы то же самое и написал в своей заметке, разве нет? :)

    ReplyDelete
  4. Так получается, что менеджеру вообще нечем заниматься. Всё за него должны делать всякие DL,QAL и другие страшные аббревиатуры :) Может я невнимательно прочёл твой пост, но что вообще должен делать PM? Мифическое "следить за сроками"? Ну ок. Следит. Сроки провалены. Чё дальше?

    Ну и тут ещё можно добавить (не в порядке спора), что украинская специфика (знакомая мне) такова, что никаких BA, DL и прочего на проектах в помине нет, а не технические менеджеры на тех же проектах присутствуют.

    ReplyDelete
  5. wicharek: Позволь, прокомментирую по пунктам :)

    >> Так получается, что менеджеру вообще нечем заниматься. Всё за него должны делать всякие DL,QAL и другие страшные аббревиатуры

    Да нет, вроде бы не получается.

    У роли PM круг вопросов очень широкий (посмотри список активностей, которые я привел). На небольшом проекте (до 3-4 человек) эти активности занимают не больше нескольких часов в день (хотя все зависит от проекта), поэтому там можно совместить эту роль с какой-нибудь другой. Т.е. менеджментом может заниматься какой-нибудь девлид/тимлид, который параллельно будет также заниматься архитектурой, писать код и вышивать крестиком. На более же крупных проектах у PM столько работы, что за глаза хватает на восьмичасовый рабочий день: митинги, коллы, ведение документации, корреспонденция, в общем, все то, что я перечислял.

    >> что вообще должен делать PM? Мифическое "следить за сроками"? Ну ок. Следит. Сроки провалены. Чё дальше?

    PM - роль, которая отвечает за проект перед вышестоящим начальством. Если проект провален, значит, это в определенной, и как правило, в максимальной степени вина PM. Здесь, конечно, можно придумать много ситуаций, когда это вина ленивой команды, плохого клиента, неправильно сделанных оценок и т.д. - это все принимается к рассмотрению. Но по каждому из этих пунктов есть отдельные действия, которые PM может и должен сделать, чтобы: а) понять, что проект катится в тартарары как можно раньше (принцип fall faster), б) принять все необходимые действия для того, чтобы он все-таки был успешно завершен или, по крайней мере, минимизировать негативные последствия. А это целое искусство: искусство управления людьми, рисками, информацией, общения, мотивации, создания и отслеживания процессов и т.д. Так что наверно PM все-таки довольно полезный член команды, без него как-то все разваливается. И даже если команда способна к самоорганизации, все равно в любом проекте есть то или иное подмножество активностей роли PM, которые расбрасываются между членами команды...

    >> никаких BA, DL и прочего на проектах в помине нет, а не технические менеджеры на тех же проектах присутствуют

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

    Чистых BA - да, мало, часто роль BA берет на себя PM. Но BA все больше и больше, потому что на больших проектах приходится снимать с PM еще и BA-активности, не справляются люди. Пара же PM-DL или даже тройка PM-DL-QAL встречается в крупных компаниях. Сходу могу вспомнить Global Logic, Epam, Stella, Intego, уверен, что такая же ситуация в Intetics, Dataart, так что это не моя выдумка.

    ReplyDelete
  6. Александр, я наверное вас недопонял с Project Lead... для меня этот термин непривычен. :)
    А вообще правильно - главная задача ПМа тащить на себе ответственность за проект и не важно по чьей вине "просел" проект - виноват все равно ПМ. Потому что не "сменеджил".

    ReplyDelete
  7. Понимаю :) Их развелось слишком много... В одной из компаний, где я раньше работал, под PL понимали человека, который по сути выполнял функции и PM, и DL (а иногда еще и QAL), то есть отвечал и за техническую реализацию продукта (прояснение требований, архитектура, оценка, раздача задач девелоперам), и за проект в целом (общение с клиентом, процесс, взаимодействие, коммуникации, отчеты, etc.) Собственно, поэтому и должность такая: Project Lead

    ReplyDelete
  8. "И швец, и жнец, и на дуде игрец" :)
    Да, конечно такой спец. должен быть технарем на 100% и при даже среднем проекте он будет работать по 14-16 часов в сутки 7 дней в неделю. Ужасная практика, проходили уже...

    ReplyDelete
  9. Ну, на самом деле не все так плохо. Конечно, можно долго рассуждать, что есть средний или крупный проект, но в целом по моим наблюдениям лидские и менеджерские обязанности можно выполнять без овертаймов на проектах где-то до 10-12 человек. Если людей больше, т.е. больше оперативного менеджмента и прочей работы - тогда да, нужно разделять роли на несколько человек. Кстати, поэтому в вышеуказанной компании это и сделали - разделили должность на 3 роли на крупных проектах.

    ReplyDelete
  10. Поменял немного концовку. Как-то слишком нескладно было... Надеюсь, теперь моя позиция более понятна :)

    ReplyDelete
  11. Спасибо за интересную статью, многое совпадает с собственными наблюдениями, и как я это понимаю.
    Хотя опять таки же наши реалии подтверждают что все зависит от конкретной ситуации (компании, проекта, людей), поэтому сложно обобщать. А отвечая на основной вопрос статьи я бы сказал банальное it depends (о чем вы в принципе тоже пишите).

    Отдельное спасибо за описание ролей dev lead и team lead и чем они отличаются, наконец-то встретил объяснение что под ними подразумевается :)

    ReplyDelete
  12. Да, согласен, it really depends. Но моей основной целью было 3 момента:
    1) развеять миф, что нетехнический PM ничего не стоит
    2) показать, чем же все-таки занимается роль PM, и чем - нет, отделить PM от технических активностей
    3) разобраться, от чего это все depends, когда можно ставить нетехнического PM, а когда - только технического
    Надеюсь, что кому-то это поможет немного навести порядок в голове, а может, и у себя на проекте :)

    ReplyDelete
  13. У меня несколько иное мнение:

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

    Чтобы понимать, что его команда лажает. Часто бывает ситуация, когда тот же девлид хочет попробовать новую технологию и условно говоря, предлагает все переписать "с нуля", расписывая как все станет круто.

    Если менеджер недостаточно технически подкован, то он может послушаться девлида и потратить потом кучу времени на спасение проекта и разбор полетов.

    Если же у нас в наличии классический менеджер, понимающий проект только в терминах "ресурсов-объема работы-сроков" и не понимающий, что именно предлагают ему программисты, то он не сможет быстро определять, когда разработчиков "заносит" (а это случается часто :-)

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

    При том же agile стиле работы например менеджеру надо реагировать быстро, иначе зазеваешься -- а программисты это уже написали.

    По моему опыту, если менеджер нетехнический, то _с той же командой_ он может сделать проект процентов на 30-50 медленнее, чем менеджер такой же квалификации, но который разбирается в программировании/архитектуре/разработке UI.

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

    С Agile все немного сложнее, там менеджеров как бы особо и нет - команды-то больше самоорганизовывающиеся. Да и особо планировать там нечего - с планированием и исполнением спринта справится любой толковый девлид. А вот для остальных ролей может подойти и нетехнический человек или в крайнем случае BA или QA.

    Насчет сравнения менеджеров одного "менеджерского" уровня, но с наличием технического бекграунда и без оного - это не совсем честно :) Лишние знания мало когда мешают. Но в то же время, если есть девлид и PM, то зачем PM знать, как правильно строить архитектуру приложения или писать код? Проектирование UI, usability - ладно, это полезные навыки, особенно для product manager'а, а вот все остальное когда может пригодится?

    ReplyDelete
  15. Вопрос к автору статьи: а Вы бы доверили строительство собственного дома прорабу без строительного образования. Филологу, например, который в сортах кирпича не разбирается, но имеет опыт управления, скажем, отделом юмора в издательстве газеты ?
    У него же есть штукатуры, маляры. А проект уже сделан архитектором.

    ReplyDelete
  16. А давайте еще сравним создание ПО с пилотированием самолета или проведением операции на мозге. Вы бы доверились "филологу"? Я - нет. Но почему-то никто не спорит, что в той же авиакомпании или больнице на руководящих должностях находятся не обязательно бывшие летчики и медики.

    А кроме этого, дом дому рознь... Если мы говорим о частном доме в один или два этажа - то здесь и вы сами справитесь не только с управлением этим процессом, но даже с постройкой (при определенных навыках и практике), разве не так? Если же это небоскреб, то там, скорее всего, аналогом ПМа будет не прораб, а какой-нибудь менеджер более высокого звена, который отвечает либо за строительство в целом, либо за его определенный участок. И, думаю, там не очень важно, знает ли он подноготную жизни кирпичей в дикой природе, или нет. А вот прорабов можно сравнить скорее с техническими лидами...

    А вообще, я не спец в строительстве, поэтому и не хочу проводить параллелей. Скажу лишь, что видел действительно классных ПМов без особого технического бекграунда. А также никакущих "технических" менеджеров. У "чистого" ПМа совсем другая сфера ответственности, задачи и навыки, чем у программиста или даже девлида, и в этом был смысл данной заметки.

    ReplyDelete
  17. "Но почему-то никто не спорит, что в той же авиакомпании или больнице на руководящих должностях находятся не обязательно бывшие летчики и медики."

    В Советском Союзе было аналогичное, "хоз.номенклатура" называлась: развалил промышленность - переводили сельское хозяйство "поднимать".
    Так что, ничего нового, а разница только в названиях и деталях, но не в принципе: "номенклатуру" перекрасили в "эффективных менеджеров", а вместо ВПШ - МБА.
    Между тем, не встречал еще в своей жизни ни одного менеджера, уволенного даже за полностью проваленный проект, а вот сделанных "крайними" разработчиков - сколько угодно.

    ReplyDelete
  18. Ни капли не аналогичное. Давайте не путать теплое с мягким. В Советском Союзе было очень много "руководителей", которые становились такими как раз не благодаря своему профессионализму, а благодаря своим заслугам перед партией и доверию, которое она им оказывает. Это же олигократия была - там все свои были, и только "своих" старались продвигать на руководящие должности. Типичное кумовство.

    В то же время многие топ-руководители Fortune 500 как раз MBA заканчивали, то есть являются профессионалами в области управления, а не конкретной предметной области компании. Были, конечно, исключения и в СССР, есть они и в Fortune 500, но не стоит всех грести под одну гребенку.

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

    Насчет увольнения менеджеров - конечно, проще сделать крайними исполнителей, менеджеру же руководство всегда доверяет больше. Это как раз остатки советской системы у нас, скорее всего... Хотя я встречал уволенных за провал проекта менеджеров :) А вы-то чего так на менеджеров ополчились-то?

    ReplyDelete
  19. Спасибо за статью, я как раз получаю бакалавриат по специальности PM в ИТ проектах, поэтому для меня сей пост особенно актуален.

    ReplyDelete
  20. Норм статья.

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


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

    ReplyDelete
  21. Спасибо за статью и комментарии. Было очень интересно прочесть мнения по этому вопросу, так как в скором времени буду проверять на собственном опыте может ли стать менеджером проекта (в области разработки ПО) системный администратор. Поступило предложение попробовать себя в этом направлении. Сначала отказался, так как тоже считаю, что менеджером здесь может стать либо программист, либо QA, в общем люди работающие в сфере разработки ПО. Но решил все же попробовать.

    ReplyDelete
  22. Попробуйте. Для того, чтобы успешно "менеджить" проект, нужны навыки управления временем и людьми, хорошая коммуникация (как с "клиентом"/рукодством, так и с командой, понимание процесса разработки ПО (что делать и в какой последовательности, что делать, если что-то идет не так) и самое главное - ясная голова, которая быстро учится и соображает. Если у вас все это есть - должно получится. В любом случае читайте больше книг и статей по проектному менеджменту в IT - это вам очень поможет.

    ReplyDelete