Готовы работать non-stop? Кто такой Project Manager и как устроен типичный рабочий день

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

Работа полицейского — это не сплошные погони. Не все журналисты каждый день интервьюируют селебритиз в роскошных интерьерах. Шеф-повар ресторана не ежедневно готовит для президента.

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

Можно искать ответы в себе на следующие вопросы:

• Было ли мне интересно заниматься такими или подобными делами каждый день на протяжении многих лет?
• Смогу ли я использовать в такой работе свои сильные стороны?
• Каких навыков мне недостает, чтобы эффективно выполнять такую работу и можно ли их где-то получить?

Что делает PM

Итак, один день из жизни проектного менеджера в IT.

10-00. Открыла ноутбук, прочла личные сообщения в рабочих мессенджерах и почту.
Ничего, что имеет критическое влияние на проектные планы, не увидела. Ответила на все письма, которые потребовали до 5 минут на ответ и еще на одно письмо от руководителя, на которое нужно было ответить до обеда.
Работать с другими буду в течение дня.

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

11-30. На встрече с командой прояснили немаловажную деталь технической реализации одного модуля. Об этом следует написать заказчику. Решение, о котором мы раньше с ним договаривались, приведет к снижению перфоманса отдельных операций для определенных пользователей. Ему это не понравится. Хорошо, что у техлида есть видение, как это можно обойти, но новая реализация требует немного больше времени. Пишу письмо, где кратко описываю проблему и возможные решения и предлагаю встретиться на 15 минут в ближайшее время, чтобы обсудить ситуацию и определиться с финальным вариантом.

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

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

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

13-00. Возвращаюсь к чеклисту по истечении испытательного срока.
По окончании отправляю его эйчару.

14-00 — 15-00. Перерыв на обед. Чтобы немного переключиться и подзарядиться, лучше выйти подышать воздухом, чем заниматься думскролингом. Игнорирую этот совет себе, жадно читаю новости и заметки по менеджменту в телеграм-каналах.

15-00. Подготовка к еженедельной встрече с заказчиком. Ведь я отправила заранее. Теперь хочу добавить обсуждение той технической проблемы с перфомансом и собрать свежие метрики по качеству для обсуждения с клиентом.

15-30 — 16-30. Встреча с клиентом. Все важные вопросы обсудили, прогресс рассказали и отчасти показали.
Заказчик согласился на временные проблемы с перфомансом, потому что для него важнее вовремя сделать релиз. Запланировать работу по техническому долгу на следующий спринт. Метриками по качеству клиент доволен. Дефекты теперь «живут» меньше, получаем меньше отчетов о багах от конечных пользователей и за последний месяц существенно увеличили покрытие интеграционными и автотестами важных элементов системы.

16-30. Встреча лицом к лицу с тестировщицей. Обсудили профессиональное развитие, жалобы на отдельные процессы, вопросы, которые стеснялась задать при всех. Вижу, что человек устал. Договорились, что после релиза возьмет несколько дней отпуска, чтобы немного отдохнуть. И что в следующем релизе поищем новые задачи для нее, которые помогут быстрее прокачивать навыки, которых пока не хватает. Записываю договоренности себе в систему, чтобы не забыть о них и промониторить выполнение следующей недели.

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

18-15. Документирую договоренности с заказчиком на нашей сегодняшней встрече. Отсылаю meeting minutes (протокол встречи) письмом, прошу проверить других участников, что все правильно записала. Также дублирую эту информацию на Confluence, чтобы у всех заинтересованных сторон был доступ к этой информации и сохранилась для истории.

18-45. Планирую на следующий день. Завтра будет интервью разработчика к нам на проект — планируем ротацию специалиста, который уже профессионально перерос наш проект и стремится к новым вызовам.

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

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

Вы все еще читаете? Тогда предполагаю, что рутина менеджера вас не испугала, и теперь вы нуждаетесь в большей полезной информации:

• какие требования к специалистам;
• какие обязанности ПМа;
• где можно научиться менеджменту и отличается ли менеджмент в IT от менеджмента в других индустриях;
• сколько ПМы зарабатывают и какой на них сейчас спрос и т. д.

Итак, начнем с требований к джуниорам специалистов:

1. Очень хороший английский. Хотя бы upper-intermediate.
   По моему мнению, это не опционально. Без классного английского ваши коммуникационные навыки ничего не стоят — вы просто не сможете ни требование клиента понять, ни рассказать членам команды из других стран, ни письма грамотного написать.
