Т.А.

Маркина
УПРАВЛЕНИЕ ПРОЕКТАМИ В
ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЯХ

Санкт-Петербург
2016
 МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ
ФЕДЕРАЦИИ

УНИВЕРСИТЕТ ИТМО

Т.А. Маркина
УПРАВЛЕНИЕ ПРОЕКТАМИ В
ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЯХ
Учебное пособие

Санкт-Петербург
2016
Маркина Т.А. Управление проектами в информационных технологиях. Учебное
пособие. – СПб: Университет ИТМО, 2016. – 88 с.
Пособие содержит теоретический материал, методические указания и задания для
выполнения лабораторной работы, деловую игру по дисциплине «Управление
проектами».
Пособие предназначено для направлений подготовки магистров 09.04.01
«Информатика и вычислительная техника» и 09.04.04 «Программная инженерия».
Пособие предназначено для магистерских программ «Безопасность
вычислительных систем и сетей», «Проектирование встраиваемых
вычислительных система и систем на кристалле», «Интеллектуальные
информационные системы», «Информационно-вычислительные системы» и
«Программное обеспечение мобильных и встраиваемых систем».
Рекомендовано к печати протокол №4 от 20 декабря 2016 г. Ученого совета
факультета программной инженерии и компьютерной техники

Университет ИТМО – ведущий вуз России в области

информационных и фотонных технологий, один из немногих
российских вузов, получивших в 2009 году статус национального
исследовательского университета. С 2013 года Университет ИТМО –
участник программы повышения конкурентоспособности российских
университетов среди ведущих мировых научно-образовательных
центров, известной как проект «5 в 100». Цель Университета ИТМО –
становление исследовательского университета мирового уровня,
предпринимательского по типу, ориентированного на
интернационализацию всех направлений деятельности.
 Университет ИТМО, 2016

Маркина Т.А., 2016

Оглавление
Основные термины и определения ................................................................................. 4
Основные положения управления проектами ............................................................... 6
Жизненный цикл проекта............................................................................................. 8
Участники проекта........................................................................................................ 9
Формы организационной структуры ........................................................................ 11
Стандарты управления проектами ................................................................................ 14
Процессы управления проектами ................................................................................. 18
Модели управления проектами ..................................................................................... 25
Традиционная (каскадная) модель управления проектами .................................... 25
Модель управления проектами PRINCE2 ................................................................ 26
Гибкая методология управления проектами ............................................................ 28
Быстрая разработка приложений (Rapid Application Development) ....................... 30
Документация проекта ................................................................................................... 34
Основные документы для управления проектами ................................................... 34
Типы документации .................................................................................................... 34
Управление рисками проекта ........................................................................................ 37
Планирование управления рисками .......................................................................... 39
Идентификация рисков .............................................................................................. 40
Способы идентификации рисков............................................................................... 41
Качественный анализ рисков ..................................................................................... 43
Количественный анализ рисков ................................................................................ 44
Программные средства для управления проектами .................................................... 45
Microsoft Project .......................................................................................................... 45
Битрикс24 .................................................................................................................... 46
Primavera Project Planner (Primavera Systems, Inc.) .................................................. 46
SureTrak........................................................................................................................ 48
Artemis Views (Artemis International) ........................................................................ 48
Spider Project ................................................................................................................ 49
Лабораторная работа ...................................................................................................... 51
Использование MS Project для управления проектами ........................................... 51
Порядок выполнения работы ..................................................................................... 51
Теоретический материал ............................................................................................ 51
Структура отчета ........................................................................................................ 70
Деловая игра.................................................................................................................... 71
Вопросы на знание основ управления проектами ....................................................... 74

3
 Основные термины и определения
Управление проектами в области информационных технологий за последнее
время завоевало признание как наилучший метод планирования и управления
реализацией инвестиционных проектов. По американским оценкам применение
методологии Управления Проектами обеспечивает высокую надежность
достижения целей проекта и на 10-15% сокращает затраты на его реализацию.
В мире накоплен огромный опыт применения управления проектами в
области информационных технологий. В частности, эта методология применяется
во всех крупных IT компаниях мира. Программные средства для управления
проектами установлены на миллионах компьютерах во всем мире – только пакет
Microsoft Project установлен более чем на двух миллионах компьютеров.
Ассоциация управления проектами Project Management Institute (Институт
Управления Проектами) объединяет около 40 тысяч членов и имеет отделения
почти на всех континентах, в том числе есть Московское отделение.
Рассмотрим основные понятия и методы управления проектами.
Проект – это временное предприятие, предназначенное для создания
уникальных продуктов или услуг.
В данном контексте "Временное" означает, что у каждого проекта есть
начало и непременно наступает завершение, когда достигаются поставленные
цели, либо приходит понимание, что эти цели не могут быть достигнуты.
В данном контексте "Уникальных" означает, что создаваемые продукты или
услуги отличаются от других аналогичных продуктов и услуг. Примеры проектов:
разработка нового оборудования, разработка или внедрение программных средств
и т.д.
Согласно PMBook Управление проектами – это приложение знаний,
опыта, методов и средств к работам проекта для удовлетворения требований,
предъявляемых к проекту, и ожиданий участников проекта. Чтобы удовлетворить
эти требования и ожидания необходимо найти оптимальное сочетание между
всеми характеристиками проекта.
Управление проектами подчиняется четкой логике, которая связывает
между собой различные области знаний и процессы управления проектами.
Каждый проект приводит к созданию уникального продукта, услуги или
результата.
Прежде всего, у проекта обязательно имеются одна или несколько целей.
Под целями понимается не только конечные результаты проекта, но и выбранные
пути достижения этих результатов (например, применяемые в проекте технологии,
система управления проектом).
Достижение целей проекта может быть реализовано различными способами.
Для сравнения этих способов необходимы критерии успешности достижения
поставленных целей. Обычно в число основных критериев оценки различных
вариантов исполнения проекта входят сроки и стоимость достижения результатов.
При этом запланированные цели и качество обычно служат основными
ограничениями при рассмотрении и оценки различных вариантов. Конечно,
возможно использование и других критериев, и ограничений - в частности,
ресурсных.
Для управления проектами необходимы рычаги. Влиять на пути достижения
результатов проекта, цели, качество, сроки и стоимость исполнения работ можно,
выбирая применяемые технологии, состав, характеристики и назначения ресурсов

4
на выполнение тех или иных работ. Таким образом, применяемые технологии и
ресурсы проекта можно отнести к основным рычагам управления проектами.
Кроме этих основных существуют и вспомогательные средства, предназначенные
для управления основными. К таким вспомогательным рычагам управления можно
отнести, например, контракты, которые позволяют привлечь нужные ресурсы в
нужные сроки. Кроме того, для управления ресурсами необходимо обеспечить
эффективную организацию работ. Это касается структуры управления проектом,
организации информационного взаимодействия участников проекта, управления
персоналом.
Информация, используемая в управлении проектами, обычно не бывает
стопроцентно достоверной. Учет неопределенности исходной информации
необходим и при планировании проекта и для грамотного заключения контрактов.
Анализу и учету неопределенностей посвящен анализ рисков.
Управление проектом осуществляется посредством надлежащего
применения и интеграции логически сгруппированных процессов управления
проектом, объединенных в 5 групп:
• Процессы инициации – принятие решения о начале выполнения проекта;
• Процессы планирования – определение целей и критериев успеха проекта
и разработка рабочих схем их достижения;
• Процессы исполнения – координация людей и других ресурсов для
выполнения плана;
• Процессы мониторинга и контроля – определение соответствия плана и
исполнения проекта поставленным целям и критериям успеха и принятие решений
о необходимости применения корректирующих воздействий и определение
необходимых корректирующих воздействий, их согласование, утверждение и
применение;
• Процессы закрытия – формализация выполнения проекта и подведение
его к упорядоченному финалу.
Практически методология управления проектами помогает:
• обосновать целесообразность инвестиций,
• разработать оптимальную схему финансирования работ,
• составить план работ, включающий сроки исполнения работ,
потребление ресурсов, необходимые затраты,
• оптимально организовать исполнение работ и взаимодействие
участников проекта,
• осуществлять планирование и управление качеством,
• осуществлять анализ и управление проектными рисками,
• оптимально планировать и управлять контрактами,
• анализировать отклонения фактического хода выполнения работ от
запланированного и прогнозировать последствия возникающих
отклонений,
• моделировать корректирующие воздействия на информационных
моделях проектов и принимать обоснованные управленческие решения,
• вести архивы проектов и анализировать опыт их реализации, который
может быть использован в других проектах, и т.д.

5
 Основные положения управления проектами
Проекты зачастую используются как средство прямого или косвенного го
или нескольких из следующих стратегических соображений:
• требование рынка (например, автомобилестроительная компания
авторизует проект по изготовлению более экономичных автомобилей в ответ на
нехватку бензина);
• стратегическая возможность/бизнес-потребность (например,
тренинговая компания авторизует проект по созданию нового курса обучения в
целях увеличения доходов);
• социальная потребность (например, неправительственная
организация в развивающейся стране авторизует проект по предоставлению систем
питьевого водоснабжения, туалетов и санитарного просвещения сообществам,
страдающим от высокого уровня инфекционных заболеваний);
• защита окружающей среды (например, государственная компания
авторизует проект по созданию нового сервисного центра для электромобилей,
которые способствуют сокращению загрязнения окружающей среды);
• требование заказчика (например, компания-производитель
электроэнергии для общественного пользования авторизует проект по
строительству новой подстанции для электроснабжения нового промышленного
района);
• технологический прогресс (например, производитель компьютерной
техники авторизует проект по разработке более быстродействующего,
экономичного и компактного ноутбука с использованием достижений в технологии
изготовления компьютерной памяти и электронных компонентов);
• юридическое требование (например, производитель химических
веществ авторизует проект по разработке руководящих указаний по обращению с
новым токсичным материалом).
Организации осуществляют руководство для определения стратегического
направления и параметров производительности. Данное стратегическое
направление предоставляет цель, ожидания, задачи и действия, необходимые для
руководства деятельностью организации, и приводится в соответствие с бизнес-
целями. Работы по управлению проектом должны быть приведены в соответствие с
направлением организации на верхнем уровне, и в случае его изменения цели
проекта должны быть пересмотрены. В условиях исполнения проекта изменения в
целях проекта влияют на эффективность и успех проекта.
Основными принципами новой концепции управления являются:
1) углубление уровня обоснованности принимаемых инвестиционных
решений, используя механизм многовариантных и многофакторных
(технологических, экономических, социальных, экологических и других) оценок;
2) высокая степень координации и контроля работ в процессе
выполнения проекта;
3) систематический анализ и учет внешних изменений (конъюнктуры
рынка по всем видам ресурсов, непредвиденных обстоятельств и негативных
факторов) при реализации проектов.
Управление проектами базируется на системном подходе, что дает
возможность декомпозиции и структуризации проекта любой сложности при
принятии решений в сложных условиях (ситуациях). Отличительная особенность
методологии управления проектами состоит в сосредоточении прав и
ответственности за достижение целей проекта на одном человеке или небольшой

6
группе. Эти права и обязанности осуществляет руководитель проекта. При этом
обеспечивается:
1. Определение всех видов работ, необходимых для достижения целей
проекта, их структуризация и определение взаимосвязей.
2. Составление и контроль сметы расходов по реализации проекта.
3. Разработка и контроль графиков работ, необходимых для достижения
желаемого результата.
4. Распределение ресурсов, выделенных для реализации проекта, в условиях
неопределенностей и рисков.
5. Управление качеством выполнения всех работ по проекту, включая
достижение планируемого качества продукции, предлагаемой проектом, и
выполнение других требований заказчика.
6. Управление риском (рисками) на всех этапах осуществления проекта.
7. Обеспечение связи с клиентами, заказчиками, потребителями продукции,
с различными группами и лицами, вовлеченными в проект (социальные группы,
местное население, власти, средства массовой информации) для решения всех
вопросов, связанных с достижением успеха проекта.
При рассмотрении и изучении деятельности по управлению реализацией
проектов можно выделить ряд подходов, определяющих структуризацию этой
деятельности. Наиболее распространены: функциональный, динамический и
предметный подходы.
a) Функциональный подход отражает общий подход к проблеме
управления и предполагает рассмотрение основных управленческих функций или
видов управленческой деятельности при осуществлении проектов в соответствии с
классификацией, принятой в менеджменте. В то же время, специфика управления
проектами проявляется в определенной детализации отдельных функций
менеджмента и некотором смещении акцентов в их содержании применительно к
реализации и специфике конкретных проектов. С учетом этого в рамках
функционального подхода рассматриваются управленческие действия,
определяемые как функции управления проектами, включая: анализ,
планирование, организацию, контроль и регулирование.
b) Предметный подход определяет структуризацию управленческого
процесса по объектам проекта, на которые направлено управление. В рамках
предметного подхода рассматриваются два типа объектов: производственные
объекты (первый тип) и элементы, связанные с деятельностью по обеспечению
реализации проекта (второй тип). Объектами второго типа могут быть: финансы,
кадры, маркетинг, контроль, риски, материальные ресурсы, качество, информация
и другие элементы, обеспечивающие получение желаемого результата при
реализации проекта. Основные объекты первого и второго типов рассматриваются
по мере необходимости при изучении дисциплины.
c) Динамический подход (известный в литературе как специальный
менеджмент – project management), предполагает рассмотрение во времени
процессов, связанных с реализацией основных стадий и этапов осуществления
проекта: анализ проблемы, разработка концепции проекта, проектирование,
строительство, монтаж, пусконаладка, эксплуатация и завершение проекта.
Детализация рассматриваемых процессов применительно к конкретному проекту
(этапов и стадий работ осуществления проекта) может изменяться в широких
пределах.

7
 Жизненный цикл проекта

Жизненный цикл проекта – набор фаз, через которые проходит проект с

момента его инициации до момента закрытия. Фазы, как правило, являются
последовательными, а их названия и количество определяются потребностями в
управлении и контроле организации или организаций, вовлеченных в проект,
характером самого проекта и его прикладной областью. Проект может быть разбит
на фазы в зависимости от функциональных или частичных целей, промежуточных
или поставляемых результатов, определенных контрольных событий внутри
общего содержания работ или доступности финансов. Фазы, как правило,
ограничены во времени, и имеют начальную и конечную или контрольную точку.
Жизненный цикл может документироваться в рамках методологии. Жизненный
цикл проекта может определяться или формироваться уникальными аспектами
организации, отрасли или используемой технологии. В то время как каждый
проект имеет определенное начало и окончание, конкретные результаты и
действия, имеющие место в этом промежутке, широко варьируются для каждого
проекта. Жизненный цикл обеспечивает базовую структуру для управления
проектом, независимо от включенных в него конкретных работ.
Проекты различаются по размеру и сложности. Все проекты могут иметь
следующую структуру жизненного цикла (см. рис. 1):
• начало проекта;
• организация и подготовка;
• выполнение работ проекта;
• завершение проекта.
Данная обобщенная структура жизненного цикла часто упоминается при
коммуникациях с вышестоящим руководством или другими сторонами, которые
менее осведомлены о деталях проекта. Не следует путать ее с группами процессов
управления проектом, потому что процессы в группе процессов состоят из
действий, которые могут выполняться и повторяться в каждой фазе проекта, а
также быть характерными для проекта как целого. Жизненный цикл проекта не
зависит от жизненного цикла продукта, произведенного или модифицированного в
результате исполнения проекта. Однако проект должен учитывать текущую фазу
жизненного цикла продукта. Это высокоуровневое представление обеспечивает
единую систему отсчета при сравнении проектов, даже если они разнородны по
своей природе.

8
 Рис. 1. Жизненный цикл проекта

Участники проекта

Главным ответственным и действующим лицом в проекте, через мозги

которого должны пройти все элементы проекта, является руководитель (менеджер)
проекта. Он назначается на первой фазе (рис. 1) одновременно с утверждением
Устава проекта.
Роль руководителя проекта – лица, ответственного за успех всего проекта –
намного шире роли функционального менеджера. Различие определяется тем, что
менеджер проекта:
• управляет временной деятельностью и командой временных участников-
специалистов из различных областей знаний;
• имеет заранее поставленную цель;
• ограничен сроками, бюджетом и техническими условиями (требованиями
к продукту и его качеству);
• управляет интеграцией всех элементов проекта, сам планирует работы и
использование ресурсов и сам претворяет их в жизнь;
• руководит созданием нового уникального продукта, свойства которого
могут уточняться по мере продвижения;
• не всегда разбирается в тонкостях реализации продукта (только на уровне
эксперта).
Для эффективного выполнения своей роли менеджер проекта должен
обладать знаниями и реальным опытом в следующих областях:
• проектный менеджмент – технологические знания и методы управления
проектами;
• общий менеджмент – знания и методы повседневного управления
компаниями;
• конкретные прикладные, предметные области.
Проектный менеджмент (управление проектами) – организационная
деятельность по оперативному управлению проектом в условиях ограничений.

9
Сегодня проектный менеджмент в России во многом опирается на стандарты ANSI
PMI PMBOK. Практическое владение стандартами и сводом знаний по управлению
проектами дает менеджеру проекта значительное преимущество перед другими
менеджерами, в т.ч. при трудоустройстве.
Общий менеджмент охватывает все аспекты управления повседневной
деятельностью предприятия. Примерный перечень знаний и навыков, входящих в
программы MBA (Master of Business Administration) – Мастер делового
администрирования, красноречиво демонстрирует емкость задач общего
менеджмента:
• планирование времени и делегирование полномочий;
• личная эффективность, проведение совещаний и личная мотивация;
• преодоление проблем и принятие решений;
• искусство ведения переговоров, эффективного общения, публичных
выступлений, переписки;
• финансовый анализ и бухгалтерский учет, оценка инвестиций;
• бюджетирование, бюджетный контроль;
• управление продажами и маркетинг;
• управление запасами и незавершенным производством;
• исследования и разработки, финансовый анализ проектов;
• финансирование, управление прибылью;
• управление персоналом, организационное управление;
• конкурентная рыночная стратегия, оценка бизнеса, покупка и продажа
компаний;
• стратегическое планирование бизнеса, разработка бизнес-планов;
• методики управления предприятием, в т.ч. методика BSC (Balanced Score
Card) – ССП (Система Сбалансированных Показателей);
• управление переменами, кризис-менеджмент и пр.
Знания и навыки общего менеджмента составляют хорошую основу для
овладения знаниями и навыками управления проектами. Следует отметить, что
проектный менеджмент в настоящее время в нашей стране еще не вылился в
самостоятельную профессию (вид профессиональной деятельности). Проектный
менеджмент развился и рассматривается как отдельная область знаний, навыков,
компетенций, стоящая рядом и на службе традиционных областей
профессиональной деятельности, таких как строительство и архитектура, ИТ-
индустрия, медицина, социология и т.д.
Кроме менеджера проекта, в проекте обычно участвуют множество других
лиц и организаций. К участникам проекта относятся физические и юридические
лица, вовлеченные в проект, а также лица, имеющие влияние (позитивное и
негативное) на проект и его результаты. Их в терминологии PMI PMBOK называют
стэйкхолдерами проекта.
Выявить всех стэйкхолдеров проекта, их интересы часто бывает трудно и
это является одной из первых задач менеджера проекта. К ключевым
стэйкхолдерам относятся:
• менеджер проекта – лицо, ответственное за конечные результаты проекта и
управляющее проектом;
• заказчик – физическое или юридическое лицо – будущий потребитель
продукта проекта;

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

Формы организационной структуры

Структура исполняющей организации накладывает ограничения на

процессы управления проектом и распределение ресурсов. Обозначим две
противоположные формы организационной структуры – функциональная (см. рис.
2) и проектная (см. рис. 3). На рисунках серым цветом выделен персонал,
участвующий в проектах. В функциональной структуре каждый такой работник
имеет одного руководителя и взаимодействует только с ним. Обычно
функциональное подразделение выполняет часть работ проекта или весь проект.
Функциональный руководитель решает все вопросы распределения ресурсов,
заданий, взаимодействия и привлечения специалистов из других функциональных
подразделений по иерархической лестнице. Роль менеджера проекта размыта. В
таких случаях роль координатора проекта возлагается на экспедитора проекта (или
диспетчер проекта). В тоже время экспедитор не может принимать
самостоятельные решения по проекту. Если же назначается менеджер проекта, то
он должен иметь определенные полномочия управления командой, максимально
четко установлена его ответственность.
В проектной структуре (см. рис. 3) весь персонал на проект собран в одном
месте (команда проекта). Созданы все условия для тесного взаимодействия
персонала разных специальностей. Менеджер проекта в значительной степени
независим и обладает максимальными полномочиями. Во многих случаях такое
образование организуется в виде проектного офиса.

11
 Координаци Глава
я проекта предприятия

Функциональный Функциональный Функциональный

руководитель руководитель руководитель

Персонал Персонал Персонал

Персонал Персонал Персонал

Персонал Персонал Персонал

Рис. 2. Функциональная организационная структура

Координаци Глава
я проекта предприятия

Руководитель Руководитель Руководитель

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

Персонал Персонал Персонал

Персонал Персонал Персонал

Персонал Персонал Персонал

Рис. 3. Проектная организационная структура

Функциональная структура больше ориентирована на выполнение

повторяющихся циклических работ. Достоинства функциональной структуры
становятся недостатками проектной и наоборот – приведены ниже:
Таблица 1. Сравнение организационных структур
Проектная организационная Функциональная организационная
структура структура
Эффективная интеграция, организация и Более сложный мониторинг и контроль
контроль проекта проекта. Акцент на функциональную
специализацию в ущерб интеграции и
другим работам проекта
Эффективная коммуникация и решение Неэффективные коммуникации по
конфликтов иерархической лестнице
Нацеленность на проект и лояльность Размытость приоритетов выполнения
проекту работ – функциональных обязанностей
и работу по проекту
Вероятность недостатка Высокий профессионализм, но акцент
профессионализма по различным на функциональную специализацию в

12
дисциплинам ущерб интеграции и другим работам
проекта
Вероятность избытка и менее Полная загруженность специалистов и
эффективного использования ресурсов более легкое управление ими
Временная работа Наличие постоянной работы по
завершению проекта
Одно ответственное лицо – менеджер Размытая ответственность за результаты
проекта проекта
Поэтому на практике часто применяют комбинацию указанных выше
структур – комбинированная организационная структура – либо другие сочетания
– слабую матричную структуру или сильную матричную структуру.
Комбинированная структура позволяет минимизировать недостатки описанных
структур – показана на рис. 4:
Глава
предприятия

Функциональный Функциональный Функциональный Начальник

