Никита Сергеев - Трансформация: особенности управления проектами преобразований. МВА-библиотека

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

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

Если брать аналогию из биологии, то это цикл от яйца до гусеницы и бабочки.

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

В классике проектного менеджмента Вы увидите что-то такое ( рис.1.3 ):

Рис.1.3. Классический жизненный цикл проекта

На самом деле это деление на практике условное – каждая организация может детализировать или укрупнять стадии на свое усмотрение. И для одного проекта их можно сделать 4, для другого понадобится четко выделить 6 или более.

Например, вот так классический 4-фазный жизненный цикл может стать 6-фазным или более ( рис.1.4 ):

Рис.1.4. Преобразование 4-фазного жизненного цикла в 6-фазный

Вокруг стадий жизненного цикла очень удобно привязывать результаты (или работы, или документы или другие моменты) которые должны быть сделаны в проекте. Результаты Вы показываете заказчику, документы держите для себя, работы предоставляете в разные службы (закупки, исполнители) и т. д. Пример «привязки» документов к фазам на рис.1.5 .

Рис.1.5. «Привязка» проектных документов к фазам

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

1. Дизайна/проектирования

2. Внедрения.

При чем первая фаза более важна – именно она высоковариантивная и определяет максимальное качество проекта. Мы об этом в книге поговорим отдельно чуть позже.

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

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

Но есть еще один жизненный цикл, которым издавна пользуются практики (и в последней версии РМВоК его наконец-то удосужились канонизировать наравне с Waterfall) – это адаптивныйжизненный цикл. Это тот самый модный Agile(гибкие методологии управления проектами).

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

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

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

В итеративном подходе в отличии от предиктивного (waterfall) мы не делаем планирование вначале, а осуществляем планирование в течение всего проекта. Мы начинаем что-то делать – и если вдруг что-либо сделали не так или поменялась ситуация – мы приводим все в соответствие.

Принципиальное отличие и значение этого подхода от Waterfall в том, что мы:

· Во-первых, изначально закладываем возможность что-то переделать по итогам полученной обратной связи по ходу проекта (от клиента\заказчика, от Спонсора, от ситуации, от оценки хода проекта или полученного промежуточного результата и т.д.);

· Во-вторых, постоянно контролируем нет ли изменений и делаем при необходимости перепланировку проекта

При инкрементном подходе Вы разбиваете проект на набор результатов (инкрементов), которые необходимо получить в ходе проекта (возможно, потом еще и увязать друг с другом, так как порознь они могут являть «запчастями», а не собранным «автомобилем»).

Каждый инкремент Вы запускаете «по кругу» (анализ-проектирование-разработка-тестирование-…) и «допиливаете» так, пока не будет достигнут необходимый результат. Это как «кушать слона по кусочку».

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

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

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

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

Даже тот же РМВoК описывает требования и содержание документов, но не дает шаблонов.

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