Работа проектного менеджера — это про постоянное жонглирование задачами и необходимость держать в памяти терабайты данных. А еще рабочий день PM'а в IT начинается задолго до того, как он стартует у команды.
Разобрались с Тарасом Федоруком, к каким челленджам нужно быть готовым, если вы проджект-менеджер, который хочет или перешел в IT из другой сферы (например, из маркетинга).
Тарас — Technical Program Manager в Booking.com и президент украинского представительства PMI. Прошел более 10 профессиональных сертификаций, в частности PMP (Project Management Professional) и PSM ІІ (Professional Scrum Master ІІ). Получил награды «Лучший руководитель проектов в IT» по версии Ukrainian IT Awards в 2019 году и PMI Rising Leader в 2022.
*Скоро у Тараса стартует онлайн-курс в Laba «Проджект-менеджмент в IT».
Как проджекту быстро адаптироваться после перехода в ІТ из другой сферы
Project Management Institute (PMI) определяет навыки менеджера проектов с помощью концепции «треугольник талантов PMI». Согласно ему проджект воплощает совокупность трех групп навыков:
- Ways of working: способы организации работы на проекте. Сюда относят навыки прогнозирования, гибкость, дизайн-мышление.
- Power skills: навыки и компетенции, которые способствуют эффективному сотрудничеству с людьми (эмпатия, активное слушание, построение доверия и умение работать в команде).
- Business acumen: навыки и компетенции, которые позволяют менеджеру проектов ориентироваться в индустрии или домене.
Если проджект-менеджер переходит в IT из банковской сферы, ритейла или любой другой, business acumen — то, к чему специалистам необходимо будет больше всего адаптироваться и заполнить пробелы в знаниях. Некоторые способы организации работы (ways of working) тоже нужно будет изменить, но не существенно, на уровне практик и отдельных подходов.
Вот 5 вызовов, к которым стоит быть готовым руководителю проектов в IT:
#1. Многозадачность и необходимость быстро реагировать на срочные задачи
Открыть глаза, взять телефон — проверка почты, если нет заголовков URGENT — пойти чистить зубы. Во время завтрака проверить почту, рассортировать. Ответить на URGENT. Приехать на работу, узнать, что в команде разработки сломалось сегодня. Понять, кто это будет чинить, и адресовать таски. Заняться бэклогом. Выяснить, кто будет чинить то, что сломалось только что. Адресовать. Заняться бэклогом снова.
Работа проектного менеджера — это всегда про многозадачность, внимательность и необходимость учитывать большие объемы данных. А еще бывает, что проджект ведет 3–4 проекта одновременно. Понятно, что человек просто физически не может одинаково хорошо работать над несколькими проектами параллельно и какой-то из них точно будет «отставать».
Чтобы избежать такой ситуации, нужно:
- Браться за проекты, которые находятся на разных стадиях жизненного цикла. Например, один проходит этап инициации, а другой уже подошел к завершению.
- Все записывать. Даже самое маленькое и незначительное дело нужно записывать, если вы не занимаетесь им прямо сейчас.
- Использовать таск-трекеры и сервисы для управления проектами: например, Asana, Active Collab, Basecamp, Trello, Monday, Notion. Согласно исследованию, 77% высокоэффективных проектов было реализовано с помощью программного обеспечения для проджект-менеджмента.
#2. Смена парадигмы заказчика
При переходе в IT из другой сферы, проджект-менеджерам не всегда удается изменить подход к работе в сторону взаимодействия клиента с подрядчиком.
Представим, что человек работал PMO в банке, занимался внутренними проектами. Его «клиентами» всегда были специалисты из того же учреждения. Это не то же самое, что работать на кого-то извне, кто заказывает продукт, платит вашей команде деньги и может в любой момент расторгнуть контракт, если что-то пошло не так.
#3. Завышенные ожидания и нежелание делать «откат» в карьере
Многие специалисты, переходя в другую сферу, убеждены, что имеют достаточно опыта и могут претендовать на аналогичные позиции на новом месте. Они не готовы воспринимать то, что на полноценный переход нужно как минимум 6–12 месяцев и что новая сфера — всегда про шаг назад.
Конечно, это не требует от специалиста соглашаться на позицию Intern/Junior Project Manager после работы директором проектов. Однако у вас все равно проверят общий объем знаний в индустрии и, вероятнее всего, переведут на Middle-уровень, даже если до этого вы были директором. Хотя вас, скорее всего, будут достаточно быстро повышать, по мере вашего погружения в новый бизнес и домен, а также овладения новыми способами работы.
#4. Сложность разработки проектной документации в IT
Одна из обязанностей PM'а в IT — фиксировать основные этапы работы над проектом и своевременно предоставлять фидбек команде, руководству и клиенту. В этом специалисту помогает документация. Она отличается в зависимости от проекта, IT-компании и подходов менеджера. В работе можно использовать собственные шаблоны или стандартизированные — все зависит от целей, договоренностей с клиентом, руководством и командой.
Три обязательных документа по версии лектора Laba:
- Устав проекта (Project Charter)
Это паспорт проекта, раскрывающий цели, требования, участников, ценность для бизнеса, структуру команды, базовые риски, ограничения на проекте. Project Charter создают для апрува основными заинтересованными лицами. Его обновляют на протяжении всего жизненного цикла проекта. Документ содержит цели, показатели успеваемости, перечень стейкхолдеров и роли, объем и бюджет, вехи, ожидаемые результаты и т. д.
- Данные о ходе работ (Work Performance Data)
Это начальные измерения и детали работы, собранные при выполнении проекта в любой форме. Эти данные позволяют делать объективные суждения о ходе событий и своевременно вмешиваться при необходимости. Примером будут служить фактические расходы бюджета, продолжительность работ, количество дефектов, запросов на изменения и т. д. - Выученные уроки (Lessons Learned)
Список рекомендаций, наработанных руководителем проекта во время работы. Эта информация призвана улучшить процессы управления и выполнения проектов внутри компании в будущем.
Этих документов достаточно для контроля основного процесса, но есть еще и другая документация, например:
- Project Status Report. Отчеты о статусе — это своевременные, лаконично написанные сообщения, по которым стейкхолдеры и команда разработки могут получить представление о том, как продвигается проект: по плану, в зоне риска или отстает. Отталкиваясь от этого, можно вносить коррективы для улучшения или поддержания текущей ситуации в проекте.
- Project Schedule. Это расписание проекта, в котором указаны все связанные задачи и сроки выполнения. По нему контролируют темпы продвижения: идете ли вы по графику, что уже сделано, какие следующие контрольные точки. Определить, когда проект будет окончен и доставлен клиенту, достаточно сложно. Согласно отчету PMI Pulse of the Profession, приблизительно 48% проектов не завершаются в изначально запланированный срок.
- Risk Register. Здесь учитывают риски. Это важный документ для каждого проекта независимо от его модели жизненного цикла: Waterfall, Agile или Hybrid. Именно риски помогают проджекту избегать «тушения пожаров», доводя проект до успешного релиза.
- Communication Matrix. Это описание передачи информации внутри и извне проекта с указанной спецификой общения: способа передачи, типа информации, частоты и привлеченных стейкхолдеров.
- RACI Matrix. Список стейкхолдеров или их групп с указанием ролей и действий, за которые они отвечают.
- Meetings Notes / Minutes. Это мини-статус после митинга. Например, вы встретились с клиентом, обсудили текущие задачи и пришли к каким-то решениям. Затем это записываете в письме и отправляете заказчику. Так вы снижаете вероятность что-нибудь забыть и фиксируете договоренности, чтобы в случае спорных вопросов иметь возможность урегулировать ситуацию в свою пользу.
#5. Общая technical awareness
Грань между IT Project Management и проектным менеджментом в других областях становится очень тонкой. Предположим, специалист переходит в IT из банковской сферы. Однако у него уже есть опыт развития IT-системы в банке. Или приходит в айти из ритейла — чем он занимался на предыдущем месте работы? Развивал интернет-магазин.
Соответственно, IT все больше проникает в другие сферы, и руководителей проектов, которые никогда ничего не слышали о технологиях, почти не существует. К примеру, есть такое мнение: «Раньше были финансовые учреждения с IT-отделом. Сейчас они — фактически IT-компании с функцией предоставления финансовых услуг».
Однако, конечно, IT предполагает специфические подходы к работе, разработке продукта, набору технологий и т. д. Это как с фитнес-клубом: представьте, что вы пытаетесь им управлять, но не знаете разницы между функциональной тренировкой и силовой или не можете объяснить клиенту разницу между типами абонементов. Будете ли вы эффективным администратором?
Также нужно понять, из чего состоит процесс разработки программного обеспечения, чтобы говорить с девелоперами на одном языке и уметь оценить масштаб проблемы или варианты решений.
Если вам ничего не говорят такие термины, как диаграмма Ганта, нефункциональные требования, критический путь, вам следует посвятить хотя бы несколько месяцев обучению. Также в IT-сфере популярна Agile-парадигма, которая позволяет быстро и эффективно выводить на рынок программное обеспечение.
Поэтому разобраться с итеративно-инкрементальным подходом к разработке тоже не будет лишним. Вероятнее всего, вас спросят на собеседовании о ключевых принципах этого подхода. А еще о том, как планировать работу, контролировать прогресс и проводить типичные встречи или события вроде ретроспектив, проработки бэклога (груминг), демо и т. д.
Хотите получать дайджест статей?
С какими проблемами в ІТ Project Management я сталкивался в начале карьеры:
-
Отсутствие наставника
В идеальном мире старт работы новичка в Project Management выглядит так:
Вы работаете проектным менеджером, а ваш руководитель — Head of PM или Senior Project Manager, то есть человек из вашего функционального поля, занимающийся теми же проблемами, что и вы, только в больших масштабах. Он может дать карьерные советы или помочь в решении рабочих задач. Это критически важно для джуна.
Однако первый мой настоящий наставник (который специализировался на проджект-менеджменте) появился у меня аж через 5 лет работы. До этого моими руководителями были владелец компании, операционный менеджер отдела, где я выполнял роль PM'а, и т. д. В таком случае обучение и развитие становится проблемой самого специалиста. Ему не к кому пойти, не у кого спросить совета, нет человека, который поможет составить индивидуальный план развития.
-
Проблемные клиенты
Крупные компании имеют возможность отказываться от сотрудничества с невыгодным с финансовой точки зрения или токсичным клиентом. У маленьких компаний такой опции нет, они «держатся» за каждого заказчика. Поэтому проджект в таких организациях сталкивается с большим количеством манипуляций, угроз, токсичности и т. д. В начале карьеры это особенно сложно выдерживать.
Стандартный повод для манипуляций — scope creep, или неконтролируемое расширение объема работ: клиент требует за то же время или бюджет сделать больший объем работы. На старте карьеры проджект еще может не знать, как вести документацию и фиксировать все договоренности так, чтобы отстоять себя и команду, доказав свою правоту. Как следствие получаем много негатива, овертаймы и истощение IT-команды.
-
Выполнение задач, которые не имеют отношения к Project Management
В маленьких компаниях PM'у часто приходится выполнять работу других специалистов: управлять требованиями (работа аналитика), наймом (работа HR), решать общие офисные проблемы (работа офис-менеджера).
В таких компаниях PM — это такой себе god object: принимает проект, пишет документацию, проектирует UI и API, планирует, выступает в роли Scrum Master у команды, ведет отчетность по проекту, выставляет инвойсы клиенту. Если нужно, может и тесты написать для API, мануально потестить, нарисовать кнопочки в Adobe Photoshop, иногда даже закодить.
Я начинал свой путь именно в маленьких компаниях — как в принципе это делает подавляющее большинство проектных менеджеров. На меня повесили еще роли тестировщика, бизнес-аналитика и других специалистов. Логично, что мне нужно было очень много всего изучить.
А когда я перешел в новую, уже большую компанию — понял, что в начале карьеры очень «потерял фокус». Оказалось, что на прежнем месте работы я выполнял 40% задач по проектному менеджменту, тогда как 60% вообще не касались моей роли. Кроме того, эта проблема может привести к тому, что у вас будет банально не хватать знаний по собственно Project Management.
Хотите получать дайджест статей?
