ОСНОВЫ ПРОЕКТНОЙ

ДЕЯТЕЛЬНОСТИ

Максим Феликсович Савельев

savelyevm@mail.ru
 СОСТАВ КУРСА
Теоретический материал : Лекции.
Вид проведения занятия – удаленный . Zoom.

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

задания .
Вид проведения занятий – очный. Аудитория по расписанию.

Техническое обеспечение : Личные РС.

Итог: Дифференцированный зачет (зачет с оценкой).

2
 КАК ПОЛУЧИТЬ ЗАЧЕТ И ПОЛОЖИТЕЛЬНУЮ ОЦЕНКУ

5 лабораторных работ - допуск к получению зачета

+
2 контрольные работы в течении семестра - формирование
базовой оценки.

Иное :

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

3
 FAQ
Я не хочу рано вставать и ходить на лекции! Мне поставят зачет ?

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

Я хочу тройку автоматом , ведь я все равно ее получу ! Можно я не буду ходить на все занятия курса ?

Нет, так как любую оценку надо заслужить! Если Вы пропустили весь курс, мы проверяем Ваше самостоятельное изучение материала
на собеседовании по всему курсу в конце семестра.

Я устроился на работу, поэтому не хожу на практические занятия, но за меня результаты сдает мой напарник (напарница). Так можно
?

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

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

Не более 2х.

4
ПРОЕКТ – ПОНЯТИЙНОЕ ПРОСТРАНСТВО
Проект – определение по ГОСТ Р 54869-2011
Комплекс взаимосвязанных мероприятий, направленный на создание уникального продукта или услуги в
условиях временных и ресурсных ограничений.
Определение проекта по PMBOK
Проект – это временное предприятие, предназначенное для создания уникальных продуктов, услуг или
результатов. Каждый проект приводит к созданию уникального продукта, услуги или результата.
Определение проекта по PRINCE2
Проект – это комплекс взаимосвязанных мероприятий, направленный на создание уникального продукта или
услуги в условиях временных и ресурсных ограничений.

Управление проектами - особый вид управленческой деятельности,

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

(ISO 21500) к проектам не относят типовую, повторяющуюся

деятельность, даже если она приводит к уникальным
результатам 5
ОТЛИЧИТЕЛЬНЫЕ ХАРАКТЕРИСТИКИ ПРОЕКТА
▪ Уникальность, новизна, неповторимость
▪ Четкое формулирование цели (измеримость), конкретные
задачи
▪ Фиксированная длительность (начало и окончание
проекта), последовательность работ
▪ Жесткие требования по времени, затратам и качеству
выполнения работы
▪ Комплексность
▪ Ограниченные ресурсы
▪ Наличие руководителя проекта и команды
▪ Отграничение от остальной деятельности

6
ПРОЕКТ – БАЗОВОЕ ПРЕДСТАВЛЕНИЕ
(акт деятельности)

Знания Цель

Субъект

Результат
Средства

Процесс
Инструменты
Исходный Продукт
материал
ПРОЕКТ: ТРИ КЛЮЧЕВЫЕ СОСТАВЛЯЮЩИЕ
– Приложение знаний, опыта, инструментов и
техники для достижения поставленных целей
(PMI);

коммуникации администрирование – Планирование, организация, отслеживание и

контроль составляющих проекта
(функциональных зон проекта) на
регулярной основе для достижения целей
проекта (ISO 10006);
технологии
– Методология управления проектами (Project
Management Methodology - РРМ) была
одобрена как общемировая в 1995 году;

– РРМ может быть применима для проектов

любой сферы деятельности.

8
МАТРИЧНАЯ СТРУКТУРА УПРАВЛЕНИЯ

9
 ПРОЕКТ: ОФИЦИАЛЬНОЕ НАЧАЛО
Зарождение управления проектами как самостоятельной сферы деятельности относят
к 30-м годам XX века и связывают с разработкой специальных методов координации выполнения крупных проектов в США:
авиационных в US Air Corp. и нефтегазовых в корпорации Exxon.

В 1937 году в США была реализована первая разработка по матричной организации управления для осуществления
сложных проектов в этих корпорациях.

Самостоятельная дисциплина «Управление проектами» появилась в 50-х гг. в странах Западной Европы, США.

В 1956 г. была образована исследовательская группа для разработки методов и средств управления проектами. В нее, в
частности, входили М. Уолкер из фирмы "Дюпон" и Д. Келли из группы планирования капитального строительства фирмы
"Ремингтон Рэнд". Они попытались использовать ЭВМ для составления планов-графиков крупных комплексов работ по
модернизации заводов фирмы "Дюпон". В результате был создан рациональный и простой метод описания проекта с
использованием ЭВМ. Первоначально он был назван методом Уолкера-Келли, а позже получил название Метода
Критического Пути - МКП (или CPM - Critical Path Method).

Параллельно и независимо в военно-морских силах США был создан метод анализа и оценки программ PERT (Program
Evaluation and Review Technique). Данный метод был разработан корпорацией "Локхид" и консалтинговой фирмой "Буз,
Аллен энд Гамильтон" для реализации проекта разработки ракетной системы "Поларис", объединяющего около 3800
основных подрядчиков и состоящего из 60 тыс. операций. Использование метода PERT позволило руководству программы
точно знать, что требуется делать в каждый момент времени и кто именно должен это делать, а также вероятность
своевременного завершения отдельных операций. Руководство программой оказалось настолько успешным, что проект
удалось завершить на два года раньше запланированного срока. 10
ПРОЕКТ: ОФИЦИАЛЬНЫЕ ИНСТИТУЦИИ
• Институт управления проектами PMI (Project Management Institute). Основан
в 1969 году, Объединяет более 475 000 членов, представлен в более чем 200
странах через Отделения (chapters) и специализированные сообщества
(communities of practice). Московское отделение открыто в 1998 году;
• Международная Ассоциация Управления Проектами (Швейцария)
(International Project Management Association, IPMA). Ассоциация основана в 1965
году, объединяет специалистов в области управления проектами и проводит
собственную четырёхступенчатую систему сертификации;
• В России представлена ассоциацией СОВНЕТ;
• Австралийский институт управления проектами (AIPM);
• Японская ассоциация развития инжиниринга (ENAA).

