APPSFLYER DEVCONNECT. 26.07 Olympic Hall
×Закрыть

Закат эпохи проектного менеджмента или кто виноват и что делать?

Le Roi est mort, vive le Roi!

Привычный command&control проектный менеджмент мёртв. То, что раньше по всем стандартам считалось ответственностью проектного менеджера — поставка проекта с утвержденным функционалом, в определенный срок с помощью выделенной команды — теперь все чаще и чаще считается ответственностью команды: владельца продукта, инженеров и дизайнеров.

Jeff Paton на одном из тренингов так ответил на вопрос о закате проектного менеджера: «Я помогал начать работать по agile самым разным компаниям, и пока что, при любых конфигурациях команды и организации, возникала необходимость финансового контроля, бюджетирования, разрешения инфраструктурных и ресурсных зависимостей. Обычно этих задач больше, чем может потянуть на себе одна команда. У некоторых есть линейный менеджер, но многие продолджают работать с проектным менеджером. Проектный менеджер необходим почти всегда для группы из более чем 3 команд, в меньших масштабах с его задачами могут справиться скрам-мастера с минимальной помощью линейного менеджера.»

Это справедливо, если вы работаете с хорошей зрелой командой. Если нет — то у вас просто не должно оставаться времени на чтение подобных статей после усилий потраченных на то, чтобы собрать команду в кучу, отменеджить триллион изменений со стороны заказчика, отследить расходы бюджета и выбить дополнительный, попытаться наладить нормальное тестирование и инженерные практики в команде :)

Если же вам повезло с командой, то, возможно, вы уже почувствовали, что властелин проекта и вершитель судьбы команды превращается в проектного администратора и секретаря, либо примеряет на себя роль владельца продукта (пока настоящий владелец продукта занят высокоуровневым планированием). Возможно, вы оценили, что заниматься организационно-управленческой стороной проектного менеджмента — совсем не так весело, как может показаться.

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

Are you experienced?

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

Из проектного менеджмента в жестоком украинском аутсорсе есть целых 3 пути вперед, к свету:

  • проектный менеджмент в более зрелом и интересном с точки зрения проектов аутсорсе

    В US и Европе немало очень клевых аутсорс студий, которые параллельно выпускают и собственные проекты. Universal Mind, Mutual Mobile, Ustwo — все предлагают вакансии Delivery manager или Project manager, на которых можно make a difference с интересными продуктами и хорошей командой.

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

  • проектный менеджмент в большой продуктовой компании

    Преимущества продуктовой команды очевидны — возможность прокачать команду в условиях более спокойной и стабильной с точки зрения проектов среды и прямое влияние на продукт (конечно, если он вам интересен). Хороший вариант для тех, чей опыт в проектном менеджементе уже слишком серьезен, чтобы резко переквалифицироваться или сорваться от кредитного Ford C-MAX в неблагоприятные условия Южной Калифорнии или Туманного Альбиона. В каждой большой компании опыт и требования к проектному менедежера могут разительно отличаться (даже в рамках подразделений одной компании требования к проектному менеджеру легко варьируются от проектного администратора до бизнес-аналитика со знанием Python), поэтому подробный разбор необходимого сета необходимых скиллов будет, увы, бесполезен.

  • продуктовый менеджмент

    Несмотря на похожее название — по сути это переход в абсолютно другую профессиональную сферу, где область знаний сильно отличается от проектно-менеджерской. От вас потребуется великолепно разбираться в трендах и рынке, уметь не только следить за имплементацией идей, но работать над ними от момента зарождения концепта до полностью готового shippable продукта. Попытка перехода в продуктовый менеджмент может успешно закончится для тех, кто способен много-много учиться, готов снова начать с нуля, лелеет вне работы личные pet project’ы, которые дают возможность потренироваться на кошках. Обилие интересных компаний и задач в продуктовом менеджменте (я для примера привела только mobile-oriented вакансии) просто зашкаливает: Disney, Wooga, GameDuell.

И если третьему пути можно посвятить десяток статей, то первые два потребуют от вас самых базовых вещей:

Hands-on навыки + 50 hp

