Текст книги "Планирование для начинающих. Методическое пособие. Теория"

2.4 Разработка плана управления проектами

Начнём с разработки плана управления проектом.

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

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

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

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

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

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

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

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

Ключевые компоненты плана управления проектами рассматриваются в следующих разделах:

ЖИЗНЕННЫЙ ЦИКЛ ПРОЕКТА. Жизненный цикл проекта описывает этапы работы над проектом, необходимые для получения результатов (например, требования, проектирование, код, тестирование, реализация). Жизненные циклы проекта варьируются от управляемых планом до управляемых изменениями.

Что значит выражение «жизненные циклы проекта варьируются от управляемых планом до управляемых изменениями»? Смотрите, как мы уже видели жизненный цикл проекта, описывает этапы работы над проектом, то есть у нас есть конкретный план и конкретные этапы работ. Изменения – это такой процесс, который оформляется документально, который утверждается многими заинтересованными сторонами и которые проходят конечную ревизию. После этого мы получаем изменённый документ. Так вот жизненный цикл проекта также варьируется от плана до изменения. То есть у нас есть один существующий план мы прошли огромное количество процедур, изменили план управления проектами и теперь мы руководствуемся изменённому плану управления, от управления планом до управления изменениями. Далее эта формулировка так же будет встречаться.

ПОДХОД К РАЗРАБОТКЕ. Подходы к разработке для получения результатов проекта варьируются от управляемых планом до управляемых изменениями.

УПРАВЛЕНЧЕСКИЕ ОБЗОРЫ. Основные этапы будут встроены в план управления проектом, с указанием времени, когда руководство и заинтересованные стороны будут сравнивать ход проекта с тем, что было запланировано, и определить необходимые изменения в любой из планов управления.

ПРОЦЕССЫ УПРАВЛЕНИЯ ПРОЕКТАМИ, КОТОРЫЕ БУДУТ ИСПОЛЬЗОВАТЬСЯ В ПРОЕКТЕ. Руководитель проекта должен определить степень, в которой процессы должны использоваться, исходя из потребностей проекта. Адаптация процесса является частью разработки плана управления проектом.

ПЛАНЫ УПРАВЛЕНИЯ ОБЛАСТЯМИ ЗНАНИЙ. Это планы управления для содержания, расписания, стоимости, качества, ресурсов, коммуникаций, рисков, закупок и управления заинтересованными сторонами.

БАЗОВЫЕ ПЛАНЫ (БАЗОВЫЙ ПЛАН ИЗМЕРЕНИЯ ИСПОЛНЕНИЯ). План управления проектом включает содержание, расписание и базовые показатели затрат, по которым руководитель проекта будет отчитываться о производительности проекта. Эти базовые планы создаются во время планирования. Они представляют собой запись того, что проект был запланирован, создано расписание и заложен в бюджет с точки зрения содержания, расписания и затрат, и используются для сравнения фактической производительности проекта с запланированной производительностью. Ниже перечислены элементы, включенные в каждый базовый план:

• Базовый план по содержанию: описание содержания проекта, иерархическая структура работ и словарь Иерархической структуры работ.

• Базовый план по расписанию. Согласованный график, включая даты начала и окончания каждой работы, а также запланированные этапы.

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

Теперь поговорим о создании плана управления проектом.

СОСТАВЛЕНИЕ ПЛАНА УПРАВЛЕНИЯ ПРОЕКТОМ. План управления проектом, включая индивидуальные планы управления и содержание, расписание и базовые показатели затрат, создается путем выполнения действий. После того, как план управления проектом завершен, спонсор или ключевые заинтересованные стороны рассматривают и утверждают его. Процесс разработки плана управления проектом должен привести к созданию плана управления проектом, который будет одобрен, реалистичен и формален. Другими словами, план управления проектом должен быть согласован с теми, кто участвует в проекте, он должен быть официально утвержден, каждый должен верить, что проект может быть выполнен в соответствии с планом, и он должен оставаться официальным документом, который контролируется и используется на протяжении всего проекта.

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

2.5 Планирование управления содержанием

Каждый из проектов имеет содержание. Согласованное и утвержденное, нам нужно выяснить каким образом формируется этот план, кем он формируется и что делать с ним дальше. И так, начинаем.

– Процесс: Планирование управления содержанием

– Группа процессов: Планирование

– Область знаний: Управление содержанием.

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

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

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

По сути, входные данные – это то, что идёт до этого процесса, то есть та цепочка работ, которая должна быть выполнена до того момента, как начнётся этот процесс. Также существуют выходные данные. Это тот процесс, та цепочка работ, которая будет начинаться после того процесса, который в данный момент закончился, они могут между собой пересекаться. Схема входов и выходов будет у вас в конспектах, её нужно будет изучить, ознакомиться с ней зазубривать её не обязательно, но важно понимать, что из чего состоит что откуда исходит. Итак, входные данные.

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

Каждый проект имеет подход к разработке. Это может быть подход, управляемый планом, управляемый изменениями или комбинированный, или гибридный подход. Подход к разработке влияет на то, как будут выявляться требования, а также как будет разрабатываться описание содержания и ИСР (для всего проекта сразу или на высоком уровне для всего проекта, а затем более подробно для каждого релиза).

