Комментарии 20
Ну сколько же можно махать битовыми флажками ДА/НЕТ? Поймите, мы живем в вероятностном мире, и управлять (в небольших пределах) можем только вероятностями наступления желательных для нас событий. В жизни, на работе, везде.

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

Продукт — сложный организм, с множеством измерений, связей, взаимовлияний, существующий к тому же не в статичной, а в динамической среде. Тех, кого вы даже только учите им управлять, не нужно учить на простых флагах. «Run Forrest» и «Stop Forrest» — это метод для пубертатного нацгероя Америки, но не для будущих капитанов.

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

Обычно после получения начальных знаний люди перестают тонко воспринимать внешние сигналы и прислушиваться к себе, ведь «вот здесь, здесь и здесь все расписано, как и что нужно делать в ситуациях A, B, С — и теперь нет повода сомневаться!». А думать и анализировать — долго и дорого (буквально в энергетическом смысле), поэтому у таких капитанов во время штиля растет зарплата и пропорционально ей — второй подбородок и чувство собственной крутости. Но это — до первого шторма.
Хорошие мысли, спасибо, что поделились.
Да, практические знания бесценны.
Из моего опыта, теоретические знания все же также полезны. Хотя бы с той точки зрения, что они помогают структурировать знания, полученные через опыт. А также, дают возможность альтернативно взглянуть на практические знания.
Тут на одной ноге далеко не убежишь. Одной теории, или одной практики все же не достаточно.

Позволю себе вмешаться. Озвученные вами коммуникации, закупки, ресурсы, изменения и далее по тексту в общем случае и есть риски, т.е. вероятности исходов событий, на которые вы в той или иной степени можете повлиять, причем ваше влияние может быть положительным (способствующем наступлению исхода события, которое нужно вам), так и отрицательным. Это и называется управление рисками.

Благодарю за комментарий. На самом деле и да, и нет.
Риски несомненно могут коснуться любого компонента на проекте, и управление рисками — это непрерывный процесс от старта и до конечной поставки.
Тем не менее, риски не возникают просто так на пустом месте. Риски, как уже было замечено, появляются в результате каких-либо действий или принятых решений. То есть в любом случае должна быть какая-то база, на основе которой риск появится (как раз построенные коммуникации, спланированные работы, закупленные ресурсы и т.п.)
Иначе проекты назывались бы рисками и дейли митинги начинались бы со фразы «как страшно жить».
А я встречал много проектов, где менеджер никак не занимается закупками и ресурсами. Он занимается в основном человеческими ресурсами, а закупками занимается представитель заказчика.
Коммуникация у менеджера больше, чем у других, но он не покрывает все 100% коммуникаций.
Совершенно верно. То был пример. На самом деле, каждый проект уникален. Соответсвенно, и обязанности могут отличаться от проекта к проекту.

Менеджером проекта не стать даже если вложиться в тысячу сертификатов. Это такая профессия, в которой важен опыт.
Провальные проекты — это такие проекты, где руководитель завалил работу. Обычно в проектах определяется стратегия штатного досрочного прекращения при наступлении неблагоприятных событий.
ПМ ответственен за то, как быть в случае абсолютно любого развития обстоятельств. Если он не знает, что делать, то он становится ответственным за последствия бездействия, а если знает — то за свои решения с учётом приемлемых рисков проекта.
Руководитель проекта обязан принимать решения как лучше поступить. Если ему не хватает каких-либо предметных знаний, то он привлекает эксперта, но решение принимает сам и транслирует его от своего лица. Важны не знания, а решения, принимаемые на их основе.
Учить заказчика проекта как лучше сделать можно только на стадии согласования требований. После того, как они приняты в проект, они становятся целью. Продавливать клиента на подмену согласованных целей — не профессионально.

Благодарю за комментарий и за то, что поделились портретом вашего идеального руководителя.
Все же, хочу отметить, что опыт везде важен. А менеджером проекта, разумеется, не стать, пока вам проект не доверят.
Да, может так случиться, что руководитель своими действиями поспособствует провалу проекта, вполне реалистичный сценарий.
Кстати, учить, не продавливать, можно и нужно по ходу проекта. Есть такая методология, Agile, которая как раз предполагает постоянные изменения и улучшения, рекомендую.
Есть такая методология, Agile, которая как раз предполагает постоянные изменения


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


  2. Кстати вся теория по управлению проектами содержится в PMbok ( в неё включён стандарт по управлению проектами), так вот до 7 версии этой книги использовался процессный подход управления проектами, а с 7 версии авторы предлагают перейти с процессов на принципы, тем самым они признают, что процессный подход в управлении не всегда эффективен.


  3. Думаю, что всем были бы интересны практические кейсы по управлению реальными проектами.


Кстати вся теория по управлению проектами содержится в PMbok ( в неё включён стандарт по управлению проектами), так вот до 7 версии этой книги использовался процессный подход управления проектами, а с 7 версии авторы предлагают перейти с процессов на принципы, тем самым они признают, что процессный подход в управлении не всегда эффективен.



Спасибо за инпут! про процессы имелось ввиду внутренние процессы компании, которые включают в себя процесс поставки релиза.

Относительно новой версии гайда, как я это вижу исходя из анонса PMI, принцип инклюзивности теперь формально допускает возможность выбора методологии самим менеджером (классической waterfall или адаптивной agile) в зависимости от нужд проекта.
Изначально же pmbok придерживался только классической версии вотерфолла, которая была признана стандартом. Позднее добавились описания гибких методологий. Теперь, же, судя по всему, стандарт формально допускает ведение проекта выбирая наиболее подходящую методологию или миксуя их.
Интересно будет посмотреть / сравнить, что существенно поменялось :)

Думаю, что всем были бы интересны практические кейсы по управлению реальными проектами.


