Методологии управления проектами гибкие: Scrum, Kanban, PRINCE2 и другие – Гибкая методология разработки — Википедия

От Требовательной Waterfall до Правительственной Prince2 — GanttPRO

*Материал в значительной степени основан на переводе статьи автора workamajig.com Эсфир Коуэн (Esther Cohen).

Методология управления проектами — это набор руководящих принципов и процедур для управления проектом.

Методология, которую вы выберете, определяет, как вы будете работать и взаимодействовать.

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

Виды методологий управления проектами

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

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

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

Итак, рассмотрим 9 популярных методологий управления проектами.

1. Waterfall (каскадная модель, «водопад»)

Методология Waterfall – самая «старая» из всех. Впервые она была изложена американским ученым в области информатики Уинстоном Уокером Ройсом в 1970 году в ответ на потребность управления все более усложняющимся процессом разработки программного обеспечения. С тех пор она получила широкое распространение, особенно в сфере программного обеспечения.

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

Необходимо иметь абсолютно четкое представление о том, что нужно проекту, чтобы продолжить работу с методологией Waterfall.

Когда проект уже будет в разработке, вы не сможете скорректировать его курс.

Методология Waterfall делится на три отдельных этапа. Сначала необходимо собрать и проанализировать требования, затем разработать решение (и подход), внедрить решение и исправить проблемы, если они появились.

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

Вышеописанное применимо к разработке программного обеспечения. Для быстрого начала планирования воспользуйтесь готовым шаблоном диаграммы Ганта для разработки ПО.

В рамках других проектов, например, творческих, этапы будут другими, но подход останется таким же.

Преимущества Waterfall модели

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

Таким образом, методология Waterfall обладает рядом преимуществ:

• Простота использования

Эту модель просто понять и использовать. Деление на этапы довольно интуитивно, его просто освоить вне зависимости от опыта.

Жесткость методологии Waterfall – одновременно и недостаток, и явное преимущество. Четкое разделение на этапы позволяет организовать и распределить работу. Поскольку назад вернуться нельзя, необходимо идеально справляться с выполнением каждого этапа, что зачастую позволяет добиться лучших результатов.

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

Недостатки Waterfall модели

• Повышенный риск

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

• Сложность первого этапа

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

Для каких проектов лучше всего подойдет Waterfall

Методология управления Waterfall зачастую используется в сфере разработки программного обеспечения. Она лучше всего подходит для:

• Коротких несложных проектов.
• Проектов с четко установленными требованиями.
• Проектов, в которых меняются ресурсы, зависимые от подробной документации.

2. Agile (гибкая методология)

Agile — это еще одна методология управления c акцентом на разработке программного обеспечения. Появилась она как результат неприменимости методологии Waterfall в рамках сложных проектов.

Хотя идеи, присущие Agile, уже давно используются в сфере разработки ПО, формально методология появилась лишь в 2001 году, когда несколько представителей из IT выпустили Agile-манифест.

Agile полностью противоположна методологии Waterfall по подходу и идеологии. Само название с английского языка переводится как «Гибкий», а это значит, что в управлении используется быстрый и гибкий подход.

В Agile проектах не требуется тщательный сбор требований.

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

Преимущества Agile методологии

• Гибкость и свобода

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

• Пониженный риск

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

Недостатки Agile методологии

• Отсутствие четкого плана

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

• Сложность взаимодействия

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

Для каких проектов лучше всего подойдет Agile

Гибкость подхода Agile позволяет адаптировать его к проектам различного типа. Методология лучше всего работает в случаях:

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

Онлайн диаграмма Ганта GanttPRO поможет вам в планировании проектов любой сложности и длительности по методологиям Waterfall и Agile.

Попробуйте GanttPRO бесплатно!

3. Гибридная модель

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

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

Сочетая свойства Waterfall и Agile, гибридная методология, которую иногда называют «Структурированным Agile», позволяет воспользоваться преимуществами обеих составляющих.

Преимущества гибридной методологии

• Большая гибкость

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

• Большая структурированность

Позаимствовав этап первоначального планирования из Waterfall, гибридная методология решает одну из основных проблем подхода Agile — недостаточную организованность и отсутствие плана. Таким образом, эта методология сочетает в себе лучшее от этих подходов.

Недостатки гибридной методологии

• Необходимость компромиссов

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

• Сочетание лучшего от обоих подходов

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

Для каких проектов лучше всего подойдет гибридная методология

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

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

4. Scrum

Scrum — это не полнофункциональная методология управления проектами. Это скорее подход к методологии Agile с акцентом на командах проекта, спринтах и ежедневных собраниях.

Несмотря на то что Scrum заимствует принципы и процессы из Agile, этому подходу свойственны свои методы и тактики управления проектами.

В какой-то степени возможна такая формулировка:

Agile — это философия, а Scrum — методология. И хотя Scrum — это Agile, Agile — это не Scrum.

В рамках подхода Scrum в центре проекта — команда. Зачастую менеджера проекта нет. Поэтому предполагается, что команда характеризуется самоорганизацией и самоуправлением. Именно поэтому такой подход идеально подойдет для опытных мотивированных команд, но вряд ли подойдет всем остальным.

Преимущества Scrum

В подходе Scrum упор делается на 30-дневные спринты, или отрезки времени. Так, команда проекта делит список конечных целей на небольшие задачи, а потом работает над ними в течение 30-дневных периодов с ежедневными собраниями. Благодаря такому подходу проще справляться с большими сложными проектами.

Благодаря разбивке работы на 30-дневные периоды с ежедневными собраниями разработка и внесение изменений происходят довольно динамично.

• Командная работа

Поскольку подразумевается самоорганизация команды проекта, участники четче понимают и знают проект. А еще лидеры проекта могут самостоятельно расставлять приоритеты согласно своим знаниям и возможностям.

Кроме перечисленных, этой методологии свойственны все преимущества Agile: быстрое внесение изменений и регулярная обратная связь с заинтересованными сторонами.

Недостатки Scrum

• Неконтролируемое расширение масштабов

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

• Повышенный риск

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

• Недостаточная гибкость

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

Для каких проектов лучше всего подойдет Scrum

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

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

Вкратце: используйте Scrum, если вы разрабатываете сложное ПО с опытной командой.

5. Метод критического пути (Critical Path Method, CPM, МКП)

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

Одна из наиболее популярных альтернатив — это метод критического пути (CPM).

В рамках метода критического пути вы классифицируете все действия, которые необходимо выполнить, чтобы достигнуть цели проекта в рамках Иерархической структуры работ (Work breakdown structure). После этого вы определяете длительность всех задач и зависимости между ними.

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

Преимущества метода критического пути

• Подробное планирование

Благодаря акценту на длительности активностей и взаимосвязях между ними вы сможете лучше спланировать задачи. Если для выполнения задачи X сначала нужно завершить задачу Y, CPM поможет вам определить это заранее и распланировать все должным образом.

• Расстановка приоритетов

Успех метода критического пути зависит от определения и планирования критических важных задач и задач второстепенного значения. Определив задачи, вы сможете оптимально распределить ресурсы.

Недостатки метода критического пути

• Для планирования необходим опыт

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

• Отсутствие гибкости

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

Для каких проектов лучше всего подойдет метод критического пути

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

