Методология проектного управления. Стандарты. Информационные технологии. Лекция №2

СТАНДАРТЫ. ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ

ЧАСТЬ 2

методах, способах и стратегиях исследования предмета.
Методология управления проектами — это набор руководящих принципов и процедур для управления проектом.
Метод (от др.-греч. μέθοδος — путь исследования или познания, от μετά- + ὁδός «путь») - способ достижения какой-либо цели.
Фреймворк - алгоритм, описывающий роли и правила в процессе работы над проектом; конкретный метод управления проектами.

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

Пример: посадка дерева:
Купить саженец
Выкопать яму
Поставить в нее саженец
Присыпать землей
Полить дерево
Пример: создание интернет-сайта:
Написать техническое задание
Нарисовать дизайн
Сверстать дизайн
Написать код
Протестировать
Запустить проект

Инструменты классической последовательной методологии управления проектами:
- инструменты календарно-сетевого планирования, в т.ч. диаграмма Ганта.

Методология классического менеджмента. Модель Waterfall (каскадная модель, модель «водопад»)

Постоянный мониторинг показателей и тестирование результатов;
- Наличие запасного времени на каждом этапе;
- Простота использования;
- Четкое разделение на этапы позволяет организовать и распределить работу;
- Поскольку назад вернуться нельзя, необходимо идеально справляться с выполнением каждого этапа, что зачастую позволяет добиться лучших результатов;
- Детально разработанная документация позволяет новым ресурсам проще влиться в проект.
Слабые стороны, недостатки, ограничения методологии Waterfall:
– Нетолерантность к изменениям, недостаточная гибкость;
- Необходимость начинать все за ново при обнаружении ошибок;
- Сложность и повышенная значимость этапа сбора требований и планирования проекта.

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

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

Манифест Agile :
Наивысшим приоритетом является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
Изменение требований приветствуется, даже на поздних стадиях разработки.
Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
Работающий продукт — основной показатель прогресса.
Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно.
Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
Простота — искусство минимизации лишней работы — крайне необходима.
Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Agile – семейство гибких итеративно-инкрементальных методов к управлению проектами и продуктами.

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

адаптивность;
- Свобода: у исполнителей проекта имеется возможность экспериментировать и вносить изменения постепенно;
- Пониженный риск: Методология Agile подразумевает регулярное получение обратной связи от заинтересованных участников и последующее внесение изменений. Это значительно сокращает риск провала проекта, так как нужные ресурсы вовлечены в процесс.
Недостатки, ограничения методологии Agile:
Необходимость самостоятельно составлять свою систему управления, руководствуясь принципами Agile;
Необходимость существенных изменений всей организации, начиная процедурами и заканчивая базовыми ценностями;
Отсутствие четкого плана: В Agile подходе реагирование на изменения происходит тогда, когда они возникают, что затрудняет управление ресурсами и планирование;
Сложность взаимодействия.

Инструменты (фреймворки) управления проектами в рамках методологии:
Scrum, Kanban, Crystal, LeSS, SAFe, Nexus.

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

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

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

по упорядочиванию бэклога (списка работ);
Планирование Спринта (короткий временной интервал, в течение которого выполняется заданный объем работы);
Ежедневные летучки;
Подведение итогов Спринта;
Ретроспектива Спринта

может справляться с большими сложными проектами;
- динамичность;
- Эффективная командная работа;
- Быстрое внесение изменений и регулярная обратная связь с заинтересованными сторонами.
 Недостатки, ограничения Scrum:
- Scrum очень требователен к команде проекта;
- Неконтролируемое расширение масштабов;
- Повышенный риск;
- Недостаточная гибкость к ресурсам команды

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

Waterfall и Agile.

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

между двумя совершенно противоположными подходами, нужно будет искать компромиссы в области требований и гибкости.
- Сочетание лучшего от обоих подходов. Методология, сочетающая в себе все лучшее от двух подходов, лишает вас гибкости Agile и стабильности Waterfall. Любые изменения, которые вы будете вносить, должны будут соответствовать бюджету и плану, обозначенным заранее.
 Применимость гибридной методологии:
Гибридная методология больше всего подойдет проектам с размытыми требованиями, в которых важны и планирование, и гибкость.
В основном это проекты среднего объема с высокой сложностью и фиксированным бюджетом. Скорее всего, у вас будет определенное представление о конечной цели, но при этом возможны эксперименты. С заинтересованными сторонами понадобится тесное взаимодействие, особенно после этапа планирования.

компании IBM Дейвом Сноуденом для описания модели решения возникающих проблем при принятии решений менеджментом компании. Согласно модели Кеневин, принятие решения и методика выработки этого решения должна зависеть от состояния системы, в которой это решение принимается.
Система - это множество элементов, находящихся в отношениях и связях друг с другом, которые образуют определенную целостность и единство. Сноуден подразделяет все системы на 4 категории:
(Упорядоченные) простые (Simple) системы;
Упорядоченные сложные (Complicated) системы;
Запутанные (Complex) системы / Неупорядоченные сложные системы;
Хаотичные (Chaotic) системы.

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