11
ЭТАПЫ РАЗВИТИЯ ПРОЕКТНОГО
УПРАВЛЕНИЯ
▪1945-1960

▪1960-1985

▪1985-2010-е

▪2001-н.в.
 1945-1960
В течение 1940-х гг. линейные руководители (т.е. те, кому непосредственно подчинялся ряд
сотрудников компании) функционировали как проектные менеджеры и использовали понятие
over-the-fence management* для управления проектами.

Линейная организационная структура - каждый

вышестоящий руководитель имеет четко https://managementmania.com/en/linear-
обозначенных подчиненных и каждый подчиненный organizational-structure
имеет ясно определенного руководителя.

*over-the-fence - неразумный, никуда не годный

▪ Метод PERT был разработан корпорацией "Локхид" и
консалтинговой фирмой "Буз, Аллен энд Гамильтон" для
реализации проекта разработки ракетной системы
"Поларис", объединяющего около 3800 основных
подрядчиков и состоящего из 60 тыс. операций.
▪ Использование метода PERT позволило руководству
программы точно знать, что требуется делать в каждый
момент времени и кто именно должен это делать, а также
вероятность своевременного завершения отдельных
операций.
▪ Руководство программой оказалось настолько успешным,
что проект удалось завершить на два года раньше
запланированного срока.
1960-1985

• Отказ от
неформальных
Необходимость принципов
реализации управления
больших и проектами в частных
сложных компаниях
проектов • Формализация
проектных процессов
 Выполнение задач,
которые не могли быть
эффективно выполнены
в рамках традиционной
структуры компании
Применение проектного
управления в 1970-х гг.
Разовое мероприятие с
минимальным
вмешательством в
ежедневную бизнес-
деятельность.
1985-2010
1960-1985 Аэрокосмическая
промышленность, оборона,
строительство

1986-1993 Поставщики
автозапчастей

1994-1999
Телекоммуникации

2000-2003 Информационные
технологии

▪ Внедрение проектного менеджмента 2004-2006 Здравоохранение

в практику стало необходимостью.
Сейчас он распространен
практически во всех отраслях.
▪ Самое интересное, что произошло 2007-2008 Маркетинг и
обратное внедрение: изначально продажи
проектный менеджмент внедрялся в
частных компаниях под давлением
государства, которое, однако,
последним стало применять его в 2009 Правительственные
своих службах службы
 2001-НАСТОЯЩЕЕ ВРЕМЯ
В феврале 2001 года в штате Юта США был выпущен «Манифест
гибкой методологии разработки программного обеспечения» (Agile
Manifesto).
Он являлся альтернативой управляемым документацией
«тяжеловесным» практикам разработки программного обеспечения, таким
как «метод водопада», являвшимся золотым стандартом разработки в то
время.
Данный манифест был одобрен и подписан представителями
методологий: экстремального программирования, Crystal
Clear[en], DSDM, Feature driven development, Scrum, Adaptive software
development[en], Pragmatic Programming.
Гибкая методология разработки использовалась многими
компаниями и до принятия манифеста, однако вхождение Agile-
разработки в массы произошло именно после этого события.
 WATERFALL
Каскадная модель («Водопад») — модель процесса разработки
программного обеспечения, в которой процесс разработки выглядит как
поток, последовательно проходящий фазы анализа требований,
проектирования, реализации, тестирования, интеграции и поддержки
Основные этапы:
▪ Определение требований
▪ Проектирование
▪ Реализация
▪ Тестирование и отладка
▪ Внедрение
▪ Поддержка
 AGILE
Обобщающий термин для целого ряда подходов и практик, основанных на
ценностях Манифеста гибкой разработки программного обеспечения и 12
принципах, лежащих в его основе:

Основные идеи:
▪ Люди и взаимодействие важнее процессов и инструментов;
▪ Работающий продукт важнее исчерпывающей документации;
▪ Сотрудничество с заказчиком важнее согласования условий контракта;
▪ Готовность к изменениям важнее следования первоначальному плану.
 AGILE
Основополагающие принципы Agile Manifesto:
▪ Наивысшим приоритетом признается удовлетворение заказчика за счёт ранней и бесперебойной поставки ценного
программного обеспечения;
▪ Изменение требований приветствуется даже в конце разработки (это может повысить конкурентоспособность полученного
продукта);
▪ Частая поставка работающего программного обеспечения (каждые пару недель или пару месяцев с предпочтением меньшего
периода);
▪ Общение представителей бизнеса с разработчиками должно быть ежедневным на протяжении всего проекта;

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

▪ Работающее программное обеспечение — лучший измеритель прогресса;

▪ Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;

▪ Постоянное внимание к техническому совершенству и хорошему проектированию увеличивают гибкость;

▪ Простота как искусство не делать лишней работы очень важна;

▪ Лучшие требования, архитектура и проектные решения получаются у самоорганизующихся команд;

▪ Команда регулярно обдумывает способы повышения своей эффективности и соответственно корректирует рабочий процесс.