CPM хорошо подходит для сложных проектов, в рамках которых часто повторяются задачи и действия, например, для промышленных проектов. Для динамичных проектов, к примеру, творческих, она подходит в меньшей степени.

6. Метод критической цепи (Critical Chain Project Management, CCPM)

Метод критической цепи — одна из относительно новых методологий управления проектами. Она была разработана в качестве альтернативы методу критического пути с акцентом на управлении ресурсами.

В рамках метода критической цепи работа происходит в обратном направлении от конечной цели.

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

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

Для ограниченных в ресурсах команд метод критической цепи может стать мощным оружием.

Преимущества метода критической цепи

• Высокая эффективность ресурсов

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

• Сосредоточенность на конечной цели

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

Недостатки метода критической цепи

• Не подходит для нескольких одновременных проектов

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

• Часто случаются задержки

CCPM учитывает буферы — временные промежутки между задачами – в общем времени задач. В теории это может привести к переоценки ресурсами своей эффективности. Но в реальности это приводит к неоправданным задержкам.

Для каких проектов лучше всего подойдет метод критического цепи

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

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

7. Интегрированная система управления проектами (Integrated Project Management, IPM)

Интегрированная система управления проектами, которую иногда также называют «Integrated Project Delivery» — Реализация комплексных проектов, — это популярная методология управления проектами в индустрии творчества. В ней акцент делается на стандартизацию и применение одинаковых процедур во всей организации. 

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

Комплексный проект состоит из следующих компонентов:

Устав проекта → объем работ → план → выполнение → мониторинг → контроль за изменениями

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

Таким образом, IPM идеально подходит для креативных агентств.

Преимущества интегрированной системы управления

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

• Подотчетность

Из-за комплексности подхода IPM вся команда проекта несет за него ответственность. Поскольку ни один сотрудник не работает изолированно от других, IPM позволяет улучшить подотчетность.

Недостатки интегрированной системы управления

• Требует подробного планирования

В рамках подхода IPM вам придется подробно планировать работу заранее и следить за тем, чтобы все процессы были правильно интегрированы. Это существенно увеличивает вашу загрузку и может привести к задержкам завершения проекта.

Для каких проектов лучше всего подойдет интегрированная система управления

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

8. PRiSM

PRiSM (Projects integration Sustainable Methods, Устойчивые методы интеграции проектов) — это методология управления проектами, разработанная Green Project Management (GPM) Global.

Отличие PRiSM от традиционных методологий состоит в том, что она выходит за рамки проекта.

В ней учитывается весь жизненный цикл проекта после его завершения с целью увеличения его устойчивости.

В рамках PRiSM задачи и активности организованны подобным образом.

Преимущества PRiSM

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

Недостатки PRiSM

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

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

Для каких проектов лучше всего подойдет PRiSM

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

9. PRINCE2

PRINCE2 (акроним от PRojects IN Controlled Environments — проекты в контролируемых средах) — это официальная методология управления проектами правительства Великобритании, используемая в большинстве таких проектов.

PRINCE2 основывается на 7 принципах, 7 темах и 7 процессах. Вот, например, 7 принципов PRINCE2:

1. Постоянная оценка целесообразности.
2. Учет предыдущего опыта.
3. Определенные роли и обязанности.
4. Поэтапное управление.
5. Управление по исключению.
6. Сосредоточенность на продукте.
7. Адаптация к внешним условиям проекта.

Преимущества методологии PRINCE2

Для работы над проектом в рамках PRINCE2 требуется подробное документирование. Кроме того, один из ведущих принципов этого подхода — это учет предыдущего опыта. Акцент на документации и прошлом опыте позволяет снизить риски.

Недостатки методологии PRINCE2

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

Для каких проектов лучше всего подойдет PRINCE2

Эта методология лучше всего подходит большим и сложным проектам с четкими требованиями. Она очень популярна в Великобритании и является обязательным требованием для работы над государственными проектами.

В статье перечислены не все методологии управления. Вот еще несколько:

• Six Sigma (Шесть сигм).
• Crystal.
• Feature Driven Development (FDD, функционально-ориентированная разработка).
• Dynamic Systems Development (DSDM, метод разработки динамических систем).
• Rational Unified Process (RUP, методология разработки программного обеспечения, созданная компанией Rational Software).
• Kanban.
• Lean Development (LD, бережливая разработка).

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

С какими методологиями управления проектами работали вы? Делитесь опытом в комментариях.

ТОП-4 Методологии управления проектами

26 Мар 2015

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

Традиционная (Каскадная) методология управления проектами

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

1. Определение требований
2. Проектирование
3. Реализация (строительство, производство…)
4. Внедрение
5. Тестирование и отладка
6. Установка
7. Эксплуатация и сопровождение

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

Однако с другой стороны, каскадная модель управления проектом требует инвестиций в планирование. Обычно первые две фазы занимают от 20 до 40% от всего времени выполнения проекта по данной методологии. Вследствие структурированного подхода, внесение изменений в содержание работ происходит медленно, что делает методологию не гибкой и не подходящей в случаях, если клиент не уверен, какой результат он хочет получить.

Методология управления проектами PRINCE2

PRINCE2 (Projects in Controlled Environments) так же является структурированной методологией к проектному управлению. Это одна из самых популярных методологий управления проектами, широко используемая в Великобритании в управлении как в бизнесе, так в органах власти. PRINCE2 – это процессно-ориентированная проектная методология, которая фокусируется на процессах верхнего уровня (управление, организация, контроль), а не на низших задачах (декомпозиция работ, разработка графиков). Методология PRINCE2 базируется на семи принципах, семи темах и семи процессах. Принципы являются центральным элементом методологии: если хотя бы один из них не выполняется, то нельзя говорить о том, что проект выполняется в рамках PRINCE2.

Принципы методологии PRINCE2:

1. Постоянная оценка экономической необходимости — остается ли неизменной экономическая выгода от проекта на протяжении всего жизненного цикла проекта
2. Обучение на опыте – команда проекта должна постоянно искать и изучать опыт предыдущих проектов
3. Определение ролевой модели – команда проекта должна иметь ясную организационную структуру и вовлекать подходящих людей для решения нужных задач
4. Управление по этапам – необходимо, чтобы проекты были спланированы, а также подвергались мониторингу и контролю на каждом этапе выполнения;
5. Управление по отклонениям – следует четко обозначить допустимые границы отклонений в проекте, чтобы установить границы ответственности
6. Фокус на продуктах – необходимо концентрироваться на определении и достижении качества продуктов (результатах проекта)
7. Адаптация к проектной среде – следует адаптировать процессы и инструменты управления проектом к требованиям проектной среды, а также к масштабу работ, их сложности, важности, квалификационным требованиям и степени риска

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

Аспекты методологии управления проектами PRINCE2:

1. Обоснование проекта: какую ценность проект принесёт организации?
2. Организация: каким образом необходимо распределить роли и ответственность между членами проектной команды для того, чтобы эффективно управлять проектом
3. Качество: какие имеются требования и критерии к качеству и каким образом можно их обеспечить
4. Планы: шаги, требуемые для разработки плана, и инструменты PRINCE2, необходимые к использованию
5. Риски: каким образом менеджмент проекта будет разрешать проблему наличия неопределённостей в плане проекта и во внешней среде
6. Изменение: как руководство проекта будет оценивать влияние непредвиденных задач и изменений и реагировать на них
7. Прогресс: реализуемость проекта, выполнение планов и дальнейшее развитие проекта

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

