[Управление проектами] Проекты в контролируемой среде или краткий пересказ PRINCE2
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
В эпоху продуктовой разработки с постоянным использованием гибких методологий и «насаживанием» их везде (порой даже не к месту) хочется напомнить об одной из классических методологий проектного управления. Вопрос классических методологий всё еще актуален для договорных отношений Заказчик – Исполнитель и проектов с каскадной формой управления. Упомянутый в заголовке статьи стандарт PRINCE2 также актуален и для проектов с гибкими методологиями, так как Agile-методы очень четко и структурировано рассказывают, как правильно разрабатывать продукт (и управлять именно процессом разработки продукта), но как именно управлять проектной деятельностью (а это, как известно, не только один процесс производства продукта) гибкие методологии покрывают не всегда и не полностью. В силу своей разрекламированности PMBOK всегда был более востребованный и популярный, вместе с этим очень перегруженный по группам процессов (например, для IT-проектов). Многим руководителям проектов использование проектной методологии PRINCE2 в сравнении с PMBOK (в силу лаконичности и структурированности первого) позволяет более изящно управлять проектами разного масштаба и структур. Историческая справкаPRINCE2 (Projects in a Controlled Environment) – структурированный метод управления проектами, разработанный в 1989 году Central Computer and Telecommunications Agency (CCTA) в Великобритании. Как указывают сами авторы методологии, PRINCE2 создан на основе опыта, полученного из тысяч проектов, в центре внимания методологии – управленческие стороны проекта.В 2013 году права на PRINCE2 переданы AXELOS Ltd (совместное предприятие правительства Великобритании и компании Capita).Исторически методология создавалась для руководства проектами в сфере IT, но в настоящее время является «de facto» стандартом для руководства проектами в Великобритании.Краткие вводные PRINCE2:
- не гарантирует соблюдение сроков или бюджета, сокращение издержек или увеличение прибыли;
- гарантирует прозрачный учет и управление рисками проекта;
- формализует возможности оперативного получения данных с необходимой детализацией;
- способствует повышению производительности работ в рамках унифицированных форматов управленческих документов.
Создатели методологии также утверждают, что использование PRINCE2 помогает обеспечить правильной информацией в правильное время правильных людей для принятия правильных решений.Как и любая методология, PRINCE2 обладает своими плюсами и минусами:+-Применим для проектов любой проектной области (особенно для IT)Отсутствуют рекомендации
по инструментам менеджеровЧеткая структура процессов (включая четкие входы и выходы) и процедур управления и контроляОтсутствуют процессы управления поставками (закупками)Минимальные усилия на адаптацию методологии
к проектамОтсутствуют процессы управления участниками команды проекта (в том числе с точки зрения лидерских компетенций)Формула PRINCE2Авторы методологии приводят следующую схему проектного управления: фундаментом являются 7 принципов, в центре находятся 7 процессов, объединяющие 7 тем, вокруг – окружающая среда проекта. При этом стандарт четко указывает, что выбранные авторами 7 принципов универсальны и не требуют обоснования, при этом управление проектом по PRINCE2 возможно только при реализации всех 7 принципов (здесь есть некоторая аналогия со SCRUM: «Только следуя всем правилам SCRUM, можно прийти к успеху проекта»).
7 принципов:
- CONTINUED BUSINESS JUSTIFICATION (Постоянная оценка целесообразности). Спонсор проекта (в русских договорных отношениях это чаще всего Заказчик, даже если он внутренний) должен быть постоянно уверен в необходимости реализации проекта, если такая необходимость отпала, то проект следует прекратить. Ожидаемые выгоды должны быть больше затрат и рисков.
- LEARN FROM EXPERIENCE (Учет предыдущего опыта). Принцип призывает руководителей проектов постоянно анализировать и использовать извлеченные уроки других проектов, а также фиксировать собственный опыт в ходе своего проекта.
- DEFINED ROLES AND RESPONSIBILITIES (Определенные роли и обязанности). В каждом проекте должна быть сформирована матрица ответственности в рамках проекта и его организационной структуре. Авторы PRINCE2 выделяют три заинтересованные стороны проекта: бизнес (определяет цели проекта и инвестирует его), пользователи (используют продукт проекта) и поставщики (предоставляют ресурсы).
- MANAGE BY STAGES (Управления по стадиям). Проект должен планироваться, отслеживаться и контролироваться по стадиям, в конце каждой стадии должен обновляться план следующей стадии с учетом результатов завершающейся текущей стадии. Между каждой стадией должны присутствовать точки принятия основных решений.
- MANAGE BY EXCEPTION (Управление по исключениям). Руководство проектами следует осуществлять путем определения обязанностей и ответственности на каждом уровне проекта при помощи строгого делегирования полномочий. Такой способ управления позволяет экономить как время высшего руководства, спонсоров проекта, так и самого менеджера проекта. Допустимые отклонения должны быть определены для каждого уровня плана проекта.
- FOCUS ON PRODUCT (Фокус на продукте). Акцент в проекте должен быть на конечном продукте и его качестве. Процедура управления изменениями снижает увеличение скоупа проекта. Акцент на качестве и утвержденном описании продукта снижает неудовлетворенность пользователей (потребителей) конченного продукта проекта.
- TAILOR TO SUIT THE PROJECT ENVIRONMENT (Адаптация к внешним условиям). Проектная команда должна осознавать, каким образом происходит адаптация принципов PRINCE2 к внешним условиям проекта (корпоративные стандарты, корпоративная культура), подходит ли используемый метод для окружения проекта.
7 тем = аспекты проекта, которые требуют постоянного внимания:
- Экономическое обоснование (Business Case) позволяет сформировать механизмы для определения востребованности, выполнимости и жизнеспособности проекта, а также остается ли проект таковым на протяжении всего его выполнения. На основании экономического обоснования с учетом выгоды, затрат и рисков должно приниматься решение о дальнейшем продолжении проекта и его инвестициях.
- Организация (Organization). Как и в любой методологии проектного управления заинтересованными лицами проекта являются лицо или группа лиц, которая может влиять на проект или на которую может влиять проект (включая процессы и риски проекта). В проекте должна быть определена и сформирована четкая структура ответственности и обязанностей проекта. Подробное описание каждой роли можно прочитать в стандарте.
- Управление качеством (Quality) – определение и внедрение средств в рамках проекта для подтверждения, что продукты проекта соответствуют утвержденному описанию и подходят для тех целей, для которых они предназначены. Любой продукт проекта должен обладать определенным комплексом свойств и неотъемлемых или установленных характеристик, которые дают понимание, что продукт отвечает ожиданиям или удовлетворяет установленным потребностям, требованиям или спецификации.
- Планы работ (Plans) – широко описывает понятия и уровни планов в проекте (план стадии инициации проекта, план самого проекта, планы стадий создания продуктов, планы исключений, планы команды).
- Анализ и управление рисками проекта (Risk). Здесь по классике: управление рисками должно осуществляться не только при инициации проекта или в момент наступления риска, а на протяжении всего срока реализации проекта. Тема анализа и управления риска предоставляет подход к выявлению, оценке и контролю рисков во время проекта и, как результат, повышению успеха проекта.
- Управление изменениями содержания (Change) = определение, оценка и последующее управление любыми потенциальными и одобренными изменениями конечных продуктов проекта. При управлении изменениями всегда должен использоваться предыдущий опыт, запросы на изменения и отклонения от спецификации должны оцениваться с точки зрения влияния на экономическое обоснование проекта.
- Принятие решений (Progress) – предназначена для формирования и утверждения механизмов мониторинга фактических результатов и достижений проекта и их сравнение с запланированными, прогнозирование целей проекта и его отклонения.
7 процессов, каждый из которых представляет набор операций для управления и реализации проекта:
- Начало проекта (Starting up a Project). Цель процесса – выполнить минимальные необходимые действия для принятия решения, стоить ли приступать к стадии инициирования проекта. Данный процесс подразумевает подготовку наброска экономического обоснования проекта для принятия решения о финансировании и необходимости проекта.
- Руководство проектом (Directing a Project) – принятие ключевых решений управляющим советом (Directing), делегируя оперативное управление менеджеру проекта. Данный процесс не равен фактическому управлению проектом менеджером проекта.
- Инициация проекта (Initiating a Project) предполагает подготовку стратегий управления риском, качеством, коммуникациями и конфигурацией проекта, создание плана проекта и установку средств контроля проекта. Данный процесс выполняется уже менеджером проекта.
- Контроль стадии (Controlling a Stage) – делегирование и отслеживание выполнения работы в рамках каждой стадии проекта, формирование отчетов о прогрессе, принятие решений по инцидентам и обеспечение корректирующих действий в проекте.
- Управление границами стадии (Managing a Stage Boundary) – предоставление необходимой информации менеджером проекта для оценки управляющим советом проекта успехов текущей стадии и утверждения плана следующей стадии с учетом экономической обоснованности.
- Управление созданием продукта (Managing Product Delivery) – управление связью между менеджером проекта и менеджером команды посредством установления формальных требований к приемке, выполнению и поставке результатов проектной работы по созданию продукта проекта.
- Закрытие проекта (Closing a Project) – обеспечение конкретного момента для подтверждения приемки продукта и признания достижения целевых показателей проекта, либо отсутствия экономического обоснования продолжения проекта в случае его досрочного прекращения.
Возможная адаптация PRINCE2PRINCE2 в рамках своего седьмого принципа говорит о том, что все составляющие стандарта (кроме принципов) могут быть адаптированы под конкретный проект (в зависимости от сложности и масштаба) и его окружающую среду (внешние методологии, местное законодательство, стандарты по охране труда, корпоративную культуру). Использование методологии в любом виде (полном или адаптированном) должно добавлять ценность проекта. При этом следует понимать, что не существует единственного правильного варианта адаптации.Короткие правила для адаптации, которые регламентируют авторы в рамках всего стандарта:
- Принципы стандарта должны выполняться всегда.
- Темы и процессы можно адаптировать при соблюдении всех принципов.
- Назначение каждой темы (аспекта проекта) должны сохраняться при адаптации с учетом выполнения минимальных требований.
- Используемые техники должны отвечать потребностям и масштабу проекта.
- Адаптация не должна повышать риск провала проекта.
- Проектный метод должен соответствовать проектной среде с учетом существующей управленческой структуры.
Хочется отметить отдельно, что PRINCE2 также допускает комбинации и сочетания практик Agile в управлении проектом вместе со своими подходами. Как и Agile-методы, PRINCE2 в своих последних изданиях фокусируются на вовлечении стейкхолдеров и плотной работе с Заказчиками, разделении на четкие роли в рамках темы «Организация». В 2015 году AXELOS выпустил руководство «PRINCE2 Agile: лучшие практики и квалификации», описывающее случаи, в которых необходимо применять те или иные техники Agile совместно с PRINCE2, а когда от них стоит отказаться.Стадии проекта в PRINCE2 Agile по-прежнему должны устанавливаться на основе потребностей управления проектом, а не превращаться в итерации. Каждый этап содержит один или несколько «выпусков», и каждый «выпуск» содержит одну или несколько «итераций». В PRINCE2 Agile итерации обычно называют «временными рамками». PRINCE2 Agile определяет Agile как набор моделей поведения и практик, а не использование адаптивного жизненного цикла.
Собственный опытВ своих проектах в «классическом» виде я никогда не применяла PRINCE2 по нескольким причинам: в нашей компании принята своя методология, основанная на комбинации «куски PMBOK + собственные правила», у Заказчиков либо отсутствовала методология управления проектами, либо использовались вырожденные случаи PMBOK/IPMA. При этом внутри нашей компании не запрещено вести проекты по лучшим практикам или методологиям, если это не нарушает правила компании с точки зрения процессов и соглашений с Заказчиком.Пожалуй, самая главная причина — избыточность в классическом виде некоторых процессов методологии конкретно для моих проектов и взаимоотношений с Заказчиками. Сам стандарт говорит о том, что PRINCE2 допускает использование минимального количества документов (минимальный перечень и требования указаны в стандарте). Вместе с этим, при возникновении каких-то нестандартных ситуации или отклонений в проекте я каждый раз стараюсь проанализировать ситуации по шаблону «а что говорит PRINCE2 на этот счет».В силу NDA с Заказчиками и компанией могу привести только сопоставление управленческих продуктов PRINCE2, которые были адаптированы в рамках моих проектов (шаблоны PRINCE2):Название документа по PRINCE2Назначение документа по PRINCE2Проектные артефактыКраткое описание проектаДля предоставления полного и надежного основания для инициации проектаМеморандум оценки работ / проекта по шаблону компанииЭкономическое обоснованиеДокумент, составляемый в начале проекта и содержащий в себе описание продукта проекта, структуру команды, роли и ответственность, и экономическое обоснованиеДокументация инициации проектаОписание основных характеристик проектаВнутренний приказ о начале работ по проекту по шаблону компанииСтратегия управления коммуникациямиОписание смысла и частоты коммуникаций с внешними и внутренними участниками проектаПлан управления взаимодействием, в котором описаны представители команд исполнителя и Заказчика, периодичность отчетности, правила проведения совещаний и т.п.План проектаПредоставляет описания, как и когда цели должны быть достигнуты, отображая основные продукты, активности и ресурсы, требуемые в рамках планаПлан работ по проекту в MS ProjectОписание продуктаЦели и задачи создания продукта, описание требований к характеристикам продукта и качеству, критерии качестваФункциональная спецификация (оформляется оп требованиям/шаблонам Заказчика)Стратегия управления качествомОпределение техники и стандартов качества, которые должны быть примененыВнутренний регламент компании «Технология выполнения проектов»Реестр рисковЗапись определенных рисков, относящихся к проекту, включая их статус и историюРеестр рисков аналогичный шаблону PRINCE2Отчет об окончании стадииИспользуется для обзора прогресса на определенную дату, общей ситуации на проектеОтчет о ходе проекта в свободной формеОтчет о контрольных точкахИспользуется, чтобы сообщать статус комплекса работ с заданной частотойОтчет об исключенииПроизводится, когда есть прогноз, что рамки допустимых отклонений плана стадии или плана проекта будут превышеныЗафиксированного формата нет, чаще всего отчет об исключениях направляется в виде электронного письмаОтчет о завершении проектаИспользуется при закрытии проекта для оценки как выполняется проект в сравнении с Инициацией проектаОтчет о завершении проекта по внутреннему шаблону компанииОтчет об урокахИспользуется для передачи извлеченных уроков, которые могут быть полезны для применения на других проектахПлан проверки выгодИспользуется для определения, как и когда могут проводится измерения достижения выгод проекта, ожидаемые Старшим пользователемНе используется на уровне РП в компанииБонус: СертификацияВ настоящее время очень развиты разнообразные программы сертификации в сфере IT, в том числе и по проектному управлению. AXELOS также проводит сертификации по двум своим стандартам: PRINCE2 и PRINCE2 Agile. По данным за 2019 год, сертификация PRINCE2 имеет самое большое распространение в мире в области проектного управления (1,4 млн сертифицированных профессионалов), на 2 месте PMP (700 тыс.), на 3 — IPMA (250 тыс.).В России в настоящее время доступны все 4 экзамена, краткое описание привожу ниже. СтупеньСрок действияФормат сдачиPRINCE2 FoundationБессрочныйЭлектронное тестирование: 60 минут, 60 вопросов; проходной балл >55%; нельзя пользоваться книгойPRINCE2 PractitionerОт 3х до 5 лет
(в настоящее время выдаются сертификаты на 3 года)Наличие уровня PRINCE2 Foundation
+
Электронное тестирование: 150 минут, кейс и 68 вопросов по кейсу; проходной балл >55%; можно использовать официальное издание "The Managing Successful Projects with PRINCE2"PRINCE2 Agile FoundationБессрочныйЭлектронное тестирование: 60 минут, 60 вопросов; проходной балл >55%; нельзя пользоваться книгойPRINCE2 Agile Practitioner3 годаНаличие одного из уровней PRINCE2 Foundation
+
Электронное тестирование: кейс и 50 вопросов по нему, время – 150 минут, проходной балл >60%, можно использовать официальное издание "PRINCE2 Agile guide"Сейчас среди многих моих знакомых бытует мнение, что сдавать срочные сертификаты в России по большей части бессмысленно, и редко такие сертификаты приносят долгосрочные бенефиты. Впрочем, в любом случае такие сертификаты помогают понять реальный уровень своих знаний стандартов, поднимают самооценку, и, наверное, статус среди других руководителей проектов (этот список можно продолжать словами про красивые строчки в резюме…).В любом случае, если погружаться в стандарт основательно, то профессиональные сертификаты получать надо. В свое время, я получила обе степени PRINCE2, и смело могу заверить, что после внимательного изучения стандарта и доступных в онлайн-тестов можно легко сдать сертификацию, тем более сейчас существует множество авторизованных провайдеров, проводящих обучение и подготовку к сертификации.
===========
Источник:
habr.com
===========
Похожие новости:
- [IT-инфраструктура, Управление проектами, Энергия и элементы питания, Инженерные системы] «Да будет свет!», или Как мы меняли систему ИБП в ЦОДе в разгар пандемии
- [Анализ и проектирование систем, Управление разработкой, Управление проектами, Микросервисы] Скрытые расходы при переходе на микросервисы
- [Open source, Управление проектами, Развитие стартапа, Управление продуктом, Управление персоналом] Мы всё переписали на $HOTLANG, но стартап всё равно провалился (перевод)
- [Управление проектами] Ведущий переговоры 2020
- [Программирование, Управление разработкой, Управление проектами, Управление продуктом] Оценка трудозатрат в разработке ПО для начинающих (перевод)
- [Управление разработкой, Управление проектами, Управление продуктом, Управление персоналом] Корпоративные опросы всех бесят, но я знаю, как это исправить
- [Управление проектами, Управление персоналом, Удалённая работа] 8 фич, которые разгрузили нашу техподдержку
- [Управление проектами, Управление продуктом] Как я научился получать удовольствие от pet-проектов
- [Управление проектами, GTD, Фриланс, Лайфхаки для гиков, Здоровье] Черная дыра прокрастинации: о чем не пишут в других статьях, и что на самом деле важнее всего
- [Управление проектами, Управление персоналом, Научно-популярное] Почему дилетанты ведут себя увереннее, чем профи, и что с этим делать
Теги для поиска: #_upravlenie_proektami (Управление проектами), #_upravlenie_proektami (Управление проектами), #_prince2, #_project_management, #_upravlenie_proektami (
Управление проектами
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 23:46
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 В эпоху продуктовой разработки с постоянным использованием гибких методологий и «насаживанием» их везде (порой даже не к месту) хочется напомнить об одной из классических методологий проектного управления. Вопрос классических методологий всё еще актуален для договорных отношений Заказчик – Исполнитель и проектов с каскадной формой управления. Упомянутый в заголовке статьи стандарт PRINCE2 также актуален и для проектов с гибкими методологиями, так как Agile-методы очень четко и структурировано рассказывают, как правильно разрабатывать продукт (и управлять именно процессом разработки продукта), но как именно управлять проектной деятельностью (а это, как известно, не только один процесс производства продукта) гибкие методологии покрывают не всегда и не полностью. В силу своей разрекламированности PMBOK всегда был более востребованный и популярный, вместе с этим очень перегруженный по группам процессов (например, для IT-проектов). Многим руководителям проектов использование проектной методологии PRINCE2 в сравнении с PMBOK (в силу лаконичности и структурированности первого) позволяет более изящно управлять проектами разного масштаба и структур. Историческая справкаPRINCE2 (Projects in a Controlled Environment) – структурированный метод управления проектами, разработанный в 1989 году Central Computer and Telecommunications Agency (CCTA) в Великобритании. Как указывают сами авторы методологии, PRINCE2 создан на основе опыта, полученного из тысяч проектов, в центре внимания методологии – управленческие стороны проекта.В 2013 году права на PRINCE2 переданы AXELOS Ltd (совместное предприятие правительства Великобритании и компании Capita).Исторически методология создавалась для руководства проектами в сфере IT, но в настоящее время является «de facto» стандартом для руководства проектами в Великобритании.Краткие вводные PRINCE2:
 7 принципов:
 Собственный опытВ своих проектах в «классическом» виде я никогда не применяла PRINCE2 по нескольким причинам: в нашей компании принята своя методология, основанная на комбинации «куски PMBOK + собственные правила», у Заказчиков либо отсутствовала методология управления проектами, либо использовались вырожденные случаи PMBOK/IPMA. При этом внутри нашей компании не запрещено вести проекты по лучшим практикам или методологиям, если это не нарушает правила компании с точки зрения процессов и соглашений с Заказчиком.Пожалуй, самая главная причина — избыточность в классическом виде некоторых процессов методологии конкретно для моих проектов и взаимоотношений с Заказчиками. Сам стандарт говорит о том, что PRINCE2 допускает использование минимального количества документов (минимальный перечень и требования указаны в стандарте). Вместе с этим, при возникновении каких-то нестандартных ситуации или отклонений в проекте я каждый раз стараюсь проанализировать ситуации по шаблону «а что говорит PRINCE2 на этот счет».В силу NDA с Заказчиками и компанией могу привести только сопоставление управленческих продуктов PRINCE2, которые были адаптированы в рамках моих проектов (шаблоны PRINCE2):Название документа по PRINCE2Назначение документа по PRINCE2Проектные артефактыКраткое описание проектаДля предоставления полного и надежного основания для инициации проектаМеморандум оценки работ / проекта по шаблону компанииЭкономическое обоснованиеДокумент, составляемый в начале проекта и содержащий в себе описание продукта проекта, структуру команды, роли и ответственность, и экономическое обоснованиеДокументация инициации проектаОписание основных характеристик проектаВнутренний приказ о начале работ по проекту по шаблону компанииСтратегия управления коммуникациямиОписание смысла и частоты коммуникаций с внешними и внутренними участниками проектаПлан управления взаимодействием, в котором описаны представители команд исполнителя и Заказчика, периодичность отчетности, правила проведения совещаний и т.п.План проектаПредоставляет описания, как и когда цели должны быть достигнуты, отображая основные продукты, активности и ресурсы, требуемые в рамках планаПлан работ по проекту в MS ProjectОписание продуктаЦели и задачи создания продукта, описание требований к характеристикам продукта и качеству, критерии качестваФункциональная спецификация (оформляется оп требованиям/шаблонам Заказчика)Стратегия управления качествомОпределение техники и стандартов качества, которые должны быть примененыВнутренний регламент компании «Технология выполнения проектов»Реестр рисковЗапись определенных рисков, относящихся к проекту, включая их статус и историюРеестр рисков аналогичный шаблону PRINCE2Отчет об окончании стадииИспользуется для обзора прогресса на определенную дату, общей ситуации на проектеОтчет о ходе проекта в свободной формеОтчет о контрольных точкахИспользуется, чтобы сообщать статус комплекса работ с заданной частотойОтчет об исключенииПроизводится, когда есть прогноз, что рамки допустимых отклонений плана стадии или плана проекта будут превышеныЗафиксированного формата нет, чаще всего отчет об исключениях направляется в виде электронного письмаОтчет о завершении проектаИспользуется при закрытии проекта для оценки как выполняется проект в сравнении с Инициацией проектаОтчет о завершении проекта по внутреннему шаблону компанииОтчет об урокахИспользуется для передачи извлеченных уроков, которые могут быть полезны для применения на других проектахПлан проверки выгодИспользуется для определения, как и когда могут проводится измерения достижения выгод проекта, ожидаемые Старшим пользователемНе используется на уровне РП в компанииБонус: СертификацияВ настоящее время очень развиты разнообразные программы сертификации в сфере IT, в том числе и по проектному управлению. AXELOS также проводит сертификации по двум своим стандартам: PRINCE2 и PRINCE2 Agile. По данным за 2019 год, сертификация PRINCE2 имеет самое большое распространение в мире в области проектного управления (1,4 млн сертифицированных профессионалов), на 2 месте PMP (700 тыс.), на 3 — IPMA (250 тыс.).В России в настоящее время доступны все 4 экзамена, краткое описание привожу ниже. СтупеньСрок действияФормат сдачиPRINCE2 FoundationБессрочныйЭлектронное тестирование: 60 минут, 60 вопросов; проходной балл >55%; нельзя пользоваться книгойPRINCE2 PractitionerОт 3х до 5 лет (в настоящее время выдаются сертификаты на 3 года)Наличие уровня PRINCE2 Foundation + Электронное тестирование: 150 минут, кейс и 68 вопросов по кейсу; проходной балл >55%; можно использовать официальное издание "The Managing Successful Projects with PRINCE2"PRINCE2 Agile FoundationБессрочныйЭлектронное тестирование: 60 минут, 60 вопросов; проходной балл >55%; нельзя пользоваться книгойPRINCE2 Agile Practitioner3 годаНаличие одного из уровней PRINCE2 Foundation + Электронное тестирование: кейс и 50 вопросов по нему, время – 150 минут, проходной балл >60%, можно использовать официальное издание "PRINCE2 Agile guide"Сейчас среди многих моих знакомых бытует мнение, что сдавать срочные сертификаты в России по большей части бессмысленно, и редко такие сертификаты приносят долгосрочные бенефиты. Впрочем, в любом случае такие сертификаты помогают понять реальный уровень своих знаний стандартов, поднимают самооценку, и, наверное, статус среди других руководителей проектов (этот список можно продолжать словами про красивые строчки в резюме…).В любом случае, если погружаться в стандарт основательно, то профессиональные сертификаты получать надо. В свое время, я получила обе степени PRINCE2, и смело могу заверить, что после внимательного изучения стандарта и доступных в онлайн-тестов можно легко сдать сертификацию, тем более сейчас существует множество авторизованных провайдеров, проводящих обучение и подготовку к сертификации. =========== Источник: habr.com =========== Похожие новости:
Управление проектами ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 23:46
Часовой пояс: UTC + 5