Почему вам лучше не работать проджектом

Часто слышу от людей, которые только хотят войти в IT, что “если ты гуманитарий, а в QA идти не хочется, то есть один путь – в менеджеры проектов”. Им кажется, что рабочий день выглядит так: провел 2-3 встречи, выпил 3 чашки кофе, построил Гант, промотивировал команду и можно идти домой.

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

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

На бумаге и на курсах по проектному управлению проджектов представляют адептами Святого Треугольника (бюджет/сроки/содержание), которые ежедневно управляют этими тремя составляющими и при этом неуклонно следят за Качеством – сердцем треугольника. Так-то оно так, но зачастую проджекты в IT сталкиваются на практике со следующим:

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

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

Какие же вещи наиболее стрессовы и с которым точно столкнется начинающий проджект?

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

Я знаю людей, которые нервничают, если им надо выбрать бар на вечер, если вы один из них – в выборе карьеры подумайте еще раз :)

Чтобы управлять неопределенностью вы должны научиться: собирать непротиворечивые требования у бизнеса, писать подробные ТЗ, управлять ожиданиями заказчиков. Избавится от стресса совсем вряд ли получится, задумайтесь об регулярной физической активности в жизни, это очень сильно снижает напряжение.

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

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

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

Чтобы разруливать всё грамотно, то нужно будет балансировать между интересами сторон, находить компромиссы, укреплять горизонтальные и личные связи со всеми участниками, налаживать процессы и устранять “узкие горлышки” в них. Очень поможет, если у вас есть прокачанные технические знания, что позволит доносить запросы заказчика сразу в нужной форме до разработчиков, так потери информации будут минимальны.

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

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

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

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

Если у вас есть опыт работы проджектом и вы уже сменили профессию, либо наоборот, влюбились в неё еще больше – оставляйте комментарии, интересно послушать ваше мнение о профессии.