ПЛАН УПРАВЛЕНИЯ СОДЕРЖАНИЕМ. План управления содержанием, который является основным результатом процесса планирование управления содержанием, является частью плана управления проектом, и руководитель проекта использует его для руководства проектом до закрытия. План управления содержанием, по существу, содержит три части, в которых подробно описывается, как содержание будет планироваться, выполняться и контролироваться. Он определяет следующее:

– Как выполнить содержание

– Какие инструменты следует использовать для планирования выполнения содержания

– Как создать ИСР

– Как содержание будет управляться и контролироваться в плане управления проектом

– Как получить принятие результатов

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

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

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

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

Идея создания плана управления содержанием и всех планов управления: если вы не можете планировать это, вы не можете сделать это.

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

2.6 Сбор требований

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

СБОР ТРЕБОВАНИЙ

– Процесс: Сбор требований

– Группа процессов: Планирование

– Область знаний: Управление содержанием

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

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

– Качество: Прописанные параметры качества для чего либо, которые нельзя нарушать.

– Бизнеспроцессы: «вы должны отслеживать и сообщать о расходах проекта таким образом.»

– Соответствие: «по закону, мы должны соответствовать этому стандарту безопасности.»

– Управление проектами: «мы требуем, чтобы процедура управления рисками X использовалась в проекте.»

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

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

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

Для сбора требований можно использовать следующие инструменты и методы.

МОЗГОВОЙ ШТУРМ. Цель мозгового штурма заключается не столько в том, чтобы заставить людей поделиться своими мыслями по теме, сколько в том, чтобы побудить участников развивать идеи друг друга.

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

ИНТЕРВЬЮ. Команда или руководитель проекта проводят собеседование с заинтересованными сторонами проекта, чтобы выяснить их требования к конкретному элементу продукта или к проектной работе, или к проекту в целом.

ФОКУСГРУППЫ. Метод фокусгрупп помогает получить мнения и требования к продукту или аспекту проекта от заинтересованных сторон и экспертов по предметной области.

БЕНЧМАРКИНГ. Бенчмаркинг фокусируется на измерении эффективности организаций по сравнению с другими организациями в той же отрасли.

ГОЛОСОВАНИЕ. Голосование обычно используется для принятия решений в группе

АНАЛИЗ РЕШЕНИЙ НА ОСНОВЕ МНОЖЕСТВА КРИТЕРИЕВ. С помощью этого метода заинтересованные стороны количественно оценивают требования, используя матрицу принятия решений, основанную на таких факторах, как ожидаемые уровни риска, оценки времени и оценки затрат и выгод.

ДИАГРАММА СХОДСТВА. В этом методе идеи, порожденные любыми другими методами сбора требований, сгруппированы по сходствам. Каждой группе требований присваивается название. Такая сортировка облегчает просмотр дополнительных областей содержания (или рисков), которые не были определены.

Немного о диаграмме сходства. Я вам объясню, что это такое. Предположим, у нас есть какой-то определённый проект и у этого проекта есть ряд требований. Например, проект создания библиотеки. У нас есть такая зона, как хранение книг, какие книги у нас там будут содержаться, какие будут использованы компьютеры, в каких помещениях всё это будет находиться и для каких посетителей библиотека. Вот смотрите у нас есть четыре критерия которые нам нужно заполнить это и называется диаграмма требования, то есть на основе собранных требований, собранных идей мы расфасовываем эту информацию, в ту зону, которой она соответствует вот как на примере диаграммы.

АССОЦИАТИВНАЯ КАРТА. Ментальная карта это диаграмма идей или заметок, помогающая генерировать, классифицировать или записывать информацию.

МЕТОД НОМИНАЛЬНЫХ ГРУПП. Задается вопрос или проблема, все участники встречи записывают, а затем делятся своими идеями, группа обсуждает, что было поделено, а затем идеи ранжируются на основе того, какие идеи являются наиболее полезными.

НАБЛЮДЕНИЯ/ОБСУЖДЕНИЯ. Этот метод обычно включает в себя наблюдение за потенциальным пользователем продукта на работе и, в некоторых случаях, участие в работе, чтобы помочь определить требования.

ФАСИЛИТАЦИЯ. Этот метод использует консенсусный подход, который позволяет достичь общего согласия в отношении решения.

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

КОНТЕКСТНАЯ ДИАГРАММА. Она показывает границы содержания продукта, выделяя продукт и его взаимодействие с людьми, процессами или системами.

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

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

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

Документация по требованиям может содержать различные типы информации, но одна вещь, которая должна быть включена это критерии приемки.

Требования должны быть описаны таким образом, чтобы связанные с ними результаты можно было протестировать или измерить в соответствии с требованиями в процессе Подтверждения содержания для подтверждения приемлемости результатов.

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

Матрица отслеживания требований, еще один результат процесса сбора требований, помогает связать требования с целями и/или другими требованиями для обеспечения достижения стратегических целей.

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

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