Какими навыками должен обладать руководитель проектов и как их приобрести. Должен ли PM хорошо разбираться в предметной области того проекта, которым он руководит. Об этом – в колонке нашего эксперта Максима Якубовича.

Начнем с того, зачем становиться руководителем проекта?

1. Спрос на профессионалов в этой сфере растет.

Согласно исследованиям PMI (Project Management Institute) к 2020 году количество вакансий в 10 странах с растущим спросом на проектных менеджеров возрастет с 13,4 миллионов до 41,5 миллионов рабочих мест.

2. Зарплата у руководителей проектов весьма приличная. Вот, например, данные в ИТ-сфере.

Источник: dev.by, данные за июнь-сентябрь 2014 года, в долларах США

3. Работа руководителя проекта - это постоянный вызов и драйв, предполагающий также и высокую ответственность.

Какими компетенциями должен обладать руководитель проекта?

На мой взгляд, они следующие:

1. Умение собирать правильных людей и создавать из них команду.

Это подразумевает:

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

2. Навыки ведения переговоров.

3. Умение повести за собой.

4. Умение выбрать более подходящую методологию (или их симбиоз) управления проектом для конкретного проекта и адаптировать ее под команду и окружение проекта.

5. Навыки использования и внедрения нескольких программных продуктов по управлению проектами.

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

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

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

Для развития этой компетенции можно посещать различные тренинги по коммуникациям и постоянно тренировать полученные знания, превращая их в навыки.

Третий навык, который стоит развивать РМ, - это умение повести за собой (или лидерство). Этот навык, на мой взгляд, можно «прокачать». О том, как стать лидером, пишут книги, этому учат на семинарах и тренингах.

Четвертое, о чем стоит побеспокоиться, - это опыт использования нескольких методологий управления проектами, желательно как минимум одной тяжелой и одной гибкой. Речь идет о реальном использовании методологий на проектах, а не изучении их по книгам. Чем больше методологий знает РМ - тем лучше для его команды. Он сможет выбрать более подходящую методологию (или интегрировать несколько методологий) для проекта и адаптировать ее под команду и окружение проекта.

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

Многих, как и меня в свое время, интересует вопрос: «А должен ли PM разбираться в предметной области того проекта, которым он руководит?» . Большинство людей скажет «да». А я не соглашусь. Эти знания не помешают, но они не являются необходимыми. Если руководитель проекта никогда не программировал, это не значит, что он не сможет привести к успеху проект по разработке софта. Ему достаточно найти помощника (технического лидера), который разбирается в программировании, и выстроить с ним доверительные отношения так, чтобы он занимался технической частью проекта, а РМ - командой, план-графиком, бюджетом проекта и т.п.

Итак, как вы можете стать проектным менеджером?

Начинать надо с управления небольшим проектом (команда 2-5 человек, срок - от полугода до года). В этом проекте нужно отладить процессы управления, попробовать инструменты, которые будут уместны, поработать над командой, автоматизировать управление проектом.

По окончании проекта нужно обязательно провести обзорное совещание проекта и написать для себя документ «Усвоенные уроки» (чему вы научились, какие ошибки допустили и что бы вы сделали по-другому).

Следующий проект можно уже брать немного крупнее с точки зрения масштаба. Я считаю, что после 6-7 успешных (или «условно успешных») проектов PM уже созревает для проекта «миллионника» (с бюджетом трудозатрат в $1 млн) и ему можно сертифицироваться на уровень профессионала в управлении проектами по какой-нибудь из систем сертификации. По сути, имея такой багаж опыта, и получив выше описанные навыки, он становится зрелым руководителем проектов.

Замечу, что все, что написано выше, - всего лишь мой личный взгляд на роль руководителя проекта через призму двух десятков проектов, выполненных в этой роли. Если у вас другая точка зрения - я с удовольствием ознакомлюсь с вашими комментариями.

Максим Якубович

Эксперт по управлению проектами, консультант и бизнес-тренер консалтинговой группы «Здесь и сейчас».

Опыт работы в сфере управления проектами - более 10 лет.