PRINCE2 подразумевает следующие процессы управления проектом:

1. запуск проекта
2. руководство проектом
3. инициация проекта
4. контроль этапов
5. управление созданием продукта
6. управление границами этапов
7. закрытие проекта

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

Гибкая методология управления проектом (Agile Project Management)

Гибкое управление проектом представляет собой поступательную и итеративную проектную методологию. Ее главной особенностью является то, что в начале выполнения проекта точно неизвестно, каким должен быть конечный продукт и каким будет жизненный цикл проекта. Вместо этого, проектная деятельность разбивается на несколько итеративных фаз, называемых «спринтами». Каждый спринт состоит из множества задач и имеет свой конечный продукт и результат. Методология Agile позволяет менеджерам проектов постоянно получать обратную связь и улучшать продукт после каждой итерации.

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

• Владелец продукта – определяет проектные цели, разрабатывает оптимальный график при заданных проектных параметрах, адаптирует процесс выполнения проекта к изменившимся требованиям и устанавливает приоритеты в характеристиках продукта
• Scrum мастер – устанавливает приоритеты в выполнении задач командой проекта и устраняет возникающие затруднения, препятствующие этому
• Члены команды – выполняют большинство поставленных задач, осуществляют ежедневный менеджмент, создают отчеты о ходе выполнения проекта, контролируют качество продукта

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

Методология быстрой разработки приложений (Rapid Application Development — RAD)

Быстрая разработка приложений (RAD) – это проектная методология, чаще всего используемая в проектах по разработке ПО, основной целью которых является быстрое и качественное создание приложения. Данная методология управления проектами выделяет 4 стадии проекта:

• Планирование
• Пользовательское проектирование
• Быстрое конструирование
• Переключение

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

Рекомендации:

• Не существует универсальной «наилучшей» методологии управления проектом – выбор определяется типом проекта и спецификой окружающей среды
• Если вы работаете над проектом с возможными небольшими изменениями содержания работ, например, в области строительства, выбирайте каскадную модель
• Для разработки программного обеспечения, графического дизайна и других сервисно-ориентированных проектов выбирайте Agile методологию
• Используйте методологию быстрой разработки приложений для небольших IT проектов с сжатыми сроками
• Если вам необходимо минимизировать риски и требуются структурированный подход в исполнении крупного или среднего масштаба проекта, выбирайте PRINCE2
• Не бойтесь использовать другие, менее популярные методологии, если они в большей степени подходят к вашему проекту

Как получить международный сертификат по Agile?

Для тех, кто хочет получить систематизированное понимание Agile, разобраться с преимуществами и недостатками гибкого подхода к проектам и продуктам, найти области наилучшего применения Agile и получить международный сертификат ICAgile Certified Professional — наш тренинг «ICAgile Certified Professional»

Смотрите также:

Источник: http://www.devx.com/enterprise/explore-the-top-4-project-management-methodologies.html

Секреты эффективности работы в команде: гибкие методологии управления проектами

В работе над проектами за каждым углом нас поджидает таинственный зверь Коллапс. Он подкрадывается незаметно, он безжалостен и непоколебим. При встрече с ним мы теряемся и перестаем видеть грани реальности: ни спрятаться, ни убежать не получится. Единственное, что мы можем сделать в такой ситуации: пойти в атаку. Всевозможные методологии управления (Adaptive Project Framework, Benefit Realization, Agile и другие) призваны справиться с коллапсом в работе над проектами и избавить директоров от необходимости прятаться на дереве от другого жестокого зверя: Дедлайна. В этой статье мы расскажем о самых эффективных методах управления работой команды и раскроем все их секреты.

Гибкие методологии как способ увеличить эффективность команды на 20%

Практик и методологий управления проектами масса, начиная от метода критического пути и заканчивая моделированием событий. О них написано много книг и статей, но мы затронем куда более актуальную тему: гибкие методологии управления. Говорят, что гибкие методологии повышают эффективность работы и бизнеса на 20%, а то и 50%. В чем их секрет? Давайте разбираться.

За счет чего повышается эффективность работы при внедрении гибких методологий? Четкая структура работы команды, распределение ролей, наконец, визуализация каждого происходящего на данный момент процесса. А ведь еще есть четкая постановка целей. Работаем только над тем, что действительно важно сейчас…

Простые принципы работы в команде, к которым человечество шло долгие годы. Насколько эффективны гибкие методологии на практике? Интересно? Тогда вот вам одна история…

Джефф Сазерленд создатель Scrum (одна из гибких методологий) сделал следующий вывод: если бы Scrum применяли спецслужбы США — трагедии 11 сентября можно было избежать. Что еще сказать об эффективности, раз есть методы, которые могут предотвратить катастрофу?

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

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

Что такое гибкие методологии: главный секрет эффективности

«Agile» [с англ. «Agile software development»] — методы гибкого управления процессами разработки, придуманные инженерами-менеджерами из мира IT. Гибкие методологии помогают работать эффективно, быстро и не теряя темпа. Как ни странно, гибкие методологии подхватили компании не только из цифрового мира, но и из мира offline. Что они делают и как помогают в работе?

Основные задачи гибких методологий в реалиях современного бизнеса

• Упрощение рабочего процесса. Достигается путем разграничения обязанностей и создания четкой структуры ответственных лиц под каждую задачу.
• Удобная и наглядная работа на стороне клиента. Достигается за счет прозрачной работы, использования сервисов управления проектами вроде Rovertask.
• Разработка качественных продуктов в сжатые сроки. За счет эффективного взаимодействия внутри команды.
• Сведение отчетности к минимуму. За счет визуальных презентаций после каждого цикла работы.

Как гибкие методологии выглядят изнутри?

Процесс разработки любого продукта — хаотичная среда и, если не придать этой среде форму, не разграничить роли и не разделить работу на циклы (так называемые итерации) — то у таких проектов туманное будущее. Достигается это путем простых правил:

• Главное продукт. Конечная цель любой гибкой методики — создание качественного продукта за минимальное количество времени. Если раньше на создание большого интернет-магазина могло уйти полгода — сейчас тот же функционал можно разработать за 3 месяца эффективной работы.
• Общение с клиентами должно быть простым, понятным и наглядным. Больше презентаций о каждом этапе работы, меньше запутанной документации. Вместо того, чтобы отсылать клиенту сложные отчеты с миллионом цифр — можно просто показать, то что сделано, в наглядной форме презентации.
• Каждому проекту — лидер, от которого зависит результат. Совсем не то, что работа в команде, где непонятно на ком лежит вся ответственность.
• Каждой задаче — ответственный исполнитель, который выполняет только свои обязанности.
  Чтобы дизайнер — рисовал, а верстальщик — верстал. И никто не менялся местами, не отвлекал и не задерживал остальных.