Вы легко докажете свою профпригодность на практически любом собеседовании при условии опыта и умения обращаться со scope management, risk management, procurement management с одной стороны (все по букве PMP)), управлением бэклогом, прототипированием, сбором требований, фасилитацией — с другой, и servant leadership — с третьей. Это костяк профессии и в сочетании с отличным английским он открывает многие двери. Помимо этого, вам просто нужно быть человеком, который умеет make things happen и любит упорядочивать хаос — иначе вас быстро раскусят, даже при самых классных теоретических знаниях.

Рекомендации и успешно завершенные проекты +30 hp

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

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

Pet projects +15 hp

Собственный проект вне работы, — один из немаловажных факторов, который выделяет кандидатов из общей массы. В свободное время вы поддерживает Ruby on Rails комьюнити в Мумабсе или написали игру для кошек в возрасте от 3 до 6 месяцев? То, что вы не ограничиваете себя рабочими задачами и можете собрать вокруг себя пусть даже 1-2 единомышленников — свидительствует о вас более чем позитивно. Возможно, вы любите то, что делаете и люди легко сплочаются вокруг вас:) Как ни странно, это нравится работодателям.

Сертификации + 5 hp

CSM, CSPO
Scrum Alliance предлагает замечательные программы для знакомства с основами работы по agile. Еще большим плюсом является то, что сертификация и участие в agile сообществе — сродни участию в open source проектах для разработчика — всегда зачтется на собеседовании, не говоря уже об общей пользе от общения с опытными коллегами. Рассматривайте лычку сертифицированного продакт оунера или скрам-мастера — как обучение, а не как получение очередной красивой бумажки за 800 $. Объем и новизна полученных знаний для большинства проектных менеджеров (особенно для тех, кто раньше исповедовал command&control) послужат отличным толчком двигаться и развиваться дальше.

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

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

Если вам интересно узнать о мучительной, но приятной переквалификации из проектного менеджмента в hands-on специальности и о том, что светит украинскому проектному менеджеру за пределами Украины, — комментируйте, пожалуйста :).

33 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Нюанс в том, что когда говорят, что вся теория проджект-менеджмента не работает, имеют в виду книжки десятилетней давности. Пока ПМ пашет и удивляется как меняется мир и работа, и как мало в нем остается от старого проджект-менеджмента, на котором он когда-то набивал свои первые шишки, теория тоже на месте не стоит, и с каждым изданием PMBOK’а и сопутствущей литературы подтягивается. Я думал, что в Гугле все ну прям вообще совсем не так, как везде, в плане проджект и програм менеджмента, пока не начал читать последнее издание Керцнера, и узнавать там свою работу.

Иногда и старые книги не теряют своей силы. ПМ в первую очередь работает с людьми.
Почитайте Тома Демарко — Deadline. Книге уже лет 20, но от этого она не потеряла свою актуальность. Утопический роман, но в нем хорошо раскрыта тема софт-скиллов.
По хард-скиллам: PM BOK 5-й вышел в 2013 г., а в этом будет уже 6-е издание.
P.S. — менеджмент будет жить дальше, все под контролем ))

что светит украинскому проектному менеджеру за пределами Украины
Это уже можно где-то почитать? :)

Д згодний з паном Миколою
Проектный менеджмент (в общем) адаптируется под внутренние стандарты компании и соответственно проектам ее подразделений (качественно и количественно, конкретнее — это отдельная тема).
Если поглобальнее, то Анна Миненкова лаконично устандартила «проблему»
Есть стандарт (пусть евростандарт), переживший время и недозревшее укрподобие ПМ с девизом (кто в лес — кто по дрова). В заметке про шестиапрельское Scrum-мероприятие в Одессе я упомянул о «блеске и нищете» подобных подходов:
Учащенность Agile-ания не означает ... процветания!

Согласен про «Hands-on навыки» и про лидерские качества, в остальном нет единого фреймворка и проектный менеджмент адаптируется к внутренним стандартным рабочим процессам и к особенностям проекта. При этом бывает так, что у ПМ сразу несколько проектов и ведутся по разным адаптированным к потребностям процессам.
Собственный pet-проект вне работы порой весьма сложно вести, особенно когда несколько проектов и дома семья с детьми.