20 выполненных проектов в роли руководителя проекта и руководителя программы проектов.

Опыт преподавания - 8 лет. Около 2000 студентов, прошедших обучение на его семинарах.

Преподаватель модуля «Управление проектами» Русской школы управления.
Приглашенный преподаватель курса «Управление проектами» в Британской Высшей школе дизайна.
Ведущий

Какой бы ни была область специализации вашей организации, важно понимать это различие.

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

1. Будьте лидером и руководителем

Лидеры сообщают общие перспективы (некоторого будущего состояния); они добиваются согласия и устанавливают направление вперед. Они мотивируют других. Руководители стремятся к получению результатов и сосредоточиваются на выполнении работы относительно согласованных требований. Хороший руководитель проекта будет постоянно переключаться от лидера к руководителю, как того требуют ситуации.

2. Будьте формирователем и руководителем группы

Так как проекты нередко многофункциональны, они используют людей, которые могли не работать до этого вместе. Руководитель проекта должен задавать тон группе и вести ее через различные фазы развития до того момента, когда члены группы будут работать как одна команда. Нередко люди из группы имеют своих непосредственных начальников, и руководитель проекта не имеет подразумеваемых полномочий – однако он должен мотивировать человека. Это особенно верно в матричной организации.

3. Будьте решателем проблем

Это навык, который можно освоить: это всего лишь требует проведения небольшой "сыскной" работы заранее! Сначала нужно определить возможные причины, приведшие к появлению проблемного симптома. Причины могут происходить из множества источников, в числе которых:

• Межличностные проблемы
• Внутренние источники
• Внешние источники
• Технические источники
• Административные источники
• Коммуникация
• Мнения или восприятия

и так далее. Следующий шаг после выявления основных причин – анализ возможных вариантов и альтернатив, и определение лучшего метода действий, которые следует предпринять. Тщательно согласуйте, что в данном случае означает «лучший» на самом деле!

4. Будьте переговорщиком и источником влияния

Переговоры – это работа вместе с другими людьми с целью прийти к совместному соглашению. Это не обязательно должно быть силовое противоборство глаза в глаза, о котором вы могли подумать! Например, необходимость убедить одного из группы работать допоздна, чтобы успеть закончить работу к предельному сроку, в то время как он хотел бы пойти на бейсбол. Для этого вы должны иметь определенные навыки влияния. Влияние – это способность заставить события произойти, убеждая другого человека, что ваш метод – это лучший метод, даже если это его не устраивает. Сила влияния – это способность заставлять людей выполнять вещи, которые они не стали бы делать в противном случае.

5. Будьте отличным коммуникатором

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

6. Будьте хорошим организатором

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

7. Будьте компетентным и последовательным планировщиком

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

1. Планы – это всегда документы. Не впадайте в заблуждение, что, например, диаграмма Ганта является планом – это только лишь календарный график.
2. Успешные проекты выполняются успешными группами. Всегда используйте помощь группы при создании плана, если только нет веской причины не делать этого, такой как коммерческая тайна или условия контракта.

8. Создавайте бюджеты и управляйте ими

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

Частью плана проекта будет нечто под названием план расходов. Он будет показывать запланированные расходы по отношению к временной шкале. Руководитель проекта будет участвовать в закупках, назначении цен, согласовании счетов, табелей учёта рабочего времени, расходов на зарплату, и т.д. Затем руководитель проекта должен установить, что на самом деле произошло по сравнению с тем, что было запланировано, и предсказать ожидаемую конечную стоимость. Обычно помогают инструменты учета и управления проектами, но помните правило "мусор на входе - мусор на выходе"!

Были кратко рассмотрены основные сферы. Если вы новичок в управлении проектами, то пусть все написанное здесь не сбивает вас с толку. Существуют широко распространенные методологии, инструменты, руководящие принципы и процедуры, которые помогут вам в развитии важных навыков управления проектами.

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

Наверное, я не открою ничего нового, но все-таки постараюсь написать и как-то показать на собственном примере “как это было”.