• Совещания и планерки для разбора появившихся проблем в работе. Поэтапная, а не параллельная работа над каждым процессом. Если игнорировать недельные планы, кто-то может просто просиживать штаны без работы и впустую тратить чужое время.
• Разграничение рабочего времени на циклы: 1-2-4 недели, в зависимости от сложности проекта. Создание того же интернет-магазина состоит из множества процессов и, чтобы фиксировать успехи — нужны временные отрезки на каждую большую задачу.
• Важная роль каждого члена команды, теплая атмосфера рабочего пространства. Что будет, если копирайтер Петр будет задирать дизайнера Олега? Будет полный пробел в креативе.
• Нужно всегда быть готовым к изменениям, даже с учетом другого изначального плана. Когда амбициозные клиенты просят учесть новые пожелания — если не готов к быстрому внесению правок в проект — пропадешь.

В чем же главный секрет эффективности гибких методологий?

Вот так строится работа в команде одного провинциального рекламного агентства:

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

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

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

Такой подход позволяет клиенту не ждать целый год первую версию продукта, а тестировать отдачу и получать заказы уже через 3-6 месяцев…».

— Андрей Кожевников, руководитель студии Solvintech

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

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

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

Секреты вовсе не секреты, а практики, которые можно опробовать самому. Даже дома, устраивая семейный совет в канун Нового года. Разделить обязанности, составить план работ, подвести итоги 31 декабря, составить фотоотчет о проделанной работе 1 января. Главный секрет гибких методологий: в совокупности интересных правил и принципов, которые работают в самой жизни.

Виды гибких методологий. Все ли они одинаково эффективны?

Существует несколько видов гибких методологий, самые популярные из которых Scrum и Kanban. Гибкие методологии похожи в своих целях: они направлены на логичное и эффективное взаимодействие в команде, бережное отношение к продукту, и все это на фоне любви к людям, жизни и творчеству.

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

Преимущества Scrum. Характеристики и секреты популярной методологии

Scrum-методология одна из самых известных в мире гибких практик. . Скрам стал известен благодаря одноименной книге Джеффа Сазерленда, о которой говорят и пишут до сих пор. Что характеризует Scrum как методологию, и в чем ее суперсила?

• В каждом проекте всегда есть скрам-мастер. Компетентный человек, который отвечает за общий ход выполнения проекта. Именно он краснеет за всех.
• Где-то в рабочем пространстве всегда есть скрам-доска. Здесь мы храним информацию по проекту: «Исходные данные», «Процессы в работе», «Уже сделано». При работе в удаленной среде, подобные задачи решаются с помощью сервисов, таких как Ровертаск. Или исключительно Ровертаск, если брать рунет в целом. Так как мы отвечаем всем требования Скрама: удобство использования, список и приоритет задач, назначение ответственного, командный чат и прочее. Именно на скрам-доске мы изображаем мучительно-невыполнимые задачи клиента, чтобы преобразовать их в понятный и легкий алгоритм работы.

• У нас всегда есть график сгорания работ. Простой график, построенный на соотношении времени и оставшихся задач в плане. График, которые возвращает нас к жизни, если мы заигрались в Наполеона.
• От команды исходит небывалая общая положительная энергия. Еще бы! Когда мы видим, что работа делается хорошо, быстро, и все остаются довольны. Когда мы видим, что работа делается хорошо, быстро и все остаются довольны — так и в единорога поверишь.

Замысловатый Kanban. Принципы и преимущества альтернативного взгляда на гибкие методологии

«Кан-бан» — таинственное японское слово. Трактуется как «сигнальная доска». В этом и есть основной принцип Канбана — визуализация процесса и темпа вечно прибавляющихся задач. Создали эту методологии для более четкой и слаженной работы на производстве. Но обо все по порядку. Характеризуется Канбан методология следующими принципами:

• Система создана в помощь производственным процессам. Основная загвоздка: никто из специалистов не может приступить к дальнейшей работе, пока об этом не будет сигнала на канбан-доске. Да, визуализация процесса есть и здесь.
• Является частью философии «Кайдзен» («система маленьких шагов»). Широко применяется, например, во внутренних процессах Toyota, где существует два главных правила: «Точно-в-срок» и автоматизация работы с участием человека. То есть, вот почему этот великий бренд заслуживает уважения — там все отлажено даже на этапе планирования, что и говорить о производстве.
• Один из важных принципов Канбан — бережное отношение к производству, продукту, проекту. Если бы машины были плохими, никто бы не покупал тойоты-короллы по всему миру.
• Канбан легко внедрить, так как его структура и принципы довольно просты и понятны. Речь идет об IT-компаниях, но с некими простыми деформациями (смена ролей, отделов и отчетов) методология подойдет для любой компании, где есть продукт и команда.
• Определяющими факторами в Канбан-методологии также являются: разделение процессов на классы обслуживания, особая отчетность руководства и анализ операций. Некие сложные технические обозначения, которые помогают Канбану оставаться в ряду популярных гибких методологий.

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

Есть и другие, менее заметные виды гибких методологий, но мы их оставим на потом. А пока перейдем к самому главному…

Внедрение гибких методологий: почему не всем удается? Мнение эксперта

И, правда, почему? Поразмыслив над этим и не найдя внятного ответа, мы обратились за помощью к одному из ведущих отечественных практиков по гибким методологиям, Марине Арефьевой сооснователю и CIO в  Demlabs.net.

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

Вопросы

1. Что такое Agile для вас? 

2. Какая из гибких методологий, на ваш взгляд, самая эффективная и почему? 

3. Насколько просто/сложно внедрить гибкие методологии в рядовую IT-компанию? 

И вот что нам удалось узнать…

1. Agile для меня — семейство гибких методологий, ключевое слово, конечно, «гибких».​

2. Под разные задачи нужны разные вещи, например, я как фанат Канбана не буду бездумно внедрять его везде, потому что у каждого есть и плюсы и минусы. Для начинающих все же лучше SCRUM, так как там «делай раз, делай два» понятнее. С другой стороны, можно привыкнуть к гибкости постепенно, и уже потом начинать экспериментировать.

3. Для внедрения в одну команду 7 (+-2) человека уходит 2 дня тренингов (в идеале) + примерно 6-12 недель сопровождения и присмотра коуча, но коуч в принципе может присматривать сразу за несколькими группами. Сама трансформация, однажды начавшись, не должна останавливаться никогда, так как каждые 2 недели команды будут на ретроспективе смотреть, что еще можно улучшить в организации. Для коллективов меньше 300 человек — требуется примерно год до полноценного аджайла. Так часто бывает, особенно при экономии на коучах…​

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

Процесс совместной работы: в офисе или на удаленной основе — здесь все не так просто, как кажется…

Программы-помощники в проектной работе при внедрении гибких методологий

Для автоматизации и визуализации гибких методологий существуют специальные программы. Одна из таких — Rovertask. Именно в нем вы сможете проследить и зафиксировать эффективность каждого сотрудника, разделить роли по задачам и предоставить открытую информацию заказчику, работая в одном пространстве в любой удобной точке на Земле.

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

И еще кое-что…

Выводы и итоги. Насколько все-таки эффективны гибкие методологии, и так ли легко их внедрить?

Что добавить напоследок? Гибкие методологии управления проектами — новая веха в истории бизнеса. Потихоньку, маленькими шагами эти методы начинают проникать в крупные компании (вроде Сбербанка), что и говорить про небольшое провинциальное рекламное агентство, которое строит свою империю в гараже.

Эффективны ли они? Да, в результате гибких практик на свет появился сам Rovertask. В своей работе мы придерживаемся некоторых правил гибких методологий, например, мы убрали множество дополнительных функций после первого тестирования. Мы работаем постепенно и только над тем, что важно сейчас. Это стратегический стержень Ровертаска и неоспоримый показатель эффективности гибких методологий.

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

