Рубашки
Профессия менеджер проектов. Профессия менеджер проектов Будьте отличным коммуникатором

Профессия менеджер проектов. Профессия менеджер проектов Будьте отличным коммуникатором

СЕМЕН
8 лет в IT: 3 года разработчиком и 5 лет менеджером проектов.

В чем суть работы проектного менеджера?

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

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

Какие нужны навыки и знания?

Английский язык - must have для любого специалиста в IT. Если не можешь говорить с заказчиком на одном языке, от тебя мало пользы.

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

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

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

Конечно, проектному менеджеру не обязательно быть программистом, но знать основы желательно. Не обязательно, потому что основы проектного управления в любой сфере примерно одинаковы. Но в IT знать предметную область хотя бы в общих чертах нужно. Во-первых, это поможет быстрее работать с командой разработчиков проекта и доступнее им объяснять, что и как хочет реализовать заказчик. Во-вторых, это сэкономит время и самим клиентам: если чего-то в рамках проекта сделать нельзя, вы сразу им об этом скажете или предложите подходящую альтернативу.

Чем отличается хороший проектный менеджер от посредственного?

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

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

АНТОН
В IT 11 лет: 2 года разработчиком, 9 лет в менеджменте.
Сейчас живет и работает в США.

Что нужно, чтобы стать проектным менеджером в IT?

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

Вообще, мне нравится придерживаться позиции Project Management Institute (PMI), который занимается разработкой и стандартизацией методов управления проектами. У них есть кодекс профессиональной этики менеджера проектов. По сути, все сводится к четырем качествам: ответственность (responsibility), уважение (respect), справедливость (fairness) и честность (honesty).

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

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

У кого учиться?

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

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

Полезно посещать менее формальные митапы, где можно свободно пообщаться с опытными менеджерами на заданные темы. Например, можно сходить и к Кириллу Бараношнику , который регулярно организует митапы People v Process . Он приглашает менеджеров проектов не только из Беларуси, но и из-за границы. Обычно meet-up посвящен одной конкретной теме или проблеме, которую можно обсудить со спикерами.

Немного двойственное отношение у меня к сертификату Certified Scrum Master и к тренингу, который необходимо пройти для его получения. С одной стороны, для меня такой тренинг в 2012 году стал настоящим толчком к настоящему понимаю Scrum и Agile, которого у меня не было после самостоятельного прочтения нескольких книг и статей. С другой стороны, я встречал немало людей как в Беларуси, так и в США, которые получили этот сертификат и прошли тренинг, но сути Agile так и не поняли. Думаю, в данном случае результат сильно зависит от личности тренера.

«Библия» проектного менеджмента - Project Management Body of Knowledge (PMBOK), издаваемая уже упоминавшимся институтом PMI. Она содержит описание всех процессов и областей знаний, используемых в управлении проектами. Начинающим я бы ее не рекомендовал - книга написана сухим формальным языком, напоминающим даже не учебник, а скорее правила дорожного движения. Читая строгие определения процессов, техник, инструментов, входной и выходной информации, сложно понять, о чем идет речь, если не сталкивался с этим раньше не практике. В то же время книга очень полезна тем, кто уже имеет несколько лет опыта за плечами: она позволяет «разложить по полочкам» весь имеющийся опыт и общаться на одном языке с менеджерами из любых стран.

Могу порекомендовать ресурс Stratoplan . Это совместный проект Александра Орлова и Вячеслава Панкратова - двух известных проектных менеджеров из России. В отличие от PMBOK, Stratoplan фокусируется на так называемых soft skills, т.е. навыках работы и общения с людьми. Как показывает практика, это самая сложная часть управления проектами. На сайте можно записаться на заочное обучение, онлайн-обучение или занятия с личным тренером, а также просто купить доступ в библиотеку с материалами. Если пока не хочется тратить деньги, можно лишь подписаться на почтовую рассылку (иногда в ней сообщают об интересных предложениях и акциях, в том числе бесплатном доступе к материалам) или почитать блог.

Из книг стоит обратить внимание на «Deadline. Роман об управлении проектами» Тома Демарко и Тимоти Листера . Книга написана в форме художественного произведения - похоже на обычную повесть, только из жизни менеджера. Хотя я бы не сказал, что художественные достоинства у книги велики, но зато есть дельные мысли о том, как следует относиться к проекту и к людям.

Есть еще несколько книг, которые считаются краеугольными камнями профессии проектного менеджера: «Мифический человеко-месяц» Фредерика Брукса и «Путь камикадзе» Эдварда Йордона . Идеи в них правильные и полезные, но они сильно растянуты по тексту. К тому же есть много деталей, которые на сегодня уже устарели. Например, там советуют записывать все, что происходит на проекте, в тетрадь. Разумеется, сейчас так уже никто не делает. Но по основным идеям книги все еще верны.

Научиться более грамотному управлению временем мне лично помогла книга Getting Things Done («Как привести дела в порядок») Дэвида Аллена . Она о том, как организовывать свое время. И речь идет как раз о письмах, задачах. Это типичная проблема, с которой сталкивается любой проектный менеджер: на почту начинают сотнями валиться письма, в Skype кто-то пишет, в Viber куча непрочитанных сообщений - и все одновременно. С этой же проблемой поможет тренинг Максима Дорофеева «Джедайская техника пустого инбокса».

АНДРЕЙ
19 лет в IT: 10 лет в программировании, 9 лет в проектном менеджменте.

Что нужно делать начинающему проектному менеджеру?

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

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

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

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

Будьте гибкими. Все люди разные, у каждого свои сильные и слабые стороны. Откройте их в своей команде. Принципы взаимодействия с командой должны меняться. Невозможно всегда быть только командиром или только другом. Нужно уметь поддерживать и вдохновлять команду, но в отдельных ситуациях придется быть и жестким.

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

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

Здесь.

Фото: сайт, личный архив героев.

ЗАО «Итранзишэн», УНП 190654745

Какими навыками должен обладать руководитель проектов и как их приобрести. Должен ли 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 студентов, прошедших обучение на его семинарах.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Карьера в IT-индустрии