Первое, что нужно сделать – определиться со своей мотивацией. Что стоит за фразой “быть руководителем проектов” для вас? В вашей компании это часть органического роста специалиста, и если вы из аналитика или разработчика не стремитесь в РМы – вы унылы и неперспективны? Вы считаете, что это “стильная-модная-молодежная” профессия, а уметь там ? Вы слышали, что РМам много платят, особенно если получить сертификат? Вы всегда хотели командовать людьми, и это отличная возможность?

К сожалению, все вышеперечисленное и его бесконечные вариации – это путь в никуда и вообще тупик. Разочарую, но хороший специалист чаще всего зарабатывает больше руководителя проекта, уметь там надо много всего (а особенно – принимать решения и брать за них ответственность). Если говорить про перспективы – то за рубежом, в отличие от хорошего разработчика, вас никто не ждет и вряд ли когда-то будет ждать (по крайней мере в ИТ, там своих хватает). Да и покомандовать не выйдет, так как либо вы работаете на стороне подрядчика в проектной организации (и вами командует заказчик, а если вы все совсем плохо изначально построили – то и вашими людьми тоже, которые к тому же вам линейно не подчиняются) либо на стороне заказчика в 99% случаев в матричной или, если совсем не повезет, функциональной структуре, где власти ноль, а ответственность вся на вас. Не передумали?

Если нет, то вот примеры хорошей мотивации – вам нравится организовывать работу людей, вы любите динамично меняющуюся рабочую среду, вы “непроцессный” человек, и хорошо работаете именно на результат, в процессе вам скучно и грустно, вы хотите вести людей за собой за счет личной харизмы, а не приказа генерального директора, вы хотите создавать что-то новое и проч.

Для тех, кто знаком с методологией оценки личности по DISC – на мой взгляд, идеальные РМы – это D, DC и DI, и опыт подсказывает, что остальным типам личности в проектах скучно, страшно и грустно.

Для меня в свое время мотивацией переквалифицироваться в РМа стало то, что сидеть и писать код на C# мне было скучно, не хватало общения с людьми, вызова, организационной работы и динамики.

Во-вторых – нужно определиться с отраслью. Я вот со страхом смотрю на то, что сейчас появились целые университетские программы по управлению проектами, не привязанные ни к какой отрасли. Это настолько бессмысленно и беспощадно, что просто слов нет. Управления проектами самого по себе не существует, и PMBOK вам тут не поможет. Необязательно быть супер-пупер-специалистом в какой-то среде, но либо бы работаете в ИТ, либо в стройке, либо в маркетинге и проч. Руководитель проекта обязан хорошо разбираться в своей отрасли, чтобы адекватно оценивать риски, трудозатраты, цены и проч.

Переход из отрасли в отрасли возможен, но сложен, долог и дорог. Например, несмотря на PMP, блог, два и прочие плюшки – проект строительства многоэтажного дома я потяну разве что в роли администратора проекта, и то вряд ли сразу буду в ней эффективна. Но при этом данный пункт часто понимается HR превратно, когда на внедрение системы, скажем, управления поездками, начинают искать PMа “обязательно делавшего такой же проекта в компании такого же профиля”. Все-таки отрасль – понятие более широкое, в данном случае – им вполне подойдет грамотный руководитель ИТ-проектов, даже если он до этого внедрял только программное обеспечение в банках.

Мне везло, всегда попадались хорошие руководители, понимавшие, что “идеального РМа, уже сделавшего точно такие же проекты, которые мы тут будем делать ближайшие 5 лет” не существует. Да и вообще адекватных руководителей больше, чем кажется, на мой взгляд.

В-третьих – смириться с тем, что оставаться специалистом и при этом быть профессиональным руководителем проектов не выйдет. Или-или. Либо вы разрабатываете, либо руководите. Первые пару лет возможно некое совмещение, но выбор делать все равно придется, так как со временем эти два стула будут все больше отдаляться друг от друга. Если не сделать его вовремя – то вы закончите плохим специалистом и очень плохим РМом, а оно вам надо? Если вы не готовы расстаться с мыслью, что писать код вы теперь будете только дома под пиво в качестве развлечения – дважды подумайте, становиться ли руководителем проектов.