Поделиться:

Управление проектами — Википедия

Управление проектами — область деятельности, в ходе которой определяются и достигаются чёткие цели проекта при балансировании между объёмом работ, ресурсами (такими как деньги, труд, материалы, энергия, пространство и другими), временем, качеством и рисками (PMBoK) ^{[источник не указан 633 дня]}.

Ключевым фактором успеха проектного управления является наличие чёткого заранее определённого плана, минимизации рисков и отклонений от плана, эффективного управления изменениями (в отличие от процессного, функционального управления, управления уровнем услуг) ^{[источник не указан 633 дня]}. Продуктами проекта могут быть продукция предприятия или организации (результаты научных и маркетинговых исследований, проектно-конструкторская и технологическая документация на новое изделие, разработанные для заказчика) и решение разных внутренних производственных задач (например, повышение качества продукции и эффективности организации труда, оптимизация финансовых потоков).

Управление проектами является частью системы менеджмента предприятия.

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

В основе современных методов управления проектами лежат методики структуризации работ и сетевого планирования, разработанные в конце 50-х годов XX века в США.

Классическая форма тройственной ограниченности[править | править код]

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

The Project Management Triangle

Как того требует любое начинание проект должен протекать и достигать финала с учетом определенных ограничений. Классически эти ограничения определены как объем работы, время и стоимость. Они также относятся к Треугольнику Управления проектами, где каждая его сторона представляет ограничение. Изменение одной стороны треугольника влияет на другие стороны. Дальнейшее уточнение ограничений выделило из содержания качество и действие, превратив качество в четвёртое ограничение.

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

Иной подход к управлению проектами рассматривает следующие три ограниченности: финансы, время и человеческие ресурсы. При необходимости сократить сроки (время) можно увеличить количество занятых людей для решения проблемы, что непременно приведет к увеличению бюджета (стоимость). За счет того, что эта задача будет решаться быстрее, можно избежать роста бюджета, уменьшая затраты на равную величину в любом другом сегменте проекта.

Подходы к управлению жизненным циклом продукта[править | править код]

Существует множество подходов к управлению жизненным циклом проекта/продукта в зависимости от типа проекта:

• Предположение о неизменности требований, низких рисках, критичности сроков завершения. В этом случае применяется водопадный жизненный цикл. Для планирования и контроля хорошо применимы методы PERT, метод критического пути, метод освоенного объема, диаграмма Ганта. Основная слабая сторона классического проектного менеджмента – нетолерантность к изменениям. Подход применим к строительным и инженерным проектам, в которых содержание проекта остаётся практически неизменным в течение всего проекта ^[1].
• Предположение о критичности качества, при этом требования к сроку и ресурсам достаточно гибки (под качеством здесь понимается полнота удовлетворения потребностей, как известных, так и неизвестных заранее, часто создаваемых выходом нового продукта). В этом случае применяются спиральный жизненный цикл, гибкая методология разработки продукта, минимизация администрирования и неформальный подход к управлению проектом. К преимуществам относят гибкость и адаптивность под изменения требований. В качестве недостатков отмечают что гибкость может приводить к потере фокуса, усложнению внесения непредвиденных изменений ^[1].
• Предположение о высоких неопределенностях и рисках проекта (для инновационных проектов и стартапов). В этом случае применяются подходы управления бережливый стартап, Phase–gate model^[en], Управление реализацией преимуществ^[en][2].

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

Заказчик определяет цель и ограничения проекта и его финансирование.
Исполнитель выполняет проект согласно утвержденному плану.

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

В случае четкого разделения ролей заказчик-исполнитель целью управления проектом является стабилизация работ и минимизация отклонений от утвержденного заказчиком плана.

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

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

Цель управления проектом и успешность проекта[править | править код]

Успешность проекта различным образом оценивается в разных методиках. Успешность может разным образом оцениваться различными участниками проекта.

Группы оценок успешности:

• Ориентированные на контракт с жесткой фиксацией требований и минимизацией изменений в ходе проекта, например традиционные методологии, в том числе PMBOK: «проект успешен, если выполнен согласно утвержденным критериям: объёму, сроку, качеству». То есть проект успешен, если исполнен и закрыт договор между Заказчиком и Исполнителем (вне зависимости от того, являлся ли он юридическим документом в случае внешних проектов или определялся как-то иначе в случае внутренних проектов). При этом оценка успешности единая как для заказчика так и для исполнителя.
• Ориентированные на удовлетворенность заказчика с гибким управлением требованиями, например гибкие методологии SCRUM: «проект успешен, если заказчик удовлетворен»
• Ориентированные на длительное взаимодействие с Заказчиком: управление программами, направленное на длительное взаимодействие, а не на один проект/контракт. Здесь делается акцент на продолжение сотрудничества Исполнителя с Заказчиком в рамках последующих проектов и иного взаимодействия.
• Сбалансированные, например PRINCE2: «проект успешен при сбалансированности по крайней мере по трем категориям — бизнеса, ориентации на пользователя и технологической зрелости». Здесь делается акцент на финансовой успешности проекта, удовлетворенности пользователей и развитии технологий. Оценка успешности может различаться с точки зрения бизнеса, пользователя и исполнителя. Такие методики оценки чаще используются для внутренних проектов, когда заказчик и исполнитель находятся в одной организации.

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

В целом можно определить цель управления проектами следующим образом:

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

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

Корпоративная система управления проектами[править | править код]

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

Процедуры управления проектом по традиционной методологии[править | править код]

Последовательность процедур управления проектом:

• Определение среды проекта.
• Формулирование проекта.
• Планирование проекта.
• Техническое выполнение проекта (за исключением планирования и контроля).
• Контроль над выполнением проекта.

Процедуры управления проектом по методологии PMI[править | править код]

Основные процедуры и процессы PMI описаны в стандарте PMBOK:

• Определение требований к проекту
• Постановка чётких и достижимых целей
• Балансирование конкурирующих требований по качеству, возможностям, времени и стоимости
• Адаптация спецификаций, планов и подходов для нужд и проблем различных заинтересованных лиц (стейкхолдеров)

Процедуры управления проектом по методологии IPMA[править | править код]

Процедуры управления проектом по методологии PRINCE2[править | править код]

• Начало проекта (SU).
• Запуск проекта (IP).
• Планирование проекта (PL).
• Управление проектом (DP).
• Контроль стадий (CS).
• Контроль границ стадий (SB).
• Управление производством продукта (MP).
• Завершение проекта (CP).

Прочие процедуры (управление командой, контрактами) вынесены «за рамки» методологии и называются инструментарием менеджера проекта. Кроме того, методология рассматривает «компоненты», которые состоят из Бизнес плана (Business Case), организации, планирования, управления рисками, управления качеством, управление конфигурацией, контроля и управления изменениями.

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

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

Международные стандарты управления (менеджмента) проектами:

• ISO 10006:2003, Quality management systems — Guidelines for quality management in projects (в России принят как ГОСТ Р ИСО 10006—2005 «Системы менеджмента качества. Руководство по менеджменту качества при проектировании»)
• ISO 21500:2012 Guidance on project management (в России принят как ГОСТ Р ИСО 21500-2014 Руководство по проектному менеджменту)^[3]

