Так получается, что со мной периодически связываются мои знакомые и знакомые моих знакомых, которым меня порекомендовали, с примерно одним и тем же вопросом: «Как мне стать 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. Вторая хорошая новость — всему этому тоже можно научиться на соответствующих тренингах.
Составим сводную таблицу, в которой будут присутствовать три кандидата:
- внешний без знания IT-отрасли
- внешний со знанием IT-отрасли
- внутренний со знанием IT-отрасли и специфики компании
Таким образом, становится очевидным, в каких пунктах можно пытаться конкурировать.
Мое мнение, что без погружения в 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 появился шанс?
План действий, который может помочь (а может и не помочь). Но если совсем ничего не делать — не поможет гарантированно.
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)
Aquary
18.05.2015 09:58Я отчасти столкнулся с похожей ситуацией, когда после позиции техлида на одном направлени меня назначили ПМ-ом на другое направление, где я был не очень сильно подкован в деталях реализации. То есть, если смотреть на табличку, у меня хромал пункт 1. Выручали как раз технари-союзники, благо я их всех давно знал.
morincer
18.05.2015 10:40По-моему, акценты расставлены не совсем верно, хотя по сути выводы и рекомендации верные. Управление проектами в IT, как и в любой подобной сфере, это управление (по убыванию важности) а) рисками, б) коммуникациями, в) ожиданиями заказчика. Все остальное — в т.ч. методологии разработки, жизненные циклы и пр. — всего лишь
Управление рисками означает заранее знать и понимать, что может пойти не так, где, почему и, соответственно, принимать либо упреждающие, либо корректирующие воздействия. Соответственно, без знания специфики и нюансов IT-разработки тут делать нечего — неофит будет просто не знать, что именно может пойти не так.
Управление коммуникациями — это вообще классика (см. известную картинку с качелями «Как хотел заказчик»). Если не знать, где и почему один член проекта может не так понять другого — опять же ничего не сделаешь.
И только управление коммуникациями более-менее нормально ложится на предыдущий опыт — естественно, если он из хотя бы как-то приближенной сферы.
Поэтому, лично мне видится единственная рекомендация — роль помощника PMа или аналогичная. Покрутиться на проектах, посмотреть как дела делаются и что может идти не так — и уже после этого думать о соло.
viru0
18.05.2015 16:54А я не доверяю PM, кто предметную область не знает. Ну серьезно как ты можешь управлять моей работой, ставить приоритеты, если ты не знаешь из чего вообще работа состоит.
Harret Автор
19.05.2015 06:45+1Кстати, на эту тему есть как свои «за», так и некоторые «против». Не все так однозначно или, если хотите, здесь нет черного и белого. На финальную эффективность могут повлиять многие внешние факторы (факторы среды и окружения).
S_A
19.05.2015 06:45Все так, единственное что наличие «союзников» в УП можно узаконить ;) В уставе проекта прописать иерархию ответственных за предоставление тех. информации. Понятно что это не гарантирует её, информации, предоставление, но софт скиллс на то и софт, чтобы подать такое назначение как крутую штуку: «в этом важном для компании проекте необходимо задействовать все наши навыки в полной мере и для этого в уставе прописано, что ты Вася, теперь будешь организовывать предоставление актуальной технической информации блаблабла».
Gradiens
19.05.2015 17:31Если не-айтишный да еще внешний менеджер будет сам набирать команду — это отличный способ абортировать любой проект.
Поэтому рассматривается только случай, когда менеджера приставляют к более-менее готовой команде, не так ли?
Айтишникам (в силу специфики) крайне важно, чтобы менеджер был уважаемым опытным экспертом. Они гораздо более чувствительны (кто-то даже может сказать — разбалованы) и не станут в полную силу работать под человеком, которого не уважают. Некоторые из них вообще предпочтут уволиться.
И вот как пришедшему снаружи менеджеру не-айтишнику завоевать уважение? Даже если каким-то чудом он не будет путать UML и XML, отсутсвие знаний предметной области вызовут у спецов лишь раздражение. И чем круче спец — тем больше его раздражение незнайкой, которого посадили на его голову.
Т.е. неформальные лидеры внутри команды, на которых, по идее, должен опираться менеджер, как раз-таки сходу будут отторгать технически неграмотного начальника.
Я даже представить не могу, насколько феноменальные должны быть у такого менеджера Soft Skills, чтобы привлечь на свою сторону крутых технарей и возглавить команду.Harret Автор
19.05.2015 22:12Тема завоевания уважения — это тема отдельной статьи. Разве IT-управленец уважение команды получает автоматом? Нет. Ему точно также приходится его завоевывать. И в данной ситуации на старте все равны. Кому-то будет легче в процессе, а кому-то труднее. В то же время знание и умение отличать UML от XML — никак на уважении не сказываются, ибо зоны ответственности менеджера и разработчика — сильно отличаются. Это разработчику как раз положено понимать такое отличие, а начальник за другое отвечает (к примеру за своевременную выплату зарплаты этому разработчику). И для зоны ответственности руководителя — отличать XML от UML — зачастую не требуется. Да, такое знание поможет говорить на одном языке с подчиненными, но только поможет. А может и не помочь, как мы можем наблюдать в сотнях и тысячах проектных команд.
И вот ровно для того, чтобы технические лидеры команды не отторгали начальника — он как раз и должен обладать просто обычными Soft Skills и быть вменяемым и толковым человеком (грамотность в тех-части — не является критически обязательной для такого отторжения или принятия).
Думаю, нужны еще статьи на эту тему…
ServPonomarev
Я всегда поражался дубовости менеджеров, выросших из программистов. Теперь знаю, что это — недостаток Soft Skills. Век живи — век учись.