Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Технологии проектной деятельности в контексте «третьей миссии» университетов. Учебное пособие
.pdf
21
Системный подход определяет основные характеристики. Проекты
могут быть разнообразными, многоплановыми. Однако они имеют специфические характеристики:
– разовость;
– уникальность;
– результативность;
– инновационность.
В свою очередь, системный подход позволяет спланировать и реализовать проект, исходя из трех главных вопросов:
– сколько времени это займет;
– во сколько это обойдется;
– совпадет ли конечный результат с ранее намеченным.
Разложить сложную задачу на ряд простых, но взаимосвязанных задач, представить её в виде иерархической структуры можно с помощью
метода декомпозиции (рис. 2.3).
Рис. 2.3. Схема применения метода декомпозиции
Подготовка к проектной деятельности осуществляется по существующему (разработанному) и утвержденному плану проектирования.
Выходящими параметрами являются: определение цели проекта, типологические признаки проекта, разработка бюджета и оценка качества
проекта, факторы проектной деятельности, основные требования к использованию метода проектов.
Проект
1-я часть проекта
2-я часть проекта
N-я часть проекта
…
Характеристики
работ
Технологический
комплекс работ 1
Технологический
комплекс работ 2
Технологический
комплекс работ N
…
Укрупненные
виды работ 1
Укрупненные
виды работ 2
Укрупненные
виды работ N
…
Детальная
работа 1
Детальная
работа 2
Детальная
работа N
…
Единичная
работа 1
Единичная
работа 2
Единичная
работа N
…
22
3. ЦЕЛЕПОЛАГАНИЕ И ПЛАНИРОВАНИЕ ПРОЕКТА
Определившись с проблематикой проекта и получив понимание
того, какой продуктовый (образовательный) результат команда проекта
хочет получить, необходимо конвертировать это понимание в программу
конкретных действий: какие задачи должна решать команда, какими ресурсами эти задачи должны быть обеспечены и т. д. Цель проекта – это
конечный результат, эффект деятельности, на достижение которого
направлен результат. Цель необходимо сформулировать так, чтобы все
участники команды ее понимали и разделяли. В этой связи самым оптимальным способом является использование критериев SMART:
S – specific (цель должна быть конкретной);
M – measurable (цель должна быть измеримой);
A – achievable (цель должна быть достижимой);
R – relevant/realistic (цель должна быть реалистичной);
T – time-bound (цель должна быть ограничена временными рамками).
Критерии SMART могут применяться прямым способом (проверка
уже сформулированной цели на предмет соответствия критериям);
обратный способ (цель формулируется из множества вариантов так,
чтобы соответствовать критериям).
Правильное целеполагание проекта способствует более легкому
прохождению всех остальных этапов рамки проектной деятельности,
в том числе в части выполнения требований, предъявляемых к проектам:
1. Проектирование от проблемы / значимости / востребованно-
сти / актуальности: наличие проблемы, которую решает проект, соот-
ветствие существующим вызовам (например, наличие заказа на результат
проекта от пользователя и/или заказчика, в том числе потенциального).
2. Реализация полного жизненного цикла проекта: от замысла
до эксплуатации и утилизации (для инновационного проекта), от гипотезы до употребления полученного знания (для исследовательского проекта). Участники проекта должны реализовать весь цикл или хотя бы видеть его целиком, если упор делается на какой-то стадии.
3. Оригинальность решения: поиск уникальности данного проекта.
Ответ на вопрос: почему эта работа является новым проектом, а не повторением пройденного по алгоритму. Объяснение, что новое порождается проектом (новое знание, продукт и т.п.).
23
4. Включенность в профессиональное сообщество: уровень полу-
чаемого результата проекта должен соответствовать реальным требованиям со стороны профессионального сообщества. Важно, что требования профессионального сообщества учитываются как на этапе реализации проектов, так и на этапе оценки результата.
5. Требования к процессу достижения результата проектов:
– самостоятельность: насколько команда самостоятельна в реализации проекта от задумки до эксплуатации, прежде всего в принятии
решений;
– учет ограниченности ресурсов: временных, финансовых и др.;
– осознанность в выборе организационных решений: индивидуальность / командность, распределение ролей, выявление вызовов, трудностей и путей их преодоления.
Помимо понимания цели и задач, которые должны быть выполнены
в проекте, важно учитывать необходимые для этого ресурсы или, другими словами, принимать во внимание проектные ограничения, которые
могут влиять на решения, принимаемые в рамках процессов проектного
менеджмента.
Ресурсы (и ограничения) бывают двух видов:
1. Материальные:
– активы (не расходуются в процессе);
– расходные материалы;
– финансы.
2. Нематериальные:
– навыки;
– время;
– дозволения/доступы;
– репутация;
– связи.
Наличие или отсутствие ресурсов у команды проекта влияет на множество параметров проекта. Например, на его длительность или предполагаемые сроки начала или завершения, допустимый уровень риска и потенциальных социальных, экологических, технологических и других
последствий проекта.
24
4. ПОДХОДЫ И СТАНДАРТЫ УПРАВЛЕНИЯ ПРОЕКТАМИ
Методологией в управлении проектами называется стандартизация
проведения проектов. Другими словами, это описание этапов работы,
требований к ее проверке и другого, т.е. некая рамка проекта. Все многообразие существующих на сегодняшний день методов можно условно
разделить на два блока в зависимости от того, какого подхода к управлению проектами придерживается команда и ее руководитель:
1. Классические.
2. Гибкие.
4.1. Классический проектный подход
Классический подход заключается в последовательной реализации
всех этапов проекта (от этапа планирования и разработки до тестирования и получения продуктового результата). Как правило, при таком подходе используется вертикальный стиль управления: имеется руководитель проекта, он управляет командой и ресурсами, отчитывается перед
вышестоящей инстанцией или заказчиком / спонсором проекта. В самом
начале руководителем проекта составляется его план, далее он согласовывается с вышестоящим органом / заказчиком / спонсором, идет работа
над проектом, а в самом конце – продуктовый результат передается заказчику. Классический проектный подход предполагает линейность
структуры и ориентирован на проекты, в которых есть строгие ограничения по последовательности выполнения задач. Как правило, жизнен-
ный цикл проекта в рамках классического подхода выглядит следующим образом:
Этап 1. Инициация запуска проекта. Руководитель проекта и ко-
манда определяют требования к проекту и его результату исходя из поставленного заказчиками ТЗ. Здесь эффективны различного рода общекомандные совещания и мозговые штурмы, в ходе которых формулируется конечный образ продуктового результата проекта.
Этап 2. Планирование. Уточнение целей и результатов проекта,
детерминация путей достижения цели, разбивка проекта на этапы, составление плана работ, формирование бюджета, выявление возможных
рисков и стейкхолдеров и др.
Этап 3. Разработка и реализация. Непосредственная работа по до-
стижению продуктового результата.
25
Этап 4. Завершение проекта. Рефлексия. Получив некий продуктовый результат, команда проекта либо передает его заказчику, либо продолжает его доработку и/ или ведение. Данный цикл весьма условен
и сильно зависит от вида проекта. Может возникать ситуация, когда каждый из этапов проекта будет восприниматься командой как отдельный
подпроект («итеративный водопад») и тогда внутри каждого подпроекта
будут выделены свои собственные этапы с соответствующими задачами
(итерации). Однако сам концепт разбиения проекта на последовательность этапов остается неизменным.
Для облегчения работы с проектами в рамках классического подхода существует целый ряд методов / инструментов, самыми популярными из которых является диаграмма Гантта и цикл Деминга – Шухарта.
Диаграмма Гантта, метод, более известный сейчас как инструмент
«Диаграмма Гантта», был изобретен в начале XX века американским инженером и бизнес-консультантом Генри Л. Ганттом (Genry L. Gantt) (рис. 4.1).
Г. Ганттом было разработано большое количество диаграмм, но суть
их всех сводилась к тому, что руководитель проекта имеет графическое
отображение работы над проектом в виде гистограмм, которые иллюстрируют план, расписание, график всех работ (задач) по проекту, основываясь на датах их начала и завершения. В диаграмму вносятся задачи,
их длительности, взаимосвязи и взаимозависимости друг от друга, а затем высчитывается критический путь – самая длинная цепочка взаимо-
связанных задач, определяющих длительность проекта в целом.
Рис. 4.1. Пример диаграммы Гантта
26
Как правило, вертикальная ось представляет собой каждую задачу,
а горизонтальная – шкалу времени. Кроме того, на диаграмме могут быть
отмечены комплексные задачи, проценты прогресса каждой, указатели
последовательности и зависимости задач и др.
Помимо очевидных преимуществ, диаграммы Гантта имеют ряд недостатков, связанных, прежде всего, с ограниченной гибкостью их функционала. Ввиду динамичности большинства проектов и большой доли
вероятности внесения изменений в проект и, как следствие, перечень задач, диаграмма Гантта подлежит «перерисовке» каждый раз при внесении корректировок. Кроме того, диаграмма не может проиллюстрировать несколько возможностей планирования в одном графике. Диаграмма также слабо отражает ресурсоемкость задач и степень их значимости для проекта, что снижает степень ее наглядности для крупных
проектов.
Цикл Деминга – Шухарта – это модель для структурирования
и упорядочивания процесса постоянных улучшений (преимущественно
в производственных процессах). Альтернативное название – цикл
PDCA – планируй (plan), выполняй (do), проверяй (check) (в альтернативной версии – изучай (study)), действуй (act). Цикл можно применить
как к процессу (проекту) в целом, так и к отдельным видам деятельности,
входящим в состав процесса (рис. 4.2).
Рис. 4.2. Цикл Деминга – Шухарта
Планируй
Выполняй
Действуй
Проверяй
27
Достоинство и недостатки классического проектного подхода:
Сильные стороны
Слабые стороны
– и проектная команда, и заказчик
с самого начала имеют представление
о желаемых результатах проекта;
– постоянный мониторинг прогресса
работы над проектом;
– понимание сроков реализации проекта
с самого начала;
– понимание объема ресурсов,
требующихся для реализации проекта
– низкая способность приспосабливаться
к изменениям (как внутренним,
так и внешним);
– зависимость каждого последующего
этапа от предыдущего увеличивает
«стоимость» ошибки и время работы
над проектом, если возникнет
необходимость внести поправки
в предшествовавшие этапы;
– сложно реализовывать при отсутствии
четко сформулированного технического
задания к продукту / решению
4.2. Гибкий проектный подход
Данный подход представляет собой семейство гибких итеративноинкрементальных методов к управлению проектами, когда они разбиваются не на последовательные фазы, а на мини-проекты, которые затем
«собираются» в готовый продукт / решение. Таким образом, инициация
запуска и базовое планирование проводятся для всего проекта, а все его
последующие этапы от разработки и тестирования до завершения работы
и рефлексии проводятся для каждого мини-проекта отдельно. Это позволяет, с одной стороны, быстрее передавать результаты этих мини-проектов (инкременты), а с другой, если в одном из мини-проектов (итерации)
возникает необходимость внести изменения, то это можно сделать
без больших затрат, одновременно минимизировав негативное влияние
на остальные части проекта.
SCRUM-метод. В 1986 году в Harvard Business Review была опуб-
ликована статья американо-японских исследователей Икуджиро Нонака
(Ikujiro Nonaka) и Хиротака Такеучи (Hirotaka Takeuchi) «New New
Product Development Game», в которой 8иллюстрировались временные
и информационные потери при традиционной на то время последовательной передаче продукта от проектировщика разработчику, от разработчика тестировщику и т. д. Авторы статьи рекомендовали специалистам последующих стадий включаться в работу раньше, даже если продукт
еще не полностью разработан, чтобы сэкономить время на создание продукта. По сути, предлагалась кросс-функциональная команда (по аналогии с правилами игры в рэгби), а не линейная (по аналогии с эстафетной
28
командой). Эта статья во многом обусловила появление одной из основных
и самых популярных к настоящему моменту разновидностей agile –
SCRUM.
SCRUM базируется на самоорганизации небольшой команды,
содержит короткие итерации разработки (спринты), по результатам каждого спринта заказчик получает работоспособную и улучшенную версию продукта.
Достоинство и недостатки гибкого проектного подхода:
Сильные стороны
Слабые стороны
– можно быстро получить рабочую версию
продукта за счет итераций / спринтов;
– минимизация рисков за счет короткой
продолжительности рабочих циклов
(итераций);
– при отсутствии у заказчика точного
«образа» конечного продуктового
результата позволяет предложить
ему несколько альтернативных версий
продукта / решения
– невозможность точно предсказать
окончательный продуктовый результат
проекта, а также его стоимость;
– риск внесения бесконечных изменений
в продукт / решение;
– высокая зависимость от уровня
квалификации и опыта проектной
команды
В большинстве случаев в любой организации есть часть проектов,
для которых больше подойдет классический подход, в то время как для
остальных – гибкий. Часто можно увидеть, что для реализации проектов
используется микс из этих двух подходов (гибкий водопад), когда часть
проектной команды в рамках своих мини-проектов работает, например,
с использованием планирования диаграммы Гантта, а вся команда в рамках каждого спринта тестирует решения по циклу Деминга – Шухарта.
4.3. Сетевой график
Существуют два вида сетевых графиков: традиционный и график
PERT. Традиционный график, представленный на рис. 4.3, построен
по принципу события-работы, график PERT (Program Evaluation
and Review Technique – метод оценки и пересмотра плана) – по типу
работы-связи (рис. 4.4).
Рис. 4.3. Пример традиционного сетевого графика
8
6
3
4
с
1
2
5
7
9
29
Проект
Внедрение
Менеджер
Куратор
Контрольная дата
Версия
Длительность проекта (календарные дни)
- критические работы, влияющие на длительность проекта
Рис. 4.4. Пример сетевого графика PERT
В современной практике чаще используется именно сетевой график
«работы-связи», потому что он гораздо удобнее, так как может отображать и работы, и события, и, кроме того, именно по этому принципу работает и компьютерная программа Microsoft Project, самая популярная
в повседневной практике проект-менеджмента.
Основные правила сетевого графика:
1) после завершения предшествующей работы можно приступать
к выполнению последующей, к которой идут стрелки (см. рис. 4.3);
2) начать работу можно, только завершив все предыдущие работы,
от которых стрелки ведут к искомой работе (см. рис. 4.4).
Для понимания смысла сетевого планирования необходимо также
дать определение ключевым понятиям сетевого графика.
Критический путь проекта – это последовательность работ проекта, которая требует больше всего времени для завершения, т. е. это
самая длительная цепочка работ. Все работы, лежащие на этом пути,
называются критическими задачами, и незапланированное удлинение
любой из них приведет к удлинению всего проекта. Очевидно, что
именно длина критического пути будет определять срок выполнения
всего проекта. Понятие критического пути позволяет проводить планирование как от даты начала проекта, так и от фиксированной даты
окончания, что весьма удобно для проект-менеджера. Тогда в первом
случае необходимо определить дату окончания, а во втором – начала
работ. Критический путь определяется вычислением раннего и позднего старта (Early Start, Late Start) и финиша (Early Finish, Late Finish)
для каждой из работ.
Разработка
стандартов
30
Некритический путь проекта – последовательность работ, которую можно выполнить с некоторой задержкой, не приводящей к увеличению длительности проекта. Это происходит в силу того, что некритический путь по определению короче критического и поэтому содержит
некий резерв времени, благодаря которому любая задача, лежащая на некритическом пути, имеет некий временной люфт и может передвигаться
по оси времени. Таким образом, резерв времени – максимальное время,
на которое можно сдвигать задачу, лежащую на некритическом пути,
без увеличения сроков проекта.
Из-за возможности передвижения некритических задач по оси времени возникает возможность определить точные сроки самого раннего
начала – окончания и самого позднего начала – окончания работ.
Для определения длины критического пути и установления сроков
раннего начала – окончания проекта предпринимается прямой анализ сетевого графика, для установления поздних сроков начала – окончания
и, соответственно, величины резервов времени – обратный анализ.
Разумеется, на практике используются и более сложные зависимости и связи. Конкретный график зависит от многих причин: от сложности
последовательностей и связей, от задач, которые стоят перед проект-менеджером, от типа программного обеспечения проекта и т. д. (рис. 4.5).
а)
б)
в)
г)
д)
Рис. 4.5. Типы взаимосвязей работ:
а – финиш – старт (операция В не может начаться до завершения операции А);
б – старт – старт (операция В начинается не раньше операции А);
в – финиш – финиш (операция В должна окончиться не раньше окончания операции А);
г – старт – финиш (операция В не может окончиться (должна продолжаться),
пока не начнется операция А); д – гамак
А
С
В
А
В
А
В
А
В
А
В
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]