Национальные стандарты с расширенной географией применения:

Национальные стандарты управления проектами:

Стандарты оценки компетенции менеджера проекта:

1. Методология PMI, сформулированная в виде стандарта PMBOK, базируется на концепции управления проектами через группу стандартных процессов. Однако последняя версия стандарта PMBOK отражает существенную коррекцию методологии в сторону итеративных методик.
2. Методология IW URM (Unique Reliable Method), разрабатывалась и оттачивалась с тем, чтобы в любом проекте был гарантирован успех — цели клиента достигнуты в оговоренный срок, в рамках определенного бюджета и с необходимым качеством. Для реализации разных типов проектов используется набор различных процедур, документов и технологий, наиболее подходящих для конкретного типа проекта.
3. Процесс управления проектами TenStep помогает менеджерам проектов успешно руководить проектами всех видов. TenStep предлагает пошаговый подход, начинающийся с простейших вещей и заканчивающийся настолько изощренными приемами, насколько это может потребоваться для конкретного проекта, включая шаблоны документов.
4. Методология P2M базируется в ориентированности не на продукт или процессы, а на улучшение организации в результате выполнения проектов. Иными словами, методология описывает, как использовать полученный в результате выполнения проектов опыт для развития компании.

Существует программное обеспечение как для управления проектами, так и управления портфелем проектов.

• Стэнли Э. Портни. Управление проектами для «чайников» = Project Management For Dummies. — М.: «Диалектика», 2006. — С. 368. — ISBN 0-7645-5283-X.
• Рассел Д. Арчибальд. Управление высокотехнологичными программами и проектами = Managing High Technology Programs and Projects. — М.: Академия Ай-ти, 2004. — С. 472. — ISBN 5-98463-002-3.
• Ньюэлл Майкл В. Управление проектами для профессионалов. Руководство по подготовке к сдаче сертификационного экзамена. — Кудиц-пресс, 2008. — С. 416. — ISBN 978-5-91136-009-2.
• Том ДеМарко. Deadline. Роман об управлении проектами. — М: Вершина, 2006. — С. 143. — ISBN 5-9626-0132-7.
• Ашманов Игорь Станиславович. Жизнь внутри пузыря. — М.: Манн, Иванов и Фербер, 2008. — С. 208. — ISBN 978-5-902862-79-6. Архивная копия от 3 июня 2009 на Wayback Machine
• Ким Хелдман. Профессиональное управление проектами. — М.: Бином, 2005. — С. 517. — ISBN 5-94774-234-9.
• Лапыгин Ю. Н. Управление проектами: от планирования до оценки эффективности. — М.: Омега-Л, 2008. — С. 252. — ISBN 978-5-370-00985-3.
•  Богданов. В. В. Управление проектами. Корпоративная система — шаг за шагом. — М: : Манн, Иванов и Фербер, 2012. — 248 c. — ISBN 978-5-91657-232-2

Agile или Waterfall — какой вариант соответствует вашему бизнесу?

Противостояние Agile и Waterfall не столько теоретическое, сколько практическое. Выбор методики, не подходящей под ваш проект, в лучшем случае существенно затормозит его развитие, в худшем — отправит в список «ТОП-провалов года».

Гибкая и каскадная модели разработки проекта (Agile и Waterfall соответственно) — одни из наиболее популярных среди прочих методологий управления. Изучив особенности конкретно вашего проекта, и вооружившись знаниями из этой статьи, вы сможете с полной уверенностью ответить на вопрос: «Что подойдёт моему бизнесу — Agile или Waterfall?»

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

Waterfall — методика управления проектами, которая подразумевает последовательный переход с одного этапа на другой без пропусков и возвращений на предыдущие стадии.

Что такое Agile

Как и другие популярные методологии разработки и управления проектами, Agile появился сравнительно недавно в США. В отличии от CPM и CCPM, за появление гибкой методологии разработки ответственна сразу целая группа людей — 17 американских IT-специалистов из штата Юта. Вместе с «Манифестом гибкой разработки ПО», в котором впервые прозвучал термин «Agile» они прописали 12 принципов Agile-разработки.

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

1. Люди и взаимодействие важнее процессов и инструментов
2. Работающий продукт важнее исчерпывающей документации
3. Сотрудничество с заказчиком важнее согласования условий контракта
4. Готовность к изменениям важнее следования первоначальному плану.

Agile стал основой для целого ряда гибких методик, среди которых наиболее известны Scrum, Lean и экстремальное программирование.

Scrum — методология гибкой разработки на основе Agile, в основе которого лежит «спринт» — отрезок от 1 до 4 недель, по окончанию которого должна быть получена рабочая версия продукта.

Lean — метод, который вырос на основе системы управления производством Toyota Production System. В его основе — философия постоянного совершенствования на всех уровнях организации, где одно из ключевых понятий — ценность (то, за что готов платить заказчик).

Экстремальное программирование (XP) — одна из Agile-методик, где важная роль отводится периодической игре в планирование с привлечением заказчика. Она позволяет определить недостатки предыдущей итерации, приоритетность задач, желаемую функциональность продукта с учётом пожеланий заказчика.

Преимущества и недостатки метода Agile

К преимуществам метода относятся:

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

Не избежала методология и недостатков, которые органично «дополняют» её достоинства:

• стимулирование постоянных изменений проекта: гибкость разработки продукта может привести к тому, что он никогда не дойдёт до финальной версии
• повышенные требования к квалификации и опыту команды: помимо непосредственно создания продукта команда должна анализировать возможные способы улучшения эффективности собственной работы, беспрерывно обмениваться информацией по проекту, быть мотивированной и самоорганизованной. Далеко не всегда ресурсы проекта позволяют привлечь таких специалистов
• философский характер методологии: Agile — это не чёткая инструкция к действию, а целая философская концепция. Команда не может механически применить механики «гибкой» разработки, нужно принять ключевые принципы системы
• сложность подсчёта итоговой суммы работы: стимуляция изменений и усовершенствования конечного продукта приводит к плавающему значению стоимости проекта. Поэтому Agile не подойдет для управления проектами в строительстве, где составляется четкая смета под всю работу.

---

Что такое Waterfall

Методика Waterfall (водопадная система разработки) — детище Винстона Уолкера Ройса, директора Lockheed Software Technology Center в Остине (штат Техас, США), пионера в области разработки программного обеспечения.

С методикой Waterfall получилось также, как и с многими изобретениями: свой вклад в создание методологии сделали Герберт Беннингтон в 1956 г. и Хозьер в 1961 г., а Уолкер использовал их наработки, обеспечив себе славу «создателя Waterfall». Победителей не судят…

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

В оригинальной работе Уолкера «Managing the development of large software systems» описаны 6 стадий разработки продукта, которые в 1985 году Департамент защиты США закрепил в стандартах работы с разработчиками программного обеспечения:

1. Системные и программные требования: закрепляются в PRD (документе требований к продукту).
2. Анализ: воплощается в моделях, схемах и бизнес-правилах.
3. Дизайн: разрабатывается внутренняя архитектура программного обеспечения, способы реализации требований. Это не только об интерфейсе и внешнем виде ПО, но и о его внутренней структурной логике.
4. Кодинг: непосредственно пишется код программы, идёт интеграция программного обеспечения.
5. Тестирование: баг-тестеры (тестировщики) проверяют финальный продукт, занося в трекеры сведения о дефектах кода программы или функционала. В случае ошибок и наличия времени/финансов происходит исправление багов.
6. Операции: продукт адаптируется под разные операционные системы, регулярно обновляется для исправления обнаруженных пользователями багов и добавления функционала. В рамках стадии также осуществляется техническая поддержка клиентов.

