Комментарии 20
Проджект-менеджер управляет рисками (то есть вероятностями отклонения процесса от проективного таргета по разным измерениям) — то есть прикладывает усилия (впрыскивает в систему дополнительную информацию) с целью увеличить вероятность финиша проекта в целевой N-мерной точке. Все.
Продукт — сложный организм, с множеством измерений, связей, взаимовлияний, существующий к тому же не в статичной, а в динамической среде. Тех, кого вы даже только учите им управлять, не нужно учить на простых флагах. «Run Forrest» и «Stop Forrest» — это метод для пубертатного нацгероя Америки, но не для будущих капитанов.
Мои наблюдения даже свидетельствуют об обратном — лучше бы начинающий менеджер вообще не посещал никаких курсов, внимательно слушал среду, и руководствовался здравым смыслом и человеческой интуицией (часто неплохо работает для тех, кто вышел из исполнителей в той же индустрии), чем с одной-двумя книжками наперевес, серебряной пулей и уверенностью недоучки в кармане отправился штурмовать океан.
Обычно после получения начальных знаний люди перестают тонко воспринимать внешние сигналы и прислушиваться к себе, ведь «вот здесь, здесь и здесь все расписано, как и что нужно делать в ситуациях A, B, С — и теперь нет повода сомневаться!». А думать и анализировать — долго и дорого (буквально в энергетическом смысле), поэтому у таких капитанов во время штиля растет зарплата и пропорционально ей — второй подбородок и чувство собственной крутости. Но это — до первого шторма.
Да, практические знания бесценны.
Из моего опыта, теоретические знания все же также полезны. Хотя бы с той точки зрения, что они помогают структурировать знания, полученные через опыт. А также, дают возможность альтернативно взглянуть на практические знания.
Тут на одной ноге далеко не убежишь. Одной теории, или одной практики все же не достаточно.
Позволю себе вмешаться. Озвученные вами коммуникации, закупки, ресурсы, изменения и далее по тексту в общем случае и есть риски, т.е. вероятности исходов событий, на которые вы в той или иной степени можете повлиять, причем ваше влияние может быть положительным (способствующем наступлению исхода события, которое нужно вам), так и отрицательным. Это и называется управление рисками.
Риски несомненно могут коснуться любого компонента на проекте, и управление рисками — это непрерывный процесс от старта и до конечной поставки.
Тем не менее, риски не возникают просто так на пустом месте. Риски, как уже было замечено, появляются в результате каких-либо действий или принятых решений. То есть в любом случае должна быть какая-то база, на основе которой риск появится (как раз построенные коммуникации, спланированные работы, закупленные ресурсы и т.п.)
Иначе проекты назывались бы рисками и дейли митинги начинались бы со фразы «как страшно жить».
Коммуникация у менеджера больше, чем у других, но он не покрывает все 100% коммуникаций.
Менеджером проекта не стать даже если вложиться в тысячу сертификатов. Это такая профессия, в которой важен опыт.
Провальные проекты — это такие проекты, где руководитель завалил работу. Обычно в проектах определяется стратегия штатного досрочного прекращения при наступлении неблагоприятных событий.
ПМ ответственен за то, как быть в случае абсолютно любого развития обстоятельств. Если он не знает, что делать, то он становится ответственным за последствия бездействия, а если знает — то за свои решения с учётом приемлемых рисков проекта.
Руководитель проекта обязан принимать решения как лучше поступить. Если ему не хватает каких-либо предметных знаний, то он привлекает эксперта, но решение принимает сам и транслирует его от своего лица. Важны не знания, а решения, принимаемые на их основе.
Учить заказчика проекта как лучше сделать можно только на стадии согласования требований. После того, как они приняты в проект, они становятся целью. Продавливать клиента на подмену согласованных целей — не профессионально.
Все же, хочу отметить, что опыт везде важен. А менеджером проекта, разумеется, не стать, пока вам проект не доверят.
Да, может так случиться, что руководитель своими действиями поспособствует провалу проекта, вполне реалистичный сценарий.
Кстати, учить, не продавливать, можно и нужно по ходу проекта. Есть такая методология, Agile, которая как раз предполагает постоянные изменения и улучшения, рекомендую.
Есть такая методология, Agile, которая как раз предполагает постоянные изменения
Вот только именно менеджеры используют ее не для постоянных улучшений проекта, а для постоянного увеличеника количества бизнес-фич на релиз, считая что они оптимизируют ресурс, а на самом деле загоняя всех в технологический долг.
Очень понравились содержательные комментарии!!!
Кстати вся теория по управлению проектами содержится в PMbok ( в неё включён стандарт по управлению проектами), так вот до 7 версии этой книги использовался процессный подход управления проектами, а с 7 версии авторы предлагают перейти с процессов на принципы, тем самым они признают, что процессный подход в управлении не всегда эффективен.
Думаю, что всем были бы интересны практические кейсы по управлению реальными проектами.
Кстати вся теория по управлению проектами содержится в PMbok ( в неё включён стандарт по управлению проектами), так вот до 7 версии этой книги использовался процессный подход управления проектами, а с 7 версии авторы предлагают перейти с процессов на принципы, тем самым они признают, что процессный подход в управлении не всегда эффективен.
Спасибо за инпут! про процессы имелось ввиду внутренние процессы компании, которые включают в себя процесс поставки релиза.
Относительно новой версии гайда, как я это вижу исходя из анонса PMI, принцип инклюзивности теперь формально допускает возможность выбора методологии самим менеджером (классической waterfall или адаптивной agile) в зависимости от нужд проекта.
Изначально же pmbok придерживался только классической версии вотерфолла, которая была признана стандартом. Позднее добавились описания гибких методологий. Теперь, же, судя по всему, стандарт формально допускает ведение проекта выбирая наиболее подходящую методологию или миксуя их.
Интересно будет посмотреть / сравнить, что существенно поменялось :)
Думаю, что всем были бы интересны практические кейсы по управлению реальными проектами.
+
отличная мысль
На самом деле, зря вы так про 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.
Поэтому, для грамотного управления проектом не достаточно просто назваться скрам мастером или проджект менеджером. И в том, и в другом случае нужны навыки и знания.
Estimation, Capacity, Velocity, Plan projection — все эти метрики используются в гибких фреймворках, а из их сочетания или использования в формулах можно получить многое. Да этих метрик нет в синтетическом scrum guide, но на то он и фреймворк, собсвтенно они выработались и испльзуются повсеместно. И для базового проекта этого вполне хватает, дальше можно проект обвешывать исходя из надобности и тех проблем что мы хотим решить.
1. У профессиональных проджект менеджеров нет провальных проектов
Факапы есть у всех, всё зависит как учились на этих факапах и как часто они повторяются. Если уроки не извлечены и проекты рушатся с регулярной периодичностью — значит это уже не миф, а факт.
2. Вы не сможете получить профессиональную сертификацию без опыта работы
It depends. Если под сертификацией понимать красивую бумажку от ООО "Рога и Копыта Корпорейшен", то да если же получать от каких-то серьёзных контор того PMI или PRINCE — тут уже без опыта никак и это требование, чтобы ПМ обкотал на практике их гроссбухи и пришёл подтверждать что он действительно осознал и может. С тем же SCRUM ситуация очень близкая — можно молучить от Scrum Alliance, но там дно и не интересно, т.к. заплатил денежку и тебя провели за ручку, а можно получить кучу развлечения со SCRUM.org, но зато на выходе будет хардкорный бородатый SM.
3. Руководитель проекта ответственен АБСОЛЮТНО за все
Это не миф, это реальность. Если сорвали сроки, а ПМ тыкает пальцов в Колю\Васю\Петю что они плохо делали код ревью — перед бизнесом и босами отвечает ПМ, а не тот кто делал плохо ревью. Т.к. это святая обязанность ПМа выстроить процессы так, чтобы ревью делалось и делалось хорошо, и в срок; и есть целая куча инструментов как это обеспечить.
Но! Можно рассмотреть вопрос делегации своих обязанностей, тут да, бесспорно, можно всё раздать и читать тихонько в уголке хабр. Вот тут то и кроется ключевая разница, можно делегировать обязанности, но ответственность делегировать нельзя. Так что де юре, ПМ отвечает филеем за всё.
4. Проджект менеджер всегда знает лучше
ПМ — ultimate decision maker, т.к. вся ответственность лежит на нём. Дальше он сам решает, исходя из своих навыков и опыта, заниматься микроменеджментов и знать лучше всех или привлекать экспертов, растить специалистов и делегировать обязанности.
5. Клиент всегда прав
Это аксиома. Если клиент не прав, он может поменять своё мнение и продолжать быть "правым". Задача ПМа правильно "продать" заказчику новое мнение заказчика.
5 главных мифов об управлении проектами