Я где-то полгода тащила это “чемодан без ручки”, пытаясь оставаться и аналитиком, и совершенствоваться как РМ. Не вышло. И да, если в компании такое совмещение принято – то при достижении определенного уровня компанию придется поменять, если вы хотите развиваться.

Если первые три пункта не отбили у вас желания стать руководителем проектов, то четвертый пункт – это ознакомиться с теорией (пока у меня не дошли руки сделать подборку книжек, но гугл по запросу “книги по управлению проектами” предложит достаточный выбор). Как минимум можно начать с “Цели” Голдратта, двух-трех вебинаров про проектное управление и “Проекта Феникс” (чтобы понять, сможете ли вы выжить в этой среде перманентного стресса). Если толстые книжки не пугают – то можно и PMBOK попробовать прочитать, если осилите и разберетесь – это будет огромным плюсом (советую в процессе чтения перерисовывать его в форме MindMap для наведения порядка в знаниях).

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

Жаль, поискала, но не смогла найти фото своего ватмана со схемой тогда еще еще 3го PMBOK, который я когда-то рисовала еще в общаге, прямо ностальгия нахлынула. Когда руками рисуешь, а не в компьютере – какая-то нежность появляется, даже к таком монстру, как PMBOK.

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

Мне когда-то после этой просьбы доверили проект по оптимизации формы ввода данных для специалистов нашего контактного центра, и это было очень круто и интересно! Я, по-моему, месяца три ночевала на работе, успела достать весь колл-центр, но в итоге скорость ввода данных в новую форму выросла на 40% по сравнению со старой, за чем и последовал мой официальный переход на должность РМа. Кстати да, не забудьте обговорить ожидаемые результаты проекта, что бы потом не было вопросов.

Ну и шестой шаг – найти работу руководителя проектов. Опять же, если вы сделали проект на работе – можно поговорить об этом с руководителем, постепенно начать брать на себя все более сложные задачи и потихоньку расти. Если вы делали проект “в ящик” – самое время его достать, подчеркнув в нем то, что , и . Пока ищете работу – по возможности сделать еще несколько проектов и почитать еще книжек. А также подготовиться к тому, что стресса и динамики в жизни теперь будет гораздо больше.

К сожалению, если вы переходите с позиции специалиста – на данном этапе возможно снижение уровня доходов, так как вы были очень хорошим специалистом, но пока еще не очень хороший РМ. Но все в ваших руках!

Я в свое время при переходе с позиции аналитика потеряла процентов 20 в зарплате, так как до этого мой KPI складывался из моей личной производительности, а теперь – из производительности всей команды, где отнюдь не все были мотивированы так же сильно, как и я. Восстановление до прежнего уровня заняло месяца четыре, через год доход практически удвоился.

Ну вот и все, если вы дочитали до этого пункта и все выполнили – вы теперь РМ. Поздравляю!

Важно! На каждом шаге желательно возвращаться к п.1, проверяя себя на то, что мотивация все еще сохраняется. Если на каком-то этапе вы ловите себя на мысли “ну зачем все это, а” – может, лучше остановиться и подумать? Я знаю много людей, которые годами работают PMами, как-то случайно туда попав. Работают плохо, не справляются, меняют работодателей, но все равно, однажды ошибившись, продолжают кушать кактус, так как это они умеют плохо, но больше не умеют ничего. Не повторяйте этой ошибки, если это не ваше – то лучше уйти как можно раньше.

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

Так получается, что со мной периодически связываются мои знакомые и знакомые моих знакомых, которым меня порекомендовали, с примерно одним и тем же вопросом: «Как мне стать 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-отрасли и специфики компании

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

Мое мнение, что без погружения в 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.: оригинал этой статьи (и другие интересные материалы) можно прочесть в моем блоге:

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

Так получается, что со мной периодически связываются мои знакомые и знакомые моих знакомых, которым меня порекомендовали, с примерно одним и тем же вопросом: «Как мне стать 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-отрасли и специфики компании

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

Мое мнение, что без погружения в 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.: оригинал этой статьи (и другие интересные материалы) можно прочесть в моем блоге: