Привет, друзья!

Так получается, что со мной периодически связываются мои знакомые и знакомые моих знакомых, которым меня порекомендовали, с примерно одним и тем же вопросом: «Как мне стать project manager'ом в IT, если до этого я работал(-а) на похожей позиции, но не в IT?».

Так как подобных запросов накопилось несколько штук за довольно короткое время, я решил написать об этом отдельную статью. Ну вы понимаете — я же ленивый, и теперь смогу сразу давать ссылку на этот текст, вместо очередного повторения уже несколько раз сформулированных ответов. Статья не претендует на универсальность — это только мой взгляд на ситуацию. В то же время скажу, что когда проводишь собеседования, нанимаешь и обучаешь project manager'ов — накапливается довольно много общих критериев, отвечающих на вопрос «А что же на самом деле должен знать и уметь IT project manager?», чтобы успешно работать в IT.

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

Поехали?

Как обычно выглядит запрос:
Алексей, добрый день! Меня зовут <...>. Мне посоветовал к Вам обратиться <...>. Нужен Ваш экспертный совет. Буду благодарна Вам за подсказку. Нашла тренинг для проектных менеджеров, который Вы читаете. Хотела бы спросить стоит ли проходить мне его. Кратко о моей ситуации: <...> хотела бы себя попробовать дальше развивать в проектном направлении, но уже в IT-сфере. Уже проходила несколько собеседований, но пока безуспешных (работодатели часто ссылаются на то, что нет опыта в IT). В связи с этим у меня возникла мысль о том, как заставить все-таки поезд тронуться. Буду очень благодарна за совет по поводу курсов. Возможно есть смысл посмотреть что-то смежное к менеджеру проекта, если нет шансов, чтобы взяли в IT-сферу на такую позицию? Буду благодарна за любую обратную связь.

Варианты обращений отличаются только предыдущим опытом работы в неких не-IT областях.

Что я могу посоветовать?

Сначала напугаю и сгущу тучи.

1. Действительно, почти всегда отказывают ровно потому, что для project manager'a в IT крайне важно разбираться не только в project management'e как таковом, но еще и в IT. Это требуется ровно для двух вещей: а) для нахождения общего языка с подчиненными (тестировщики, аналитики и разработчики, которые все айтишники) и соответственно понимания сути диалогов, спецификаций, проблем и прочего, и б) для нахождения общего языка с представителями заказчика, которые зачастую точно также имеют в основном айтишный background. Конечно, есть некоторые небольшие шансы убедить будущего работодателя, что понимания специфики IT-области не критично для данной позиции. Важно помнить, что эти шансы очень и очень небольшие. Все-таки наниматель лучше знает, что ему надо, и убедить его в другом — довольно сложно. Особенно работодателей в IT — они уж точно знают, какой именно сотрудник им нужен. В то же время, никто не запрещает пробовать убеждать. Вдруг получится?

2. В IT очень важным является понимание этапов разработки продуктов (SDLC — Software Development Life Cycle). Работая в НЕ-айтишных организациях это понимание полностью получить, увы, невозможно. Есть моменты специфичные для IT-отрасли. А раз project manager в IT отвечает за разработку продукта/кода/функционала к заданному сроку, с заданным качеством и в заданных рамках по качеству/функционалу, то ему обязательно понимать, как же достичь всего этого теми средствами, которыми он обычно располагает в IT-сфере. В других отраслях могут быть свои нюансы, отличающиеся от IT в ту или иную сторону.

3. Любые тренинги по управлению проектами «вообще», скорее всего не сильно помогут. Нужны тренинги по управлению проектами в IT. Поясню почему я так считаю: тренинги «вообще» не дадут понимания двух важных вещей: «айтишного технического языка» и «понимание этапов разработки именно в IT».

4. В любой IT компании, уже есть свои сотрудники, желающие стать руководителями. И эти сотрудники (разработчики, тестировщики, аналитики) — уже разбираются в IT (владеют тем же техническим языком, что и окружающие), а также знают SDLC. Более того, они знают заказчика, знают специфику компании и ее внутреннюю кухню (это не критичные пункты, но сравнивая с нулевыми знаниями внешнего кандидата — даже эти пункты могут перевесить). Таким образом получается, что внешний кандидат НЕ из IT-отрасли вынужден конкурировать как с внутренними кандидатами изнутри самой компании, так и с другими внешними кандидатами, тоже из IT-отрасли.

Итак, какие же параметры получились?

1. Владение техническим IT-шным языком. Понимание, к примеру, что вообще такое FTP, Signoff, Sprint, ASAP, Regression, XML, Database request, Deadline, FYI, Client-Server Architecture, Redline, Smoke Test, FTE, Release… Список можно продолжать бесконечно. Быть супер специалистом в некоторых упомянутых вещах — совсем не требуется. Требуется понимание сути, что это такое вообще, что за термины, что они обозначают, что за ними стоит, иначе бы будете как слепой в мире зрячих.

2. Знание SDLC (Software Development Life Cycle) — этапов разработки программных продуктов. И не просто знание, а понимание, почему именно такие этапы, почему именно в таком порядке, где и почему можно перескакивать с одного этапа на другой и можно ли двигаться по этим этапам в обратную сторону, и если да, то когда и при каких условиях.

3. Методологические навыки управления проектами и людьми (PM Hard Skills). Сюда входят знания методологий, принципов управления и процессов по областям. Таких как Agile, Scrum, Kanban, Waterfall, Communication management, Specification & Requirements management, Change management, Risk management, Reporting и т.п. Хорошая новость — всему этому так или иначе можно научиться на соответствующих тренингах, вебинарах и множестве доступных онлайн материалов.

4. Личностные навыки управления проектами и людьми (PM Soft Skills). Сюда входят Team & Client management skills, Ability to solve complex tasks, Presentation skills, Conflict management skills, Communication skills, Feedback skills, Ability to hear, listen & understand, Openness to other points of view, Ability to admit own mistakes and to correct them, Self-criticism, Leadership skills, Coaching/Mentoring skills, Ability to explain, Professional culture (quality of speech, emails, calls), Ability to make decisions and take responsibility for it, Pro-activity, Task management skills, Delegation skills, Execution control skills, Personal effectiveness, Time management skills. Вторая хорошая новость — всему этому тоже можно научиться на соответствующих тренингах.

Составим сводную таблицу, в которой будут присутствовать три кандидата:
  1. внешний без знания IT-отрасли
  2. внешний со знанием IT-отрасли
  3. внутренний со знанием IT-отрасли и специфики компании

image

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

Мое мнение, что без погружения в IT-среду невозможно овладеть IT-шным языком хотя бы на уровне понимания. Таким образом с первым пунктом конкурировать нет смысла. Вы (внешний не IT кандидат) тут гарантированно проиграете. Остальные три области — вполне поддаются конкуренции. Причем если вторая (знание SDLC) тоже требует погружения в среду для полного понимания, то хотя бы примерно разбираться в ней не работая в IT — научиться можно. Недостаток знаний SDLC можно компенсировать за счет знаний толкового технического-лида, архитектора да и вообще любого технически грамотного человека из вашей будущей команды. А вот чтобы найти с таким человеком общий язык и получить его помощь — нужны очень серьезные навыки в PM Soft Skills.

Остаются PM Hard Skills и PM Soft Skills — и это ровно те области, где не IT-кандидат может значительно переиграть кандидата из IT-отрасли. Почему я так считаю? Многие руководители из IT — выросли из разработчиков, аналитиков, тестировщиков. Да, среди них есть очень крутые специалисты. Многие такие кандидаты в менеджеры из IT отрасли — они в глубине души остаются теми же самыми программистами, аналитиками и тестировщиками. А это говорит о том, что как раз PM Hard и Soft Skills у них могут быть развиты слабее, чем у внешнего кандидата. Ведь обе эти области (PM Hard Skills и PM Soft Skills) не зависят от IT специфики. Их можно и нужно развивать независимо от области, где вы сейчас работаете.

В итоге, что получается? Какой может быть наша сводная табличка, чтобы у внешнего кандидата ранее не работавшего в IT появился шанс?
image

План действий, который может помочь (а может и не помочь). Но если совсем ничего не делать — не поможет гарантированно.

1. Поговорить с кем-то из ТОЛКОВЫХ знакомых айтишников (разработчиков, тестировщиков, аналитиков, а еще лучше тим-лидов или менеджеров) про SDLC. Дополнительно почитать об этом в Интернет. Возможно, стоит поговорить не раз и даже не два.

2. Попробовать выбрать роль ассистента project manager’a в IT, либо роль младшего PMO-специалиста (там важнее знание процессов управления, чем знание этапов и нюансов и терминов разработки). Попав на любую из этих ролей — необходимо будет уже изнутри изучать терминологию и специфику IT, если действительно есть сильное желание двигаться и развиваться именно в этой области.

3. Объяснить на собеседовании, что «Твои сильные стороны — это умение решать конфликты, навык работы со сложными ситуациями, успех в переговорах, знание английского языка. А технические пробелы в знаниях ты будешь закрывать за счет правильной коммуникации и помощи от технических специалистов, которые будут твоими подчиненными. Ведь работа с людьми — это твой конек». Примерно такими словами. Важно, чтобы это была действительно правда про сильные стороны, а не бравада для прохождения собеседования. Поверьте — любой толковый руководитель определит на собеседовании, если вы обманываете. И на этом все закончится. Но допустим вы получили работу — тогда необходимо срочно искать союзника среди технарей, который будет помогать полностью покрывать и регулярно объяснять техническую сторону работы, задач и возникающих сложностей.

Грубо говоря — вы + технарь союзник будете таким сборным менеджером о двух головах (может быть союзников потребуется больше одного). Многие нанимающие руководители (ваш будущий начальник) это понимают и могут не захотеть идти на это, ведь вы будете «отъедать» время технических специалистов, что уменьшит продуктивность команды в целом. Так что отсутствие у вас некоторых навыков и знаний будет на одной чаше весов, а на другой чаше — ваш будущий руководитель взвесит возможное уменьшение эффективности и продуктивности команды, куда вас планируют взять. И чем больше будет перевешивать чаша эффективности — тем меньше шансов, что вас возьмут. Учитывайте это.

Резюмируя. Чтобы конкурировать с ребятами, которые разбираются в IT и тоже стремятся стать project manager’ами — необходимо серьезно превосходить их в PM Soft Skills.

P.S.: оригинал этой статьи (и другие интересные материалы) можно прочесть в моем блоге: consultpm.com
P.P.S.: мне резонно заметили, что IT не ограничивается разработкой. Это верно. В таком случае второй пункт (знание SDLC) будет менее значим, либо совсем заменен на какой-то свой, специфичный именно для вашего направления.

