воскресенье, 29 июня 2008 г.

Что такое PRINCE2

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

Оглавление

Введение

Личные впечатления

Об описание методологии

Процесс и активности

Организационная структура

Business case oriented

О продуктах и проектах

Чего в PRINCE нет

Описания техник для остальных 5ти из 8ми компонентов

Управления людьми

Управления поставками и контрактами

Воды

Введение

PRINCE2 — английский стандарт на ведение проектов. Изначально создан для IT проектов, потом расширен для использования в любых проектах.

PRINCE2 — основан на четком процессе, разбитом на 8 стадий и 45 подстадий. В этом он подобен RUP. У каждой стадии есть свой набор целей, активностей а также входных и выходных артефактов. Есть критерии, по которым можно судить о качестве артефактов. Они позволяют контролировать отклонения от качества в течение жизненного цикла проекта.

Особенностью стандарта является его масштабируемость. В каждой стадии и подстадии описано, какую ее часть можно опустить, если проект маленький и гигантский масштаб процессов не требуется. С одной стороны, это очень мило, с другой, отмечается появление большого количества так называемых PINO (Prince in name only) проектов, в которых опущено почти все, но они гордо зовутся сделанными по методологии PRINCE2.

Личные впечатления

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

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

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

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

Стандарт является методологией, пригодной к непосредственному использованию для выполнения проектов (по крайней мере IT проектов).

Об описание методологии

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

Начато с того что там 8 стадий процесса (например старт проекта, стратегическое управление проектом) и 8 компонентов/аспектов (планирование, управление изменениями и т п).

Затем детализирована каждая стадия по активностям (или подстадиям) (их уже 45), входящим и исходящим артефактам, критериям, позволяющим активность начать.

Затем описаны связи между активностями (в итоге получаем некую «трехмерную сеть», как оно в жизни и бывает). Указаны какие из 8ми компонентов (аспектов) являются актуальными для каких из 45ти подстадий. Забавно, что у каждой из 45 подстадий есть уникальный идентификатор из одной буквы (первая в названии стадии) и цифры — (порядковый номер в стадии). Сразу видно руку Itшников. :-)

Наконец, для трех важных компонентов (Планирование, управление изменениями и управление качеством) даны уже пошаговые инструкции - техники, как это можно делать. Ключевое слово — МОЖНО. На самом деле «техники» - конкретные пошаговые инструкции могут быть разными, в рамках стадий. При описании процессов даны все важные моменты, о которых надо помнить, выбирая (или придумывая) ту или иную технику. Очень похоже на интерфейсы и имплементации — процессы это интерфейсы, техники — имплементации. Три стандартные техники — дефолтовые имплементации. Имплементации, кстати, вполне себе пригодные к непосредственному использованию.

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

Процесс и активности

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

Например, процесс стратегического управления идет в течение всего жизненного цикла проекта.

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

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

Организационная структура

Интересен подход PRINCE к оргструктуре проекта.

Есть менеджер проекта в традиционном понимании.

Есть совет проекта (project board), перед которым регулярно отчитывается менеджер. Состоит из 3х человек — Заказчика, Главного пользователя и Главного специалиста. Совет проекта ответственен за принятие стратегических решений. Менеджер проекта обязан отслеживать возможные проблемы и предлагать совету альтернативные решения. Совет решает — какой путь лучше.

Есть служба project assurance цель которой предоставлять независимое мнение о проекте с точки зрения тех же трех групп людей — заказчиков, пользователей и специалистов (в предметной области)

Служба готовит три отчета — buniness report, user report & technical report.

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

Во второй — отслеживание того, насколько хорошо выполняются требования пользователей

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

В маленьких проектах роль project assurance выполняет совет проекта. В больших это — отдельная группа.

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

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

Стадии и компоненты