2. Опыт управления людьми для достижения целей. Достаточно сложно научить работать с людьми с нуля. Когда ты имеешь дело с кандидатом, который уже работал с мотивацией сотрудников, контролировал производительность, ставил задачи и принимал их, решал конфликты и т. д. — это добавляет кандидату много баллов в глазах рекрутера или менеджера по найму.
   Даже если этот опыт не из IT-сферы, он все равно релевантен, его следует вписать в резюме и подчеркивать, что вы умеете работать с людьми.
3. Знание менеджмент терминов, инструментов и практик.
   Если вам ничего не говорят такие термины как диаграмма Ганта, нефункциональные требования, критический путь, оценка рисков, метрики по качеству и т. д., то вам точно следует посвятить хотя бы несколько месяцев обучению, прежде чем пытаться трудоустроиться.
   Также много лет в IT сфере тренд на работу в Agile-парадигме, которая позволяет быстро и эффективно выводить на рынок программное обеспечение. Поэтому разобраться с итеративно-инкрементальным подходом к разработке будет не лишним. Скорее всего, вас будут спрашивать на собеседовании о ключевых принципах этого подхода, как планировать работу, контролировать прогресс и проводить типовые встречи или церемонии типа ретроспектив, груминг (или refinement), демо и т. д.
4. Technical awareness. Представьте, что вы пытаетесь управлять фитнес-клубом, но не знаете разницы между функциональной тренировкой и пилатесом, не представляете, в чем заключается работа тренера в тренажерном зале и не можете объяснить потенциальному клиенту разницу между типами ваших абонементов. Вы будете эффективным администратором? Также вам нужно понимать, из чего состоит процесс разработки программного обеспечения хоть на высоком уровне, чтобы говорить с девелоперами на одном языке и оценить масштаб проблемы или варианты решений.
   
   Мой опыт показывает, что статьи или видео в интернете являются не очень эффективным способом нетехническому специалисту разобраться с процессом создания программного обеспечения.
   
   Довольно действенно себя показывают курсы для начинающих программистов, где объясняют, что такое IDE, репозиторий, фреймворк и т. д. Но действительно ли ПМу нужно написать маленькую программу, чтобы понять на базовом уровне с чем работают программисты? Я считаю, что нет. И если выбирать, чему учиться будущему руководителю, то я все же голосовала бы за «менеджмент», а не за «программирование». Поэтому предлагаю вариант, который может дать необходимые ответы и не отнимет у вас месяцы жизни.
   
   Уверена, что у каждого в окружении есть друг-разработчик, который не откажет вам в услуге показать, как он работает. Тогда вы собственными глазами увидите, как выглядит интегрированная среда разработки, как работать с хитом, что такое база данных и т. д.
   
   После того за чашкой чая можно еще его расспросить о клаудах, CI/CD, интеграционных и юнит тестах, клиент-серверной архитектуре, разнице между мобильной нативной разработкой и кросс-платформенными решениями, практиках peer review, инструментах для статического анализа кода и т. д.
   
   Конечно, за один день все не получится запомнить и постичь. Но дальше вам будет проще изучать статьи или видео, чтобы разобраться на достаточном для ПМА уровне.
5. Высокая мотивация быстро учиться и преодолевать трудности. Сколько бы профессиональной литературы вы ни прочитали или курсов не закончили, вы не подготовитесь ко всем возможным ситуациям на работе в качестве ПМа IT-проекта. У вас впереди много стресса. Вам точно оно нужно?
   Демонстрируйте готовность инвестировать много времени в собственное профессиональное развитие. Да, возможно вы еще чего-то не знаете или не умеете, но вы приложите все усилия, чтобы быстро научиться и стать профессионалом.
   
   Поздравляю, вы прочли половину этой статьи. Возможно, ваша заинтересованность в профессии руководителя проектов в IT подлинная. Тогда предлагаю обсудить ключевые обязанности и зону ответственности ПМА.

Обязанности и ответственность ПМА

За что отвечает ПМ на проекте? Простой и быстрый ответ — за всё.

1. Разобраться, что нужно клиенту.
   Для этого ПМ должно разбираться в требованиях, уметь их прояснить, задокументировать и знать приоритетные техники, чтобы помочь клиенту определиться с очередностью разработки, если все-все не вмещается в релиз.
   — Оу, так это для бизнес аналитиков, а я вообще собираюсь стать проектным менеджером, — можете сказать вы.
   Что ж, спасибо за этот своевременный комментарий. И, во-первых, бизнес-аналитики не идут по умолчанию на каждый проект, и вам лучше быть готовым к сценарию, где эта функция ляжет на ваши плечи. Если вы будете начинать свой профессиональный путь в небольшой компании, то там BA — это скорее исключение.
   Во-вторых, даже если вам удалось иметь BA в команде, вам все равно следует понимать, что он/она делает, уметь дать обратную связь по работе, предложить просмотреть подходы, если избранные не работают, и т. д. Лишними эти знания не будут.