Компания Toyota, популяризовавшая методологии Lean и Kanban, до конца 2000-ых пользовалась каскадной моделью разработки ПО для нужд производства.

Преимущества и недостатки Waterfall

В число наибольших преимуществ методики Waterfall вошли:

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

Среди недостатков водопадного метода можно выделить:

• лишенный гибкости процесс — так, если проект требует больше временных и финансовых ресурсов, чем возможно, то под нож пойдёт фаза тестирования. Согласно исследованиям консалт-группы Rothman, стоимость исправления багов после выпуска продукта выше в среднем в 20 раз, чем во время полноценного многоэтапного тестирования в процессе разработки
• «стойкость» к изменениям — жёсткий каркас из этапов разработки и условие предоставление только готового продукта определяют невозможность вносить изменения во время разработки
• инерционность — на первых стадиях прогноз временных и финансовых трат может измениться в сторону увеличения, но изменить проект в сторону оптимизации затрат, изменения функционала или концепции до выпуска готового продукта невозможно
• повышенный риск — классическая система тестирования подразумевает отдельно тестирование каждого из компонентов проекта, в том числе, во взаимодействии с другими. При использовании Waterfall происходит тестирование готового продукта.

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

Сашими или водопадная модель с наслаивающимися фазами — cамая известная среди них. В ней этапы как и в оригинальной методике идут друг за другом, но при этом перекрываются одна другой во времени.

Waterfall с субпроектами — модель, в которой вы работаете с трёмя крупными блоками: концептуализацию, проектирование требований и архитектурная структура продукта. Затем для каждого из них вы проходите стадии (субпроекты) детального проектирования, кодирования и тестирования. В конце проводится интеграция всех компонентов на этапе тестирования системы.

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

Сравнительная таблица

	Agile	Waterfall
Суть	Гибкая модель разработки, основанная на итеративных принципах	Каскадная система разработки, основанная на жёсткой последовательности процесса разработки
Дата создания	2001 г.	1956 г., 1961 г., 1970 г.
Разработчики	Группа IT-специалистов (США)	Г. Беннингтон, Хозьер, В. Уолкер Ройс
Принципы применения	наивысший приоритет в удовлетворении потребностей заказчика на протяжении всего проекта команда и заказчик ежедневно взаимодействуют между собой и друг с другом работающий продукт — главный показатель прогресса работу можно доверить только самоорганизованной, мотивированной команде оптимальные сроки выпуска рабочего продукта — от 2 недель до 2 месяцев.	жёсткая последовательность этапов разработки переход к новому этапу — только после успешного завершения предыдущего фиксированная стоимость продукта заказчик не привлекается к непосредственному процессу разработки изменения могут быть внесены только после завершения всего процесса разработки.
Плюсы	высокий уровень взаимодействия между членами команды проекта быстрый результат (рабочий код) в итоге «спринтов» стимулирование изменения и улучшений продукта во время его разработки непосредственное вовлечение заказчика к рабочему процессу.	понятная и чёткая схема рабочего процесса возможность просчёта точного количества затраченных на проект ресурсов не требует затрат по налаживанию коммуникаций между всеми членами команды.
Минусы	риск бесконечных изменений продукта большая зависимость от уровня квалификации и опыта команды практически невозможно точно подсчитать итоговую стоимость проекта.	приоритет формального подхода к последовательности процесса работы невозможность внесения изменений заказчиком до окончания разработки продукта в случае нехватки ресурсов страдает качество проекта из-за сокращения этапа тестирования.
Компании-практики	Unilever, ряд банков (Альфа Банк, Home Credit, Райффайзен Банк и т.д.)	Cisco Ericsson AB, Toyota (до 2010)
Подойдёт вам, если…	над проектом работает опытная, высококвалифицированная команда вы работаете над стартапом нужно быстро получить рабочую версию продукта заказчик выступает в качестве партнёра, а не инвестора продукт разрабатывается в сфере, подверженной постоянным изменениям.	большая часть или вся работа над проектом проводится на аутсорсе у вас есть чёткая концепция продукта, который хотите получить вы не ограничены во времени и ресурсах создания продукта создание продукта или бизнеса построено на соблюдении строгой последовательности выполнения задач.
Не подойдёт, если…	вы не готовы тратить дополнительные ресурсы на налаживание ежедневной стабильной коммуникации между всеми участниками процесса продукт должен быть создан к конкретному сроку бюджет проекта строго ограничен вам нужна детальная документация по всем процессам разработки.	вы хотите создать инновационный продукт или крупный проект вы не уверены в концепции предлагаемого проекта финансовые ресурсы не являются ключевым ограничителем в вашем проекте.

Вердикт

Agile и Waterfall — две абсолютно разные методики разработки и управления проектами. Каждая из них породила десятки модификаций и методов, «заточенных» под конкретный формат проектов.

Гибкая модель будет идеальной для IT-компаний, стартапов, проектах в инновационных сферах

Каскадная модель не сдаёт позиции в строительных проектах или проектах, где ключевым ограничителем является срок реализации проекта, а не финансы

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

Scrum Foundation 1. Управление проектами с использованием гибких подходов

Главная > Курсы > Курсы управления проектами (PM) и IT-менеджмент | IT-менеджмент

Код курса: СКРАМ1-Б

Путеводитель Управление проектами Курсы Java Этот курс в нашем Центре успешно закончили 2125 человек!

Agile-Scrum Foundation 1 Скрам (Agile) — популярная методология ведения проектов по разработке программного обеспечения. Как организовать взаимодействие команды разработчиков, чтобы проект разработки завершился успешно. Что и как документировать, как, с кем и как часто обсуждать детали проекта, как ставить задачи людям и как контролировать результат. Всё это и есть Скрам (Agile). В отличие от таких всеобъемлющих подходов к управлению проектами, как, например, стандарты Института Управления Проектами (PMI)® PMBOK® Guide, Скрам изначально предназначался для разработки программного обеспечения в условиях часто меняющихся требований. При этом Скрам (Agile) больше ориентирован на сам процесс разработки, чем на процесс управления. Эта технология хорошо дополняет любой из классических процессов управления и может быть с ним интегрирована при разработке даже очень больших IT проектов. В настоящий момент Agile практики стали частью PMBOK® Guide. На курсе «Agile — Scrum Foundation 1. Управление проектами с использованием гибких подходов». Вы научитесь организовывать процесс разработки программного обеспечения и получать готовый продукт в жёстко фиксированные, а главное, небольшие сроки в часто меняющихся условиях. В течение курса с помощью Скрама (Agile) Вы будете разрабатывать новый «продукт». Вы, будучи Скрам-командой, приобретёте живой опыт и испытаете на себе преимущество работы по Скраму (Agile). Под руководством нашего тренера вы пройдёте через различные, близкие к реалиям, ситуации, для решения которых надо будет применять новые, инновационные подходы Скрама (Agile). Аудитория курса: Разработчики программного обеспечения – члены команд разработки, тим-лиды (старшие групп разработки). Специалисты, желающие освоить роль Product Owner или Scrum Master в Scrum-командах. Менеджмент Scrum-команд, желающий познакомиться с особенностями работ внутри команды. Курс «Agile-Scrum Foundation 1. Управление проектами с использованием гибких подходов» дает  для подготовки к сертификациям Института Управления Проектами (PMI)® и PDU для продления имеющихся у вас сертификаций в соответствии с действующими правилами: PMI является зарегистрированной маркой Института Управления Проектами. PMBoK является зарегистрированной маркой Института Управления Проектами.