По поводу того, что привычный command&control проектный менеджмент уже не настолько актуальный, согласен. Руководители научились более эффективно управлять, делегировать, и быть ответственными за несколько направлений. Потому снизилась необходимость в большом количестве таких специалистов. А command&control менеджмент остается в основном для кризисных ситуаций.

По поводу самой должности Project Manager не однозначно. Обязанности на этой должности отличаются в каждой компании, нет единого корпоративного стандарта. По обязанностям это может быть технический руководитель, руководитель центра разработки, scrum master или классический PM fixed price проектов. В любом случае кто-то должен руководить подразделением разработки, как минимум заниматься операционной работой.

Навыки проектного менеджмента остаются актуальными. Не однозначно, что у каждого клиента есть достаточная экспертиза для самостоятельного управления удаленной командой в другой стране и с разницей во времени. Команда опытных инженеров хорошо справляется самостоятельно с достижением краткосрочных целей. А определение самих целей, формирование команды, постановка процессов, долгосрочное планирование и управление рисками остаются отвественностью PM.

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

На строчке «... я для примера привела только mobile-oriented вакансии.. » подозрение переросло в уверенность, я перешел в начало страницы и прочел имя автора. Угадал. :)
Интересная статья.

Ого, какой крутой инсайт. Приятно видеть такой анализ среди потока «Что почем» и «Где программисту жить хорошо».

По сценариям:

Первый наверное таки уныло — менять уютненький отечественный аутсорс с покупательской способностью over 9000 на какие-то сомнительные перспективы за бугром вряд ли охота. Да и там своих родненьких ПМов хватает, чтобы не выписывать никого из передовых стран бывшего союза.

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

Ну и третий, пожалуй, самый интересный — умеешь getting things done, молодец, вперед за новые горизонты. Учись делать меньше, достигать больше, чувствовать рынок. видеть будущее, вот это все.

Пишите еще.

По поводу 3го: Мне видится, что этот чувачек не просто Project(product) Manager, а Business PM. Это роль, которая в себе заключает: Business analysis + Consulting + Project Management. Вектор этого BPM должен быть направлен в сторону поиска business solutions для каждого проекта. Тут и лежит его added value.

Вот это наш таки язык — полуанглийский. РМ такой РМ!

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

Чем чревато: PM взятый из проекта с чужой ответственнойстью — убьёт продукт. Потому что не возьмёт на себя «лишнюю» роль, а будет строго выполнять «свою».

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

Главная задача проектного менеджера — минимизировать свою надобность и макимально задействовать команду в организации. Но полностью отказаться от этой роли, к сожалению, не всегда удается.

Роль никуда не девается. Просто её частями берут на себя другие. Так бывает — роль есть, а должности нет.

Мне кажется, его главная задача — всё-таки успешно сдать проект :)
А насчет «минимизировать свою надобность»... ПМ выполняет кучу «фоновой» работы (своеобразный project backend), которую снаружи вроде бы и не видно, но без которой проект длительностью/размером чуть более X/Y станет неуправляемым, джира захламится, клиент будет в печали от отсутствия конструктивных репортов, а продукт утратит малейшее соответствие скоупу проекта и документации вообще.
Так что ПМ минимизирует ВИДИМУЮ надобность, но трудится очень даже.
Ну, тебе ли не знать :)

В том то и дело, что это общая задача команды — успешно сделать проект. Чем взрослее команда и заказчик, тем меньше деятельности не связанной с непосредственным созданием продукта (а это не только кодирование конечно).

Нет ни какого заката эпохи, есть просто некоторая смена приоритетов. Раньше были в моде классические ПМы (на западе они мегапопулярны и сейчас, в т.ч. снаружи ИТ индустрии), потом технические ПМы с некоторыми функциями аналитиков, сейчас популярны скрам-мастеры, но на первый план выходят продактовые менеджеры, способные деливерить что-то (показатель как раз те самые Pet projects).

Классический PM на западе — это человек 30-40 лет с десятилетним опытом работы на неменеджерской позиции и 5+ годами тяжеловесного проектного менеджера, серьезными сертификациями PMP/Prince 2/что-то локально значимое в его индустрии и соответственно с глубокими представлениями о финансовом, риск менеджменте, procurement. Таких людей в Украине и России с удовольствием хантят в Газпром, РБК, Мейлру и иже с ними, они на вес золота.

