Есть мнение, что знания и навыки в project management'е универсальны.И, да, есть знакомый который перейдя из IT в агросектор прокомментировал "Да какая разница? Тут программистами управляешь,там - трактористами".
С одной стороны - это, действительно, так. С другой стороны - в IT наблюдается устойчивый спрос на project management, которые имеют технический бекграунд.
Попытаемся разобраться зачем нужны technical project manager, какие вопросы они должны закрывать и подходит ли вам эта роль.
Какие PM'ы нужны ?
Примеры того что могут ожидать от technical project manager как в небольших продуктовых компаниях, так и в лидерах рынка :
- ...Experience with hands-on technical delivery. Former developer is preferred. A deep understanding of digital technologies used to develop real-time web sites and mobile applications, including Java, Javascript, HTML, CSS, XML and JSON file transforms and handling...Т.е. технический бекграунд предполагается разный.
- ...Knowledge of web architectures (AWS), CMS systems and modern online marketing tools...
- ... Development experience (open source in LAMP stack, HTML, CSS, JS). Deep Technology and Architectural Understanding...
-...A vision of future technologies and marketing trends...
-... Excellent understanding of wider industry context & trends, both technical & product
Где-то достаточно быть в курсе последних технических новинок.
Чаще в роли TechPM видят специалиста, который свернул с пути развития по технической вертикали в сторону менеджмента. Либо даже и не бросал активное участие в разработке, но приобрел некий менеджерский опыт.
Зачем опыт разработки PM'у?
Несколько реальных кейсов зачем могут понадобится PM'у технические навыки:
1. расширение эккаунта, повышения доверия заказчика
У компании-аутсорсера есть небольшой, но долгосрочный проект у заказчика в конкретном домене, и очень большие планы по расширению эккаунта. PM должен не только успешно выполнить текущий проект, но и постоянно предлагать заказчику варианты решения его бизнес потребностей смежных с проектными, повышая тем самым его доверие к PM'у/проекту/ компании.2. роль СТО/техлид по совместительству
Нет возможности/необходимости для найма выделенного специалиста отвечающего за архитектуру проекта. Например, потому. что это инвестиционный проект компании /стартап, который необходимо с небольшой командой инженеров поднять "на коленке" и запустить с перспективой вырастить в направление/эккаунт. В какой-то момент развития проекта, конечно же, появятся специально обученные люди, которые будут отвечать за архитектуру. Но это будет потом и если проект "взлетит" :)3.onsite менеджер в технической вертикали
Стремительный рост изначально небольшой out-staff команды инженеров "здесь" с руководством "там" приводит к проблемам в process & people management. Стало очевидно, что руководитель не может решить удаленно все возникающие вопросы. А так как в роли PM'а выступает СТО компании-заказчика, то и onsite PM был необходим с сильным техническим бэкргаундом, кто-то из "своей песочницы".4. синхронизация команд
Проект с непростой организационной структурой: 4 agile команды с общим количеством 40+ инженеров, scrum master'ов и product owner'ов. По разработке продукта на уровне отдельных команд, вроде бы, все хорошо: фичи выпускаются, баги фиксятся, заказчики и исполнители в целом довольны. Но начали возникать существенные отличия от команды к команде в процессах, технических стеках, инженерных практиках. Одна из задач, которую нужно решить PM'у - изменить ситуацию по образованию "зоопарка" решений и синхронизировать команды в выработке технических подходов и практик.5. people management инженеров
TechPM понадобился в ситуации, когда инженеров нужно растить, а заниматься этим некому. HR недостает hardskills, а у лидов не хватает softskills/времени/навыков для того что бы растить команду. Development plan&performance review для разработчиков и QA? Нет, не слышали.5. technical solution review
В команде есть solution architects/техлиды, но необходимо валидировать их технические верхнеуровневые решения. И это возлагается на PM'a. Очевидно, что при неизбежно существующей разнице в экспертизе, условный инженер доведет PM'a до границ (не) компетентности. Но чем глубже "знание предмета" у PM'a, тем дольше это будет длиться и тем больше правильных вопросов по обсуждаемой архитектуре/техническому решению PM успеет задать.6. упрощение коммуникации с техническими специалистами в команде (в противовес позиции "Да ты же PM/бывший QA-аналитик! О чем с тобой вообще разговаривать?!");
С одной стороны - залезаешь в зону ответственности инженеров, ведь многие из подобных задач традиционно закрываются тим\техлидами, СТО и прочими техническими специалистами.
С другой - встречающиеся проблемы со софсткиллами таких специалистов, смещение акцентов в менеджменте в IT с command&control в сторону servant leadership, потребность в людях пребывающих на стыке бизнес и технических интересов.
Ты - TechPM?
Почему же не каждый, даже опытный, PM сможет осилить специфические задачи, которые возлагаются на technical project manager'а в описанных кейсах?
- Отсутствие технического опыта. Речь об изначально нетехнических PM'ах. Свитчеры из других отраслей, которые делали крутые проекты в аргосекторе, открывали крупнейшие в городе пивные магазины, запускали нашумевшие ТВ-проекты, могут быть хорошими управленцами, но в роли околотехнических PM'ов в IT скорее-всего не подойдут.
- PMы с отсутствием интереса к IT-инженерии. Не всем интересно разбираться с технической составляющей проекта. Управления рисками, customer relationship management, WBS, PERT - интересно и вдохновляюще, а вот SOLID, git, SOAP API и Kibana ничего кроме уныния не вызывают. Если позиция подразумевает постоянное пребывание в контакте с инженерной проблематикой, то эта работа не для вас.
- Специфичность позиций. Иногда происходит подмена понятий и вместо teamlead'а (возможно с чуть более прокачанными определенными менеджерскими скиллами) ищут project manager'а. Т.е. изначально нужен разработчик, а не управленец.
Будь особенным!
Количество откликов на PM'ские вакансии согласно информации на dou на текущий момент составляет около 20 откликов на одну вакансию. Для сравнения - у технических специалистов в зависимости от профиля этот же показатель колеблется в пределах 5..10. И ситуация врядли будет кардинально меняться в сторону уменьшения.
Потому, если нужно выделиться из толпы, можно делать это в том числе и за счет развития/актуализации технических навыков.
Возможностей оставаться "в тренде" в наше время дистанционного обучения, технических блогов, многочисленных конференций и open-source проектов более чем достаточно. Дерзайте!
