Какие есть методологии управления проектами?

Всем привет! Продолжаю рассказ про воркфлоу задач. Часть первая здесь. 

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

Классический процесс управления проектом выглядит так:

Инициация это определение и старт работ. Чем меньше проект, тем проще эта стадия проходит.

Планирование это самая важная часть (успешного) проекта. По американской методологии PMBOK планирование занимает порядка 50% всего времени, что особенно подчеркивает его значимость. На данном этапе определяется скоуп работы и разделение на более мелкие задачи/подзадачи (декомпозиция или WBS — Work Breakdown Structure).

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

Все современные методологии управления проектами, в той или иной мере, «гибкие» — то есть, планирование, исполнение и контроль происходят циклами.

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

«Классическое» или «традиционное» проектное управление. Это наиболее широко распространённый метод управления проектами, основанный на каскадном цикле, при котором задача проходит последовательные этапы, напоминающим поток. Это, как раз и есть workflow со статусами и переходами:

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

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

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

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

В этом нам могут помочь гибкие методологии.

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

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

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

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

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

Продолжение следует… 

Всем добра!