По окончании курса Вы будете уметь:

• Распределять роли и обязанности в Скрам
• Гибко анализировать потребности стейкхолдеров в проекте
• Создавать Vision Statement проекта
• Выполнять декомпозицию работ
• Оценивать объем работ и упорядочивать по степени важности перечень требуемых работ (бэклог продукта и спринта)
• Планировать и осуществлять спринты, включая демонстрацию продукта и ретроспективу спринта
• Планировать календарный график выпуска функций продукта

Специалисты, обладающие этими знаниями и навыками, в настоящее время крайне востребованы. Большинство выпускников наших курсов делают успешную карьеру и пользуются уважением работодателей.

Продолжительность курса — 16 ак. ч.

Предварительная подготовка

Требуемая подготовка:


Приветствуется опыт участия в проектах, в том числе в качестве исполнителя, и опыт работы с инструментами планирования и управления проектами

Рекомендуемая подготовка (необязательная):


Успешное окончание курса IT — Project Management: управление проектами в области информационных технологий  или Основы управления ИТ услугами по ITIL 4.0 или OSA: Service Desk и процессы поддержки ИТ услуг в соответствии с ITIL® 2011. Часть 1 или эквивалентная подготовка.

Получить консультацию о необходимой предварительной подготовке по курсу Вы можете у наших менеджеров:
+7 (495) 232-32-16.

Наличие предварительной подготовки является залогом Вашего успешного обучения. Предварительная подготовка указывается в виде названия других курсов Центра (Обязательная предварительная подготовка).

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

Если Вы обладаете знаниями менее 85-90% рекомендуемого курса, то Вы обязательно должны получить предварительную подготовку.

Только после этого Вы сможете качественно обучиться на выбранном курсе.

Рекомендуемые курсы по специальности

Чтобы стать профессионалом, мы рекомендуем Вам вместе с этим курсом изучить:

Тестирование по курсу

Программа курса

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

• утренним группам с 8:30 до 10:00
• дневным группам — по 1 ак.ч. до и после занятий (13.15-14.00, 17.10-17.55)

Ближайшие группы 

На данный момент групп нет

На данный момент групп нет

Центр предоставляет специальную услугу Индивидуального обучения. Длительность индивидуального обучения — минимум 4 академических часа. Стоимость обучения в Москве уточняйте у менеджера. При выездном индивидуальном обучении устанавливается надбавка: +40% от стоимости заказанных часов при выезде в пределах МКАД, +40% от стоимости заказанных часов и + 1% от стоимости заказанных часов за каждый километр удаления от МКАД при выезде в пределах Московской области. Стоимость выезда за пределы Московской области рассчитывается индивидуально менеджерами по работе с корпоративными клиентами.

**Указана минимальная цена за индивидуальное обучение. Число часов работы с преподавателем в 2 раза меньше, чем при обучении в группе. Если Вам для полного усвоения материала курса потребуется больше часов работы с преподавателем, то они оплачиваются дополнительно. В случае занятий по индивидуальной программе расчёт стоимости обучения и количества необходимых часов производится отдельно.

Документы об окончании

В зависимости от программы обучения выдаются следующие документы:

Удостоверение*

Свидетельство

^*Для получения удостоверения вам необходимо предоставить копию диплома о высшем или среднем профессиональном образовании.

По курсу «Agile — Scrum Foundation 1. Управление проектами с использованием гибких подходов» сертификат международного образца с PDU выдаётся в бумажном формате (на руки студенту либо по почте).

Все документы Центра

Актуальные новости

Учебный центр «Специалист» против коронавируса

Дорогие слушатели! Наши очные занятия проходят в штатном режиме. Все группы пройдут обучение в заявленные сроки. Если вы не готовы переходить на дистанционное обучение — всё в порядке! Вам не нужно ничего не менять, мы заботимся о вашем здоровье и безопасности. Случаев заболевания коронавирусом в Учебном центре «Специалист» не выявлено, мы соблюдаем все меры предосторожности. Будьте здоровы и продолжайте учёбу!

Полный текст новости

Лидерами не рождаются, лидерами становятся! Запишитесь на курс «Разбуди в себе лидера!»

Вы хотите стать лидером, повысить личную и профессиональную эффективность, обрести уверенность в себе? Задатки харизматичного лидера есть в каждом. Мы научим Вас выявлять и развивать их! Новый уникальный курс Центра поможет Вам сформулировать успешную стратегию лидерства. Вы будете правильно определять и достигать значимые цели в карьере, работе, личной жизни и творчестве.

Полный текст новости

Все новости

Главная > Курсы > Курсы управления проектами (PM) и IT-менеджмент | IT-менеджмент

Методология управления проектами: разработка и внедрение

Стандарты для разработки методологии управления проектами

Цель методологии управления проектами заключается в формализации принципов, правил и процессов проектного управления.

При разработке методологии управления проектами используются существующие стандарты и методологии в области проектного менеджмента (ISO 21500, PMBOK®, ГОСТ Р 54869-2011 «Проектный менеджмент», гибкие методологии проектного менеджмента Agile) и, главным образом, лучшие практические наработки в области проектного управления крупнейших организаций российского и зарубежного рынка.

Структура методологии управления проектами

Методология управления проектами в разных организациях может состоять из разных типов нормативно-методических документов. Как правило, в методологию управления проектами входят:

• Положение о проектной деятельности (описывает подходы, принципы, классификацию, жизненный цикл, ролевую модель проектов, интеграцию проектного управления с другими процессами организации)
• Регламенты/Процедуры управления проектами (описывают схемы и шаги процессов проектного управления с участием всех заинтересованных сторон)
• Методики и Правила (детально описывают отдельные аспекты процессов проектного управления)
• Инструкции (описывают глубоко отдельные аспекты процессов проектного управления с позиции одной роли)
• Шаблоны документов

Состав шаблонов по управлению проектами

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

• Документ, устанавливающий основные параметры проекта (Устав/Паспорт проекта или Заявка на проект, утверждается приказом, распоряжением или протоколом коллегиального органа, например, Проектного комитета)
• Документ, устанавливающий сроки исполнения задач или контрольных точек, а также ответственных за их исполнение (План-график/Детальный план/Календарный план проекта)
• Документ, изменяющий параметры проекта (Запрос на изменение)
• Документ, показывающий статус выполнения проекта (Отчет о статусе проекта)
• Документ, который утверждает завершение проекта (Итоговый отчет или Отчет о завершении проекта)

Внедрение методологии управления проектами

Утверждать методологию проектного управления лучше всего после апробации процессов и шаблонов на пилотных проектах. До внедрения методологии рекомендуется также сделать следующие шаги:

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

 

Смотрите также: