15
которые занимаются управлением проектами. Например, NASA имеет
открытый пул информации по своим проектам и каждый желающий может
ознакомиться с их опытом в космических проектах
Обсуждения с экспертами – это вытекает из анализа окружения и
анализа похожих ситуаций. Этот метод подразумевает обсуждение
возможных ситуаций с людьми, которые имеют опыт и информацию о
похожих проектах. Экспертами могут быть как члены команды проекта, так
и те, кто так или иначе связан с похожими проектами.
Изучение законодательства – стоит изучить законодательство страны
в которой ведется проект на предмет соответствия путей реализации проекта
с установленными законом нормами, так как в любой момент времени может
оказаться, что есть какое-либо несоответствие.
Мозговой штурм – вместе с начальством, командой, коллегами
собраться и разобрать самые разные идеи. На данном этапе любые идеи
могут быть полезны.
- оценка рисков
При анализе\оценке риска используются принципы, предложенные
американским экспертом Бермером:
1. Потери от риска не зависимы друг от друга
2. Потеря по одному направлению из портфеля рисков, не
обязательно увеличивает вероятность потери по-другому.
3. Максимально возможный ущерб не должен превышать
финансовых возможностей участника.
9
Все риски делятся на 2 типа:
- динамический;
- статический;
9
Павлов А.Н. Управление программами проектов на основе стандарта PMI The Standart for Program
management. Изложение методологии и рекомендации по применению / А.Н. Павлов. – М.: БИНОМ.
Лаборатория знаний, 2014. – 304 с.
16
Динамический – это риск непредвиденных изменений, которые
связаны с капиталом проекта, как следствие принятия управленческих
решений или же других условий, которые могут привести, как к потерям, так
и к доходам.
Статический – это риск потерь из-за нанесения ущерба, а также
потерь дохода по причине недееспособности организации или какой-либо ее
части. Такой риск приводит только к потерям.
Также, существует 2 взаимодополняющих вида анализа рисков – это
качественный и количественный.
Качественный анализ может быть сравнительно простым, его главная
задача – определить факторы риска, и при каких этапах и работах он может
возникнуть.
Главная задача количественного анализа - это численное определение
размеров риска, как отдельных, так и для проекта в целом. Все факторы,
которые влияют на риск, тем или иным образом, можно разделить на 2
группы: объективные и субъективные. К субъективным факторам относятся
такие факторы, которые характеризуют конкретное предприятие, такие как,
производственный потенциал, техническое оснащение, организация труда и
другие. Объективные факторы в основном не зависят от деятельности
предприятия, такими факторами являются, например, инфляция,
конкуренция, экономические и политические кризисы. При количественном
анализе используются такие методы как, статистический, аналитический,
метод экспертных оценок, анализ затрат и использование аналогов. В
практике принятия решений, обычно, придерживаются шкалы допустимого
риска, потому как данная шкала отражает вид риска и величину потерь:
- вид риска не значительный, если величина потерь не превышает 5%
- малый риск, 5-10% (величина потерь)
- средний риск – 11-20%
- повышенный риск – 21-30%
- риск азартный – свыше 30%
17
Как правило, большинству рискованных решений соответствует
средняя величина - в пределах 20%. Во многих странах формируются
специальные фонды, для полного покрытия и возмещения рисковых затрат,
которые связаны с разработкой, с внедрением новых технологий и техники.
Фонды создаются в разных сферах хозяйственной и научной деятельности,
кроме того, они каждый имеет свое название - например, Фонд Неурожая и
Бедствия, Технический прогресс и капитальные вложения и т.д. Для
стимулирования дальнейшего развития научно-технического прогресса
существует инновационный фонд, который финансирует научные проекты с
высокой степенью риска. В случае успеха, средства с частью дохода,
возвращаются фонду, а в случае неудачи, финансовые средства не
компенсируются. Культуры разных стран, формируют различные системы
ценностей и существенно влияют на экономическое поведение в условиях
риска. В одних культурах поощряется твердая и однозначная позиция при
принятии решения, в других – склонность к компромиссам. У менеджеров
запада и востока существуют различия в методах реагирования на риски.
Таким образом, если на западе предпочитают индивидуальные решения, то
на востоке больше привыкли к коллективным, если на западе стремятся
управлять внешним миром, то на востоке стремятся соблюдать гармонию с
внешним миром. Если на западе можно увидеть ограничение деловых
отношений конкретными функциями, то на востоке – распространение
деловой атмосферы и социальной жизни. Также на западе, ориентация на
деловые связи в пределах действия контракта, на востоке – учитываются
интересы поколений.
10
- определение стратегии реагирования на риск;
Стратегии реагирования - это методы, которые используются для
снижения последствий или вероятности определенных ранее рисков. Для
каждого отдельного риска нужно разработать или выбрать
стратегию\комбинацию стратегий, которая обеспечит максимально
10
Информационно аналитический журнал «Управление Проектами» - http://www.pmmagazine.ru/
18
эффективную работу с ним. Таким образом, выбор стратегии реагирования
происходит на основании результатов количественных и качественных
оценок рисков, чтобы определить, сколько и каких ресурсов потребуется
затратить для ограничения последствий или предотвращения риска.
11
Существует четыре типовые стратегии реагирования на появление
негативных рисков: уклонение, передача, принятие и снижение:
- Уклонение от риска. Эта стратегия состоит в полном исключении
воздействия риска на проект за счет изменений характера проекта или плана
управления проектом. Большинство рисков, возникающих на ранних стадиях
проекта, например, из-за отсутствия четких требований заказчика, возможно
избежать, если уделить больше времени для их идентификации на стадии
планирования. Однако стратегия уклонения не имеет возможности
полностью исключить риск.
- Передача риска. Такая стратегия подразумевает передачу риска и
ответственность за негативные последствия третьим лицам. В основном, при
передаче риска выплачивается премия за риск стороне, которая принимает
его на себя.
- Принятие риска. Стратегия означает решение команды не
уклоняться от риска. Таким образом, при пассивном принятии риска не
предпринимается никаких действий по его снижению и разрабатывается
план реагирования при его возникновении, который подразумевает
исправление последствий риска или способ обхода риска. При активном
принятии риска, план реагирования разрабатывается заранее, и называется
планом действий в непредвиденных обстоятельствах.
- Снижение риска. Стратегия предполагает усилие, направленное на
понижение вероятности и/или последствий риска до приемлемых пределов.
В такой стратегии обычно используется включение в план проекта
превентивных работ, которые будут выполняться независимо от
возникновения риска и нацелены на его снижение или предотвращение,
11
Сайт Проектные Сервисы - https://www.pmservices.ru/
19
такими работами будут считаться проведение дополнительного
тестирования функциональности информационной системы, разработка
прототипа системы.
12
Планирование реагирования на риски
- Реестр рисков (обновления). Содержит в себе определенные
способы реагирования на риски, которые разработаны и утверждены в
процессе планирования реагирования;
- План управления проектом (обновления). Обновление плана
управления проектом осуществляется за счет добавления нужных операций
реагирования на риски в процессе управления изменениями проекта;
- Контрактные соглашения, которые могут касаться рисков. Такие
соглашения составляются для юридического определения ответственности
каждой из сторон в случае возникновения каждого отдельного риска. Это
могут быть контракты\договоры страхования или оказания услуг по проекту;
- регулярное отслеживание изменений (Мониторинг рисков).
Мониторинг и управление рисками - процесс отслеживания
идентифицированных рисков, мониторинга остаточных рисков,
идентификации новых рисков, исполнения планов реагирования на риски и
оценки их эффективности на протяжении жизненного цикла проекта.
Мониторинг рисков является завершающим этапом процесса
управления рисками, он очень важен для эффективной реализации действий,
которые были запланированы на предыдущих этапах управления рисками.
Мониторинг - это контролирующая деятельность, предусмотренная
ранее составленным планом управления рисками. Мониторинг обеспечивает
своевременность исполнения мер и планов по предотвращению и смягчению
рисков и последствий. Для этого используются индикаторы – триггеры
("признаки рисков", "симптомы риска"), которые указывают на состояние
12
Постановление Правительства РФ от 15.10.2016 № 1050 ≪Об организации проектной деятельности в
Правительстве Российской Федерации≫.
20
событий риска. Триггеры определяются на этапе идентификации рисков и
фиксируются в Плане управления проектом.
Примеры параметров, к которым могут быть привязаны признаки
рисков и за которыми может потребоваться регулярное наблюдение:
- количество найденных и неисправленных ошибок на один модуль
или компонент;
- среднее за неделю количество сверхурочных, ненормированных
часов работы на одного сотрудника;
- еженедельное количество изменений в требованиях;
- какие-либо изменения бизнес-процессов Заказчика;
- своевременность выделения и использования требуемых для
осуществления работ ресурсов;
- техническое обеспечение работ.
13
Рисунок. 3 Пример матрицы Рисков по проекту
Корни гибкого подхода тянутся вглубь веков, к сформулированному
в 1620 году Френсисом Бэконом научному методу. Возникновение и
первоначальное развития Agile началось в 30-е годы ХХ века, когда физик и
статистик Уолтер Шухарт начал применять циклы Планируй-Делай-Изучай-
Действуй к развитию и улучшению различных продуктов и процессов.
основы такой итеративно-инкрементальной разработки он передал своему
ученику, Уильяму Эдвардсу Демингу, который в свою очередь
13
Сооляттэ А.Ю. Управление проектами в компании: методология, технологии, практика: учебник. – М.:
Московский финансово-промышленный университет «Синергия», 2012
21
популяризировал этот метод в Японии, во время восстановления после
второй мировой войны. Компания Toyota начала свое сотрудничество с
Демингом, чтобы обучить сотни менеджеров компании, что привело к
созданию знаменитой Производственной системы «Toyota», что в
последствии стало источником современного «бережливого» производства.
В 1986, Хиротака Такеучи, совместно со своим партнёром Икуджиро
Нонакой опубликовал статью под названием “The New New Product
Development Game” в которой, авторы выявили командно-ориентированный
подход, путем изучения компаний, лидировавших на рынке инноваций и
опережавших своих конкурентов, который полностью изменял классический
процесс разработки продукта и ведения проектной деятельности. Такой
метод применялся в компаниях “Xerox”, “Honda” и “Canon”. Вместо
классической каскадной модели движения продукта поэтапно в подходе
использовался метод, похожий на игру в «регби», когда команда проекта
продвигается по дистанции как единое целое.
14
В 1993 году Джефф Сазерленд тоже столкнулся с неосуществимой
задачей: Компания «Easel Corporation», которая занималась разработкой
программного обеспечения, должна была менее чем за шесть месяцев успеть
разработать замену своему основному продукту. У ученого на тот момент,
уже был опыт работы с нестандартными, гибкими методологиями, такими
как быстрая разработка приложений, объектно-ориентированная разработка
и Цикл Деминга (PDCA), а также работы с автономными креативными
исследовательскими группами и в следствии этого, идеей было создать
креативную группу в штаб-квартире организации, сочетая автономность и
интеграцию. В ходе этого исследования он прочёл сотни статей, поговорил с
десятками ведущих менеджеров продуктов и его заинтересовали несколько
оригинальных идей. Одна из оригинальных идей пришла из Лаборатории
Белла, в которой когда-то разрабатывался Цикл Деминга (PDСA). Эта идея
14
Кеннет С. Рубин. Основы Scrum. Практическое руководство по гибкой разработке ПО. Изд. Вильямс. 2016,
544с.
22
заключалась в пользе коротких ежедневных встреч команды, которые
улучшали синхронизацию и повышали производительность команды, однако
ключевая концепция подхода была взята из статьи Нонаки и Такеучи о
«регбийном» подходе, несмотря на то, что он относился скорее к
производству, нежели к сфере IT-разработки. Взяв огромное количество
идей из различных источников, Сазерленд создал новый подход к разработке
программного обеспечения, дав ему название «Scrum», в честь аналогии с
игрой в регби. Такой подход позволил успешно завершить практически
невозможный проект в срок, в рамках бюджета и с невозможно низким
количеством ошибок в коде. в 1995 году Сазерленд, объединившись со
своим коллегой Кеном Швабером для формализации подхода, представили
Scrum всему мировому сообществу. Конечно, Швабер и Сазерленд были не
одиноки в своих поисках инновационных методов управления проектами и
разработки ПО. В то время на рынке стремительно развивались технологии,
программное обеспечение стало неотъемлемой частью практически каждого
бизнеса, и многие разработчики трудились над тем, чтобы сделать методы
разработки более гибкими.
В 2001 году, 17 разработчиков, которые называли себя
«организационными анархистами» встретились в городе Сноубёрд, штат
Юта, чтобы поделиться идеями повышения эффективности. Сазерленд и
другие сторонники Scrum были среди них. В группу входили приверженцы
нескольких конкурирующих подходов гибкой разработки и управления
проектами: экстремального программирования (ХР), crystal, adaptive software
development (ASD), feature-driven development (FDD); и dynamic-systems-
development method (DSDM). Все эти подходы были известны как «лёгкие»
фреймворки, потому что они используют более простые правила и процессы
для быстрой адаптации к изменяющейся среде. Несмотря на разногласия,
участники выбрали новое название для движения, так появился Agile.
История Agile начинается с публикации в 2001 году «Манифеста
гибкой разработки ПО», состоящего из 12 принципов. Отдельно изложенные
23
принципы Agile - подхода появлялись и ранее, но только этот документ
систематизировал и изложил их в достаточной для использования мере.
Сейчас каждый год под манифестом подписываются новые компании, IT-
специалисты и проектные менеджеры, появляются новые методы
и модификации гибкой системы разработки.
Agile — итеративная модель разработки, в которой программное
обеспечение создают инкрементально с самого начала проекта, в отличии
от каскадных моделей, где код доставляется в конце рабочего цикла.
Основа гибкой методологии — декомпозиция проектов на меньшие
рабочие кусочки, которые называют пользовательскими историями. Далее,
согласно приоритетности задачи, выполняют в рамках коротких циклов
(итераций).
12 принципов, которые составляют Agile-методологию, можно
поделить на 4 главные идеи:
-Люди и взаимодействие важнее процессов и инструментов;
-Работающий продукт важнее исчерпывающей документации;
-Сотрудничество с заказчиком важнее согласования условий
контракта;
-Готовность к изменениям важнее следования первоначальному
плану.
15
Управление проектами – это деятельность по достижению
поставленных целей и задач проекта, вовремя и в рамках бюджета. Все
проекты разные и на данный момент не существует единой системы
управления, которая могла подойти для каждого из видов проектов, а также,
которая подошла бы каждому руководителю проектов и всем членов
команды проекта. В основном все разработанные подходы сильно
отличаются друг от друга из-за специфики области их применения, а также
15
Дейв Сазерленд. Scrum. Революционный метод управления проектами. -М.: Манн, Иванов и Фербер, 2016. -
288с.
24
по детализированности, самодостаточности и формализации. Классический
подход позволяет сосредоточиться на затрачиваемых ресурсах, которые
ограничены, и времени реализации, так как есть дедлайны и контрольные
точки фаз проекта, которые должны быть соблюдены. Появление гибких
подходов обосновано тем, что разным проектам нужен разный уровень
контроля. А также важно управлять не только временем реализации и
ресурсами, а уделять большее внимание людям, участникам проекта,
взаимодействию и процессу. Для похожих проектов скорее подойдут гибкие
методы управления, такие как Agile и другие связанные с ним подходы,
например, Lean, Kanban, и другие.
16
Заказчик больше вовлечен в проект, в отличие от работы по
классическим методологиям, таким образом, ему необходимо вместе с
командой планировать итерации, принимать решения и результаты работ по
итерациям. Например, в Scrum, одном из таких гибких подходов, где
владелец продукта, выступает в роли представителя заказчика и формирует
очередность реализации функционала продукта и принимает итоги работ по
каждой итерации. Именно благодаря постоянному взаимодействию с
командой проекта и изучению промежуточных результатов, заказчик или его
представитель, глубже понимает функциональность и ценность продукта,
ему легче дается процесс приемки по завершении проекта.
Заказчик проекта нацелен на то, чтобы в ограниченный срок и
бюджет сделать самые важные функции продукта, без которых продукт не
сможет выполнять свое назначение. Управление приоритетами в реализации
требований к продукту очень нужно и полезно, так, в соответствии с
некоторыми исследованиями, пользователи IT-продуктов используют
примерно половину функций, существующих в продукте, а это значит, что
деньги на оставшуюся половину потрачены зря. Главной задачей команды
является определение этой самой «потребляемой» половины и их реализация
в первой итерации продукта.
16
Сайт ПМ-эксперт - http://www.pmexpert.ru/