Размещено на http://www.allbest.ru/

ВВЕДЕНИЕ

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

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

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

Необходимость решения большого количества проблем, поставленных сегодня перед мировым сообществом, привело к созданию больших комплексных систем. Сложно сказать, был ли менеджмент проектов разработан в результате необходимости менеджеров в технике управления такими проблемами. Однако бесспорно то, что сегодняшние комплексные проблемы требуют объединенных усилий многих отраслей. Управление проектами обеспечивает именно такой подход к решению сложных проблем.

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

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

Задачи:

1. Рассмотреть, что собой представляет управление содержанием проекта.

2. Рассмотреть структуру работ проекта.

3. Изучить, что такое глоссарий проекта и для чего он нужен.

1. УПРАВЛЕНИЕ СОДЕРЖАНИЕМ ПРОЕКТА

Управление содержанием проекта (scope management) - область знаний управления проектом, что включает процессы определения необходимых объемов работ проекта, планирование их выполнения, управление изменениями в объемах и работах.

Процессы, что используются при управлении содержанием проекта и вспомогательные инструменты могут различаться в зависимости от сферы реализации проекта. Утвержденное содержание проекта и иерархическая структура работ являются базовым планом проекта, куда могут вноситься изменения, проводится отслеживание выполнения работ [1, с 27].

Управление содержанием проекта включает в себя процессы, необходимые для подтверждения того, что проект включает все виды деятельности и только те из них, которые необходимы для успешного завершения проекта. Основная задача - определение и проверка того, что включено или не включено в проект [2].

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

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

· Сбор требований - процесс определения и документирования потребностей заинтересованных сторон проекта для достижения целей проекта.

· Определение содержания - процесс разработки подробного описания проекта и продукта.

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

· Подтверждение содержания - процесс формализованной приемки завершенных результатов проекта.

· Управление содержанием - процесс мониторинга статуса проекта и содержания продукта, а также управления изменениями базового плана по содержанию.

Эти процессы взаимосвязаны друг с другом, а также с процессами из других областей знаний. Каждый процесс может включать в себя действия одного или нескольких лиц в зависимости от потребностей проекта. Каждый процесс происходит в каждом проекте не менее одного раза и выполняется в одной или нескольких фазах проекта, если проект разбит на фазы. Хотя процессы представлены здесь в виде дискретных элементов с четко выделенными границами, на практике они накладываются друг на друга и оказывают взаимное влияние; такие наложения и взаимодействия здесь не описаны. Взаимодействия процессов подробно рассматриваются в главе 3 «Процессы управления проектом». В контексте проекта термин «содержание» может обозначать:

· Содержание продукта. Свойства и функции, которые характеризуют продукт, услугу или результат; и/или

· Содержание проекта. Работы, которые необходимо выполнить для создания продукта, услуги или результата с указанными характеристиками и функциями.

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

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

2. СТРУКТУРА РАБОТ ПРОЕКТА

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

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

Рисунок 2.1 Структура работ по проекту

Рисунок 2.2 Структура работ проекта

Для этого весь проект делится на компоненты или хозяйственные программы, определяющие подразделы и отдельные группы работ. Эта процедура известна как составление дерева работ проекта (WBS - Work Breakdown Structure) [5].

Иерархическая структура работ (далее ИСР) -- это разбиение вашего проекта на более мелкие и измеримые части. ИСР описывает все результаты/работы, которые должны быть получены/выполнены для завершения проекта. Все, что не вошло в ИСР в рамки проекта не входит [6].

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

Структурная декомпозиция работ проекта является центральным инструментом определения работ, которые должны выполняться в рамках проекта. Описание работ (пакетов работ) должно включать: содержание работ, предполагаемые результаты, возможность измерения и оценки степени их выполнения. Чаще всего используется два вида СДР:

Декомпозиция по функциональному принципу (продукту проекта и его составляющим). Ниже в качестве примера приведена декомпозиция проекта по системной интеграции. Основным продуктом проекта является информационная система, включающая в себя промежуточные продукты: локальную сеть, рабочие станции и сервера, СУБД, системное и прикладное программное обеспечение.

Декомпозиция по хронологическому принципу (жизненному циклу проекта).

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

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

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

Одна из главных задач СДР -- определение и проверка того, что включено или не включено в предметную составляющую проекта, т.е. фиксация границ проекта.

Чем детальнее в СДР отражены задачи нижнего уровня, тем выше может обеспечиваться прозрачность проекта. Проработанная в деталях и передаваемая в реальное исполнение СДР является эффективным инструментом по управлению проектом. При этом опытные менеджеры особое внимание уделяют фиксации мероприятий, передающих результаты предшествующей задачи (задач) на вход последующей (последующим), что осуществляется посредством вех, фиксирующих условия передачи результатов, достижения текущих целей и необходимые в данном случае документы. Четкое и системное определение вех в СДР обеспечивает высокое качество обратной связи в управлении проектом и контроля его исполнения, так как основная часть вех содержит требования по предоставлению отчетности по состоянию задач. Такая методика позволяет эффективно учитывать отклонения от плановых параметров задач и управлять изменениями проекта [4].

2.1 СТРУКТУРНАЯ МОДЕЛЬ ПРОЕКТА ПО ФАЗАМ ЖИЗНЕННОГО ЦИКЛА

Основные подходы к построению структурной модели проекта:

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

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

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

* Дерево ресурсов -- структурная декомпозиция требуемых ресурсов для выполнения проекта.

* Дерево стоимости -- структурная декомпозиция стоимостных показателей проекта, которая строится на основе СДР, дерева ресурсов и данных о стоимости элементов проекта.

* Структурная декомпозиция контрактов по работам проекта.

* Дерево распределения рисков проектов.

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

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

3. ГЛОССАРИЙ ПРОЕКТА

Замечали, когда, вы приходите в проектную команду, которая довольно давно работает над проектом, то первое время вы чувствуете себя несколько неуютно из-за того, что люди вокруг вас говорят на каком-то особенном, своем языке. Они используют названия модулей, краткие названия каких-то фич, состояний, ситуаций, форм, ролей, документов, мэйлстоунов и много еще чего, что для свежего уха превращается в какой-то совершенно не понятный «птичий язык». Это все - глоссарий проекта. Он существует независимо от того, фиксируете вы его в документе или нет. Он появляется в первые дни работы над проектом, когда появляется первое рабочее название будущей системы, и очень активно формируется в последующие дни, во время бесед с заказчиками и обсуждений внутри команды. Фиксировать его на бумаге или нет - ваше дело. Но я думаю, что глоссарий проекта это документ из тех, что больше нужен вам (проектной команде), чем заказчику, а потому сформировать его и поддерживать в рабочем состоянии весьма полезно. управление проект глоссарий

Глоссарий входит в число необходимых документов во всех «тяжелых» методиках разработки (RUP, MSF). Но и для гибких (agile) методик, глоссарий, относится к вещам, которые лучше иметь, чем не иметь. Основополагающим принципом всех agile методик является поддержка внутри - командных коммуникаций на самом высоком уровне. Согласитесь, сложно общаться, не зная языка, а глоссарий - это и есть язык, на котором говорит команда. Для ведения глоссария вполне подходят wiki системы.

Важная функция, которую должен выполнять глоссарий, это установление соответствия между терминами заказчика (предметной области) и терминами архитектуры системы. Это особенно важно для тяжелых методик, в которых проектные роли аналитика, архитектора, разработчика и тестировщика выполняют разные люди. Типичный пример - наименования состояний объектов. На уровне требований и пользовательского интерфейса они имеют свои имена. Когда мы спускаемся на уровень дизайна и реализации - те же вещи называются по-другому. Учитывая, что требования (use cases) и дизайн (design models) описаны в разных документах возникает путаница и всякие нелепые ошибки.

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

В глоссарии желательно зафиксировать:

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

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

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

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

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

· названия состояний сущностей системы и соответствующие им системные названия.

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

· роли пользователей [7].

3.1 ГЛОССАРИЙ РАБОТЫ

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

Цель проекта -- то, чем должен завершиться проект. Проект всегда имеет две цели:

Управление содержанием проекта (scope management) - область знаний управления проектом, что включает процессы определения необходимых объемов работ проекта, планирование их выполнения, управление изменениями в объемах и работах.

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

Определение содержания - процесс разработки подробного описания проекта и продукта.

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

Подтверждение содержания - процесс формализованной приемки завершенных результатов проекта.

Управление содержанием - процесс мониторинга статуса проекта и содержания продукта, а также управления изменениями базового плана по содержанию.

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

Иерархическая структура работ (далее ИСР) -- это разбиение вашего проекта на более мелкие и измеримые части. ИСР описывает все результаты/работы, которые должны быть получены/выполнены для завершения проекта. Все, что не вошло в ИСР в рамки проекта не входит.

ЗАКЛЮЧЕНИЕ

Изучив предложенную тему можно сделать выводы.

Управление содержанием проекта (scope management) - область знаний управления проектом, что включает процессы определения необходимых объемов работ проекта, планирование их выполнения, управление изменениями в объемах и работах.

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

Для реализации проекта необходимо выполнить определенные виды работ.

Для этого весь проект делится на компоненты или хозяйственные программы, определяющие подразделы и отдельные группы работ. Эта процедура известна как составление дерева работ проекта (WBS - Work Breakdown Structure).

Мною были рассмотрены также основные подходы к построению структурной модели проекта.

Глоссарий входит в число необходимых документов во всех «тяжелых» методиках разработки (RUP, MSF). Но и для гибких (agile) методик, глоссарий, относится к вещам, которые лучше иметь, чем не иметь. Основополагающим принципом всех agile методик является поддержка внутри - командных коммуникаций на самом высоком уровне. Согласитесь, сложно общаться, не зная языка, а глоссарий - это и есть язык, на котором говорит команда. Для ведения глоссария вполне подходят wiki системы.

Размещено на Allbest.ru