руководителей
руководитель руководитель руководитель проектов

Персонал Персонал Персонал Руководитель проекта

Персонал Персонал Персонал Руководитель

проекта

Персонал Персонал Персонал Руководитель проекта

Координация проекта Координация проекта

Рис. 4. Комбинированная организационная структура.

В комбинированной структуре персонал на проект может иметь двойное

подчинение: в рамках организации подчинение функциональному руководителю
(менеджеру), а в рамках проекта – руководителю (менеджеру) проекта. Поэтому
должны быть четко разграничены полномочия между руководителем проектов и
функциональными руководителями. На рис. 4 Руководитель проекта 2 четко
планирует и согласовывает участие персонала в проекте с Функциональными
руководителями.
Если уровень организационной культуры организации не позволяет
разграничить полномочия менеджеров проекта и функциональных менеджеров, не
допускает нововведений для достижения успеха, то лучшим решением является
создание независимых проектных команд для выполнения критически важных
проектов.

13
 Стандарты управления проектами
Методология управления проектами отражается в стандартах управления
проектами. В настоящее время существуют следующие виды стандартов:
− международные – стандарты, получившие международное значение в
процессе своего развития или предназначенные для международного
использования;
− национальные – созданные для применения внутри одной страны или
получившие общенациональный статус в процессе своего развития;
− общественные – подготовленные и принятые сообществом специалистов;
− частные – комплексы знаний, пропагандируемые для свободного
использования частными лицами, компаниями или учреждениями;
− корпоративные – разработанные для применения внутри одной компании
или внутри группы родственных компаний.
Международные стандарты представляют собой полные системы,
включающие, помимо описания требований к управлению проектами, обучение,
тестирование, аудит, консалтинг и другие элементы. Всеохватывающих
международных стандартов управления проектами пока не существует, но
наиболее известны следующие стандарты.
1. Project Management Body of Knowledge (PMВОК) Американского
института управления проектами (Project Management Institute – PMI). Этот
стандарт обновляется приблизительно один раз в четыре года. Одна из наиболее
распространенных редакций датируется 2000 г., а самая актуальная, четвертая,
версия стандарта – The Guide to the PMBOK, 4th Edition – вышла в конце 2008 г.
Стандарт был первоначально принят Американским национальным институтом
стандартов (ANSI) в качестве национального стандарта в США, а в настоящее
время обрел мировое признание.
В основе стандарта лежит процессный подход к управлению проектами.
Общее множество возможных процессов представим в виде трехмерного
пространства, изображенного на рис. 1.2. По осям координат отложены те
измерения, которые упоминаются в рамочных стандартах. Могут быть предложены
и другие, например уровни управления, календарные периоды. Каждая точка этого
пространства представляет собой элементарный процесс управления. Например,
"планирование рисков на стадии внедрения системы".
Выбранные элементарные процессы образуют процедуры управления
проектами, которые могут быть построены по "осевому" принципу.
Стандарт содержит обобщенные принципы и подходы, используемые в
области проектного менеджмента, формализованные и структурированные таким
образом, чтобы их можно было использовать в большинстве проектов в
большинстве случаев. Детально описываются девять областей знаний, связанных с
управлением проектами:
• управление интеграцией проекта (Project Integration Management);
• управление содержанием проекта (Project Scope Management);
• управление сроками проекта (Project time Management);
• управление стоимостью проекта (Project Cost Management);
• управление качеством проекта (Project Quality Management);
• управление человеческими ресурсами проекта (Project Human Resource
Management);

14
 • управление взаимодействием в проекте (Project Communications
Management);
• управление рисками проекта (Project Risk Management);
• управление контрактами проекта (Project Procurement Management).
Каждая область знания включает в себя отдельные процессы, выполняемые
менеджером при реализации проекта на том или ином этапе. Процессно
ориентированный подход в управлении проектами, используемый в стандарте,
предполагает четкое, формальное описание входных документов и данных,
необходимых менеджеру для реализации процесса, методов и средств, которые он
может использовать при его реализации, и перечня выходных документов
процесса.
2. IPMA Competence Baseline (ICB) является международным
нормативным документом, определяющим систему международных требований к
компетентности менеджеров проектов. Этот стандарт разработан международной
ассоциацией IРМЛ (International Project Managers Association). На его основе
производится разработка национальных систем требований к компетентности
специалистов в странах, являющихся членами IPMA. Национальные системы
требований должны соответствовать ICB IPMA и официально утверждаться
(ратифицироваться) соответствующими уполномоченными органами IPMA. Для 32
стран – членов IPMA он является основой для разработки национальных сводов
знаний; в настоящее время утвержденные национальные своды знаний,
соответствующие ICB, имеют 16 стран.
ICB, в отличие от РМВОК, придерживается компетентностного,
деятельностного подхода, т.е. определяет области квалификации и компетентности
в управлении проектами, а также принципы оценки кандидата на получение
сертификата. ICB содержит 42 элемента (28 основных и 14 дополнительных),
определяющих области требований к знаниям, мастерству и профессиональному
опыту в менеджменте проектов.
ICB издан на английском, немецком и французском языках. Основой для
него послужило несколько национальных разработок: Body of' Knowledge of АРМ
(Великобритания); Beurteilungsstruktur, VZPM (Швейцария); PM-Kanon, PM-
ZERT/GPM (Германия); Criteres d'analyse, AFITEP (Франция).
Каждая входящая в IPMA национальная ассоциация ответственна за
разработку и утверждение собственных Национальных требований по
компетентности (National Competence Baseline – NCB) со ссылкой на ICB и в
соответствии с ним, а также с учетом национальных особенностей и культуры.
Национальные требования оцениваются специальным Комитетом IPMA на
соответствие ICB и основным критериям сертификации согласно стандарту EN
45013.
3. Стандарт ISO 10006. Обращение к вопросам эффективности
проектного управления объективно выявило острую потребность в разработке
системы управления качеством проекта. При этом особое значение наряду с
требованиями к качеству конечного продукта стало придаваться качеству
процессов проекта, отсутствие должного внимания к которым приводило к не
менее значимым отрицательным последствиям непосредственно для создаваемого
продукта.
Стандарт ISO 10006 является основополагающим документом из серии
стандартов рассматриваемого профиля, подготовленным техническим комитетом
ISO/TC 176 "Управление качеством и обеспечение качества" Всемирной федерации
национальных органов стандартизации (члены ISO).

15
 Основной упор сделан на принцип эффективности проектирования
оптимального процесса и контроля этого процесса, а не на контроле конечного
результата.
В этой серии стандартов процессы сгруппированы в две категории. К
первой категории отнесены процессы, связанные с обеспечением продукта проекта
(проектирование, производство, проверка). Описанию последних посвящен
стандарт ISO 9004–1. Вторая категория охватывает непосредственно процессы
управления проектом и представлена стандартом ISO 10006.
Данный стандарт охватывает десять групп процессов управления проектом.
Первая группа представляет процесс разработки стратегии, который
фокусирует проект на удовлетворение потребностей заказчика и определяет
направление хода работ. Вторая группа охватывает управление взаимосвязями
процессов. Остальные восемь групп – это процессы, связанные с проектным
заданием, сроками, затратами, ресурсами, кадрами, информационными потоками,
риском и материально-техническим снабжением (закупками). Более подробно
содержание данного стандарта отражено в приложении 1.
Международный стандарт ISO 10006 ориентирован на проекты самого
широкого спектра – малые и крупные, краткосрочные и долгосрочные, для
различных окружающих условий. Он безотносителен к типу проектируемого
продукта (включая технические средства, программное обеспечение,
полуфабрикаты, услуги или их сочетание). Это означает, что заложенные в нем
рамочные требования требуют последующей адаптации данного руководства к
конкретным условиям разработки и реализации отдельного проекта.
Стандарт заимствует ключевые определения из ИСО 8402, включая такие
термины, как проект, продукт проекта, план проекта, участник проекта, процесс,
оценка хода работ. Для всех процессов управления проектом (планирование,
организация, мониторинг и контроль) применяются процессы и задачи
менеджмента качества.
На основе международных стандартов разрабатываются и национальные
стандарты управления проектами. Отметим, что в России национальный стандарт
отсутствует. Однако Ассоциация по управлению проектами России (SOVNET)
разработала в 2001 г. на основе стандарта IPMA "Основы профессиональных
знаний. Национальные требования к компетентности специалистов". Перевод
стандарта ИСО 10006:2003 зарегистрирован, стандарт PMI распространяется в
России частным порядком и часто используется как основа для корпоративных
стандартов.
4. Стандарты зрелости управления проектами, тоже приобретающие
функции международных. В 2004 г. PMI был выпущен стандарт оценки уровня
зрелости организации по управлению проектами ОРМЗ (Organization Project
Management Maturity Model), содержащий методологию определения состояния
управления проектами в организации.
Термин «организационная зрелость по управлению проектами» описывает
способность организации отбирать проекты и управлять ими таким образом, чтобы
это максимально эффективно поддерживало достижение стратегических целей
компании.
ОРМЗ – это стандарт, представляющий собой всесторонний подход,
который помогает организациям оценивать и развивать свои возможности по
эффективной реализации проектов. Он является своего рода ключом к
организационной зрелости управления проектами и содержит три взаимосвязанных
элемента:

16
 • элемент «знание» (knowledge) представляет собой сотни лучших
практик по управлению проектами, характеризующих те или иные
уровни организационной зрелости управления проектами;
• элемент «оценка» (assessment) является инструментом, помогающим
организациям оценить текущую зрелость управления проектами и
определить области улучшения;
• если организация принимает решение развивать практики управления
проектами и переходить на новые более высокие уровни зрелости, то в
дело вступает элемент «улучшение» (improvement), который помогает
компаниям построить схему развития управления проектами таким
образом, чтобы обеспечить максимально эффективное достижение
своих стратегических целей.
Основное назначение ОРМЗ – быть стандартом для корпоративного
управления проектами и организационной зрелости по управлению проектами.
Основная отличительная черта ОРМЗ – это наличие уникальной базы
данных, которая содержит сотни лучших практик, описание тысяч ключевых
факторов успеха, результатов и другой информации, характеризующей развитие
зрелости управления проектами в организации.
ОРМЗ спроектирован таким образом, чтобы быть легким в понимании и
использовании, масштабируемым, гибким и настраиваемым на потребителя.
Основываясь на базе ОРМЗ как стандарта управления проектами, организация
может успешно перейти к такому состоянию, когда проекты будут достигать
поставленных целей в рамках бюджета, сроков и, что более важно, преследуя
корпоративные стратегические цели.
Специфика ИТ-проектов находит отражение также в специфической
методологии управления проектами:
• CMMi;
• Microsoft Solution Framework;
• Rational Unified Process.

17
 Процессы управления проектами
Разбивая жизненный цикл проекта на фазы с промежуточными
результатами (рис. 6), мы, тем самым, делаем его более управляемым, снижая
степень неопределенности от фазы к фазе. Более того, некоторая фаза может
вылиться в отдельный подпроект. Например, на фазе определения концепции
проекта могут потребоваться глубокие маркетинговые исследования рынка, что
можно выделить в отдельный проект маркетингового анализа со своими
собственными фазами.
Для того, чтобы провести проект по фазам к результату, необходимо
выполнить некоторые серии действий. Причем в каждом проекте выполняются
похожие процессы, не зависящие от предметной области. Такими общими для всех
проектов процессами со схожим содержанием являются инициация, планирование,
исполнение, управление и завершение проекта. Их взаимосвязь показана на рис. 6
– стрелками указаны направления потоков информации.
Как видно, за процессом инициации проекта следуют процессы
планирования и исполнения проекта. Процессы управления могут возвращаться к
процессам планирования, если не достигнут конечный результат,
удовлетворяющий целям и ограничениям проекта. Процессы завершения
закрывают проект.
Интегративный характер управления проектом требует, чтобы группа
процессов мониторинга и контроля взаимодействовала с другими группами
процессов, как показано на рис. 6. Процессы мониторинга и контроля
осуществляются в то же самое время, что и процессы, входящие в другие группы
процессов. Таким образом, на рис. 6 процесс мониторинга и контроля изображен
как «фоновая» группа процессов для других четырех групп.

Рис. 6. Взаимосвязь процессов управления

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

18
 Рис. 7. Взаимодействие групп процессов
Раскроем содержание и взаимосвязи каждой группы процессов. Группы
процессов 2-5 покажем схематически, как это принято в стандарте ANSI PMI
PMBOK – рис. 8-11.
Содержание процессов управления проектами
Инициация (1) – определение деловой потребности в проекте и его
авторизация, а именно:
• выбор проекта и определение деловых потребностей;
• сбор информации;
• определение целей проекта;
• определение ограничений и допущений;
• разработка описания продукта;
• определение обязанностей менеджера проекта;
• определение требований к человеческим ресурсам (кадры, квалификация);
• оценочное определение ресурсов;
• окончательная доработка Устава проекта и назначение менеджера проекта.
Процессы планирования (2) направлены на разработку планов по
составляющим проекта (расписание, стоимость, бюджет, качество, персонал,
риски, взаимодействие, контракты и пр.) и их интеграцию в целостный,
согласованный документ - План проекта. Как показано на рис.6, планирование —
это процесс, постоянно повторяющийся на протяжении всего жизненного цикла
проекта.
В планировании выделяют основные процессы, присутствующие всегда и
выполняющиеся в строго определенном порядке, и вспомогательные процессы,
зависящие от характера проекта. На рис.8 показан состав и связи процессов
планирования. Кратко поясним каждый процесс из рис. 8:
Планирование содержания – на основе Устава проекта и других входных
документов, составляется документ, описывающий: а) уточненное описание
продукта и результатов поставки; б) классификацию возможных изменений и
способ их обнаружения; в) порядок оценки и включения изменений в проект.
Определение содержания – разбиение, декомпозиция целей проекта на
меньшие и более управляемые части (подцели). Глубина декомпозиции должна
обеспечивать возможность назначения законченных групп работ и исполнителей

19
на эти части. Результатом определения содержания является ИСР (Иерархическая
Структура Работ), англ. WBS (Work Breakdown Structure).
Определение состава операций – подготовка перечня всех операций,
выполняемых по проекту, и уточнение ИСР. Операции, не включенные в
уточненную ИСР, считаются не включенными в проект и не подлежат
выполнению.
Планирование ресурсов – определение потребности (состава, количеств) в
людских и материальных ресурсах, необходимых для выполнения операций
проекта.
Определение взаимосвязей операций – выявление взаимосвязей и
взаимозависимостей операций, построение сетевых диаграмм работ проекта. Часть
операций связана между собой жесткой логикой, другие операции могут
выполняться в произвольной последовательности, т.е. связаны мягкой логикой.
Оценка длительности операций – установление количества единиц времени
на операции проекта, вычисление резервов времени и критического пути с
минимальной гибкостью по времени.
Оценка стоимости – количественная оценка возможных затрат на
вовлекаемые ресурсы, составление сметы и плана управления стоимостью.
Планирование управления рисками – установление подхода и мероприятий
(когда, как и что делать) при угрозе или наступлении нежелательных и
незапланированных событий и отклонений, с целью их предотвращения или
эффективного реагирования.
Составление расписания – анализ данных о последовательности и
длительности операций и требуемых ресурсах с целью создания расписания
исполнения проекта.
Разработка бюджета – определение сметной стоимости по отдельным
пакетам работ и проекту в целом.
Разработка плана проекта – интеграция данных предыдущих процессов и
составление согласованного Плана проекта – в виде одного документа или
собрания документов.
Вспомогательные процессы планирования устанавливают стандарты
качества, распределение ролей и ответственности, информационные потребности
участников и способы взаимодействия, выявляют риски и последствия их
воздействия на цели проекта и т.д.

20
 Основные процессы

Содержание Сроки Сроки

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

Вспомогательные процессы

Качество Человеческие Человеческие Контракты Контракты

Планирование ресурсы ресурсы Планирование Планирование
качества Орг. планир-е Назн. персонала контрактов заявок

Взаимодействие Риски Риски Риски Риски

Планирование Идентифика- Качественный Количествен- Планирование
взаимодействия ция рисков анализ ный анализ реагирования

Рис. 8. Основные и вспомогательные процессы

Процессы исполнения (3) показаны на рис. 9. Исполнение плана проекта –
есть непосредственное выполнение составляющих его операций. Вспомогательные
процессы обеспечивают гарантии качества, комплектацию/распределение работ и
информации, проведение совещаний о ходе работ и идентификацию изменений,
развитие навыков и знаний команды, сбор предложений поставщиков, управление
отношениями с поставщиками.

21
 Интеграция
Основные процессы Исполнение
плана проекта

Качество Человеческие
Вспомогательные процессы Подтвержде- ресурсы
ние качества Выбор команды

Контракты Контракты Взаимодействие

Получение Выбор Планирование
предложений поставщиков содержания

Контракты
Административ-
ное завершение

Рис. 9. Основные и вспомогательные процессы 2

Процессы мониторинга, управления, анализа (4) направлены на сбор и
распределение отчетности по состоянию проекта, контроль отклонений,
координацию изменений расписания и бюджета. Состав и связи процессов
исполнения показаны на рис. 10:
Основные процессы Взаимодействие Интеграция
Отчетность по Общее управление
исполнению изменениями

Вспомогательные процессы

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

Риски
Стоимость Качество Мониторинг и
Управление Управление управление
стоимостью качеством рисками

Рис. 10. Основные и вспомогательные процессы 3

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

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

Контракты Взаимодействие
Закрытие Административное
контрактов завершение

Рис. 11. Основные и вспомогательные процессы 4

Области знаний управления проектами.
Грамотное и эффективное исполнение перечисленных процессов требует от
менеджера проекта знаний в следующих областях:
1. Управление интеграцией проекта.
2. Управление содержанием проекта.
3. Управление сроками проекта.
4. Управление стоимостью проекта.
5. Управление качеством проекта.
6. Управление человеческими ресурсами проекта.
7. Управление коммуникациями проекта.
8. Управление рисками проекта.
9. Управление закупками проекта.
10. Управление заинтересованными лицами.
Содержание этих областей знаний будет раскрыто ниже. Карта связи
процессов управления проектами и областей знаний согласно PMBOK приведена в
таблице 7:
Таблица 7. Карта связи процессов управления проектами и областей знаний
Группы процессов управления проектом
Область
Инициация Планирование Исполнение Мониторинг и Закрытие
знаний
контроль
1. Разработка Разработка плана Руководство Мониторинг и Закрытие
Управление устава управления и управление контроль работ проекта или
интеграцией проекта. проектом. работами проекта. фазы.
проекта проекта. Интегрированный
контроль
изменений.
2. Планирование Подтверждение
Управление управления содержания.
содержимы содержанием. Контроль
м проекта Сбор требований. содержания.
Определение
содержания.
Создание ИСР.
3. Планирование Контроль
Управление управления расписания.
сроками расписанием.
проекта Определение
операций.

23
 Определение
последовательности
операций.
Оценка ресурсов
операций. Разработка
расписания.
4. Планирование Контроль
Управление управления стоимости.
стоимостью стоимостью. Оценка
проекта стоимости.
Определение
бюджета.
5. Планирование Обеспечение Контроль
Управление управления качества. качества.
качеством качеством.
проекта
6. Планирование Набор
Управление управления команды
человечески человеческими проекта.
ми ресурсами. Развитие
ресурсами команды
проекта проекта.
Управление
командой
проекта.
7. Планирование Управление Контроль
Управление управления коммуникац коммуникаций.
коммуникац коммуникациями. иями.
иями
проекта
8. Планирование Контроль рисков.
Управление управления рисками.
рисками Идентификация
проекта рисков.
Качественный анализ
рисков.
Количественный
анализ рисков.
Планирование
реагирования на
риски.
9. Планирование Проведение Контроль закупок. Закрытие
Управление управления закупок. закупок.
закупками закупками.
проекта
10. Определение Планирование Управление Контроль
Управление заинтересова управления вовлечением вовлечения
заинтересов нных сторон. заинтересованными заинтересова заинтересованных
анными сторонами. нных сторон. сторон.
лицами

24
 Модели управления проектами
Традиционная (каскадная) модель управления проектами

Каскадная модель (англ. waterfall model, иногда переводят как модель

«Водопад») — модель процесса разработки программного обеспечения, в которой
процесс разработки выглядит как поток, последовательно проходящий фазы
анализа требований, проектирования, реализации, тестирования, интеграции и
поддержки. В качестве источника названия часто указывают статью,
опубликованную У. У. Ройсом (W. W. Royce) в 1970 году; при том, что сам Ройс
использовал итеративную модель разработки.
В 1970 году в своей статье Ройс описал в виде концепции то, что сейчас
принято называть «каскадная модель», и обсуждал недостатки этой модели. Там же
он показал как эта модель может быть доработана до итеративной модели.
В оригинальной каскадной модели Ройса, следующие фазы шли в таком
порядке:
• Определение требований
• Проектирование
• Конструирование (также «реализация» либо «кодирование»)
• Воплощение
• Тестирование и отладка (также «верификация»)
• Инсталляция
• Поддержка
Переход от одной фазы к другой происходит только после полного и
успешного завершения предыдущей
Следуя каскадной модели, разработчик переходит от одной стадии к другой
строго последовательно. Сначала полностью завершается этап «определение
требований», в результате чего получается список требований к ПО. После того
как требования полностью определены, происходит переход к проектированию, в
ходе которого создаются документы, подробно описывающие для программистов
способ и план реализации указанных требований. После того как проектирование
полностью выполнено, программистами выполняется реализация полученного
проекта. На следующей стадии процесса происходит интеграция отдельных
компонентов, разрабатываемых различными командами программистов. После
того как реализация и интеграция завершены, производится тестирование и
отладка продукта; на этой стадии устраняются все недочёты, появившиеся на
предыдущих стадиях разработки. После этого программный продукт внедряется и
обеспечивается его поддержка — внесение новой функциональности и устранение
ошибок.
Тем самым, каскадная модель подразумевает, что переход от одной фазы
разработки к другой происходит только после полного и успешного завершения
предыдущей фазы, и что переходов назад либо вперёд или перекрытия фаз — не
происходит.
Тем не менее, существуют модифицированные каскадные модели (включая
модель самого Ройса), имеющие небольшие или даже значительные вариации
описанного процесс.

25
 Requirements

Design

Implementation

Verification

Meintenance

Рис. 12. Каскадная модель управления проектами

Критика
Методику «Каскадная модель» довольно часто критикуют за недостаточную
гибкость и объявление самоцелью формальное управление проектом в ущерб
срокам, стоимости и качеству. Тем не менее, при управлении большими проектами
формализация часто являлась очень большой ценностью, так как могла
кардинально снизить многие риски проекта и сделать его более прозрачным.
Поэтому даже в PMBOK 3-ей версии формально была закреплена только методика
«каскадной модели» и не были предложены альтернативные варианты, известные
как итеративное ведение проектов.
Начиная с PMBOK 4-й версии удалось достичь компромисса между
методологами, приверженными формальному и поступательному управлению
проектом, с методологами, делающими ставку на гибкие итеративные методы.
Таким образом, начиная с 2009 года, формально Институтом управления
проектами (PMI) предлагается как стандарт гибридный вариант методологии
управления проектами, сочетающий в себе как плюсы от методики «Водопада», так
и достижения итеративных методологов.

Модель управления проектами PRINCE2

PRojects IN Controlled Environments 2 (PRINCE2) представляет собой

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

История
Первоначально метод был разработан в 1989 году Central Computer and
Telecommunications Agency (CCTA) в Великобритании как стандарт для
руководства проектами в сфере информационных технологий. В настоящее время
широко используется и является «de facto» стандартом для руководства проектами
в Великобритании.

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

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

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

Процессы в концепции PRINCE2

Диаграмма показывает процессы метода PRINCE2. Стрелки показывают
направления информационных потоков.
Начало проекта. Как от начальной идеи проекта (отраженной в мандате на
проект) перейти к непосредственно реализации этих идей. Создается организация -
минимум назначаются руководитель проекта и Председатель Комитета проекта.
Формулируется краткое описание проекта (project brief) и подход к его реализации.
Детально планируется стадия запуска проекта.
Инициация проекта. Производится планирование проекта, включая план
качества. Создается экономическое обоснование проекта (Business Case) и
открывается журнал рисков, производится оценка рисков проекта. Планируются
вехи, точки контроля проекта.
Управление проектом. Здесь сосредоточены ворота принятия решений
Комитетом проекта (в том числе по досрочному завершению проекта) и
ситуационное управление по значительным проблемам и отклонениям.
Контроль стадий. Непосредственная работа руководителя проекта по
ежедневному управлению проектом - выдача и приёмка заданий, фиксация
сложностей и рисков, принятие решения об эскалации, отчетность перед
Комитетом.
Управление производством продукта. Меры, которые исполнители и
рабочие группы должны предпринять для определения объёмов работы, отчеты о
прогрессе и передаче выполненной работы.
Контроль границ стадий. Здесь происходит анализ исполнения плана
стадии, промежуточное планирование следующей стадии, запасных планов, обзор
рисков и бизнес-плана. Служит для перехода между стадиями.
Завершение проекта. Как закрыть проект, как управлять последующими
действиями, как разбирать обзоры преимуществ проекта.
Планирование. Как планировать, независимо от того, когда осуществляется
планирование.

27
 Стратегическое управление

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

Инициация Контроль Управление Завершение

проекта стадий границами проекта
стадий

Начало Управление
проекта поставкой
продукта

Планирование

Рис. 13. Диаграмма процессов метода PRINCE2

Организационная структура
• Менеджер проекта в традиционном понимании.
• Комитет проекта (project board), перед которым регулярно отчитывается
менеджер. Состоит из 3х человек — Заказчика, Главного пользователя и Главного
специалиста. Совет проекта ответственен за принятие стратегических решений.
Менеджер проекта обязан отслеживать возможные проблемы и предлагать совету
альтернативные решения. Совет решает — какой путь лучше.
• служба project assurance (аналог проектного офиса), цель которой
предоставлять независимое мнение о проекте с точки зрения тех же трех групп
людей — заказчиков, пользователей и специалистов (в предметной области).
Служба готовит три отчета —
• business report (отчет о финансовом состоянии проекта и выгодности
проекта в целом),
• user report (насколько хорошо выполняются требования пользователей),
• technical report (насколько хорош проект в технологическом плане — туда
ли он движется).
• Есть служба административной поддержки (администраторы проектов и т.
п.), ответственная за проведение встреч, доведение нужной информации до всех её
адресатов, сохранение проектной информации и т. п. В случае маленьких проектов
это делает менеджер проекта.

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