2. ПМ отвечает за своевременные поставки клиенту качественного продукта.
   Для этого нужно уметь: оценивать работы, считать бюджет, планировать выполнение работ, работать с рисками, определять критерии качества, контролировать выполнение плана и т. д.
3. Создание здоровой рабочей атмосферы в команде. Команда, в которой каждый знает свою роль и профессионально выполняет свои функции. Где взаимоуважение и работа на общий результат. Где люди мотивированы, развиваются, не боятся обращаться к коллегам за советом. Где нет носителей уникальных знаний, где новички быстро адаптируются, где желание постоянно улучшаться.
   — Утопия, — возможно прокомментируете вы. Сознательная и профессиональная работа с людьми — отвечу вам я. Теория мотивации, управление конфликтами, командная динамика, матрица компетентностей, правильная обратная связь, целеполагание — это все не просто термины по теории управления персоналом. Это все менеджеру нужно понимать и применять в своей повседневной работе.
4. Развитие отношений с клиентом. Если с требованиями иногда помогает BA, с людьми HR, кто вас прикроет в коммуникациях с клиентами? Умение вести переговоры, презентовать идеи, понимать потребности и ограничения клиента, управлять ожиданиями и просто классно коммуникировать как письменно, так и вербально — вот этому надо учиться и отшлифовывать эти навыки на протяжении всей жизни.

Карьерный путь менеджера в IT

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

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

Senior PM — это тот, кто ведет сложные проекты с большими командами или управляет целыми программами в компании. Кто обучает и наблюдает за junior и middle PM-ами. Перед специалистами Senior-уровня обычно уже стоят бизнес цели, такие как получение новых клиентов, расширение существующего бизнеса, рост числа работников в компании и т. д.

Где учат ПМов

Во-первых, в университетах. Глубокое экономическое образование не будет лишним 😊 Сейчас университеты активно сотрудничают с IT-компаниями и приглашают практиков преподавать. Автор и сама регулярно работает со студентами отдельных вузов. Если это ваш кейс, берите максимум и ищите возможности получить управленческую практику в параллель. Работе с людьми научиться только по учебникам не получится.

Во-вторых, курсы. О, как много этого на рынке… Обычно они продолжаются около 3 месяцев, там галопам по Европам рассказывают все области знаний, редко проверяют домашние задания и дают персональную обратную связь. Такие курсы позволяют лучше понять, о чем профессия, изучить термины и ознакомиться с инструментами. Лучше чем ничего!

Для тех, кто умеет самоорганизовываться и держать дисциплину самостоятельно, есть множество вариантов на Coursera, Udemy и украинском Prometheus, в том числе бесплатных. Недостаток — не будет преподавателя, которому можно задавать вопросы, если это записанные курсы. Но это можно решить и другим путём. К примеру, найти себе ментора среди друзей-практиков.

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

Зарплаты

Компенсация для начинающих специалистов, согласно статистике на DOU и Djinni, составляет $500–600. Но на мой личный взгляд, на входе можно согласиться и на меньшее, потому что первые полгода это скорее о вашем обучении и куче инвестированного времени других специалистов компании в ваше развитие. Важно получить этот опыт управления проектами. Дальше будет легче, спрос на вас будет больше, и тогда уже можно поднимать вопрос о пересмотре зарплаты.

Что почитать

• Project Management For Dummies by Stanley E. Portny;
• Scrum and XP from the Trenches by Henrik Kniberg;
• Peopleware: Productive Projects and Teams по Tom DeMarco & Timothy Lister;
• Never Split the Difference: Negotiating As: If Your Life Depended On It by Chris Voss;
• Software requirements third edition by Karl Wiegers.

Слово напутствия

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

«Стартовая степень любого проекта». Кто такой Concept Artist и как им стать

По теме

«Стартовая степень любого проекта». Кто такой Concept Artist и как им стать

«Главный челлендж в работе — это уметь переключать фокусы». Кто такой Engineering Manager и как им стать: опыт айтишника с 15-летним опытом

По теме

«Главный челлендж в работе — это уметь переключать фокусы». Кто такой Engineering Manager и как им стать: опыт айтишника с 15-летним опытом

«Гемблинг, дейтинг, финансы, криптовалюты — это не полный перечень ниш, где готовы платить гораздо больше, чем в других сферах». Кто такой SEO-специалист и как им стать

По теме

«Гемблинг, дейтинг, финансы, криптовалюты — это не полный перечень ниш, где готовы платить гораздо больше, чем в других сферах». Кто такой SEO-специалист и как им стать

Читайте главные IT-новости страны в нашем Telegram

По теме

Читайте главные IT-новости страны в нашем Telegram