Поделитесь этой статьей с друзьями.
Спасибо и успехов вам!

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


  1. ServPonomarev
    18.05.2015 08:51
    +2

    Я всегда поражался дубовости менеджеров, выросших из программистов. Теперь знаю, что это — недостаток Soft Skills. Век живи — век учись.


  1. Aquary
    18.05.2015 09:58

    Я отчасти столкнулся с похожей ситуацией, когда после позиции техлида на одном направлени меня назначили ПМ-ом на другое направление, где я был не очень сильно подкован в деталях реализации. То есть, если смотреть на табличку, у меня хромал пункт 1. Выручали как раз технари-союзники, благо я их всех давно знал.


  1. morincer
    18.05.2015 10:40

    По-моему, акценты расставлены не совсем верно, хотя по сути выводы и рекомендации верные. Управление проектами в IT, как и в любой подобной сфере, это управление (по убыванию важности) а) рисками, б) коммуникациями, в) ожиданиями заказчика. Все остальное — в т.ч. методологии разработки, жизненные циклы и пр. — всего лишь

    Управление рисками означает заранее знать и понимать, что может пойти не так, где, почему и, соответственно, принимать либо упреждающие, либо корректирующие воздействия. Соответственно, без знания специфики и нюансов IT-разработки тут делать нечего — неофит будет просто не знать, что именно может пойти не так.

    Управление коммуникациями — это вообще классика (см. известную картинку с качелями «Как хотел заказчик»). Если не знать, где и почему один член проекта может не так понять другого — опять же ничего не сделаешь.

    И только управление коммуникациями более-менее нормально ложится на предыдущий опыт — естественно, если он из хотя бы как-то приближенной сферы.

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


  1. iYalovoi
    18.05.2015 11:26

    «listem & understand, Opennes to other points of view» может listen и Openness?


    1. Harret Автор
      19.05.2015 06:44

      Спасибо, исправил!


  1. viru0
    18.05.2015 16:54

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


    1. Harret Автор
      19.05.2015 06:45
      +1

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


  1. S_A
    19.05.2015 06:45

    Все так, единственное что наличие «союзников» в УП можно узаконить ;) В уставе проекта прописать иерархию ответственных за предоставление тех. информации. Понятно что это не гарантирует её, информации, предоставление, но софт скиллс на то и софт, чтобы подать такое назначение как крутую штуку: «в этом важном для компании проекте необходимо задействовать все наши навыки в полной мере и для этого в уставе прописано, что ты Вася, теперь будешь организовывать предоставление актуальной технической информации блаблабла».


  1. Gradiens
    19.05.2015 17:31

    Если не-айтишный да еще внешний менеджер будет сам набирать команду — это отличный способ абортировать любой проект.
    Поэтому рассматривается только случай, когда менеджера приставляют к более-менее готовой команде, не так ли?
    Айтишникам (в силу специфики) крайне важно, чтобы менеджер был уважаемым опытным экспертом. Они гораздо более чувствительны (кто-то даже может сказать — разбалованы) и не станут в полную силу работать под человеком, которого не уважают. Некоторые из них вообще предпочтут уволиться.
    И вот как пришедшему снаружи менеджеру не-айтишнику завоевать уважение? Даже если каким-то чудом он не будет путать UML и XML, отсутсвие знаний предметной области вызовут у спецов лишь раздражение. И чем круче спец — тем больше его раздражение незнайкой, которого посадили на его голову.
    Т.е. неформальные лидеры внутри команды, на которых, по идее, должен опираться менеджер, как раз-таки сходу будут отторгать технически неграмотного начальника.
    Я даже представить не могу, насколько феноменальные должны быть у такого менеджера Soft Skills, чтобы привлечь на свою сторону крутых технарей и возглавить команду.


    1. Harret Автор
      19.05.2015 22:12

      Тема завоевания уважения — это тема отдельной статьи. Разве IT-управленец уважение команды получает автоматом? Нет. Ему точно также приходится его завоевывать. И в данной ситуации на старте все равны. Кому-то будет легче в процессе, а кому-то труднее. В то же время знание и умение отличать UML от XML — никак на уважении не сказываются, ибо зоны ответственности менеджера и разработчика — сильно отличаются. Это разработчику как раз положено понимать такое отличие, а начальник за другое отвечает (к примеру за своевременную выплату зарплаты этому разработчику). И для зоны ответственности руководителя — отличать XML от UML — зачастую не требуется. Да, такое знание поможет говорить на одном языке с подчиненными, но только поможет. А может и не помочь, как мы можем наблюдать в сотнях и тысячах проектных команд.

      И вот ровно для того, чтобы технические лидеры команды не отторгали начальника — он как раз и должен обладать просто обычными Soft Skills и быть вменяемым и толковым человеком (грамотность в тех-части — не является критически обязательной для такого отторжения или принятия).

      Думаю, нужны еще статьи на эту тему…


  1. mckalech
    20.05.2015 15:33

    А что на счет такой же подробной инструкции, как перейти из разраба в ПМ?