Стадии:

  • Starting Up a Project (SU)

    Смысл стадии — понять, а надо ли вообще проект делать. Описать причины проекта в документе Мандат Проекта. Выбрать подход к выполнению проекта.

  • Initiating a Project (IP)

    Здесь описывается Бизнес Кейс проекта, формируется орг структура. Планируется сроки и цена проекта.

  • Planning (PL)

    Планирование и перепланирование проекта. Идет все время жизни проекта.

  • Directing a Project (DP)

    Стратегическое управление проектом. Выполняется Project Board-ом на основе документов, предоставленных менеджером проекта и Project Assurance. Менеджер обязан отслеживать возможные риски и возможности проекта и формулировать вопросы к PB. Желательно, чтобы на них можно было ответить да или нет. PB принимает решения. Причем каждый член PB должен отстаивать свой аспект — бизнес, usability и технологический соответственно.

  • Controlling a Stage (CS)

    Стандартные активности по ежедневному управлению проектами при помощи контура управления. Осуществляются менеджером проекта.

  • Managing Product Delivery (MP)

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

  • Managing Stage Boundaries (SB)

    Активности по подготовке и предоставлению информации Project Boardу.

  • Closing a Project (CP)

    Активности по контролируемому закрытию проекта.

Компоненты :

  • Business case

  • Организация

  • Контроль

  • Управление рисками

  • Управление конфигурациаями

  • Планы

  • Управление качеством

  • Управление изменениями

Business case oriented

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

О продуктах и проектах

Забавен «рекурсивный» подход, продвигаемый авторами PRINCE. Например, вместо выделения скажем прототипирования в отдельный этап проекта, утверждается что проекты могут состоять из проектов и прототипирование — отдельный проект, который можно делать по методологии PRINCE. Как отдельный проект может быть выделен проект по пониманию, а нужно ли вообще наш проект делать и тп. Явно прослеживается стремление к обобщению и борьба с расползанием, которого так много в PMBOK

Аналогично, термином «продкут», называют как сам продукт, который надо произвести, так и любую его часть, а также существующие продукты, которые надо задействовать при производстве и продукты, которые при производстве произвести придется (например любой проектный документ — тоже продукт, а написание его можно считать проектом, который можно делать по методологии PRINCE) :-)

При планировании, вместо традиционного WBS используют PBS — Product Breakdown Structure, которая разбивает целевой продукт на непересекающиеся подпродукты (в том числе и проектная документация туда входит)

Чего в PRINCE нет

Описания техник для остальных 5ти из 8ми компонентов

Тоесть для

  • Business case

  • Organisation

  • Controls

  • Management of Risk

  • Configuration management

Хотя первые три «разжеваны» очень хорошо, а вторые две сильно зависят от характера проекта.

Для остальных трех техники описаны:

  • Plans

  • Quality Management

  • Change control

Управления людьми

Остаётся вне контекста, кроме описания орг. Структуры. Ничего про мотивацию и т п

Управления поставками и контрактами

Утверждается что, например, заключение контракта - проект, который надо делать по методологии PRINCE2 (см о продуктах и проектах)

Воды

Никаких лишних рассуждений за жизнь


8 комментариев:

Евгений комментирует...

Я знаком только с IT-шными AIM, agile/scrum, было бы интересно ознакомиться с данной концепцией более подробно.
В связи с чем вопрос: где можно скачать полную документация по PRINCE2?

dima-lovermann комментирует...

Очень кратно и в общем понятно. Спасибо за резюме. Использовал для подготовки к экзамену в качестве "расширителя кругозора". Читать самому документацию в силу недостатка времени нет! :)

Andrew комментирует...

Подскажите, пожалуйста, где скачать полную документацию по PRINCE2?
Заранее огромное спасибо!

Роман Кузьмин комментирует...

Где скачать последнюю редакцию - сам не знаю. У меня есть только

OGC - Prince2 Manual - 3rd Edition - 2002.pdf

Но он, скорее всего, уже устарел.

Jericho комментирует...

Роман, подскажите, пожалуйста а где можно найти даже и устаревшую документацию по PRINCE2. Интересно пока для расширения кругозора.
И вот ещё, не совсем всё таки понятно и мало где написанно, это видимо отсылка к . Что собственно такое Проект?
Так же как в ITIL что такое OLA. Как конкретный пример, в последнее время хоть стали появляться более полные описания каталогов услуг и SLA в принципе. Может когда нибудь и до OLA дойдет.

Jericho комментирует...

мм..
понятно, что проект это, что-то чего мы раньше не делали, где-то читал пример, про поставки, а теперь по новому это и есть проект, пока по новому не станет стандартным процессом. Но может быть проект - что-то ещё?

Mina Vucinic комментирует...

This site gives you a good overview of PRINCE2 Foundation Manual: http://ru.prince2.wiki/PRINCE2

Mina Vucinic комментирует...

Этот сайт предоставит вам хороший обзор руководства PRINCE2 Foundation: http://ru.prince2.wiki/PRINCE2