Хорошие мысли, спасибо, что поделились.
Да, практические знания бесценны.
Из моего опыта, теоретические знания все же также полезны. Хотя бы с той точки зрения, что они помогают структурировать знания, полученные через опыт. А также, дают возможность альтернативно взглянуть на практические знания.
Тут на одной ноге далеко не убежишь. Одной теории, или одной практики все же не достаточно.
Благодарю за комментарий и за то, что мыслями поделились.
На самом деле, зря вы так про 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.
Поэтому, для грамотного управления проектом не достаточно просто назваться скрам мастером или проджект менеджером. И в том, и в другом случае нужны навыки и знания.
Кстати вся теория по управлению проектами содержится в PMbok ( в неё включён стандарт по управлению проектами), так вот до 7 версии этой книги использовался процессный подход управления проектами, а с 7 версии авторы предлагают перейти с процессов на принципы, тем самым они признают, что процессный подход в управлении не всегда эффективен.
Спасибо за инпут! про процессы имелось ввиду внутренние процессы компании, которые включают в себя процесс поставки релиза.
Относительно новой версии гайда, как я это вижу исходя из анонса PMI, принцип инклюзивности теперь формально допускает возможность выбора методологии самим менеджером (классической waterfall или адаптивной agile) в зависимости от нужд проекта.
Изначально же pmbok придерживался только классической версии вотерфолла, которая была признана стандартом. Позднее добавились описания гибких методологий. Теперь, же, судя по всему, стандарт формально допускает ведение проекта выбирая наиболее подходящую методологию или миксуя их.
Интересно будет посмотреть / сравнить, что существенно поменялось :)
Думаю, что всем были бы интересны практические кейсы по управлению реальными проектами.
сожалею о негативном опыте.
также наблюдала подобные проблемы. Смею предположить, тут не Agile виноват, а расстановка приоритетов и настройка внутренних процессов
Благодарю за комментарий и за то, что поделились портретом вашего идеального руководителя.
Все же, хочу отметить, что опыт везде важен. А менеджером проекта, разумеется, не стать, пока вам проект не доверят.
Да, может так случиться, что руководитель своими действиями поспособствует провалу проекта, вполне реалистичный сценарий.
Кстати, учить, не продавливать, можно и нужно по ходу проекта. Есть такая методология, Agile, которая как раз предполагает постоянные изменения и улучшения, рекомендую.
Благодарю за комментарий. На самом деле и да, и нет.
Риски несомненно могут коснуться любого компонента на проекте, и управление рисками — это непрерывный процесс от старта и до конечной поставки.
Тем не менее, риски не возникают просто так на пустом месте. Риски, как уже было замечено, появляются в результате каких-либо действий или принятых решений. То есть в любом случае должна быть какая-то база, на основе которой риск появится (как раз построенные коммуникации, спланированные работы, закупленные ресурсы и т.п.)
Иначе проекты назывались бы рисками и дейли митинги начинались бы со фразы «как страшно жить».
На самом деле, не только рисками. Также, коммуникациями, изменениями, закупками, ресурсами и много еще чем. Тем не менее, хороший поинт насчет рисков — большая отдельная любимая мной тема. В статье же указано на сказки, которые могут препятствовать процессу / старту работы в роли прожект менеджера для тех, кто еще в самом начале карьеры. Благодарю за прочтение :)
Да, практические знания бесценны.
Из моего опыта, теоретические знания все же также полезны. Хотя бы с той точки зрения, что они помогают структурировать знания, полученные через опыт. А также, дают возможность альтернативно взглянуть на практические знания.
Тут на одной ноге далеко не убежишь. Одной теории, или одной практики все же не достаточно.
На самом деле, зря вы так про 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.
Поэтому, для грамотного управления проектом не достаточно просто назваться скрам мастером или проджект менеджером. И в том, и в другом случае нужны навыки и знания.
Спасибо за инпут! про процессы имелось ввиду внутренние процессы компании, которые включают в себя процесс поставки релиза.
Относительно новой версии гайда, как я это вижу исходя из анонса PMI, принцип инклюзивности теперь формально допускает возможность выбора методологии самим менеджером (классической waterfall или адаптивной agile) в зависимости от нужд проекта.
Изначально же pmbok придерживался только классической версии вотерфолла, которая была признана стандартом. Позднее добавились описания гибких методологий. Теперь, же, судя по всему, стандарт формально допускает ведение проекта выбирая наиболее подходящую методологию или миксуя их.
Интересно будет посмотреть / сравнить, что существенно поменялось :)
+
отличная мысль
также наблюдала подобные проблемы. Смею предположить, тут не Agile виноват, а расстановка приоритетов и настройка внутренних процессов
Все же, хочу отметить, что опыт везде важен. А менеджером проекта, разумеется, не стать, пока вам проект не доверят.
Да, может так случиться, что руководитель своими действиями поспособствует провалу проекта, вполне реалистичный сценарий.
Кстати, учить, не продавливать, можно и нужно по ходу проекта. Есть такая методология, Agile, которая как раз предполагает постоянные изменения и улучшения, рекомендую.
Риски несомненно могут коснуться любого компонента на проекте, и управление рисками — это непрерывный процесс от старта и до конечной поставки.
Тем не менее, риски не возникают просто так на пустом месте. Риски, как уже было замечено, появляются в результате каких-либо действий или принятых решений. То есть в любом случае должна быть какая-то база, на основе которой риск появится (как раз построенные коммуникации, спланированные работы, закупленные ресурсы и т.п.)
Иначе проекты назывались бы рисками и дейли митинги начинались бы со фразы «как страшно жить».