Упорядоченные простые системы понятны, для их решения у команды есть опыт. Уже на старте понятно, что получится в результате, за какие деньги и в какие сроки.
Формула принятия решений: Определяем – Классифицируем – Реагируем.
Методология управления проектами, методы и инструменты: Каскадная методология управления проектами и другие наилучшие практики.
Пример: производство стульев – задача ясна и понятна.

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

Упорядоченные сложные системы: задача не уникальна, однако опыта работы в этом направлении у команды нет
Формула принятия решения: Определяем – Анализируем – Реагируем. Методология управления проектами, методы и инструменты: подходы PMI , Prince2 и PMBoK 
Пример: производство стульев в условиях невесомости – технология изготовления понятна, но влияние факторов среды не очевидно.

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

Формула принятия решения: Измеряем – Определяем – Реагируем.
Методология управления проектами, методы и инструменты: Agile , в частности Scrum.
Пример: эксперимент, моделирующий на Земле ремонт космической станции в состоянии невесомости. 

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

Хаотичные – абсолютно новые задачи, которые никто и никогда не решал раньше. Попытка разобраться с такой системой – путь к инновациям. Здесь хорошо работает экспериментальный подход. Любой способ решения (стабилизации системы) будет новым. Порой нужно действовать вразрез с традиционными методами менеджмента. 
Формула принятия решения: Действуем – Определяем – Реагируем. Метод: новый, комбинация методов.
Пример: любой стартап.

от типа проекта

задачам вашего проекта. Как должен выглядеть конечный результат? Какие выгоды он должен предоставлять? Вот несколько примеров:
• Если это материальный объект — например, здание или бытовые товары — с четко определенными материалами и понятными ожиданиями заинтересованных сторон, удачным может стать применение последовательной методологии, например каскадной или методологии критического пути.
• Если же это программный продукт или приложение, окончательный вариант которого еще не разработан, то оптимальным решением для проекта может стать гибкая Agile-методология.
• Если экологическая устойчивость является ключевой ценностью вашей организации и неотъемлемой частью создаваемого продукта, рассмотрите методологию PRiSM.
• Процессно-ориентированные методологии, например бережливое производство или бережливое производство плюс шесть сигм, помогут оперативно разработать простейший работающий продукт.

создаваемый для сопоставления их с другими подобными явлениями

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

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

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

Baseline, описывающий требования к компетенциям, необходимым менеджерам проектов и членам проектных команд для управления проектами, программами и портфелем проектов.
Для оценки компетенций используется четырехуровневая система сертификации IPMA:
уровень А — Сертифицированный директор проектов;
уровень B — Сертифицированный старший менеджер проектов;
уровень С — Сертифицированный менеджер проектов;
уровень D — Сертифицированный специалист по управлению проектами.

Стандарты International Project Management Association (IPMA)

обоснование проекта с точки зрения бизнеса;
определенная организационная структура для команды управления проектом;
продукто-ориентированный подход к планированию проекта;
акцент на разделение проекта на управляемые и контролируемые стадии;
гибкость применения в соответствии с уровнем проекта.
Сферы применения стандарта PRINCE2:
IT-проекты по разработке и внедрению новых информационных технологий и продуктов.
Разработка и вывод на рынок новых продуктов.
Жилищная сфера.
Инженерные нововведения.
Общественный сектор проектной деятельности.

при проектировании;
ГОСТ Р 52806–2007. Менеджмент рисков проектов. Общие положения;
ГОСТ Р 52807–2007. Руководство по оценке компетентности менеджеров проектов;
ГОСТ Р 53892-2010. Руководство по оценке компетентности менеджеров проектов. Области компетентности и критерии профессионального соответствия;
ГОСТ Р ИСО/МЭК ТО 16326–2002. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом.
ГОСТ Р 54869—2011 «Проектный менеджмент. Требования к управлению проектом»  (Россия)
ГОСТ Р 54870—2011 «Проектный менеджмент. Требования к управлению портфелем проектов» (Россия)
ГОСТ Р 54871—2011 «Проектный менеджмент. Требования к управлению программой» (Россия)
ГОСТ Р ИСО 21500 – 2014 «Руководство по проектному менеджменту»)

Стандарты по управлению проектами, разработанные в России, и зарубежные стандарты, переведенные на русский язык

для составления смет

Программы для организации коммуникаций, конференций, командной коммуникации

Комплексные системы автоматизированного управления проектами

применяемым процессам управления проектами;
зрелости проектного управления;
культуре вашей организации