А PM в классическом украинском аутсорсовом представлении имеет к такому специалисту минимум отношения.

Анна, я 7 лет развиваюсь именно в этом направлении, в последнии 2 года углубляясь в RnD, и вижу в этом хорошие перспективы именно для IT-индустрии.
В скрам не тянет, это все таки очень легенький ПМ фреймворк и рассчитан больше для разработчиков, которым делегируют какие-то части ПМ, да и дыр я в нем сильно много вижу, мы тут уже не раз устраивали дебаты об этом.

Поделитесь опытом (абсолютно не сарказм, действительно интересно), много ли людей вокруг вас, которые идут таким карьерным путем? Вокруг меня совсем мало — то ли это долгий и тернистый путь, то ли спрос рынка не так велик. Хотя я, пожалуй, напрасно забыла такой путь развития.
Agile неплохо масштабируется, и можно посмотреть на много удачных примеров, когда большие и даже не it компании успешно его применяют — IBM первые кто пришел в голову — на сложных и крупных проектах.

P.S. оценила Prince 2 в профиле:)

Agile приятен клиенту в случае аутстаффинга или прямого найма разработчиков к себе в команду с целью удешевления затрат разработки. В случае работы с большими корпоративными клиентами классические ПМ-знания необходимы как воздух и вода. Увы, не все проекты можно мирно и спокойно двигать вперед с помошью Agile. К примеру, фиксед прайс проекты, в которых главное сроки и качество, на спринты и релизы можно разбивать лишь для внутреннего использования, т.к. клиенту интересен лишь конечный результат, а не то Agile это или не Agile.
По поводу опыта: все зависит от процессов, выбранных на уровне компании/проекта. В принципе я лично пытаюсь миксить методологии и знания. Prince2? Да, для ПМа — это очень «вкусно», но это, если выражаться технически, всего лишь backend, и если использовать еще и «гибкий» frontend — это будет еще интереснее. Использование же Agile-принципов в чистом виде без элементов негибких методологий — это все равно что распивать спирт в чистом виде :)
Ответил на Ваши вопросы?

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

«Fixed price проекты, где клиенту важен исключительно срок и качество», но не продукт — одна из причин по которым мне (да и не только мне) не хочется работать в аутсорс среде.

Да, есть такие люди, естественно.
Знакомые локальные ПМы — их немного, но хороших спецов никогда много и не бывает :)
Знакомые иностранные ПМы.
Те люди, которых я консультирую и помогал внедрять процессы.

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

видите ли, agile без ультимативной вовлеченности заказчика — это карго-культ, глупое и опасное баловство

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

взагалі було би непогано, якби хтось внятно класифікував весь бестіарій ролей, які в пост-срср аутсорсі озвучують ємким словом «менеджер», з коротким описом призначення/предметна зона...

Боюсь, если полностью и внятно классифицировать, внезапно выяснится, что часть «ролей» стоит упразднить. А люди же хотят кушать, повелевать и кредитный форд фокус.

ви надаєте класифікації демонічних властивостей ))))

Ти диви! Тільки почав заглиблюватися в проектний менеджмент — а він здох!
Може мені ще почати Internet Explorer користуватися ? =)))

А Google Reader ви користувалися останнім часом?

Хм... Где бы проверить свои hands-on навыки?

А то рекомендации есть, пет-прожекты — есть, получить сертификат скрам-мастера — запросто (но не вижу смысла, тут все правильно написано).

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

Походить по собеседованиям + очень полезная штука — присматриваться к вопросам-ответам pm.stackexchange.com и тематических pm группах в линкедине. Много интересных обсуждений, которые наталкивают на мысли о том, что стоит прокачать/почитать/узнать

Спасибо. На собеседования на роль ПМа не ходил. Нашел работу, где сказали, что вырастят из меня ПМа. Но теперь понимаю, что это была ошибка. В ЕПАМе я как тим-лид делал больше, чем тут ПМы.

Подписаться на комментарии