Гибкая методология разработки (англ. Agile software development, agile-

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

28
классу гибких методологий разработки, в частности экстремальное
программирование, DSDM, Scrum, FDD.
Применяется как эффективная практика организации труда небольших
групп (которые делают однородную творческую работу) в объединении с
управлением ими комбинированным (либеральным и демократическим) методом.
Большинство гибких методологий нацелены на минимизацию рисков путём
сведения разработки к серии коротких циклов, называемых итерациями, которые
обычно длятся две-три недели. Каждая итерация сама по себе выглядит как
программный проект в миниатюре и включает все задачи, необходимые для
выдачи мини-прироста по функциональности: планирование, анализ требований,
проектирование, программирование, тестирование и документирование. Хотя
отдельная итерация, как правило, недостаточна для выпуска новой версии
продукта, подразумевается, что гибкий программный проект готов к выпуску в
конце каждой итерации. По окончании каждой итерации команда выполняет
переоценку приоритетов разработки.
Agile-методы делают упор на непосредственное общение лицом к лицу.
Большинство agile-команд расположены в одном офисе, иногда называемом англ.
bullpen. Как минимум, она включает и «заказчиков» (англ. product owner —
заказчик или его полномочный представитель, определяющий требования к
продукту; эту роль может выполнять менеджер проекта, бизнес-аналитик или
клиент). Офис может также включать тестировщиков, дизайнеров интерфейса,
технических писателей и менеджеров.
Основной метрикой agile-методов является рабочий продукт. Отдавая
предпочтение непосредственному общению, agile-методы уменьшают объём
письменной документации по сравнению с другими методами. Это привело к
критике этих методов как недисциплинированных.

История
В феврале 2001 в штате Юта США был выпущен «Манифест гибкой
методологии разработки программного обеспечения». Он являлся альтернативой
управляемым документацией, «тяжеловесным» практикам разработки
программного обеспечения, таким как «метод водопада», являвшимся золотым
стандартом разработки в то время. Данный манифест был одобрен и подписан
представителями методологий: экстремального программирования, Crystal Clear,
DSDM, Feature driven development, Scrum, Adaptive software development, Pragmatic
Programming. Гибкая методология разработки использовалась многими
компаниями и до принятия манифеста, однако вхождение Agile-разработки в
массы произошло именно после этого события.

Принципы
Agile — семейство процессов разработки, а не единственный подход в
разработке программного обеспечения, и определяется Agile Manifesto. Agile не
включает практик, а определяет ценности и принципы, которыми руководствуются
успешные команды.
Agile Manifesto разработан и принят 11 – 13 февраля 2001 года на лыжном
курорте The Lodge at Snowbird в горах Юты. Agile Manifesto содержит 4 основные
идеи и 12 принципов. Примечательно, что Agile Manifesto не содержит
практических советов.
Основные идеи:
• люди и взаимодействие важнее процессов и инструментов;
• работающий продукт важнее исчерпывающей документации;

29
 • сотрудничество с заказчиком важнее согласования условий контракта;
• готовность к изменениям важнее следования первоначальному плану.
Принципы, которые разъясняет Agile Manifesto:
• удовлетворение клиента за счёт ранней и бесперебойной поставки ценного
программного обеспечения;
• приветствие изменений требований даже в конце разработки (это может
повысить конкурентоспособность полученного продукта);
• частая поставка рабочего программного обеспечения (каждый месяц или
неделю или ещё чаще);
• тесное, ежедневное общение заказчика с разработчиками на протяжении
всего проекта;
• проектом занимаются мотивированные личности, которые обеспечены
нужными условиями работы, поддержкой и доверием;
• рекомендуемый метод передачи информации — личный разговор (лицом к
лицу);
• работающее программное обеспечение — лучший измеритель прогресса;
• спонсоры, разработчики и пользователи должны иметь возможность
поддерживать постоянный темп на неопределённый срок;
• постоянное внимание улучшению технического мастерства и удобному
дизайну;
• простота — искусство не делать лишней работы;
• лучшие технические требования, дизайн и архитектура получаются у
самоорганизованной команды;
• постоянная адаптация к изменяющимся обстоятельствам.

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

Быстрая разработка приложений (Rapid Application Development)

RAD (от англ. rapid application development — быстрая разработка

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

30
создавать компьютерные программы. Практическое определение: RAD — это
жизненный цикл процесса проектирования, созданный для достижения более
высокой скорости разработки и качества ПО, чем это возможно при традиционном
подходе к проектированию. С конца XX века RAD получила широкое
распространение и одобрение. Концепцию RAD также часто связывают с
концепцией визуального программирования.

История
Концепция RAD стала ответом на неуклюжие методы разработки программ
1970-х и начала 1980-х годов, такие как «модель водопада» (англ. Waterfall model).
Эти методы предусматривали настолько медленный процесс создания программы,
что зачастую даже требования к программе успевали измениться до окончания
разработки. Основателем RAD считается сотрудник IBM Джеймс Мартин, который
в 1980-х годах сформулировал основные принципы RAD, основываясь на идеях
Барри Бойма и Скотта Шульца. А в 1991 году Мартин опубликовал известную
книгу, в которой детально изложил концепцию RAD и возможности её
применения. В настоящее время RAD становится общепринятой схемой для
создания средств разработки программных продуктов.

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

Применение
Технологию RAD целесообразно применять, когда четко определены
некоторые приоритетные направления разработки проекта.
1. Необходимо выполнение проекта в сжатые сроки. Быстрое выполнение
проекта позволяет создать систему, отвечающую требованиям сегодняшнего дня.
Если система проектируется долго, то весьма высока вероятность, что за это время
существенно изменятся фундаментальные положения, регламентирующие
деятельность организации, то есть, система морально устареет ещё до завершения
её проектирования.
2. Нечетко определены требования к ПО. В большинстве случаев заказчик
весьма приблизительно представляет себе работу будущего программного
продукта и не может четко сформулировать все требования к ПО. Требования
могут быть вообще не определены к началу проекта либо могут изменяться по
ходу его выполнения.

31
 3. Проект выполняется в условиях ограниченности бюджета. Разработка
ведётся небольшими RAD-группами в короткие сроки, что обеспечивает минимум
трудозатрат и позволяет вписаться в бюджетные ограничения.
4. Интерфейс пользователя (GUI) есть главный фактор. Нет смысла
заставлять пользователя рисовать картинки. RAD-технология дает возможность
продемонстрировать интерфейс в прототипе, причём достаточно скоро после
начала проекта.
5. Возможно разбиение проекта на функциональные компоненты. Если
предполагаемая система велика, необходимо, чтобы её можно было разбить на
мелкие части, каждая из которых обладает четкой функциональностью. Они могут
выпускаться последовательно или параллельно (в последнем случае привлекается
несколько RAD-групп).
6. Низкая вычислительная сложность ПО.
RAD-технология не является универсальной, то есть её применение
целесообразно не всегда. Например, в проектах, где требования к программному
продукту четко определены и не должны меняться, вовлечение заказчика в процесс
разработки не требуется и более эффективной может быть иерархическая
разработка (каскадный метод). То же касается проектов, ПО, сложность которых
определяется необходимостью реализации сложных алгоритмов, а роль и объём
пользовательского интерфейса невелик.

Основные принципы
Принципы RAD технологии направлены на обеспечение трёх основных её
преимуществ — высокой скорости разработки, низкой стоимости и высокого
качества. Достигнуть высокого качества программного продукта весьма непросто и
одна из главных причин возникающих трудностей заключается в том, что
разработчик и заказчик видят предмет разработки (ПО) по-разному.
• Инструментарий должен быть нацелен на минимизацию времени
разработки.
• Создание прототипа для уточнения требований заказчика.
• Цикличность разработки: каждая новая версия продукта основывается на
оценке результата работы предыдущей версии заказчиком.
• Минимизация времени разработки версии, за счёт переноса уже готовых
модулей и добавления функциональности в новую версию.
• Команда разработчиков должна тесно сотрудничать, каждый участник
должен быть готов выполнять несколько обязанностей.
• Управление проектом должно минимизировать длительность цикла
разработки.
Принципы RAD применяются не только при реализации, но и
распространяются на все этапы жизненного цикла, в частности на этап
обследования организации, построения требований, анализ и дизайн.

Высокая Высокая
скорость скорость
RAD

Высокое качество

Рис. 14. Принципы RAD

32
 Фазы разработки
Планирование – совокупность требований, полученных при системном
планировании и анализе процедуры разработки жизненного цикла (SDLC). На этом
этапе пользователи, менеджеры и IT-специалисты обсуждают задачи проекта, его
объём, системные требования, а также сложности, которые могут возникнуть при
разработке. Фаза завершается согласованием ключевых моментов с RAD-группой
и получением от руководителей проекта разрешения на продолжение.
Пользовательское проектирование – на протяжении данного этапа
пользователи, взаимодействуя с системными аналитиками, разрабатывают модели
и прототипы, которые включают в себя все необходимые системные функции. Для
перевода пользовательских прототипов в рабочие модели RAD-группа обычно
использует технику объединенной разработки приложений (JAD) и CASE-
инструменты. Пользовательское проектирование оказывается длительным
интерактивным процессом, который позволяет пользователям понять, изменить и в
конечном счёте выбрать рабочую модель, отвечающую их требованиям.
Конструирование – этап, в котором основная задача заключается в
разработке программ и приложений. Аналогична стадии «реализация» в SDLC. В
RAD, однако, пользователи продолжают принимать участие и по-прежнему могут
предлагать изменения или улучшения в виде разработанных ими докладов. В их
задачи входит программирование и разработка приложений, написание кода,
интеграция модулей и системное тестирование.
Переключение – включает в себя операции по конверсии данных,
тестирование, переход на новую систему и тренировку пользователей. По своим
задачам напоминает финальную стадию SDLC. Сравнивая с традиционными
методами разработки ПО, весь процесс оказывается сжатым по времени. Как
результат, новая система оказывается быстрее построенной, доставленной до
заказчика и установленной на рабочих местах.

Планирование

Пользовательское
Конструирование
проектирование

Переключение

Рис. 15. Модель быстрой разработки RAD

Преимущества
Технология быстрой разработки приложений (RAD) позволяет обеспечить:
• быстроту продвижения программного продукта на рынок;
• интерфейс, устраивающий пользователя;
• лёгкую адаптируемость проекта к изменяющимся требованиям;
• простоту развития функциональности системы.

33
 Документация проекта
Основные документы для управления проектами

Если вы поговорите с опытным руководителем проекта, то он наверняка

даст вам немало советов о том, что вам стоит, а чего не стоит делать для успешного
управления любым проектом. В основном все они будут о том, как управлять
людьми и их работой (а также и вашей работой), как предоставлять результаты
вовремя и согласно бюджету, при этом держать уровень риска на минимуме.
1. Устав проекта
К примеру, в начале вашего проекта вам понадобится создать
одностраничный документ - устав проекта. Данный документ должен обеспечить
то, что вы и ваш клиент понимают основные цели проекта. Если вы не знаете, куда
идете, как же вы поймете, что вы у цели?
Для получения данной информации вам стоит устроить встречу с вашим
клиентом и задать следующие 3 важных вопроса:
• Каковы цели вашего проекта?
• Что вы хотите производить или предоставлять?
• Каково бизнес-обоснование для выполнения данного проекта?
После встречи запишите все ответы на данные вопросы в вашем уставе
проекта и вышлите его клиенту для получения подтверждения.
Теперь вы выполнили наиболее важную часть вашего проекта, то есть
осознали и согласовали с вашим клиентом предназначение вашего проекта.
Если вы изучите время, потраченное на выполнение данного шага в вашем
проекте, то у вас получится примерно две встречи и 30 минут для записи всей
информации, то есть примерно два часа на маленький проект. Не так уж много.
2. План проекта
Теперь вы можете создать второй документ - план проекта. Он должен
включать в себя список всей работы, которая должна быть выполнена (другими
словами, масштаб проекта), кто ее будет выполнять, затраты и время на
выполнение данной работы и наконец простой обзор того, что может пойти не так,
или же исследование рисков.
3. Отчет о прогрессе
Обычно раз в неделю или в месяц вам необходимо предоставлять отчет об
успехе вашим клиентам. Они хотят знать, что было выполнено, как и сколько
времени и средств было потрачено. Они также хотят знать о том, необходима ли
вам их помощь в решении проблем. В ваши обязанности входит сбор данной
информации, чтобы вы могли создать данный документ.

Типы документации

Существует четыре основных типа документации на ПО:

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

34
 Архитектурная/проектная документация
Проектная документация обычно описывает продукт в общих чертах. Не
описывая того, как что-либо будет использоваться, она скорее отвечает на вопрос
«почему именно так». Например, в проектном документе программист может
описать обоснование того, почему структуры данных организованы именно таким
образом. Описываются причины, почему какой-либо класс сконструирован
определённым образом, выделяются паттерны, в некоторых случаях даже даются
идеи как можно будет выполнить улучшения в дальнейшем. Ничего из этого не
входит в техническую или пользовательскую документацию, но всё это
действительно важно для проекта.

Техническая документация
При создании программы, одного лишь кода, как правило, недостаточно.
Должен быть предоставлен некоторый текст, описывающий различные аспекты
того, что именно делает код. Такая документация часто включается
непосредственно в исходный код или предоставляется вместе с ним.
Подобная документация имеет сильно выраженный технический характер и
в основном используется для определения и описания API, структур данных и
алгоритмов.
Часто при составлении технической документации используются
автоматизированные средства — генераторы документации, такие как Doxygen,
javadoc, NDoc и другие. Они получают информацию из специальным образом
оформленных комментариев в исходном коде, и создают справочные руководства в
каком-либо формате, например, в виде текста или HTML.
Использование генераторов документации и документирующих
комментариев многими программистами признаётся удобным средством, по
различным причинам. В частности, при таком подходе документация является
частью исходного кода, и одни и те же инструменты могут использоваться для
сборки программы и одновременной сборки документации к ней. Это также
упрощает поддержку документации в актуальном состоянии.

Пользовательская документация
В отличие от технической документации, сфокусированной на коде и том,
как он работает, пользовательская документация описывает лишь то, как
использовать программу.
В случае если продуктом является программная библиотека,
пользовательская документация и документация на код становятся очень
близкими, почти эквивалентными понятиями. Но в общем случае, это не так.
Обычно, пользовательская документация представляет собой руководство
пользователя, которое описывает каждую функцию программы, а также шаги,
которые нужно выполнить для использования этой функции. Хорошая
пользовательская документация идёт ещё дальше и предоставляет инструкции о
том, что делать в случае возникновения проблем. Очень важно, чтобы
документация не вводила в заблуждение и была актуальной. Руководство должно
иметь чёткую структуру; очень полезно, если имеется сквозной предметный
указатель. Логическая связность и простота также имеют большое значение.
Существует три подхода к организации пользовательской документации.
Вводное руководство (англ. tutorial), наиболее полезное для новых пользователей,
последовательно проводит по ряду шагов, служащих для выполнения каких-либо
типичных задач. Тематический подход, при котором каждая глава руководства
посвящена какой-то отдельной теме, больше подходит для совершенствующихся

35
пользователей. В последнем, третьем подходе, команды или задачи организованы в
виде алфавитного справочника — часто это хорошо воспринимается
продвинутыми пользователями, хорошо знающими, что они ищут. Жалобы
пользователей обычно относятся к тому, что документация охватывает только один
из этих подходов, и поэтому хорошо подходит лишь для одного класса
пользователей.
Во многих случаях разработчики программного продукта ограничивают
набор пользовательской документации лишь встроенной системой помощи (англ.
online help), содержащей справочную информацию о командах или пунктах меню.
Работа по обучению новых пользователей и поддержке совершенствующихся
пользователей перекладывается на частных издателей, часто оказывающих
значительную помощь разработчикам.
Маркетинговая документация для многих приложений необходимо
располагать рядом с ними рекламные материалы, с тем, чтобы заинтересовать
людей, обратив их внимание на продукт. Такая форма документации имеет целью:
• подогреть интерес к продукту у потенциальных пользователей
• информировать их о том, что именно делает продукт, с тем, чтобы их
ожидания совпадали с тем, что они получат
• объяснить положение продукта по сравнению с конкурирующими
решениями
Одна из хороших маркетинговых практик — предоставление слогана —
простой запоминающейся фразы, иллюстрирующей то, что необходимо донести до
пользователя, а также характеризующей ощущение, которое создаёт продукт.
Часто бывает так, что коробка продукта и другие маркетинговые материалы
дают более ясную картину о возможностях и способах использования программы,
чем всё остальное.

36
 Управление рисками проекта
Риск – это неопределенное событие или условие, наступление которого
отрицательно или положительно сказывается на целях проекта, таких как
содержание, расписание, стоимость и качество. Причем влияние риска на проект
может быть, как отрицательным, так и положительным. На практике риски
рассматриваются как угроза проектам.
Риск может быть вызван одной или несколькими причинами и в случае
возникновения может оказать воздействие на один или несколько аспектов.
Причиной может быть существующее или потенциальное требование, допущение,
ограничение или условие, которое создает вероятность отрицательных или
положительных последствий. Например, причиной риска может быть
необходимость получения разрешительной документации в области охраны
окружающей среды или недостаток персонала, привлеченного для разработки
проекта. Риском в первом случае будет задержка с выдачей разрешения
контролирующим органом, а во втором, в случае благоприятной возможности,
дополнительный персонал, который может быть привлечен к разработке проекта,
может стать доступным для назначения на проект. Возникновение любого из этих
точно не известных заранее событий может повлиять на проект, его содержание,
стоимость, расписание, качество или исполнение. К условиям возникновения
рисков могут также относиться аспекты среды организации или проекта,
способствующие увеличению риска (например, незрелые практики управления
проектами, отсутствие общих систем управления, одновременное исполнение
нескольких проектов или зависимость от внешних участников проекта, которых
невозможно контролировать напрямую).
Причины рисков проекта находятся в неопределенности, которая
присутствует во всех проектах. Известные риски – это те риски, которые были
идентифицированы и проанализированы, что позволяет планировать реагирования
на них. Для тех известных рисков, которыми невозможно управлять проактивно,
следует выделить резерв на возможные потери. Неизвестными рисками
невозможно управлять проактивно, и, следовательно, для них можно выделить
управленческий резерв. Наступивший отрицательный риск проекта
рассматривается как проблема.
Отдельные риски проекта отличаются от общего риска проекта. Общий риск
проекта отражает эффект неопределенности по отношению ко всему проекту. Это
больше чем сумма отдельных рисков в проекте, так как сюда входят все источники
неопределенности проекта. Он отражает подверженность заинтересованных сторон
воздействию (как положительному, так и отрицательному) от вариаций в конечном
результате проекта.
Готовность организации брать на себя риск называется толерантностью к
риску – кто-то готов пойти на риск ради потенциальных выгод и шанса получить
больше, кто-то предпочтет избежать риски, понести необходимые для этого
затраты.
Базовые планы по содержанию, по срокам и по стоимости создаются с
учетом нейтрализации части рисков, предполагаемых с вероятностью 100%.
Поэтому базовые планы включают работы и затраты, которые предстоит
исполнить с вероятностью 100%.
Риски, не ожидаемые с вероятностью 100% и не предполагающие
нейтрализации, не отражаются в базовых планах. Наступление таких рисков,
приводит к последствиям, которые, как правило, выливается в дополнительные

37
работы и затраты (денег и времени), вероятность которых до этого считалась
меньше 100%. Такие риски покрываются за счет резервов.
Классификации рисков. Риски разделяют на известные и неизвестные.
Известные риски – это риски, которые выявлены, идентифицированы. Их можно
анализировать и планировать. Неизвестные – не идентифицированные риски не
поддаются управлению, но могут быть учтены при формировании резервов.
С точки зрения управляемости, риски подразделяют на внутренние и
внешние. Внутренние риски – это события, условия и процессы, которые команда
проекта может контролировать. Внешние риски – это события, условия и
процессы, которые выходят за пределы влияния команды проекта. Например,
изменения законодательства страны, изменения требований и приоритетов
спонсоров, изменения в исполняющей организации или у заказчика, рыночные
изменения, гражданские и природные катаклизмы и другие форс-мажорные
обстоятельства.
В зависимости от источников возникновения риски можно разделить на
следующие категории:
• технические риски – связаны с ошибками проектирования,
использования непроверенных технологий, нарушением промышленных
стандартов и пр.;
• управленческие риски – связаны с упущениями в планировании и
управлении проектом на уровне менеджера проекта. Например, неудачно
составленное расписание, плохо описанные роли и ответственности, подбор
недостаточно квалифицированного персонала, частые перестановки в команде,
ошибочные оценки и расчеты исполнения проекта и т.д.;
• организационные риски – возникают из-за недоработок на уровне топ-
менеджера проекта и связаны с несогласованностью между проектами, низкой
проектной дисциплиной и конфликтами из-за ресурсов, несовместимостью целей
проекта, сильным влиянием внешних факторов, недостаточным или
нестабильным финансированием и т.д.;
• деловые риски – связаны с изменениями бизнес-среды и бизнес-условий,
в которых инициировался проект. Например, ошибки в рыночных прогнозах,
низкая ответственность ведущих стэйкхолдеров, смена приоритетов и требований
спонсора или заказчика, другие риски заказчика и пр.;
• риски окружающей среды – природно-климатические, экологические и
другие риски;
• социальные и политические – забастовки, государственные перевороты и
пр.;
• риски злонамеренных действий и т.д.
Процесс обнаружения и идентификации рисков должен быть непрерывным
и постоянным в течение всех фаз жизненного цикла проекта. Ведь риски могут
изменяться, исчезать, могут быть обнаружены новые, ранее неизвестные риски. По
мере продвижения проекта к завершению и снижения общей неопределенности,
большая часть рисков должна быть идентифицирована, оценена, "побеждена".
Решая задачи по управлению рисками, менеджер проекта и команда
управления рисками проекта, периодически проходят и возвращаются к
следующим действиям:
• идентификация и оценка рисков (2 основных параметра оценки риска –
вероятность возникновения и последствия);
• минимизация вероятности наступления рисков, предотвращение или
подготовка к наступлению рисков;

38
 • реагирование на риски, минимизация отрицательных последствий рисков,
а если риск все же наступил, то нахождение способов преодоления и обеспечения
исполнения проекта по плану;
• фиксация отклонений от базовых планов по срокам, по стоимости и по
содержанию; если последствия серьезны и отклонения от планов неизбежны,
изменение и согласование планов с учетом последствий, выполнение
корректирующих действий.
Таким образом, управление рисками можно определить, как
систематический процесс идентификации, анализа и реагирования на проектные
риски.
Управление рисками требует дополнительных затрат. Эти затраты должны
соизмеряться с бюджетом всего проекта, быть необходимыми и достаточными,
чтобы обеспечить достижение целей и результатов проекта. Суммы затрат на
управление рисками в проектах могут колебаться в диапазоне 1%-15% всего
бюджета проекта.
Согласно таблице 1 усилия и действия по управлению рисками
предпринимаются на этапах планирования и управления. Эти действия зависят от
характера проекта и являются вспомогательными процессами. В стандарте ANSI
PMBOK выделяют 6 составляющих процессов управления рисками, причем первые
пять из них направлены на предварительную работу над рисками, на подготовку к
возникновению рисков:
1. Планирование управления рисками.
2. Идентификация рисков.
3. Качественный анализ рисков.
4. Количественный анализ рисков.
5. Планирование реагирования на риски.
6. Контроль рисков.

Планирование управления рисками

Планирование управления рисками — процесс, определяющий, каким

образом осуществлять управление рисками проекта. Ключевая выгода данного
процесса состоит в обеспечении того, чтобы степень, тип и наглядность
управления рисками были соразмерны рискам и важности проекта для
организации.
Процесс планирования управления рисками должен определить правила и
подходы к управлению рисками проекта, а именно:
• способы выявления и источники рисков;
• роли и ответственности, как на уровне руководства, так и на уровне членов
команды – может быть создана специальная команда управления рисками;
• бюджет управления рисками;
• периодичность идентификации, анализа и оценок рисков;
• критерии пороговых величин, после которых требуется вмешательство;
• формы отчетности и документирования.
Раскрытие перечисленных пунктов приводит к созданию на выходе
процесса плана управления рисками. На входе процесса необходимо иметь такие
источники как:
• план управления проектом;
• Устав проекта;
• реестр заинтересованных лиц;
39
 • факторы среды предприятия;
• активы процессов организации;
• другая необходимая и доступная информация из общего плана проекта.
Полезным приложением к Плану управления рисками может являться
построение иерархической структуры рисков (ИС Рисков). Вначале строится
шаблон ИС Рисков, а далее по аналогии с ИСР, источники (причины) рисков
детализируются до таких рисков, за которые можно назначить одно ответственное
лицо (см. Рис. 16).

Технические Внешние Организационные Управление

риски риски риски проектом

Правовые Зависимости
Требования проекта Оценка
нормы

Технологии Рынок Ресурсы Планирование

Сложность и Расстановка
взаимодействие
Заказчик приоритетов Контроль

Рис. 16. Пример ИС Рисков

Идентификация рисков

Идентификация рисков — процесс определения перечня рисков, которые

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

40
 На выходе необходимо получить:
• реестр рисков (пронумерованный список рисков с описанием).
На этом этапе риски должны быть четко разграничены и о рисках должны
быть точно записаны следующие данные:
• наименование и дата идентификации риска;
• описание риска.
По ходу выполнения проекта информация о рисках должна обновляться и
дополняться следующими данными:
• лицо, ответственное за управление риском;
• ссылка на ИСР, где могут возникнуть дополнительные работы;
• вероятность возникновения риска;
• последствия риска;
• стратегия реагирования на риск и т.д

Способы идентификации рисков

Идентификация рисков – это процесс, требующий интеллектуальных

усилий, абстрагирования, опыта и знаний.
Возможные инструменты и методы:
• обзор документации;
• методы сбора информации:
o мозговой штурм;
o метод Дельфи;
o проведение интервью;
o анализ первопричины;
• анализ с помощью контрольного списка;
• анализ допущений;
• методы диаграмм:
o диаграммы причинно-следственных связей;
o блок-схемы процесса и системы;
o диаграммы влияния;
• анализ SWOT;
• экспертная оценка.
Можно осуществлять структурированный анализ документации по
проекту, включая планы, допущения, архивы предыдущих проектов, соглашения и
другую информацию. Качество планов, а также согласованность планов с
требованиями и допущениями проекта могут служить показателями рисков в
проекте.
Целью мозгового штурма является создание всеобъемлющего списка
рисков проекта. Как правило, мозговой штурм проводит команда проекта, часто с
участием ряда экспертов из разных областей, не являющихся членами команды.
Генерация идей, относящихся к рискам проекта, происходит под руководством
модератора либо в традиционной свободной форме мозгового штурма, либо с
помощью структурированных методов проведения массовых интервью. За основу
может приниматься система категорий рисков, например иерархическая структура
рисков. Далее риски подлежат идентификации и категоризации по типам, а их
определения – уточнению.
Метод Дельфи – это способ достижения консенсуса между экспертами.
Данный метод предполагает, что эксперты по рискам проекта принимают в нем

41
участие анонимно. С помощью опросного листа модератор собирает идеи о
важных рисках проекта. Ответы резюмируются и затем возвращаются экспертам
для дальнейших комментариев. Консенсуса можно достичь за несколько циклов
данного процесса. Метод Дельфи помогает снизить необъективность в оценке
данных и устраняет избыточное влияние отдельных лиц на конечный результат.
Проведение интервью среди опытных участников проекта,
заинтересованных сторон или экспертов по предметной области способствует
идентификации рисков.
Анализ первопричины представляет собой особый метод определения
проблемы, выявления основополагающих причин, приведших к ней, и разработки
предупреждающих действий.
Контрольные списки идентификации рисков разрабатываются на основе
исторической информации и знаний, полученных в ходе исполнения предыдущих
аналогичных проектов или из других источников информации. В качестве
контрольного списка рисков можно также использовать самый нижний уровень
RBS. Хотя контрольный список может быть кратким и простым, невозможно
создать исчерпывающий список, и поэтому необходимо удостовериться, что
контрольный список не используется с целью избежать усилий по надлежащей
идентификации рисков. Команда должна также уделять внимание вопросам,
которые не нашли своего отражения в контрольном списке. Кроме того,
контрольный список необходимо время от времени сокращать для удаления или
архивирования связанных пунктов. При завершении проекта контрольный список
следует пересматривать, чтобы учесть в нем извлеченные уроки и улучшить его
для использования в будущих проектах.
Анализ допущений исследует обоснованность допущений применительно к
проекту. Данный анализ позволяет идентифицировать риски проекта,
возникающие вследствие неточности, нестабильности, противоречивости или
неполноты допущений.
Диаграммы причинно-следственных связей, также известные как диаграммы
Исикавы или диаграммы «рыбий скелет», используются для определения причин
возникновения рисков.
Блок-схемы процесса или системы – вид графического отображения,
демонстрирует порядок взаимодействия различных элементов системы между
собой и их причинно-следственные связи.
Диаграммы влияния – графическое представление ситуаций, отображающее
причинно-следственные связи, последовательности событий во времени и другие
отношения между переменными и результатами.
Анализа SWOT позволяет провести анализ проекта с точки зрения каждого
из аспектов: сильных и слабых сторон, благоприятных возможностей и угроз
(strengths, weaknesses, opportunities, and threats, SWOT), что делает идентификацию
рисков более полной, учитывая риски внутри проекта. При использовании данного
метода начинают с определения сильных и слабых сторон организации, уделяя
особое внимание либо проекту, либо организации, либо области бизнеса в целом.
Затем в процессе анализа SWOT идентифицируют любые благоприятные
возможности проекта, обусловленные сильными сторонами организации, а также
любые угрозы, появляющиеся вследствие ее слабых сторон. При помощи данного
анализа также исследуют, насколько сильные стороны организации компенсируют
угрозы, и идентифицируют благоприятные возможности, которые можно
использовать для преодоления слабых сторон.

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

Качественный анализ рисков

После того, как все риски идентифицированы, проводят качественный

анализ рисков с целью упорядочить риски по уровням их значимости.
Качественный анализ рисков – процесс расстановки приоритетов в
отношении рисков для их дальнейшего анализа или действий, выполняемый путем
оценки и сопоставления их воздействия и вероятности возникновения. Ключевая
выгода данного процесса состоит в том, что он позволяет руководителям проектов
уменьшать уровень неопределенности и фокусироваться на высокоприоритетных
рисках. Значимость риска определяется соотношением двух факторов –
вероятностью риска и последствиями риска для целей проекта. При качественном
анализе рисков эти два фактора описываются «оценочно», например, вероятность
низкая, средняя, высокая, последствия незначительные, умеренные, значительные
и т.д. Поэтому такое ранжирование рисков по уровням важности не требует
больших временных и денежных затрат, большого объема подробной информации.
На входе процесса качественного анализа рисков имеем:
• план управления рисками;
• базовый план по содержанию;
• реестр рисков;
• факторы среды предприятия;
• активы процессов организации.
На выходе:
• обновление документов проекта: ранжирование рисков по уровням
важности, перечень рисков, требующих дополнительно анализа, тренд результатов
при повторении качественного анализа, т.е. тенденции изменения рисков.
Основным методом качественного анализа рисков является использование
матрицы вероятности и воздействия. Она содержит две шкалы:
• шкалу вероятности, которая обычно имеет линейный диапазон значений
[0,1], [1,10] или [1,100];
• шкалу последствий, которая может быть, как линейной, так и нелинейной,
и отражает значимость последствий.
Каждый риск ориентировочно оценивается по вероятности и последствиям
и, согласно матрицы, получает определенный ранг (рейтинг) важности. В
зависимости от ранга, т.е. клетки матрицы, куда он попадает, риски подразделяют
на Низкие, Средние и Высокие. Пороги для такого деления рисков в каждой
организации устанавливаются самостоятельно в зависимости от толерантности к
рискам.
Кроме того, в некоторых организациях могут составляться отдельные
матрицы вероятности и последствий для отдельных целей проекта (стоимости,
сроков, содержания, качества) с разной шкалой и порогами.
Поскольку точная оценка вероятности и последствий на этом этапе может
быть затруднена, то можно предложить вариант матрицы вероятности и
последствий с упрощенной шкалой.

43
 Количественный анализ рисков

Количественный анализ рисков обычно проводится после качественного

анализа рисков. Количественный анализ рисков – процесс численного анализа
воздействия идентифицированных рисков на цели проекта в целом. Ключевая
выгода данного процесса состоит в том, что он предоставляет количественную
информацию о рисках в поддержку процесса принятия решений с целью
уменьшения неопределенности проекта.
Этот процесс заключается в следующем:
• количественной оценке вероятностей и последствий каждого риска,
сортировке рисков по приоритетам;
• определении рисков, требующих реагирования и сосредоточения усилий;
• количественном определении величины резервов по стоимости и срокам;
• определении наиболее реальных сценариев достижения целей по
стоимости, срокам и содержанию для проекта в целом.
На входе процесса количественного анализа рисков имеем как минимум
следующую информацию:
• план управления рисками;
• план управления стоимостью;
• план управления расписанием;
• реестр рисков;
• факторы среды предприятия;
• активы процессов организации.
На выходе:
• обновления документов проекта:
o перечень рисков по приоритетам, оценка последствий рисков;
o вероятностный анализ проекта;
o тренды результатов (при повторном анализе).
Количественный анализ рисков производится в отношении тех рисков,
которые в результате процесса качественного анализа рисков были
классифицированы как потенциально и существенным образом влияющие на
конкурирующие требования проекта. В процессе количественного анализа рисков
оценивается воздействие данных рисков на цели проекта. Он используется, в
основном, для оценки совместного воздействия всех рисков на проект. Когда риски
попадают в количественный анализ, данный процесс может использоваться для
присвоения числового рейтинга приоритетности этим рискам по отдельности.
В некоторых случаях выполнение процесса количественного анализа рисков
невозможно в связи с отсутствием необходимых данных для разработки
соответствующих моделей. Руководитель проекта должен пользоваться экспертной
оценкой для определения необходимости и целесообразности количественного
анализа рисков. Выбор метода (методов) анализа в каждом конкретном проекте
определяется наличием времени и бюджетом, а также потребностью в
качественном и количественном описании рисков и их воздействий. Чтобы
определить, был ли риск проекта успешно снижен, количественный анализ рисков
следует, при необходимости, повторно провести в рамках процесса контроля
рисков. Анализ тенденций может указать на необходимость уделить больше или
меньше внимания соответствующим действиям по управлению рисками.

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

Microsoft Project

Microsoft Project является на сегодняшний день самой распространенной в

мире системой УП. Во многих западных компаниях MS Project стал привычной
добавкой к Microsoft Office даже для рядовых сотрудников, которые используют
его для планирования графиков несложных комплексов работ.
Отличительной особенностью пакета является его простота. Разработчики
MS Project не стремятся вложить в пакет более сложные алгоритмы календарного
или ресурсного планирования. В то же время значительное внимание уделяется
использованию современных стандартов, позволяющих эффективно интегрировать
пакет с другими приложениями.
Поддержка Microsoft Mail и Microsoft Exchange позволяет облегчить и
систематизировать групповую работу с проектами. Настройка сообщений для
команды проекта включает возможность определения состава проектных данных
пересылаемых участникам проекта по электронной почте и установку ограничений
на коррекцию пересылаемой информации получателями. Хранение проектов в
папках Exchange обеспечивает дополнительные средства разграничения доступа к
файлам проектов.
Для быстрого включения в работу начинающего пользователя MS Project
предоставляет, кроме обычных средств помощи, также возможность пошаговой
разработки проекта (Create Your First Project и Cue Cards) и интеллектуальной
подсказки (Answer Wizard). К сожалению, Project пока не руссифицирован, так что
для эффективного использования этих средств необходимо знание английского
языка, включая специфическую терминологию управления проектами.
Среди достоинств пакета также следует отметить достаточно удобные и
гибкие средства создания отчетов. Основные типы отчетов могут быть выбраны из
заготовок (Report Gallery). Возможность одновременно иметь до шести планов для
каждого проекта позволяет повысить эффективность анализа. В то же время MS
Project предоставляет минимальный набор средств для планирования и управления
ресурсами. Дополнительные возможности Project также включают импорт/экспорт
данных в форматах ASCII, CSV, Excel, Lotus 1-2-3, dBASE и FoxPro, средства
записи макрокоманд, Visual Basic.
MS Project может быть рекомендован для планирования несложных
проектов пользователями непрофессионалами и новичками.

45
 Битрикс24

Система управления задачами Битрикс24 позволяет работать с задачами в

Экстранете совместно с другими участниками проекта.
Планирование проекта и управление задачами помогают руководителям
контролировать своевременное исполнение задач в подразделении, а подчиненным
– не допускать нарушений. В рамках проекта учитываются затраты времени и
других ресурсов на выполнение задач.
Задачи можно представить в виде планировщика проектов – диаграммы
Ганта – классической ленточной диаграммы, которая наглядно отображает
временные рамки задач, причем, в той последовательности, в которой они должны
проходить на протяжении проекта.
Взглянув на диаграмму, сразу видно сколько всего задач по проекту,
сколько из них завершено и сколько находится в работе, какие задачи просрочены,
а какие – вообще без срока.
Большой проект легко читаемый: на диаграмме Ганта видно визуальное
представление продолжительности и крайних сроков по всем задачам.
Диаграмма Ганта поддерживает связи между задачами. Теперь если проект
сместился, достаточно указать новую дату его начала – все остальные задачи в
проекте переместятся автоматически. При изменении даты начала или окончания
задачи, меняется дата исполнения связанной задачи.
Диаграмма Ганта в Битрикс24 поддерживает 4 типа связей:
• задача начинается после завершения предыдущей (Финиш > Старт);
• одновременное начало задач (Старт > Старт);
• одновременный «дедлайн» по задачам (Финиш > Финиш);
• задача начинается после завершения предыдущей (Старт > Финиш).

Primavera Project Planner (Primavera Systems, Inc.)

Центральный программный продукт семейства Primavera, Primavera Project

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

46
 При описании ресурса могут быть указаны нормальное и максимальное
количество наличия данного ресурса, а также его цена по шести временным
интервалам. Ресурс может быть помечен как управляющий (объем назначения
управляющего ресурса на задачу будет влиять на длительность ее выполнения).
Например, определив, что рабочие - это управляющий ресурс, а бригадир - нет,
можно добиться сокращения сроков выполнения задачи прокладка траншеи за счет
назначения большего количества рабочих. Увеличение же количества бригадиров
не повлияет на длительность работы.
При планировании загрузки ресурсов может возникнуть необходимость в
описании нелинейного профиля потребления ресурса отдельной задачей. Project
Planner дает возможность описать различные кривые распределения ресурса,
предлагая девять стандартных кривых и возможность определить собственный
профиль потребления, разбив временную фазу задачи на 10 периодов.
Средства автоматического перепланирования задач с учетом ограничений
на ресурсы приобретают особую важность для крупных проектов, когда менеджер
не в состоянии самостоятельно проанализировать причины нехватки ресурсов и
найти решение для каждой конкретной работы. Project Planner позволяет выбрать
режим перерасчета расписания и подобрать критерий перепланирования работ,
обеспечивающий получение более короткого расписания. Среди режимов
перерасчета можно выделить выравнивание вперед (определение возможной даты
окончания проекта при заданной начальной дате), выравнивание назад
(определение самой поздней допустимой даты начала проекта), сглаживание
перегрузок ресурсов в рамках во временных резервов работ или в рамках заданного
интервала.
Кроме того, имеется возможность перераспределять назначение работ
между сгруппированными ресурсами.
К недостаткам средств ресурсного планирования можно отнести
ограничение на количество календарей. Кроме главного календаря проекта, P3
позволяет описать лишь 30 дополнительных календарей, в то время как
возможность задания индивидуальных графиков работы для каждого ресурса уже
стало нормой в современных пакетах УП). Другое ограничение связано с
количеством ресурсов (не более 120), контролируемых при выравнивании профиля
загрузки ограниченных ресурсов.
Средства поддержки многопроектной среды управления в Project Planner
включают возможность определения иерархии и права доступа к мастер-проекту и
подпроектам. Менеджер-координатор проекта имеет право редактировать мастер-
проект и все подпроекты. Менеджер подпроекта имеет право добавлять ресурсы в
словарь ресурсов, но не удалять их и не изменять их цены. Если разрешение
ресурсных конфликтов в рамках подпроекта требует данные другого подпроекта,
менеджер может это сделать только при наделении его дополнительными
полномочиями со стороны менеджера-координатора проекта. Однако, ресурсное
планирование по всему проекту в целом может осуществляться только
менеджером-координатором. Только он может определить связи между
подпроектами. По сравнению со многими другими программными продуктами,
которые также дают возможность многопроектного управления, отличительной
особенностью P3 является подробное описание принципов многопроектного
управления в документации, где они рассматриваются с двух точек зрения:
менеджера-координатора проекта и менеджера подпроекта (хотя считается, что
тема мультипроектного управления требует дополнительного учебника).

47
 SureTrak

Кроме Project Planner, компанией Primavera Systems поставляется

облегченная система для УП – SureTrak. Этот программный продукт ориентирован
на небольшие проекты, подпроекты, работу конкретных исполнителей с
фрагментами проектов. SureTrak имеет те же средства, что и P3 в плане
организации проекта по кодам и фильтрации информации, установки ограничений
и расчета расписания, но в то же время существует ряд ограничений и
дополнительных возможностей.
Из ограничений следует отметить отсутствие средств многопроектного
управления и фрагментации проектов, меньшую размерность проектов, более
скромные средства создания отчетов. Однако в SureTrak появились календари
ресурсов и, как следствие возможность расчета длительностей работ с учетом
согласования календарей исполнителей (ожидается, что календари ресурсов
появятся и в следующей версии Project Planner). Кроме того, у ресурсов появилась
дополнительная категория – доход. SureTrak отличается от всех остальных
продуктов Primavera тем, что он полностью русифицирован и поставляется вместе
с руководством для пользователя на русском языке.
SureTrak осуществляет импорт/экспорт файлов в форматах Project Planner и
MS Project. Таким образом, работая совместно, Project Planner и SureTrak
предлагают масштабируемый подход к управлению проектами различного размера
и сложности. Кроме вышеназванных продуктов из семейства Primavera интерес
может представлять система анализа рисков проекта Monte Carlo for Primavera.

Artemis Views (Artemis International)

Другая известная в мире управления проектами торговая марка - Artemis.

Традиционно ПО семейства Artemis использовалось для управления крупными
инженерными проектами. На сегодняшний день корпорация Artemis International
распространяет под этой торговой маркой серию программ под общим названием
ArtemisViews.
Семейство ArtemisViews состоит из набора модулей, автоматизирующих
различные аспекты управления проектами: ProjectView, ResourceView, TrackView,
CostView. Все модули совместимы по данным, работают в архитектуре
клиент/сервер, поддерживают ODBC стандарт и легко интегрируются с
популярными СУБД Oracle, SQLBase, SQLServer, Sybase.
Каждый модуль может работать как независимо, так и в комбинации с
другим ПО. Цена на это, традиционно недешевое ПО, рассчитывается исходя из
заказываемой конфигурации.
ProjectView позволяет реализовать мультипроектную,
многопользовательскую систему планирования и контроля проектов в
организации. ProjectView позволяет разделять проектные данные (календари,
кодификаторы, списки ресурсов) между пользователями или пользовательскими
группами, обеспечивает средства безопасности при одновременной работе
пользователей с проектом. Система позволяет получать значительное количество
различных отчетов с помощью собственных средств или с использованием
специализированного ПО (например, Quest). В комбинации со средствами
управления ресурсами ResourceView позволяет построить интегрированный
подход к управлению проектными работами и текущими операциями.

48
 ResourceView – специализированная система для планирования и контроля
использования ресурсов как в проектной или матричной среде управления, так и
для текущих работ. В системе реализованы средства поддержки согласования
руководителями распределения ресурсов между работами. Графическая панель
управления ресурсами позволяет менеджерам планировать, контролировать и
оптимизировать их загрузку за счет перераспределения очереди работ в
соответствии с наличием ресурсов.
TrackView предоставляет средства ведения фактической информации по
выполненным объемам работ, контроля за состоянием выполнения и стоимостью
текущих работ (проектных и вне-проектных). Система позволяет интегрировать
данные для различных уровней управления в организации от рядовых
исполнителей, ведущих информацию по своим задачам, до высшего руководства,
которое может получить укрупненые данные по фактическим затратам и объемам
работ.
CostView обеспечивает поддержку центрального репозитария для
информации по всем затратам и доходам проектов. Пакет позволяет анализировать
экономическую эффективность контрактов, строить таблицы денежных потоков,
предсказывать затраты и рассчитывать показатели внутренней нормы
рентабельности проектов. Безусловно ArtemisViews позволяет создать мощное
интегрированное решение, однако, затраты, связанные с приобретением и
внедрением данного ПО, существенно ограничивают круг потенциальных
пользователей.

Spider Project

Обзор систем УП, доступных на Российском рынке, был бы неполон без

упоминания российской разработки – Spider Project. По информации, полученной
от специалистов, разрабатывающих и поддерживающих пакет (Spider Technologies
Group), система была инсталлирована для управления несколькими десятками
крупных проектов.
Данный пакет имеет несколько отличительных особенностей, позволяющих
ему конкурировать с западными системами на крупных, промышленных проектах.
Во-первых, это мощные алгоритмы планирования использования
ограниченных ресурсов. Тестирование известных пакетов УП (Artemis Views не
тестировался) показало преимущество алгоритмов Spider Project по качеству
составляемых планов выполнения работ при ограниченности имеющихся ресурсов.
Для 32 из 100 проектов, участвовавших в тестировании, Spider Project составил
более короткие расписания работ, а для остальных 68 его расписания не уступали
лучшим из расписаний, составленных западными пакетами.
В пакете реализована возможность использования при составлении
расписания работ взаимозаменяемых ресурсов (пулы ресурсов), которая также
позволяет получить более короткие расписания. Использование ресурсных пулов
избавляет менеджера от необходимости жестко назначать исполнителей на работы
проекта. Ему достаточно указать общее количество необходимых для производства
работ ресурсов и из каких ресурсов это количество выбирать. Это позволяет и
сократить непроизводительные простои ресурсов и облегчить работу проектного
менеджера, избавляя его от необходимости производить утомительные на больших
проектах оценки «что, если».
Еще одной особенностью пакета является возможность использование
нормативно-справочной информации – о производительностях ресурсов на тех или

49
иных видах работ, расходе материалов, стоимостях работ и ресурсов. Spider Project
позволяет неограниченно наращивать число учитываемых в проектах показателей,
создавать и использовать в расчетах любые дополнительные табличные документы
и базы данных, вводить любые формулы расчета. Возможность настройки системы
позволяет пользователям получать от пакета не только расписание работ, графики
загрузки ресурсов и стоимостные характеристики проекта, но и технологические
характеристики составленных расписаний. Так, например, в горнодобывающей
промышленности пользователи Spider Project получили возможность планировать
не только порядок выемки объемов руды, но и учитывать объемы отдельных
компонентов, содержащихся в руде.
Превосходя многие западные пакеты по мощности и гибкости отдельных
функций, Spider Project, в целом, уступает в области программной реализации
(использование стандартов обмена данными, пользовательский интерфейс и т.д.).
На сегодняшний день не завершен полный перевод системы в среду Windows.
Пакет имеет Windows надстройку, ввод и отображение данных в диаграммах Гантт
и PERT, однако программы расчета по-прежнему функционируют в DOS. Для
создания пользовательских табличных отчетов по проекту необходимо
использовать программу электронных таблиц AUTOPLAN (DOS версия), которая
входит в поставку Spider Project.

50
 Лабораторная работа
Использование MS Project для управления проектами

Цель работы – создание проекта, внесение базовой информации о проекте

и создание расписания проекта; расстановка временных связей между задачами;
добавление в проект ресурсов; проверка и корректировка проекта с учетом
ограничений; контроль над ходом выполнения проекта и его оптимизация в
процессе выполнения; использование отчетов MS Project для анализа проекта.

Порядок выполнения работы

1. Создание нового проекта.

2. Заполнение сведений о проекте.
3. Изменение базовых календарей проекта.
4. В ключение в проект дополнительной документации.
5. В нести задачи проекта в табличную часть диаграммы Г анта.
6. У порядочить задачи проекта в соответствии с логикой проекта.
7. В вести кода структурной декомпозиции работ.
8. У становить длительность всех дочерних задач.
9. У казать зависимости задач.
10. Настроить ограничения задач.
11. Настроить напоминания о крайних сроках.
12. Добавить вехи.
13. Настроить календари задач.
14. Добавить в проект трудовые ресурсы.
15. Добавить в проект материальные ресурсы.
16. Настроить календари рабочего времени ресурса.
17. Назначить ресурсы задачам.
18. Профилирование загрузки ресурса.
19. Обзор планируемых затрат проекта.
20. Работа с критическими путями и критическими задачами.
21. Балансировка загрузки ресурсов.
22. Работа с базовыми планами.
23. Отслеживание выполнения задач.
24. К онтроль и оптимизация календарного плана, затрат и загрузки ресурсов.
25. Планирование отчетности проекта.
26. Публикация сведений о проекте в Интернет.
27. А нализ сведений о проекте в MS E xcel.
28. А нализ хода работ и затрат методом освоенного объема.
29. Планирование структуры сложных проектов.
30. Объединение проектов.
31. Пул ресурсов.

Теоретический материал

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

51
обычно входит список заранее организованных и размещенных определенным
образом задач, а также информация о ресурсах, пользовательские представления,
календари, отчеты, макросы и т.д. Любая информация, предлагаемая шаблоном,
может быть изменена в соответствии с требованиями конкретного проекта. В
качестве шаблона также может быть использован созданный ранее проект.
Рабочее пространство программы называется видом или представлением. По
умолчанию после создания проекта активен вид «Диаграмма Ганта». Данная
диаграмма служит для отображения последовательности задач проекта, как в
текстовом, так и в графическом виде.
После создания проекта необходимо настроить его основные параметры. Для
этого удобно использовать мастер «Новый проект». Для этого следует нажать
кнопку «Задачи» на панели «Консультанта» и выбрать ссылку «Определение
проекта». Ответив на вопросы о дате начала проекта и совместной работе над
проектом и сохранив результат, следует выбрать ссылку «Определение рабочего
времени проекта» для запуска мастера «Рабочее время проекта». Т аким образом,
можно настроить календарь проекта.
Следующим решением, которое необходимо принять на стадии создания,
является выбор исходной даты проекта. План проекта может быть составлен от
даты начала или завершения проекта. Для настройки планирования от начальной
даты следует выбрать в меню «Проект» пункт «Сведения о проекте». В
появившемся окне следует выбрать планирование «От даты начала проекта» и
поставить «Дату начала». Дата окончания будет рассчитана далее автоматически. В
случае планирования от конечной даты следует выбрать «От даты окончания
проекта» и поставить «Дату окончания». В этом случае автоматически будет
рассчитываться дата начала.
Т акже в этом окне можно выбрать календарь для проекта. В состав пакета MS
Project входит три базовых календаря – стандартный, ночная смена и 24 часа. В
стандартном календаре рабочий день начинается с 8:00 и заканчивается в 17:00 с
обеденным перерывом с 12:00 до 13:00. Рабочая неделя начинается с понедельника
и заканчивается в пятницу. Это календарь, применяемый по умолчанию. В
календаре ночной смены рабочий день начинается с 23:00 и заканчивается в 8:00 с
часовым перерывом с 03:00 до 04:00.
В календаре «24 часа» рабочее время продолжается круглые сутки без
выходных и обеденных перерывов.
Базовые календари можно редактировать. Для этого в меню «Сервис»
необходимо выбрать пункт «Изменение рабочего времени». В появившемся окне
необходимо выбрать базовое расписание, которое необходимо отредактировать.
Для изменения рабочего времени одного дня необходимо выбрать этот день в
календаре. Далее, если необходимо сделать этот день выходным, следует выбрать
параметр нерабочее время, если же необходимость только изменить временные
рамки рабочего дня, то выбираем параметр нестандартное рабочее время и в полях
ниже вводим время начала и завершения рабочего дня.
Можно также создать новое базовое расписание. Для этого в окне
«Изменение рабочего времени» следует нажать кнопку «Создать». В появившемся
окне следует выбрать создание нового календаря на основе стандартного или
создание копии любого другого календаря. Значения рабочего времени для вновь
созданного календаря могут также быть отредактированы через окно «Изменение
рабочего времени».
Создаваемый проект может быть использован в качестве хранилища
проектной документации, например обзора проекта, результатов проведенных

52
анализов или спецификации создаваемого продукта. Для присоединения такой
документации целесообразно использовать т.н. суммарную задачу проекта,
содержащую итоговую информацию о датах и стоимости проекта. Для
отображения суммарной задачи на диаграмме Г анта необходимо в меню «Сервис»
выбрать пункт «Параметры» и перейти на вкладку «Вид». На данной вкладке
необходимо выбрать параметр «Показать суммарную задачу проекта» под
заголовком «Параметры структуры для проекта». С уммарная задача появится в
нулевом ряду диаграммы Г анта.
Проектная документация может, как включаться в файл проекта, так и быть
доступной через гиперссылки. Для включения документов в файл проекта
необходимо выбрать суммарную задачу проекта и нажать кнопку «Сведения о
задаче», расположенную на стандартной панели задач. В открывшемся окне
следует выбрать вкладку «Заметки». На вкладке следует нажать кнопку «Вставить
объект». В открывшемся окне необходимо выбрать опцию «Создать из файла».
После этого следует указать путь к файлу документа, который предполагается
включить в проект.
После закрытия окна сведений о суммарной задаче в диаграмме Г анта
появится индикатор примечаний.
Для создания гиперссылки к документу необходимо нажать кнопку
«Г иперссылка» на панели задач. В поле «Т екст» открывшегося диалогового окна
«Добавление гиперссылки» следует ввести название связываемого документа,
затем выберите документ в списке. В поле индикаторов диаграммы Г анта появится
индикатор гиперссылок.
Для создания расписания работ в программе MS Project необходимо внести
задачи в диаграмму Г анта в соответствии с их иерархией. Для перехода в режим
диаграммы Г анта необходимо выбрать из меню «Вид» пункт «Диаграмма Ганта».
С уществуют несколько методик внесения задач в диаграмму Г анта:
• произвольный ввод – задачи вносятся без соблюдения последовательности
или группировки задач. Необходимые изменения вносятся позже;
• последовательный ввод – задачи вводятся последовательно, от начала до
завершения проекта (или наоборот);
• обозначение фаз – вносятся только главные задачи. Далее следует их
декомпозиция;
• обозначение вех – внесение ключевых задач. Далее в расписание вносятся
задачи, необходимые для выполнения ранее внесенных задач.
Для добавления задачи в столбец «Название задачи» вводится название
задачи. В дальнейшем название и другие свойства задачи можно редактировать
двойным нажатием на любом столбце табличной части диаграммы Г анта.
Данные о задачах также могут быть импортированы из программного
продукта MS E xcel. Для этого необходимо, чтобы поля таблиц MS E xcel
полностью соответствовали полям диаграммы Г анта. Поэтому сначала создаем на
основе Шаблона импорта списка задач Microsoft Project новую таблицу MS E xcel.
После заполнения и сохранения файла таблицы необходимо открыть этот
файл в MS Project. Для этого, нажав в меню «Файл» пункт «Открыть», в
диалоговом окне открытия файла указываем тип файла «Книги Microsoft Excel» и
выбираем файл сохраненной таблицы из списка.
Некоторые задачи повторяются регулярно, например, еженедельно. Для задач
такого типа нет необходимости вводить несколько раз одну и ту же информацию,
достаточно указать, что задача является повторяющейся. В таком случае
необходимо в диаграмме Г анта выбрать задачу, после которой необходимо

53
вставить повторяющуюся задачу. Затем в меню «Вставка» выбрать пункт
«Повторяющаяся задача». В открывшемся окне необходимо заполнить название
задачи, указать частоту и диапазон повторений. Т акже в случае необходимости
указываем дату окончания задачи.
В диаграмме Г анта повторяющаяся задача отмечена специальным
индикатором. Повторяющаяся задача показана в виде суммарной задачи, где все ее
повторения являются отдельными подзадачами. Для расположения задач в
логической последовательности может быть использовано перемещение,
добавление, копирование и удаление задач. Для перемещения задачи строку задачи
в диаграмме Г анта необходимо выделить целиком, для этого нажимаем на
заголовке строки серого цвета. После изменения курсора на «+» перетаскиваем
строку в желаемое место. Для добавления задачи выбираем строку в диаграмме
Г анта, выше которой будет располагаться новая задача и нажимаем в меню
«Вставка» пункт «Новая задача» либо нажимаем кнопку «Insert». Для копирования
задачи необходимо выбрать задачу и нажать кнопку «Копировать» ячейку на
стандартной панели инструментов. Далее, перейдя в свободную строку, нажимаем
кнопку «Вставить». Можно скопировать одновременно несколько задач, для этого
нажав «Ctrl» (для несмежных задач) или «Shift» (для задач, расположенных рядом),
выделяем необходимые задачи.
Для удаления задачи необходимо выбрать соответствующую строку таблицы
и нажать «Delete».
После расположения задач в логической последовательности необходимо
создать структуру, представляющую иерархию выполняемых задач. Задача,
расположенная на самом верхнем уровне структуры расписания, называется
суммарной задачей. Задачи более низкого уровня называются подзадачами. К аждая
такая подзадача, в свою очередь, может быть также разделена на подзадачи. MS
Project поддерживает до девяти уровней вложенности задач. Для структурирования
задач можно использовать следующие средства MS Project:
• Перемещение задачи на один уровень ниже. Для этого необходимо
выделить перемещаемую задачу в диаграмме Г анта и нажат кнопку «На
уровень ниже» на панели инструментов «Форматирование». В ыбранная
задача становится подзадачей, а вышестоящая становится для нее
суммарной. Перемещать можно и несколько задач, предварительно выделив
их с помощью «Ctrl» или «Shift».
• Перемещение задачи на один уровень выше. Для этого необходимо выбрать
перемещаемую задачу и нажать кнопку «На уровень выше» на панели
инструментов «Форматирование».
• Отображение всех задач, вплоть до указанного уровня вложенности. Для
этого необходимо нажать кнопку «Показать» на панели инструментов
«Форматирование». Из списка выбрать необходимый уровень. Будут
отображаться только задачи данного уровня или более высоких.
• Скрыть или показать все подзадачи для данной задачи. Для этого
необходимо нажать знак «плюс» или «минус» слева от заголовка задачи.
После структуризации можно настроить коды структурной декомпозиции
работ (СДР). К аждый уровень и элемент структурной декомпозиции работ
описывается с помощью уникального кода. К ак правило, каждая цифра,
присутствующая в таких кодах, указывает на уровень в структурной иерархии. По
умолчанию, MS Project создает коды СДР на основе структурных номеров. Для
отображения структурных номеров в диаграмме Г анта необходимо нажав правой

54
кнопкой на заголовке табличной части диаграммы выбрать пункт меню «Вставить
столбец». В открывшемся окне следует выбрать имя поля «Номер» в структуре.
Для настройки собственной схемы СДР необходимо в меню «Проект»
выбрать пункт «СДР/Определить код». В открывшемся окне следует выбрать
префикс кода проекта, далее в поле «Последовательность» следует выбрать формат
кода для уровней иерархии, начиная с первого. После закрытия окна в табличную
часть диаграммы Г анта следует вставить столбец с заголовком СДР.
После заполнения списка задач и упорядочивания его, необходимо внести
информацию о количестве рабочего времени, необходимого для завершения
каждой задачи. Для этого необходимо внести значение продолжительности задачи
в поле «Длительность» табличной части диаграммы Г анта, например «1 день».
Значение длительности также может быть внесено как приблизительное. MS
Project рассчитывает подтвержденную длительность, однако данная возможность
позволяет указать предварительный характер длительности, который необходимо
уточнить по ходу разработки проекта. Для внесения приблизительной
длительности необходимо после временной единицы добавить знак вопроса,
например «1нед?». У далив знак вопроса, приблизительную длительность задачи
можно изменить на подтвержденную.
Для задания длительности в проекте могут использоваться различные
временные единицы, включая:
• минуты (мин);
• часы (ч);
• дни (д);
• недели (нед);
• месяцы (мес).
При вводе длительности задач могут использоваться как полные названия
временных единиц, так и их аббревиатуры. Е сли единицу измерения времени не
указывать, MS Project автоматически будет использовать дни.
Для получения достоверной информации о длительности задач можно
использовать четыре возможных источника:
• Знания сотрудников, работающих над проектом;
• Экспертные оценки;
• Информация о предыдущих проектах;
• Промышленные стандарты.
При существовании расхождений в оценке длительности задач или
необходимости моделирования альтернативных сценариев выполнения проекта
используется методика PE R T (Program, E valuation and R eview T echnique). При
анализе методом PE R T для расчета длительности задачи используются
средневзвешенные значения оптимистической, пессимистической и ожидаемой
длительности. А нализ PE R T является эффективным методом предупреждения
рисков. Он позволяет рассчитывать расписание проекта с учетом возможного или
имеющегося времени, ресурсов или стоимости.
Для выполнения анализа методом PE R T необходимо выбрать пункт «Анализ
по методу PERT» в меню «Вид/Панели инструментов». На появившейся панели
инструментов «Анализ по методу PERT» нажмите кнопку «Лист ввода PERT».
В ведите для каждой задачи значения оптимистической, пессимистической и
ожидаемой длительности в соответствующие поля таблицы. Е сли длительность
известна точно, то во всех полях таблицы указывается одинаковая длительность.

55
 При нажатии на кнопку «Вычисления по методу PERT» на этой же панели
инструментов программа рассчитает приблизительную длительность задачи,
которая будет внесена в поле таблицы «Длительность».
Следующим шагом в построении базового расписания является установка
взаимосвязей между задачами. Связь между задачами возникает в том случае, если
начало и/или конец одной задачи как-либо зависит от другой задачи. В MS Project
можно создать связь между предыдущей задачей, называемой предшественником и
следующей задачей − последователем, и тем самым создать зависимость между
ними. Для этого необходимо перейти в режим диаграммы Г анта. Следует выбрать
две задачи, которые необходимо связать между собой. Е сли задачи расположены в
списке задач не рядом, следует выделить задачу-предшественник, а затем,
удерживая клавишу «Ctrl», выбрать задачу-последователь. Далее следует нажать
кнопку «Связать задачи» на панели задач. После этого связь будет показана на
диаграмме Г анта стрелкой и в столбце «Предшественники» появится номер задачи-
предшественника. Т акже связь может быть установлена указанием задачи-
предшественника в столбце «Предшественники» напрямую.
По умолчанию всегда строится связь типа «конец-начало», когда вторая
задача начинается сразу после конца первой. Однако MS Project поддерживает и
другие типы связей. Для их создания на диаграмме Г анта следует выбрать задачу,
являющуюся последователем в устанавливаемой связи. Двойным нажатием мыши
следует открыть окно «Сведения о задаче». На вкладке «Предшественники»
следует выбрать любую свободную ячейку в поле «Имя задачи». В строке появится
раскрывающийся список, содержащий задачи проекта. Следует выбрать задачу,
являющуюся предшественником в устанавливаемой зависимости. Нажав на поле
«Тип» следует выбрать из списка тип связи. Для частичного совмещения задач
необходимо в поле «Запаздывание» ввести устанавливаемое время опережения.
Это значение вводится либо в процентах, либо во временных единицах и для
случая совмещения задач должно быть отрицательным. В случае если при
выполнении задачи-последователя возникает запаздывание, в поле «Запаздывание»
указывается положительной значение.
Для удаления связи необходимо на вкладке «Предшественники» в окне
«Сведения о задаче» для удаляемой связи указать тип связи (Нет). После закрытия
окна связь исчезнет. Любая задача в MS Project имеет ограничения по времени
выполнения. По умолчанию это «Как можно раньше». MS Project поддерживает
следующие типы ограничений:
• Г ибкие – «Как можно раньше» и «Как можно позже». Наличие таких
ограничений повышает гибкость времени выполнения задачи.
• Изменяемо-гибкие – «Начало не ранее», «Начало не позднее», «Окончание
не ранее» и «Окончание не позднее». Т акие ограничения позволяют
использовать при работе с ними временной интервал и допускают наличие
вариантов времени выполнения.
• Негибкие – «Фиксированное начало» и «Фиксированное окончание».
В се остальные ограничения будут второстепенными по отношению к
данным. В не зависимости от взаимосвязей задач они должны выполняться с
учетом фиксации дат начала/окончания.
Для изменения ограничений необходимо на вкладке «Дополнительно» окна
«Сведения о задаче» поменять «Тип ограничения» и «Дату ограничения». Т акже
при установке даты начала или конца задачи в табличной части диаграммы Г анта
тип ограничения также автоматически изменится на «Фиксированное
начало/окончание».

56
 В тех случаях, когда задача должна быть завершена к определенному сроку,
но расписание менять нежелательно, используются напоминания о крайних сроках.
Т акое напоминание не влияет на расписание проекта, при выполнении задачи
после крайнего срока в столбце индикаторов появляется предупреждение. Для
установки крайнего срока необходимо выбрать дату в поле «Крайний срок»
вкладки «Дополнительно» окна «Сведения о задаче». После этого в графической
части диаграммы Г анта появится указатель крайнего срока.
Т акже крайние сроки можно сразу ввести в столбец «Крайний срок»
табличной части диаграммы Г анта.
Для указания начала или завершения основных фаз проекта, либо для
указания завершения назначений проекта могут использоваться вехи, специально
выделяемые задачи, отображающие достижение промежуточных результатов
проекта. В ехи также не влияют на расписание проекта, однако, как правило, они
взаимосвязаны с другими задачами проекта. Простейшим способом создания вехи
является ввод задачи нулевой длительности. «У казатель вехи» появляется на
графической части диаграммы Г анта.
Для ввода вех ненулевой длительности, например последней задачи,
выполняемой на каждой фазе проекта, необходимо установить флажок «Пометить
задачу как веху» на вкладке «Дополнительно» окна «Сведения о задаче»,
предварительно выделив желаемую задачу.
В случае если необходимо планировать задачу с учетом рабочего времени,
отличного от принятого в календаре проекта или календаре ресурса, задаче
назначается свой календарь. В качестве такого календаря можно выбрать один из
уже имеющихся базовых календарей или создать новый. Для создания нового
календаря необходимо в меню «Сервис» выбрать пункт «Изменить рабочее время».
В открывшемся окне нажимаем кнопку «Создать…» Задав имя нового календаря и
выбрав исходный календарь, вносим желаемые изменения в рабочее время. Закрыв
окно, можно назначить созданный календарь задаче. Для этого в окне «Сведения о
задаче» на вкладке «Дополнительно» заполняем поле «Календарь». После выбора
календаря в поле индикаторов появляется индикатор календаря.
В ыполнение любых задач обеспечивается тремя видами ресурсов – людьми,
машинами и оборудованием. В программе MS Project все ресурсы делятся на две
категории: люди и оборудование относятся к трудовым ресурсам. За единицу
измерения усилий, затраченных такими ресурсами при выполнении задачи,
принято время. Материалы относятся к материальным ресурсам. Для них
измеряемой величиной по отношению к выполняемым задачам является
потребление ресурса, а единицей измерения − количество ресурса.
Для добавления ресурсов в проект необходимо выбрать представление листа
ресурсов, для этого выбираем пункт «Лист ресурсов» в меню «Вид». В
открывшейся таблице вводим название ресурса и выбираем его тип.
Для трудового ресурса необходимо указать максимальное количество
доступных единиц. Ресурсам, работающим на полную ставку, присваивается 100%.
Далее указываем стандартную ставку оплаты труда и сверхурочную (если есть). По
умолчанию используется почасовая оплата, но можно указывать и месячную
ставку. Т акже можно указать затраты на использование – дополнительные
одноразовые затраты, применяемые при каждом назначении ресурса. Начисление
затрат на ресурсы может осуществляться в конце или начале задаче или
пропорционально ее выполнению. По умолчанию в качестве базового календаря
применяется стандартный, однако в случае особых условий труда можно выбрать
любой другой календарь или создать свой. В случае если максимум доступных

57
единиц трудового ресурса будет изменяться по ходу выполнения проекта,
необходимо настроить доступность ресурса. Для этого следует выделить ресурс в
Листе «Ресурсов» и нажать кнопку «Сведения о ресурсе» на панели инструментов
«Стандартная». В открывшемся окне таблицу доступности ресурса следует
добавить диапазоны дат и максимальное количество единиц ресурса в данном
диапазоне.
Для материального ресурса заносится единица измерения материала и в
качестве стандартной ставки используется стоимость за единицу измерения.
При вводе ресурсов можно использовать как конкретные, так и
универсальные названия. Под универсальным ресурсом подразумевается ресурс,
обозначающий определенную должность, ей могут соответствовать разные
сотрудники. Конкретный ресурс относится к определенному сотруднику. По мере
разработки проекта универсальные ресурсы заменяются конкретными.
К любому ресурсу можно добавить любую дополнительную информацию.
Для этого необходимо выделив ресурс в «Листе ресурсов» нажать кнопку «Заметки
ресурса» на панели инструментов «Стандартная». В области заметок можно внести
свои комментарии или вставить любой файл данных.
Для назначения ресурсов следует перейти в диаграмму Г анта и выделить
задачу, на которую необходимо назначить ресурс. На панели инструментов
«Стандартная» нажмите кнопку «Назначить ресурсы». В открывшемся окне
«Назначение ресурсов» следует выбрать ресурс, который необходимо назначить и
нажать кнопку «Назначить». После этого в столбце «Единицы» появится
выделенный по умолчанию процент рабочего времени, равный либо
максимальным единицам данного ресурса (максимум до 100%), либо 100%
(максимум 100% или более). Процент может быть изменен на любой другой в
пределах максимальных единиц ресурса. Для материальных ресурсов единицами
являются количество ресурса. На одну задачу может быть назначено несколько
ресурсов.
Т акже через окно назначения вы можете снять ресурс с задачи (нажав кнопку
«Удалить»), заменить один ресурс на другой (кнопка «Заменить») или вывести
график трудозатрат (кнопка «Графики»).
Для задач с фиксированным количеством ресурса и фиксированными
трудозатратами добавление новых ресурсов снижает длительность. Е сли же задача
имеет фиксированную длительность, то добавление новых ресурсов снижает
количество единиц для каждого из назначенных ресурсов. Для тех случаев, когда
добавление новых ресурсов не должно приводить к изменению длительности,
отключают фиксированный объем работ в окне «Сведения о задаче» на вкладке
«Дополнительно».
При назначении ресурса задаче, рабочее время ресурса по умолчанию
равномерно распределяется по всей длительности задачи. Форма распределения
трудозатрат называется профилем загрузки. Для его изменения можно внести свои
значения загрузки в табличную часть представления использования ресурса (пункт
«Использование ресурса» меню «Вид»). Т акже можно применить к назначению
один из встроенных профилей загрузки. Для этого выбрав назначение, которому
необходимо придать определенный профиль, нажимаем кнопку «Сведения о
назначении». На вкладке «Общие» выбирается профиль загрузки из
предложенного списка.
Для любого проекта наиболее актуальны три группы ограничений – затраты,
длительность и использование ресурсов.

58
 Просмотреть затраты на назначения можно, применив таблицу «Затраты» к
представлению задач или ресурсов. Для этого в меню «Вид» выбираем команду
«Использование задач» или «Использование ресурсов». После этого также в меню
«Вид» следует выбрать пункт таблицы «Затраты». В представлении использования
задач отображаются затраты на отдельные назначения, а также общие затраты на
каждую задачу. В представлении использования ресурсов отображаются затраты
на отдельные назначения и общие затраты на каждый ресурс.
Повременное распределение затрат можно увидеть, добавив сведения о
затратах в табличную часть представления использования задач или ресурсов. Для
этого, перейдя в представление «Использование задач» или «Использование
ресурсов», необходимо в меню «Формат» выбрать пункт «Подробности/Затраты».
После этого в столбец «Подробности» табличной части представления будет
добавлено поле «Затраты».
Для просмотра данных в другом временном масштабе используются кнопки
«Увеличить/Уменьшить» на панели инструментов «Стандартная».
Для того, чтобы увидеть затраты, связанные с выполнением ресурсами
назначенных им задач, необходимо в таблицу ресурсов вставить столбец
«Затраты». Для этого, выбрав представление «Лист ресурсов», нажимаем на
заголовке столбца, справа от которого необходимо вставить столбец затрат. В
меню «Вставка» выбираем команду «Столбец». В открывшемся окне в списке
«Имя поля» выбираем «Затраты». После закрытия окна в таблице появится поле
Затраты, в котором будут показаны планируемые затраты на все назначения для
каждого ресурса.
Ресурсы можно сортировать, группировать и фильтровать по затратам:
• Для сортировки по затратам необходимо, открыв представление «Лист
ресурсов», выбрать пункт меню «Сортировка/по затратам» в меню
«Проект». П ункт меню «Сортировка/по идентификатору» возвращает
исходный порядок.
• Для фильтрации необходимо выбрать в меню «Проект» команду
«Фильтр/Другие фильтры». Из открывшегося списка выбираем вариант
«Затраты больше чем». После нажатия на кнопку «Применить» необходимо
ввести пороговое значение затрат. В ыбрав фильтр «Все ресурсы»
возвращаем исходную ситуацию.
• Для группировки необходимо выбрать команду «Группировать
по/Стандартной ставке» в меню «Проект». Для отмены группировки
выбираем пункт меню «Группировать по/нет группировки».
Планируемые затраты можно увидеть в отчетах о бюджете и движении
денежных средств. Для отображения отчета «Бюджет» необходимо выбрать пункт
«Отчеты» в меню «Вид». Далее выбираем категорию «Затраты» и вид отчета
«Бюджет». В появившемся отчете отображаются фиксированные затраты и общие
затраты по задачам.
Отчет «Движение денежных средств», также выбираемый из категории
«Затраты», отражает общие планируемые затраты на задачи за недельные периоды.
Общие затраты на весь проект можно увидеть в окне статистики проекта. Для
этого необходимо в меню «Проект» выбрать команду «Сведения о проекте». В
открывшемся окне нажимаем на кнопку «Статистика».
Планирование в MS Project осуществляется на основании метода
критического пути. Для этого анализируются все последовательности связанных
задач в проекте и определяется, какая из последовательностей имеет наименьший
временной резерв, она и обозначается как критический путь. В норме задачи,

59
лежащие на критическом пути, имеют нулевой временной резерв. Однако можно
поменять определение критической задачи, используемое программой. Для этого
необходимо выбрать пункт «Параметры» в меню «Сервис» и в открывшемся окне
перейти на вкладку «Расчет». Значение максимального временного резерва
критической задачи устанавливается в поле «Считать критическими задачи»,
имеющие резерв не более. Т акже на этой вкладке можно настроить режим
использования нескольких критических путей. В этом случае Microsoft Project
изменяет расчет критического пути таким образом, что любая задача, не имеющая
последователя, становится критической. Это значит, что ее дата позднего
окончания устанавливается равной дате раннего окончания и временной резерв
оказывается равным нулю. Любая последовательность задач, предшествующих
данной, становится критическим путем.
Для того, чтобы узнать величину свободного и полного временного резерва
необходимо, открыв диаграмму Г анта, выбрать пункт «Таблица: Календарный
план» из меню «Вид». После этого в табличной части появятся поля «Свободный
временной резерв» и «Общий временной резерв». Для того чтобы увидеть
критический путь на диаграмме Г анта, необходимо выбрать пункт «Диаграмма
Ганта с отслеживанием» в меню «Вид». На этой диаграмме критический путь
отображается красным цветом в графической части представления.
В проекте, ограниченном по ресурсам, необходимо обеспечить максимальное
использование всех ресурсов, назначение их на правильные задачи и недопущение
превышения доступности.
Ресурсы с превышением доступности обозначаются в «Листе ресурсов»
красным цветом. Чтобы увидеть, на какие задачи назначены ресурсы с
превышением доступности необходимо добавить в представление задач (например,
диаграмму Г анта) столбец «Превышение доступности». Для этого необходимо,
перейдя в представление задач, выбрать пункт «Столбец» из меню «Вставка». В
открывшемся окне в списке «Имя поля» выберите «Превышение доступности».
Е сли у задачи есть перегруженные ресурсы, то в данном столбце будет значение
«Да». Чтобы увидеть, какое количество работы назначено ресурсу в течение
определенного времени, можно использовать График ресурсов. Для этого
необходимо выбрать представление «График ресурсов» в меню «Вид». По
умолчанию показываются пиковые единицы, однако можно выбрать, например,
трудозатраты или процент загрузки. Для этого нажимаем в области окна вида
правой кнопкой мыши и выбираем нужный режим из контекстного меню. Более
подробно сведения об использовании ресурса отображаются в «Форме ресурса».
Для того, чтобы ее увидеть, необходимо открыть представление «Лист ресурсов» и
затем выбрать в меню «Окно» команду «Разделить». После этого в нижней части
окна появится форма ресурсов, в которой будет показана информация о выбранном
ресурсе.
При перегрузке ресурсов можно:
• заменить перегруженный ресурс на другой. Для этого необходимо, выбрав
на диаграмме Г анта задачу с перегруженными ресурсами, нажать кнопку
«Назначение ресурсов» на панели инструментов «Стандартная». В
диалоговом окне «Назначение ресурсов» выбрать заменяемый ресурс и
нажать кнопку «Заменить». В окне «Замена ресурсов» выбрать тот ресурс,
на который необходимо провести замену;
• назначить дополнительный ресурс;
• отложить задачу или назначение до тех пор, пока у ресурса не появится
свободное время. Для этого используется выравнивающая задержка и

60
 задержка назначения. Выравнивающая задержка – количество времени
которое должно пройти от планируемой даты начала задачи до момента
фактического начала выполнения. При этом задерживаются все назначения
по данной задаче. Для добавления выравнивающей задержки необходимо,
перейдя в представление «Диаграмма Ганта с отслеживанием», выбрать из
меню «Вид» пункт «Таблица/Другие таблицы». Из предлагаемого списка
выбираем таблицу Задержка и нажимаем «Применить». После этого
выравнивающая задержка вводится в соответствующее поле. Задержка
назначения – количество времени, которое должно пройти от планируемой
даты начала выполнения задачи до планируемой даты начала назначения.
Для добавления задержки назначения необходимо вставить в табличную
часть диаграммы Г анта с отслеживанием столбец «Задержка» назначения;
• назначить сверхурочные. Для этого переходим в представление
Использование ресурсов и добавляем в табличную часть столбец
«Сверхурочные трудозатраты». Для отображения сверхурочных затрат по
временным периодам необходимо в меню «Формат» выбрать пункт «Стили
подробных данных». В открывшемся окне в списке «Доступные поля»
выбираем «Сверхурочные трудозатраты» и нажимаем на кнопке «показать».
После закрытия окна сверхурочные затраты появляются в обоих частях
представления.
Сверхурочные затраты можно добавить только в табличную часть, изменить
их автоматическое распределение по временным периодам нельзя.
• прервать задачу. Для того, чтобы прервать выполнение задачи и вернуться к
ней с определенной даты, необходимо перейти в представление Диаграмма
Ганта, и нажать кнопку «Прервать задачу». После этого в графической
части необходимо выбрать прерываемую задачу и указать дату, где должно
произойти прерывание. В торую часть отрезка перетаскиваем к той дате, где
должно произойти прерывание.
План проекта, утвержденный для выполнения после внесения всех
необходимых
изменений, считается базовым планом. Базовый и текущий план совпадают
только в момент сохранения базового плана. В ходе выполнения проекта текущий
план может изменяться. Для того чтобы иметь возможность сравнить базовый план
с текущим его надо сохранить. Для этого необходимо выбрать пункт меню
«Отслеживание/Сохранить базовый план» в меню «Сервис». В открывшемся окне
убедитесь, что выбран пункт «Сохранить базовый план» и в списке базовых планов
выбран «Базовый план без номера». Т акже в группе должно быть выбрано
значение всего проекта.
Добавлять задачи в базовый план можно и после его сохранения. Для этого в
окне сохранение базового плана необходимо выбрать базовый план, в который
необходимо добавить задачи и переключатель установить в значение выбранных
задач. Флаги из группы «Сведение базовых планов» указывают, как будет
обновляться суммарная задача при обновлении базового плана. У становка флага во
все суммарные задачи приводит к тому, что выделенные задачи учитываются во
всех суммарных задачах, к которым относятся. Флаг из подчиненных в выбранные
суммарные задачи приводит к тому, что выделенные задачи сводятся только в
выбранной суммарной задаче.
Сохранение базового плана не тождественно сохранению полного плана
проекта.

61
 При сохранении базового плана записываются следующие поля всех задач,
ресурсов и назначений:
• затраты – в поле «Базовые затраты»;
• длительность – в поле «Базовая длительность»;
• окончание – в поле «Базовое окончание»;
• начало – в поле «Базовое начало»;
• трудозатраты – в поле «Базовые трудозатраты».
Для просмотра информации базового плана после его сохранения можно
использовать диаграмму Г анта с отслеживанием, на которой отрезки,
соответствующие базовому плану, отображаются под отрезками текущего плана.
Т акже поля базового плана, например «Базовая длительность», могут быть
добавлены к любой таблицы, где есть соответствующие поля актуального плана.
Для этого необходимо, перейти в представление данной таблицы и выбрать пункт
«Столбец» из меню «В ставка». В поле «Имя поля» выбрать необходимое поле
базового плана.
В промежуточных планах сохраняются только даты начала и окончания
задач.
Данные о датах сохраняются в настраиваемых полях вида «Начало1-10» и
«Окончание1-10». Для очистки базовых и промежуточных планов проекта
необходимо выбрать пункт меню «Отслеживание/Очистить базовый план» в меню
«Сервис». В открывшемся окне необходимо выбрать очищаемый план и будет ли
очищаться весь проект, либо только выбранные задачи.
Отслеживание выполнения задач соответствует регулярному обновлению
информации о состоянии проекта по ходу его выполнения. Для этого в план
проекта должны вносится следующие сведения:
• процент завершения;
• фактическая длительность и оставшаяся длительность;
• фактическое начало и фактическое окончание;
• процент завершения трудозатрат;
• фактические трудозатраты и оставшиеся трудозатраты;
• фактические трудозатраты за оставшийся период времени.
При вводе любого из этих параметров остальные вычисляются программой
автоматически. При этом также корректируются расписание и бюджет проекта.
Многие функции отслеживания доступны через панель «Отслеживание». Для
вывода ее на экран необходимо выбрать пункт «Панели
инструментов/Отслеживание» в меню «Вид».
К нопки на панели «Отслеживание» имеют следующие функции (слева
направо):
• Статистика проекта. Открывает диалоговое окно «Статистика проекта»
со сведениями о текущих, базовых и фактических датах начала и окончания
проекта и их отклонениях от базовых дат, а также текущих, базовых,
фактических и оставшихся длительности, трудозатратах и стоимости;
• Обновить по графику. Добавляет в выделенные задачи информацию,
показывающую, что они выполняются точно по графику;
• Изменить график работ. Г рафик работ по всем задачам проекта изменяется
таким образом, чтобы все незавершенные дела начинались после даты
отчета. Е сли дата отчета не указана, то она считается соответствующей
текущей дате;
• Добавить линию хода выполнения. Превращает курсор в инструмент
выделения, с помощью которого можно указать дату выполнения для

62
 которой будет строится линия хода выполнения. Для этого надо окно
подходящего представления, например диаграммы Г анта, должно быть
активным;
• 0%,25%,50%,75%,100% завершено. У станавливает для выделенных задач
соответствующий процент выполнения;
• Обновить задачи. Открывает диалоговое окно «Обновление задач», где
можно настроить фактические даты начала и окончания, % выполнения и
длительность выделенных задач;
• Панель инструментов совместной работы. В ыводит на экран панель
Совместная работа. С ее помощью можно опубликовать назначения,
обновлять и запрашивать сведения о ходе выполнения проекта и
пользоваться различными функциями взаимодействия через Microsoft
Project Server.
К роме отслеживания через сведения о задачах можно применять
отслеживание через сведения о трудозатратах ресурсов. Т рудозатраты появляются
в проекте только после назначения ресурсов в результате пересчета длительности
задач во время работы ресурсов. Для учета трудозатрат можно либо ввести процент
завершенных трудозатрат или значения фактических и оставшихся трудозатрат.
Для того чтобы ввести процент завершенных трудозатрат необходимо сначала
перейти в представление со списком задач, например диаграмму Г анта. К данному
представлению необходимо применить таблицу «Т рудозатраты». В ыбираем пункт
меню «Таблица/Трудозатраты» в меню «Вид». В поле «% заверш. по труд. задачи»,
данные о ходе работ которой необходимо обновить, указывается значение
процента завершенных трудозатрат.
Для того чтобы указать процент завершенных трудозатрат по конкретному
назначению необходимо открыть представление «Использование задач». В ыберите
назначение, которому вы хотите ввести процент завершенных трудозатрат. Можно
выбрать несколько назначений, если необходимо ввести одинаковый процент.
Нажав кнопку «Сведения о назначении» на панели «Стандартная» отображаем
соответствующее окно. В нем выбираем вкладку «Отслеживание». И в поле «%
завершения» по трудозатратам вводим необходимое значение.
Для ввода фактических трудозатрат по задаче необходимо ввести значение в
поле «Фактические» любого представления со списком задач при включенной
таблице «Трудозатраты». При этом значения в полях «Оставшиеся» и «% заверш.
по труд.» будут пересчитаны автоматически.
В тех случаях, когда проект по каким-либо причинам прерывался, и данные о
его выполнении стали неактуальными, необходимо перенести незавершенные
задачи на новую дату. Для этого необходимо выбрать пункт
«Отслеживание/Обновить проект» в меню «Сервис». В открывшемся окне
необходимо установить переключатель «Перепланировать незавершенные
трудозатраты» с началом после и указать дату возобновления проекта в
соответствующем поле.
Эффективное взаимодействие по проекту заключается в регулярном
получении, сборе и предоставлении информации заинтересованным лицам, прежде
всего это участники команды проекта. Первым этапом управления
взаимодействием в рамках проекта всегда является планирование. При
планировании проекта важно определить требования к отчетам, а именно:
• получатели отчетов;
• информация, включаемая в отчет;
• частота подготовки отчетов.

63
 Эффективность информационного взаимодействия между членами команды
зависит от набора используемых средств – от регулярных собраний и рассылок по
электронной почте до использования Microsoft Project Server и W eb A ccess.
Информация предоставляется в форме отчетов. В MS Project отчеты разделяются
на шесть категорий – «Обзорные», «Текущая деятельность», «Затраты»,
«Назначения», «Загрузка», «Настраиваемые». Для вывода отчетности используется
пункт «Отчеты» в меню «В ид». В открывшемся окне выбираем категорию отчета.
В категорию «Обзорные», предназначенную для отображения общей
информации по проекту, включаются отчеты:
• «Сводка по проекту» содержит основные сведения из плана проекта -
длительность, трудозатраты, состояние работ и ресурсов и т.п. Позволяет
сравнить фактические и планируемые данные;
• «Задачи верхнего уровня» содержит сведения о суммарных задачах проекта.
В него входят результаты суммарных задач верхнего уровня, объединяющие
данные по всем подзадачам;
• «Критические задачи» применяет к проекту фильтр, оставляющих только те
задачи, которые могут повлиять на дату окончания проекта. Помимо
сведений о критических задачах, этот отчет содержит сведения о
последующих задачах, что позволяет определить на какие задачи проекта в
первую очередь повлияет задержка критических задач;
• «Вехи» показывает отчетность по вехам проекта;
• «Рабочие дни» выводит сведения о рабочих и нерабочих днях каждого из
базовых календарей, используемых в проекте. К аждый календарь
отображается в отдельной таблице. Отчеты по текущей деятельности
показывают ход работ по проекту. В эту группу включены следующие
отчеты:
• «Неначатые задачи» показывает те задачи, по которым не были введены
фактические данные. Общее количество задач в данном отчете сокращается
по мере выполнения проекта, поэтому данный проект становится особенно
полезным при приближении сроков окончания проекта. Ресурсы,
назначенные данным задачам, выводятся в отдельных таблицах;
• «Задачи, которые скоро начнутся»: представляет собой сокращенный
вариант отчета «Не начатые задачи». При выборе данного отчета
необходимо последовательно ввести начальную и конечную даты, по
которым необходимо построить отчет;
• «Выполняющиеся задачи»: показывает те задачи, которые в данный момент
выполняются. Задачи группируются по месяцам, это позволяет оценить как
объем начатых работ, так и отставание задач от графика;
• «Задачи, которые должны были начаться»: показывает те задачи, которые
должны уже были начаться по графику, но данные об их фактическом
выполнении не приведены;
• «Завершенные задачи» отображает все задачи, для которых указан процент
выполнения - 100%. Данные группируются по месяцам;
• «Запаздывающие задачи» используется только в том случае, если
предварительно был сохранен базовый план проекта. В отчет включаются те
задачи, которые уже начались, но должны закончится позже
запланированной даты окончания. Это позволяет выявить задачи, для
которых необходима перепланировка. В данный отчет включаются
суммарные задачи, примечания, а также таблицы со сведениями о
последующих задачах.

64
 В категорию «Затраты» включены отчеты:
• «Движение денежных средств» – таблица с перекрестными ссылками,
показывающая запланированную и фактическую стоимость каждой задачи.
Данные группируются по неделям. В отчет выводятся сведения о
накопленной стоимости, причем для задач суммируются все типы затрат;
• «Бюджет» содержит все задачи проекта, упорядоченные в порядке
убывания общих затрат. В нем отражаются фактические и общие затраты,
метод их начисления и оставшиеся затраты;
• «Задачи с превышением бюджета»: позволяет быстро найти задачи,
фактическая или запланированная стоимость которых превышает базовую.
Задачи сортируются в порядке убывания отклонения. Для вывода отчета
необходимо сохранение базового плана;
• «Ресурсы с превышением бюджета» содержит сведения о тех ресурсах,
затраты на которые превышают или должны превысить базовые. Ресурсы
сортируются в порядке убывания разницы. Для вывода данного отчета
также необходимо сохранение базового плана;
• «Освоенный объем» выводит проектную информацию согласно концепции
освоенного объема – метода сравнения фактических и планируемых затрат.
Используемые в отчете термины приведены в таблице 1.
Т аблица 11. Т ермины метода освоенного объема
Термин Пояснение
Базовая стоимость запланированных Изначально определенная стоимость
работ (БСЗР) работ по задаче до даты отчета о
состоянии
Базовая стоимость выполненных работ Изначально запланированная стоимость
(БСВ Р) работ, помноженная на рассчитанный
процент завершения задачи.
Фактическая стоимость выполненных Затраты, понесенные в результате
работ (ФСВ Р) выполнения фактических работ по
задаче, а также всех накопленных
фиксированных затрат.
Отклонение от календарного плана Разность базовой стоимости
(ОК П) запланированных и выполненных работ.
Отклонение по стоимости (ОПС) Разность базовой стоимости и
фактической стоимости выполненных
работ.
Предварительная оценка по завершении С умма фактических и оставшихся затрат
(ПОПЗ) по задаче.
Бюджет по завершении (БПЗ) Полная базовая стоимость задачи,
включая стоимость ресурсов и все
фиксированные затраты.

Отклонение по завершении (ОПЗ) Разность запланированных и базовых

затрат на задачу.
Индекс отклонения стоимости (ИОС) Рассчитываемый индикатор освоенного
объема по затратам. Отношение базовой
к фактической стоимости выполненных
работ.
Индекс отклонения от календарного Отношение базовой стоимости
плана (ИОК П) выполненных работ и выполненных

65
 работ.
Относительное отклонение по Отличие ожидавшейся стоимости задачи
стоимости (ООПС) от фактической стоимости на дату
отчета о состоянии. В ыражается в
процентах.
Относительное отклонение от Показывает опережение или отставание
календарного плана (ООК П) от графика выполнение задачи в
процентах.
Показание эффективности выполнения Отношение незавершенных работ к
(ПЭВ ) запланированным неизрасходованным
средствам для данной задачи.
Физический процент завершения Пользовательская оценка завершения.
Имеет приоритет перед расчетной на
основании даты начала, окончания и
отчета о состоянии.
В категорию «Назначения» включены следующие отчеты:
• «Дела по исполнителям» содержит список задач, назначенных каждому
ресурсу.
• « Подробност и о задаче и имя ресурса» приводятся в отдельной таблице. В
отчет также включаются индикаторы примечаний и необходимость
выравнивания загрузки;
• «Дела по исполнителям и времени» уточняет сведения отчета Дела по
исполнителям, дополняя их количеством часов, отводящихся на каждую
задачу в каждый рабочий день;
• «Ресурсы с превышением доступности» включает сведения только о тех
ресурсах, которым назначен объем работ, превышающий их возможности
согласно календарю ресурсов. Отчет включает также сведения о
назначенных ресурсам задачах.
В категорию «Загрузка» входят отчеты:
• «Использование задач» содержит данные о том, сколько времени ресурсы
тратят на каждую из задач проекта. Итоговые значения выводятся по
каждой недели и по каждой задаче проекта;
• «Использование ресурсов» показывает сведения о работе, осуществляемой
каждым ресурсом. Для ресурсов выводятся названия недельные
трудозатраты по каждому назначению.
Последняя категория отчетов называется «Настраиваемая». В программе MS
Project предусмотрено три метода создания настраиваемых отчетов:
• Создание нового отчета с нуля. Необходимо выбрать один из общих
форматов отчетов: «Задача», «Ресурс», «Месячный календарь» или
«Перекрестная таблица». Создание отчета осуществляется путем ввода
данных в поля на вкладках появляющегося диалогового окна.
• Выбор и редактирование существующего отчета. В этом случае
редактируется существующий встроенный отчет.
• Копирование и редактирование существующего отчета. Создается копия
встроенного отчета, в которую и вносятся изменения.
В се три метода начинаются одинаково. Необходимо выбрать категорию
отчетов «Настраиваемые». В открывшемся окне указываем вид отчета и нажимаем
кнопку «Создать», «Изменить» или «Копировать» в зависимости от того, каким
способом создается отчет.

66
 После выбора метода создания в следующем окне необходимо определить
содержимое отчета.
В связи с широким распространением сети Интернет имеет смысл
публикация сведений о проекте на веб-странице. Для этого необходимо открыть
представление данных, которое необходимо опубликовать и настроить его так, как
он должен выглядеть на странице. После этого выбираем пункт «Сохранить как
Веб-страницу» в меню «Файл». В открывшемся окне выбираем место сохранения и
имя файла. После нажатия «Сохранить» открывается окно мастера экспорта.
Нажимаем кнопку «Далее». В следующем окне выбираем пункт «Создать новую
схему». На следующем экране необходимо выбрать тип экспортируемых данных и
параметры страницы.
Для каждого типа экспортируемых данных мастер открывает свое окно
сопоставления для выбора экспортируемых данных. Например, в форме
сопоставления задач необходимо добавить поля задач проекта. Можно добавить
все поля, нажав кнопку «Добавить все», выбрать конкретное поле, нажав
«Добавить строку» или использовать в качестве образца таблицу, нажав «На
основе таблицы». После выбора необходимых полей нажимаем «Готово». Это
завершает работу мастера.
В случае если анализ проекта предполагает интенсивную работу с числовыми
данными, сложное форматирование или вывод диаграмм, полезно использовать
MS E xcel. Для экспорта данных необходимо выбрать подходящее представление
данных и выделить в нем экспортируемые данные. Е сли необходимо выделить
таблицу целиком, то нажимаем на верхнюю левую клетку. После отбора данных
выбираем пункт «Сохранить как» в меню «Файл». В открывшемся окне
«С охранение документа» необходимо выбрать тип файла «Книга Microsoft Excel
(*.xls)». После нажатия на кнопку «Сохранить» появляется окно мастера экспорта,
аналогичное использовавшемуся для публикации в виде веб-страницы. Нажав
кнопку «Далее», выбираем формат экспортируемых данных. В данном случае
необходимо выбрать формат «Выбранные данные». На следующих экранах
выбираем создание новой схемы экспорта и типы данных для экспорта. Далее в
окнах сопоставления данных (соответственно это может быть сопоставление задач,
ресурсов или назначений) выбираем поля экспортируемых данных и указываем то,
как они будут представляться в MS E xcel. После нажатия на кнопку «Готово»
работа мастера экспорта завершается.
Для некоторых видов анализа необходимо разделять данные по наиболее
общим типам, для MS Project это задачи, назначения и ресурсы. Для этого
необходимо при экспорте данных указать формат данных «Шаблон проекта
(Excel)». В созданной книге MS E xcel будет четыре листа: «Таблица_ресурсов»,
«Таблица_задач», «Таблица_назначений» и «Таблица_сведений», содержащие
данные, упорядоченные по типам.
В большинстве случаев анализ сведений о проекте осуществляется методом
сравнения фактических параметров с базовыми. Сравнение показывает
соответствие хода работ запланированному графику, либо отклонение одного от
другого. В MS Project доступны следующие методы анализа отклонений:
• освоенный объем;
• индекс отклонения стоимости;
• индекс отклонения от календарного плана;
• предварительная оценка по завершении;
• отклонение по завершении.

67
 Метод освоенного объема – систематизированный метод вычисления этих
характеристик выполнения проекта. Для отображения показателей метода
освоенного объема необходимо выбрать одно из представлений, отображающих
задачи, например диаграмму Г анта. Далее выбрать пункт «Таблица/Другие
таблицы» из меню «Вид». В открывшемся списке выбираем таблицу «Освоенный
объем». После этого в табличной части представления появляются поля
характеристик проекта, рассчитанные по методу освоенного объема.
Т акже, кроме таблицы «Освоенный объем», можно выбрать таблицы
«Показатели календ. плана (освоенный объем)» и «Показатели затрат (освоенный
объем)». Данные таблицы предоставляют дополнительные поля для оценки
выполнения соответственно задач и затрат по данному методу.
Microsoft Project позволяет вставлять один проект внутрь другого. В любом
представлении со списком задач подпроекты выглядят как суммарные задачи. К о
всем задачам подпроекта имеется полный доступ: В ы можете просматривать и
изменять их содержимое, при этом меняются сведения о задачах в исходном файле
проекта. Необходимость разбиения проекта на главный проект плюс подпроекты
может быть вызвана как сложностью проекта и наличием подчиненных
руководителей проекта, так и необходимостью переключаться между проектами с
разными уровнями детализации.
Для создания главного проекта необходимо в проект, который станет
главным, добавить все остальные подчиненные проекты. Для этого открываем
проект, который будет главным, и выбираем представление со списком задач,
например диаграмму Ганта. В ыделяем строку, под которой необходимо вставить
подпроект. Задача в этой строке может находиться на любом уровне
существующей структуры. В ставленный проект будет находиться на том же
уровне, что и выделенная задача. В ыберите пункт «Проект» в меню «Вставка». В
появившемся окне выберите имя вставляемого проекта и нажмите кнопку
«Вставить». После вставки название проекта появится в выделенной строке списка
задач и в столбце индикаторов будет отображаться значок вставленного проекта.
Повторяем вставку проекта для всех остальных подпроектов, относящихся к
главному проекту.
Для контроля связей между проектами необходимо выбрать пункт «Связи
между проектами» из меню «Сервис». В открывшемся диалоговом окне будут
показаны сведения обо всех внешних предшественниках и внешних
последователях. Т акже в любом представлении задач можно добавить в табличную
часть поле «Внешняя задача», в котором будет указана, является ли данная задача
внешней по отношению к данному проекту, и поле «Проект», в котором будет
указано имя проекта, к которому относится задача.
Для удаления связей между проектами можно использовать диалоговое окно
Связи между проектами. Перейдя на вкладку внешних предшественников или
последователей, выделите связь, которую необходимо удалить, и нажмите кнопку
«Удалить связь». Сведения о ресурсах и задачах могут быть перенесены из одно
проекта в другой.
Для этого можно использовать стандартные команды «Копировать ячейку»,
«Вырезать ячейку» и «Вставить» из меню «Правка». При вырезании ячейки, она
будет удалена из исходного проекта, это применимо, если необходимо разбить
сложный проект на несколько подпроектов. Для копирования открываем проект, из
которого необходимо скопировать данные и выбираем соответствующее
представление данных. Например, для копирования информации о задачах можно
использовать диаграмму Г анта. В ыделив необходимые данные, выбираем пункт

68
«Копировать» из меню «Правка». Далее открываем проект, куда необходимо
скопировать данные, и выбираем аналогичное представление данных. В ыделяем
строку, после которой необходимо добавить копируемые данные. После этого
выбираем пункт меню «Вставить» из меню «Правка».
В тех случаях, когда необходимость изменять данные подпроекта
отсутствует, можно сделать подпроект доступным только для чтения. Для
настройки доступа необходимо в диаграмме Г анта выделить суммарную задачу,
относящуюся к подпроекту и нажать кнопку «Сведения о задаче» на панели
инструментов «Стандартная». В диалоговом окне переходим на вкладку
«Дополнительно» и устанавливаем флажок «Т олько для чтения». В этом же окне
можно разорвать связь между данным подпроектом и основным проектом, для
этого убираем флажок «Связь с проектом».
К роме подхода «главного проекта плюс подпроекты» сведения из нескольких
проектов также могут быть собраны в один объединенный проект. Т акой проект
также создается с помощью функции «Вставка проекта», но имеет следующие
отличия:
• Объединенный проект не обязательно должен иметь иерархическую
структуру. В се вложенные проекты могут находиться на одном уровне.
• Проекты могут не иметь абсолютно никакого отношения друг к другу.
Объединенный проект может быть только хранилищем нескольких файлов.
• Объединение проектов в одном файле может быть временным и
применяться, например, для формирования отчета.
Для объединения проекта необходимо создать новый проект, затем вставить в
него все необходимые файлы проектов через пункт «Проект» меню «Вставка» как
и для главного проекта. Специфическим вариантом объединенного проекта
является пул ресурсов, такой проект служит исключительно для хранения сведений
о ресурсах, их доступности, стоимости и текущем использовании. В качестве пула
можно использовать как один из имеющихся проектов, содержащий все
необходимые ресурсы, так и создать новый. Для создания нового пула ресурсов
необходимо во вновь созданном проекте заполнить информацию о ресурсах,
например, используя «Лист ресурсов». Необходимо ввести, по крайне мере имя
ресурса, единицу измерения и стандартную ставку.
После сохранения пула ресурсов как обычного проекта, его можно
подключать к другим файлам проектов. Для этого необходимо открыть файл пула
ресурсов и файл проекта, к которому планируется добавить ресурсы. Далее в
проекте выбираем пункт «Доступ к ресурсам» из меню «Сервис/Общие». В
открывшемся диалоговом окне Общий доступ к ресурсам устанавливаем
переключатель «Использовать ресурсы». В списке выбираем имя файла пула
ресурсов. У казываем метод обработки конфликта ресурсов. После нажатия на
кнопку «ОК» файл проекта станет клиентом пула ресурсов. В се сведения из пула
отображаться в проекте, а информация о ресурсах из файла проекта будет
добавлена в файл пула.
При следующем открытии файла проекта, В ам будет предложено открыть и
файл пула. Е сли пул ресурсов не будет открыт, то доступа к его ресурсам тоже не
будет. В ы следующем окне можно выбрать режим доступа к файлу пула, включая
только чтение, чтение и запись, а также чтение и запись с созданием главного
проекта для всех файлов связанных с пулом ресурсов.
При использовании пула ресурсов в нескольких проектах, необходимо
периодически обновлять информацию о его состоянии. Для этого необходимо
выбрать пункт «Обновить пул ресурсов» меню «Сервис/общие ресурсы».

69
Для отключения использования пула ресурсов необходимо в окне «Общий доступ»
к ресурсам установить переключатель «Использовать собственные ресурсы».

Структура отчета

1. Расписание проекта.
1.1. Перечень основных задач. Декомпозиция задач проекта.
1.2. В заимосвязи между задачами. Различные временные связи задач В ашего
проекта. Длительность задач.
1.3. В ехи проекта, критические даты.
2. К оманда проекта. У частники и их роли.
3. Ресурсы проекта. Использование ресурсов различными задачами. Особенности
трудовых и материальных ресурсов.
4. Стоимость проекта. Бюджет проекта. Расход денежных средств на различных
стадиях проекта.
5. А нализ реализуемости проекта.
5.1. В ременная реализуемость
Цель анализа: определить выполнимость Вашего проекта в заданные
временные сроки и рассчитать риски невыполнения проекта из-за превышения
длительности.
5.1.1. У казать сколько времени занимает ваш проект и какой общий объем
работ.
5.1.2. Построить сетевую модель. Рассчитать временные резервы полный и
свободный для всех задач вашего проекта.
5.1.3. Посчитать сколько % от общего числа задач критические.
5.1.4. Описать какие настройки календарей использовались.
5.2. Стоимостная реализуемость
Цель анализа: определить возможность выполнения Вашего проекта с учетом
бюджетных ограничений.
5.2.1. Использовать отчеты из группы Отчеты о затратах.
5.2.2. Проанализировать использование бюджета В ашего проекта и
движение денежных средств.
5.2.3. У казать основные факторы стоимости В ашего проекта.
5.3. Ресурсная реализуемость
Цель анализа: выявить перегрузку и недогрузку ресурсов (назначений).
Избавиться от ресурс-конфликтов.
5.3.1. А нализ Листа ресурсов проекта.
5.3.2. Использование предлагаемых отчетов из группы отчетов о
назначениях. Отчет Использование ресурсов.
6. Риски. В иды рисков проекта. Оценка рисков. У правление рисками.
7. В ыводы. В ы должны определить, что необходимо изменить в В ашем проекте,
чтобы его можно было реализовать на практике. Перспективы развития В ашего
проекта.

70
 Деловая игра
1. Аннотация
Данная деловая игра поможет на примере абстрактного IT-проекта
приобрести навыки принятия решений руководящим работникам и специалистам в
различных производственных ситуациях, в рамках заданных правил, при наличии
конфликтных ситуаций и информационной неопределённости.
Руководитель проекта и его верная команда попробуют реализовать проект,
доведя его до логического завершения, в то время, как недобросовестные
работники всеми силами будут этому мешать, набивая собственные карманы и
играя на руку конкурентам. Лишь сплоченность коллектива, прозорливость
руководства, сообразительность участников и толика удачи помогут вытащить
проект из бездны, в которую его толкают недоброжелатели.
Игра рассчитана на небольшую группу из 7-10 игроков. От участников не
требуется владеть определенными навыками и умениями, однако опыт
руководящей работы и анализа рисков сделает игру чуть проще, а их отсутствие,
наоборот, затруднит победу, однако цель, так или иначе будет достигнута.
2. Цель
Целью данной игры является приобретение игроками руководящих
навыков, умения оценивать риски, критически оценивать суждения коллег,
продвигать собственные интересы и грамотно донести собственные идеи,
соображения до руководства, принимать сложные решения и ставить интересы
команды выше собственных, ставя победу в долгосрочной перспективе выше
сиюминутных бонусов.
Игра завершается вместе с последней стадией проекта или при исчерпании
бюджета и всех разыгранных карт длительного действия. Условия победы для
каждой роли свои, однако победа отдельного игрока не является целью.
3. Сценарий
3.1. Подготовка
Ведущий раздает участникам колоды карт. В каждой из них присутствует
карта роли. У колод одинаковая рубашка, поэтому игроки не знают ролей друг
друга.
Руководитель раскрывает себя и получает бюджет на реализацию проекта.
Любой другой участник, раскрывший себя, автоматически выбывает из игры.
Ведущий держит при себе колоду ресурсов. Каждый игрок набирает до 8 карт из
своей колоды.
3.2. Раунд
Каждый игрок может разыграть по одной карте ресурсов и действия из
своей колоды. Игроки ходят одновременно, выкладывая свои карты рубашкой
вверх, так чтобы другие игроки не видели разыгранной карты. Ведущий берет
выложенные карты у участников и сообщает руководителю запрошенное в карте
действие. Если требуется, руководитель принимает решение и распределяет
бюджет.
3.3. Планёрка
Если руководитель разыграл свою карту, в конце раунда начинается
планёрка. Руководитель выбирает одного из участников, который становится его

71
помощником. Остальные игроки рассказывают о совершённых в этом раунде
действиях. Никто не обязан говорить правду. После этого помощник может
выдвинуть кандидатуру одного из игроков на увольнение. Руководитель может с
ним согласиться. В этом случае, игрок раскрывает свои карты и выбывает из игры.
3.4. Жизненный цикл
Для успешного завершения проекта, необходимо последовательно
завершить все его стадии. Каждая карта из общей колоды имеет показатель
эффективности на каждой стадии. Ведущий последовательно сменяет стадии, по
мере их завершения.
Каждая стадия имеет сроки реализации. При превышении этих сроков,
ведущий разыгрывает карту истечения сроков реализации проекта, снижающую
вероятность успешного завершения проекта.
Проект проваливается после того, как ни один из участников не может
продвигать его реализацию по причине нехватки бюджета или исчерпания
собственной колоды карт.
Таблица 12. Значение изображений на карточках
Изображение Значение
Продолжительность

Р Материальные ресурсы

Вычислительные ресурсы

Данные

Контрагенты

 Прочие ресурсы

Руководитель

Работник
Исследователь
Хапуга

Засланец

★ Эффективность

4. Итоги
После окончания проекта, подводятся итоги игры. Вначале объявляются
победители. Те, кто одержал победу согласно правилам игры. Затем происходит
обсуждение действий каждого игрока. Правильно ли он себя вёл, выделение
ошибок в игре (неоправданный риск, отсутствие командой игры) и при общении с
другими игроками на планёрках. Особо внимание уделяется решением принятым
руководителем и игрокам, которые были уволены. Каждый игрок высказывает своё

72
мнение о других участниках игры и о том, что, по его мнению, они делали верно, а
что нет.
Руководитель должен был грамотно выбирать помощников на планёрках и
верно оценивать действия каждого участника игры. Если в процессе игры он
сохранял баланс между общими картами и картами из колоды руководителя, это
относится к плюсам. Если пренебрегал одной из колод, когда в ней была
необходимость – к минусам.
Действия работников и исследователя оцениваются положительно, если он
не совершал рискованных действий в условиях неопределенности и участвовал в
жизни команды, приобретая для других игроков карты ресурсов, но лишь тогда,
когда эти действия были безопасны или в положительном ключе определяли
судьбу проекта. Грамотная оценка других участников игры, убедительность на
планёрках, становление в процессе игры помощником руководителя также могут
быть отнесены к плюсам.
Хапуга и засланец имеют доступ к общей колоде карт наравне с остальными
игроками. Отринув вредительские порывы и собственную жадность, они могут
работать на благо проекта наравне с остальными игроками. Кроме того, они могут
раскрыть себя и добровольно выйти из игры, что приведёт к формальному
поражению. Задача игрока – сделать сложный выбор, поставив интересы команды
превыше собственных, принять неочевидное решение, шагнуть в сторону с
накатанных рельс.

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

1. Кто готовит план управления проектом?

A. Руководитель проекта и члены проектной команды

B. Спонсор проекта
C. Заказчик
D. Управляющий комитет

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

заинтересованных сторон?

А. Планирования коммуникаций
В. Составления устава проекта
С. Распространения информации
D. Реализации проекта

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

имели сертификаты профессионала по управлению проектами, является
примером

A. Допущения
B. Ограничения
C. Исключения
D. Выравнивания ресурсов

4. Может ли проект быть закрыт в конце фазы?

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

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

5. Какая ситуация самая неблагоприятная с точки зрения руководителя

проекта?

A. У проекта есть два спонсора – со стороны заказчика и со стороны

исполнителя проекта
B. Спонсор и заказчик проекта работают в одной компании
C. У проекта отсутствует спонсор, или спонсор не заинтересован в
успешности
D. Заказчик проекта коллективный (например, совет директоров)

6. В чём заключается основная задача руководителя проекта при выполнении

плана проекта?

A. В личном выполнении наиболее ответственных и сложных проектных

задач
B. В разработке плана управления проектом

74
 C. В невмешательстве в работу команды
D. В координации действий команды для выполнения плана проекта

7. Кто принимает решения по принятию изменений базового плана проекта?

A. Спонсор проекта
B. Руководитель проекта
C. Управляющий комитет (или заказчик проекта по согласованию со
спонсором)
D. Руководитель проекта или пользователи продукта проекта

8. Кто должен получить план управления проектом?

A. Все участники проекта, но с разной степенью детализации

B. Все участники проекта должны получить один и тот же документ
(одинаковая степень детализации)
C. Заказчик и спонсор проекта
D. Все, кроме заказчика и спонсора проекта

9. Руководитель проекта ведет крупный проект по разработке программного

обеспечения. Критически важным фактором для этого проекта является
стоимость его реализации. Руководителю проекта следует:

A. Положиться на вышестоящее руководство в определении бюджета

обеспечения качества
B. Выставить счет заказчику за все меры по улучшению качества
C. Реализовать наиболее возможное качество независимо от затрат
D. Реализовывать меры по улучшению качества до тех пор, пока выгоды
будут перевешивать затраты

10. Что можно сказать об интенсивности процессов каждой группы процессов

проекта?

A. Интенсивность каждой группы процессов одинакова на протяжении

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

11. Что является основным недостатком функциональной структуры

организации?

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

B. Двойное подчинение (руководителю проекта и функциональному
руководителю)
C. Отсутствие руководителя проектов
D. У функциональной структуры нет недостатков

75
12. Каким образом можно сформулировать правило Парето для управления
качеством?

A. Большая часть проблем вызывается относительно небольшим

процентом причин
B. Самые сложные проблемы вызываются одной или двумя причинами
C. Проблемы можно решить, только устранив все причины
D. Проблемы можно решить в случае устранения одной, самой сильно
влияющей причины

13. Какова основная цель устава проекта согласно стандарту PMBOK?

A. Проведение технико-экономического обоснования проекта

B. Формальный старт проекта и назначение руководителя проекта
C. Подготовка контракта по проекту
D. Определение даты завершения и бюджета проекта

14. Как связаны процессы управления проектом и фазы жизненного цикла

проекта?

A. В каждой фазе жизненного цикла проекта должны действовать

процессы управления из каждой группы процессов управления
проектом
B. Процессы управления проектом и фазы проекта – это синонимы
C. Процессы управления проектом и фазы проекта никак не связаны
D. Для первой фазы проекта выполняются только процессы инициации, а
для последней – только процессы завершения

15. Выдвигают ли заинтересованные стороны (кроме заказчика) требования к

проекту?

A. Да, но только спонсор проекта

B. Да, это бывает всегда
C. Нет, не выдвигают
D. Да, это возможно

16. План управления рисками включает:

A. Подходы, инструменты и источники данных, которые могут

использоваться при управлении рисками в проекте
B. Изначально установленные риски
C. Идентифицированные риски и планы реагирования на них
D. Процедуры управления рисками в конкретном проекте и заполненный
реестр рисков

17. Какая из следующих стратегий разрешения конфликта даст самый

неблагоприятный результат?

A. Избегание
B. Принуждение
C. Компромисс
76
 D. Сотрудничество

18. Что из следующего неверно в отношении параллельного выполнения задач,

которые обычно должны выполняться последовательно?

A. Оно повышает риск

B. Оно снижает продолжительность проекта
C. Оно называется быстрым проходом
D. Оно называется сжатием

19. Во время совещания по статусу проекта все участники разговаривают

одновременно, обсуждаются все вопросы подряд. Какое правило
проведения эффективных совещаний не было соблюдено?

A. Обозначить цель совещания

B. Определить вопросы для обсуждения и разослать повестку
C. Не составлен протокол встречи
D. Получить подтверждение от участников о возможности присутствия

20. На ком лежит ответственность за качество проекта?

A. На спонсоре
B. На заказчике
C. На руководителе проекта
D. На проектной команде

21. Осуществляется проект по изготовлению электронных устройств.

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

A. Контракт с фиксированной ценой

B. Контракт «Время и материалы»
C. Контракт с возмещением затрат
D. Контракт с вознаграждением

22. Команда проекта рассматривает вопрос о покупке услуги или

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

A. Цена поставщика
B. Процедура подписания договора у поставщика
C. Стоимость и наличие производственных площадей в своих помещениях
D. Технический персонал поставщика

23. Кто определяет требования к качеству проекта?

A. Заказчик

77
 B. Спонсор
C. Руководитель проекта
D. Любой из перечисленных

24. Что не должно быть включено в план управления закупками?

A. Договоренности, на которых будут строиться отношения с подрядчиками

B. Типы контрактов, которые будут использованы
C. Реквизиты потенциальных поставщиков
D. Способы организации отчетности поставщиков

25. Пример какого типа отчета об исполнении Вам представлен?

A. Отчет о качестве
B. Анализ отклонений
C. Анализ трендов
D. Диаграмма Парето

26. Чего не должен делать опытный руководитель проекта в разговоре?

A. Поддерживать точку зрения собеседника

B. Поддерживать визуальный контакт, проявлять невербальную реакцию
C. Задавать уточняющие вопросы
D. Говорить громче, если его не понимают

27. Какой из типов контрактов обычно более рискованный для покупателя?

A. Фиксированная цена с вознаграждением за результат

B. Время и материалы
C. Контракт с возмещением затрат
D. Фиксированная цена

28. К какому методу реагирования относится решение руководителя проекта

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

A. Уклонение
B. Снижение
C. Передача
D. Принятие

29. Руководитель проекта проводит первое собрание по обсуждению рисков

78
 проекта. Результатом собрания являются:

A. Перечень потенциальных рисков

B. Ожидаемые последствия наступления рисков
C. Стратегии реагирования на риски
D. Качественный анализ рисков

30. Фаза разработки проекта по созданию нового программного продукта почти

завершена. Следующие фазы – тестирование и внедрение. Проект на 2
недели опережает график. На чем должен сконцентрировать свои усилия
менеджер проекта перед переходом к следующей фазе?

A. На подтверждении содержания
B. На контроле качества
C. На отчете о выполнении работ
D. На контроле стоимости

31. Процесс подтверждения содержания – это:

A. Утверждение документа, описывающего содержание проекта

B. Формальное принятие участником проекта результата проекта
(промежуточного или окончательного)
C. Утверждение ИСР
D. Ни одно из перечисленного

32. Ваш проект выходит за рамки установленного времени. Чтобы уложиться в

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

A. Сжатия
B. Быстрого прохода
C. Распределения ресурсов
D. Корректировки календаря ресурсов

33. Что показывает матрица распределения ролей и ответственности?

A. Подчинённость людей в проектной команде

B. Действия участников проекта по отношению к различным
результатам проекта
C. Численный состав проекта для каждой роли
D. Состав и функции управляющего комитета проекта

34. На встрече команды проекта один из членов команды предложил провести

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

A. Процесса внесения изменений в содержание проекта

B. Контроля содержания
C. Анализа качества работ

79
 D. Декомпозиции работ

35. Руководитель проекта идентифицировал риск, который может произойти в

проекте на самой последней стадии проекта, которая состоится через год.
Когда нужно создавать планы реагирования
на риск?
A. Сразу после идентификации
B. В соответствии с методом бегущей волны – за 1-2 месяца
до наступления риска
C. После прояснения всех обстоятельств
D. Если риск не критичен, то сразу после его возникновения

36. Какой из перечисленных рисков чаще всего несёт покупатель в случае

заключения контракта с фиксированной ценой?
A. Длительное согласование условий контракта
B. Увеличение стоимости контракта
C. Невозможность мотивировать поставщика
D. Невыполнение условий контракта

37. Какой тип оценки из перечисленных ниже можно использовать сразу после
инициации проекта?
A. Оценка каждого из элементов WBS
B. Оценка «снизу-вверх»
C. Оценка каждой выполняемой операции
D. Оценка по аналогу

38. В проекте по модернизации оборудования необходимо заменить все

принтеры компании на более современные. В середине проекта часть
рабочих, меняющих оборудование, была заменена другими, той же
квалификации и не требующих обучения.
Изменится ли содержание проекта?
A. Нет, поскольку работы не изменились
B. Нет, поскольку не было изменения целей проекта
C. Да, поскольку теперь работают другие люди
D. Да, поскольку любое изменение ведёт к изменению содержания проекта

39. Вы пристраиваете комнату к своему дому. Вы договариваетесь с

генподрядчиком о дате завершения. Он считает, что в лучшем случае для
завершения необходимо 7 недель, в худшем–17 недель. Наиболее вероятная
оценка – 9 недель. С помощью метода PERT выполните оценку ожидаемого
времени завершения.
A. 9 недель
B. 10 недель
C. 11 недель
D. 12 недель
80
40. В чём заключается стратегия принятия для негативных рисков?
A. Создание временных, денежных и ресурсных резервов
B. Игнорирование рисков, поскольку они не могут существенно
повлиять на проект
C. Понижение вероятности возникновения риска
D. Разработка планов избегания риска или смягчения его последствий

41. Что из следующего является неприемлемым методом сокращения

расписания?
A. Отзыв ресурсов с тех задач, которые имеют временной резерв,
и приложение их к задачам на критическом пути
B. Сжатие
C. Быстрый проход
D. Снижение качества продукта без согласования с заказчиком

42. Ваш проект выходит за рамки установленного времени. Вы проверяете

график проекта и видите, что операции, которые должны начаться
последовательно, можно начать одновременно. Это пример
A. Сжатия
B. Быстрого прохода
C. Распределения ресурсов
D. Корректировки календаря ресурсов

43. Как часто проводится оценка бюджета проекта?

A. Один раз в каждой фазе проекта
B. Однократно в ходе проекта
C. Несколько раз по ходу проекта
D. Один раз до начала проекта

44. Что можно сказать о показателях проекта, если CPI >1, SV<0?
A. Экономия бюджета и отставание от графика
B. Экономия бюджета и опережение графика
C. Перерасход бюджета и опережение графика
D. Перерасход бюджета и отставание от графика

45. Идёт проект по внедрению информационной системы.

Может ли утверждённый бюджет пересматриваться в ходе проекта
в сторону уменьшения?
A. Может в случае сокращения требований заказчика
B. Может по решению руководителя проекта
C. Может по решению пользователей продукта проекта
D. Не может

46. Основная причина конфликтов в проекте – это:

A. Сроки проекта
B. Стоимость проекта

81
 C. Личные мотивы
D. Административные процедуры

47. На что из перечисленного ниже в первую очередь должна быть направлена

мотивация во внешнем проекте?

A. На своевременное закрытие этапов проекта

B. На лучший индивидуальный результат
C. На командную работу
D. На экономию бюджета проекта

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

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

A. К функциональному руководителю
B. К заинтересованным лицам проекта
C. К заказчику проекта
D. К администратору проекта

49. Член команды проекта не справляется с поставленным заданием, так как он

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

A. Стимулировать его материально

B. Сделать выговор
C. Отправить его на обучающие курсы
D. Использовать часть резерва проекта

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

бюджета проекта на 3%?

A. Да, если другие ограничения проекта (содержание, качество, сроки)

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

82
РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА И РЕСУРСЫ СЕТИ
ИНТЕРНЕТ

1. Терминология управления проектами [Электронный ресурс] // Режим

доступа: [Link]
2. Методы управления проектами [Электронный ресурс] // Режим
доступа: [Link]
3. Управление проектами [Электронный ресурс] // Режим доступа:
[Link]
4. Творческая работа на тему Объекты и процессы исследования в
управлении проектами [Электронный ресурс] // Режим доступа:
[Link]
ектами html.
5. Тенгиз Курпава. Информационные технологии и управление
проектами. [Электронный ресурс] // Режим доступа:
[Link]
6. Оценка денежных характеристик проекта. [Электронный ресурс] //
Режим доступа: [Link]
7. Управление финансами предприятий. [Электронный ресурс] // Режим
доступа: [Link]
8. Группы процессов управления проектами. [Электронный ресурс] //
Режим доступа: [Link]
[Link].
9. Стандарты управления проектами. [Электронный ресурс] // Режим
доступа: [Link]
10. Project management institute. [Электронный ресурс] // Режим доступа:
[Link] (дата обращения 04.11.2016).
11. Стандарты управления проектами. [Электронный ресурс] // Режим
доступа:
[Link]
12. Каскадная модель. [Электронный ресурс] // Режим доступа:
[Link]
13. Области знания по управлению проектами. [Электронный ресурс] //
Режим доступа: [Link]
14. Структура управления проектами. [Электронный ресурс] // Режим
доступа: [Link]
15. ТОП-4 Методологии управления проектами. [Электронный ресурс] //
Режим доступа: [Link]
upravleniya-proektami/.
16. Топ-7 методов управления проектами: Agile, Scrum, Kanban,
PRINCE2 и другие. [Электронный ресурс] // Режим доступа:
[Link]
proektami-agile-scrum-kanban-prince2-i-drugie/.
17. RAD программирование. [Электронный ресурс] // Режим доступа:
[Link]
18. Документация проекта. [Электронный ресурс] // Режим доступа:
[Link]
19. Лекция 5. Управление рисками проекта. [Электронный ресурс] //
Режим доступа: [Link]

83
 20. Риски проекта. [Электронный ресурс] // Режим доступа: [Link]
[Link]/data/ip/[Link].
21. Теория планирования ресурсов в Microsoft Project. [Электронный
ресурс] // Режим доступа:
[Link]
22. Time Line (Time Line Solutions). [Электронный ресурс] // Режим
доступа: [Link]
23. Primavera (Primavera Systems, Inc.) [Электронный ресурс] // Режим
доступа: [Link]
24. Обзор систем управления проектами. [Электронный ресурс] // Режим
доступа: [Link]
25. Управление проектами - выбор, внедрение и использование ПО в
России [Электронный ресурс]. Режим доступа:
[Link]
26. Хенрик Книберг Scrum и XP: заметки с передовой

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

КАФЕДРА ВЫЧИСЛИТЕЛЬНОЙ ТЕХНИКИ

Кафедра была создана в 1937 году и является одной из старейших и
авторитетнейших научно-педагогических школ России. Первым заведующим
кафедрой был профессор М.Ф. Маликов.
Первоначально кафедра называлась кафедрой счетно-решающих и математических
приборов и занималась разработкой электромеханических вычислительных
устройств и приборов управления. На кафедре развивалось два направления
вычислительной техники: машины непрерывного действия (приборы управления)
и машины дискретного действия (счетные или, как они тогда назывались, счетно-
аналитические).
В сентябре 1937 года при кафедре была создана лаборатория. Ее первым
заведующим был К.Г. Кроль (впоследствии – доцент кафедры). К осени 1939 года
кафедра стала одной из ведущих в институте. Для чтения отдельных разделов
курсов и руководства дипломными проектами привлекались ведущие специалисты
промышленности. Все курсы были обеспечены преподавателями, велись
лекционные и лабораторные занятия, выполнялись курсовые и дипломные
проекты. В эти годы кафедра ежегодно выпускала около 20 инженеров.
C 1944 года кафедрой заведовал профессор С.А. Изенбек. В послевоенный период
на кафедре были развернуты исследования принципов построения
электромеханических вычислительных устройств. На их основе были разработаны
тренажеры, приборы для автоматизации прочностных расчетов и обработки
результатов ходовых испытаний кораблей.
В 1950-х годах на кафедре функционировали три учебно-исследовательские
лаборатории: электромеханических и счетно-решающих устройств, счетных и
счетно-аналитических машин, приборов управления. В них исследовались счетно-
решающие устройства на потенциометрах, приборы для автоматизации расчетов и
электронные счетные устройства.
Эксперименты по применению электронных машин для выполнения операций над
числами, проводимые доцентом Ф.Я. Галкиным и инженером М.Н.Романовым,
позволили разработать проект электронной вычислительной машины для
инженерных расчетов. Он был поддержан руководителем проблемной оптической
лаборатории института профессором М.М. Русиновым.
В 1956 году началось изготовление ЭВМ. Создание электронно-вычислительных
машин собственной разработки началось в ЛИТМО, когда ЭВМ, такие как «Урал",
еще только создавались. В 1962-1964 годах была создана ЭВМ «ЛИТМО-2" на
ферриттранзисторных модулях.

85
В 1962 году заведующим кафедрой был избран профессор С.А. Майоров, и в 1963
году кафедра была переименована в кафедру вычислительной техники.
С начала 60-х годов на кафедре развернулись работы по методам проектирования
ЭВМ: имитационному моделированию цифровых устройств (Новиков Геннадий
Иванович), анализу и синтезу переключательных схем (Немолочнов Олег
Фомич), тестированию и диагностике схем (Гольдман Р.С., Немолочнов О.Ф.),
машинному анализу электронных схем (Ермолаенков Э.Г.), монтажно-
коммутационному проектированию (Шипилов П.А.). Автоматизация
проектирования ЭВМ стала основным научным направление кафедры.
Кафедра вычислительной техники является одной из крупнейших в университете,
на которой работают высококвалифицированные специалисты, в том числе 8
профессоров и 15 доцентов, обучающие около 500 студентов и 30 аспирантов.
Кафедра имеет 4 компьютерных класса, объединяющих более 70 компьютеров в
локальную вычислительную сеть кафедры и обеспечивающих доступ студентов ко
всем информационным ресурсам кафедры и выход в Интернет. Кроме того, на
кафедре имеются учебные и научно-исследовательские лаборатории по
вычислительной технике, в которых работают студенты кафедры.
На кафедре сформировалась и действует научно-педагогическая школа
«Организация вычислительных систем и сетей".
В настоящее время кафедрой заведует доктор технических наук, профессор
Алиев Тауфик Измайлович.

86
 Маркина Татьяна Анатольевна

Управление проектами в информационных

технологиях
Учебное пособие

В авторской редакции
Редакционно-издательский отдел Университета ИТМО
Зав. РИО Н.Ф. Гусарова
Подписано к печати 26.12.2016
Заказ № 3810
Тираж 30
Отпечатано на ризографе
Редакционно-издательский отдел
Университета ИТМО
197101, Санкт-Петербург, Кронверкский пр., 49