+
отличная мысль
Спасибо за многие мысли как в статье, так и в комментариях. Добавлю от себя. Меня не покидает мысль, когда сегодня смотрю на сегодняшний тренд в сторону Agile. И долго думал, что мне не подходит. И кажеться для себя определил. Раньше PM должен был хоть какие-то навыки в Project Management иметь. А это целая наука. Сегодня ничего этого не надо. Называйся каким-нибудь Scrum-Master и всё — координируешь целые потоки. И не надо никаких навыков в оценке затрат, ценах, качествах, решения задач не на один месяц, а на многие годы вперёд итд. На лицо упрощеный подход к решению любых задач. Но упрощённых не всегда может быть — лучшим. И вот тут как всегда — выигрывает тренд, а не логика. К сожалению.
Благодарю за комментарий и за то, что мыслями поделились.

На самом деле, зря вы так про Agile и про Scrum. Это также большой институт со своими ценностями и пакетом знаний.

Есть 2 больших направления в управлении проектами.

Kлассический, предиктив (predictive), который предполагает знание стандарта управления проектами предлагаемого Project Management Institute, а так же Axelos — сертификация Prince II. Здесь за основу берется четкое пошаговое планирование без изменений в плане. Этот подход также называется Waterfall.
Как писал kiroleg:
Учить заказчика проекта как лучше сделать можно только на стадии согласования требований. После того, как они приняты в проект, они становятся целью.


Адаптивный подход, основанный на гибких методологиях (Agile). Это направление также популярно, есть целые институты и международные сертификации в это области. Самое большое сообщество — Scrum Alliance, то самое, которое сертифицирует скрам мастеров — Scrum Master Certified. Гибкость заключается в том, что Agile предполагает, кратко говоря, частые демонстрации результата и получения отзывов, на основе которых могут вноситься изменения в план работы для получения лучшего результата на выходе.
Agile — это не упрощенный подход к управлению проектами, это подход, основанный на иных принципах.

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

Если интересно, у меня есть статьи на английском, где я подробно рассказываю о разных сертификациях области управления проектами и сравниваю их. А также, о сравнении Agile & Waterfall.

Поэтому, для грамотного управления проектом не достаточно просто назваться скрам мастером или проджект менеджером. И в том, и в другом случае нужны навыки и знания.
… покажите мне хоть одну формулу в Agile. Для посдчёта чего-нибудь. Вы возьмёте кучу книг и не увидите ни одного расчёта. Ни о чём. В этом и заключается беда, что это просто теория, завёрнутая в конечно-же хорошую обёртку. И работает только там, где или сама ситуация не так уж и сложная или если вопреки всем усилиям находятся пару, которые вытягивают «проект» на боллее менее нормальное положение. В остальных случаях — обречено на успех провал. Хотя конечно-же с видоизменением этого самого Agile на что-нибудь подходящее и работающее — конечно-же можно чего-нибудь и добиться. Но тогда — с Agile это имеет мало чего общего.

Estimation, Capacity, Velocity, Plan projection — все эти метрики используются в гибких фреймворках, а из их сочетания или использования в формулах можно получить многое. Да этих метрик нет в синтетическом scrum guide, но на то он и фреймворк, собсвтенно они выработались и испльзуются повсеместно. И для базового проекта этого вполне хватает, дальше можно проект обвешывать исходя из надобности и тех проблем что мы хотим решить.

Я с Вами соглесен, "… можно проект обвешывать..", но это никто не делает. Почему? Не знают-ли или не хотят? Наверное первое. Но от этого не меняется суть. Это совсем не инженерный подход. Тяп-ляп. И так сойдёт. Да, и в таких Agile проектах находятся проффессионалы, которые и в таких условиях совершают чуда. Но это больше исключение из правил.
1. У профессиональных проджект менеджеров нет провальных проектов

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


2. Вы не сможете получить профессиональную сертификацию без опыта работы

It depends. Если под сертификацией понимать красивую бумажку от ООО "Рога и Копыта Корпорейшен", то да если же получать от каких-то серьёзных контор того PMI или PRINCE — тут уже без опыта никак и это требование, чтобы ПМ обкотал на практике их гроссбухи и пришёл подтверждать что он действительно осознал и может. С тем же SCRUM ситуация очень близкая — можно молучить от Scrum Alliance, но там дно и не интересно, т.к. заплатил денежку и тебя провели за ручку, а можно получить кучу развлечения со SCRUM.org, но зато на выходе будет хардкорный бородатый SM.


3. Руководитель проекта ответственен АБСОЛЮТНО за все

Это не миф, это реальность. Если сорвали сроки, а ПМ тыкает пальцов в Колю\Васю\Петю что они плохо делали код ревью — перед бизнесом и босами отвечает ПМ, а не тот кто делал плохо ревью. Т.к. это святая обязанность ПМа выстроить процессы так, чтобы ревью делалось и делалось хорошо, и в срок; и есть целая куча инструментов как это обеспечить.
Но! Можно рассмотреть вопрос делегации своих обязанностей, тут да, бесспорно, можно всё раздать и читать тихонько в уголке хабр. Вот тут то и кроется ключевая разница, можно делегировать обязанности, но ответственность делегировать нельзя. Так что де юре, ПМ отвечает филеем за всё.


4. Проджект менеджер всегда знает лучше

ПМ — ultimate decision maker, т.к. вся ответственность лежит на нём. Дальше он сам решает, исходя из своих навыков и опыта, заниматься микроменеджментов и знать лучше всех или привлекать экспертов, растить специалистов и делегировать обязанности.


5. Клиент всегда прав

Это аксиома. Если клиент не прав, он может поменять своё мнение и продолжать быть "правым". Задача ПМа правильно "продать" заказчику новое мнение заказчика.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.