Circum Risk Space. Whale Rider Conference. Moscow

Около Рисковое Пространство Сергей Поволяшко, PMP. www.it-tuning.com

Докладчик 15 лет стажа в IT. Работал по нескольким IT специальностям (разработчик, системный администратор, тестировщик). Начиная с 2001 года в основном работаю в области управления проектов и IT подразделений. Текущая деятельность в компании TEAM International ( www.teaminternational.com ): менеджер отдела разработок, менеджер проектов, менеджер IT инфраструктуры. Принимал лидирующее участие во внедрении CMMI L 3 в компании TEAM International. Сертификации: Project Management Professional (PMP), ITIL Foundation V3. Проект «ИТ Тюнинг» - www.it-tuning.com . Настройка, упорядочивание рабочих процессов ИТ компании.

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

Содержание
Просто освежим понимание управления Рисками
Основные подпроцессы
Основной инструментарий
Собственно Около Рисковое Пространство
Риск ? – > Факт – > План
Риск ? – > Шаблон поведения – > Факт – > План
Риск? – > История – > Прогноз – > Контроль
Коммуникации

Планирование управления рисками – определение подхода, инструментария, ресуров.
Идентификация рисков – определение рисков, их описание
Анализ рисков – приоритезация рисков на основе их вероятности и влияния
Реагирование на риски – разработка планов реагирования на риски
Мониторинг и управление рисками – воплощение планов, мониторинг рисков, определение новых рисков, оценка эффективности процесса управления рисками

Идентификация и Анализ рисков – участники
Эксперт Проектная команда Менеджмент Заказчик

Основной инструментарий
Risk Breakdown Structure
Матрица вероятности и последствий
Реестр рисков
Способы реагирования: mitigation - до , contingency - после

Около Рисковое Пространство

Некоторые вещи воспринимаются нами как риски, отсюда:
Применение практик управления рисками
Или же, как часто происходит, игнорирование  , авось пронесет
Но, положа руку на сердце они являются фактами !

Некоторые вещи воспринимаются нами как риски, отсюда:
Применение практик управления рисками
Или же, как часто происходит, игнорирование  , авось пронесет
Но, положа руку на сердце они являются фактами !
IF Вероятность >= 90% THEN
{
Риск = Факт
Create План (работы, ресурсы, время)
Include План в План Проекта
}

Примеры:
Интеграция произошла …
без проблем и …
вовремя
При приемке продукта заказчик ...
согласился-таки с функционалом
Все вовлеченные в проект + заказчик отвечают на вопросы …
быстро

Примеры:
Интеграция произошла …
без проблем и …
вовремя
При приемке продукта заказчик ...
согласился-таки с функционалом
Все вовлеченные в проект + заказчик отвечают на вопросы …
быстро
– Да вы, наверное, шутите! Такого не бывает!
И правда, давайте признаемся, это НЕ Риски – это ФАКТЫ.
Они ДОЛЖНЫ быть в Плане Проекта

Риск ? – > Факт – > План Интеграция – включаем изначально больше времени; разрабатываем план интеграции; привлекаем высококвалифицированого специалиста; собираем среду, близкую к целевой; делаем интеграцию итеративной Приемка продукта – четко определяем критерии приемки; вводим формальное утверждение требований; выбираем правильное сочетание типа проекта, типа контракта, способностей и / или возможностей наших и заказчика; используем итерации, прототипы Скорость ответа – договариваемся о правилах коммуникации; документируем факты задержек; эскалируем; формализуем коммуникации; используем эффективные способы коммуникации

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

Некоторые вещи воспринимаются нами как неожиданности, ассоциируемые с рисками:
Вдруг выпал снег, снегоуборочная техника не готова
Вдруг началась эпидемия гриппа, треть персонала заболела
Верьте или нет, но эти вещи случаются с завидной регулярностью !
IF Вероятность_Регулярности > 60-70% THEN
{
Риск = Шаблон поведения
Шаблон поведения = Факт
Create План (работы, ресурсы, время)
Include План в План Проекта
}

Риск ? – > Шаблон поведения – > Факт – > План Примеры: Текучка кадров Отсутствие по болезни

Риск ? – > Шаблон поведения – > Факт – > План Шаблон «Текучка кадров» - держим руку на пульсе; и пользуемся моментом; держим скамейку запасных; вводим человеко-независимость Шаблон «Отсутствие по болезни» - оздоровительные меры (проветривание, витамины, заболел – сиди дома); планируем пониженную отдачу; вводим человеко-независимость

Некоторые неприятности, ОЙ, опять случаются, опять Риски:
В очередной итерации мы скорее всего отстанем от графика, на сколько?
Опять у типичного проекта скорее всего будут проблемы с качеством
И этот заказчик скорее всего будет менять требования при сдаче проекта
А ведь можно проанализировать причины, принять меры, спрогнозировать!

Некоторые неприятности, ОЙ, опять случаются, опять Риски:
В очередной итерации мы скорее всего отстанем от графика, на сколько?
Опять у типичного проекта скорее всего будут проблемы с качеством
И этот заказчик скорее всего будет менять требования при сдаче проекта
А ведь можно проанализировать причины, принять меры, спрогнозировать!
IF Типичные : _Проекты_Итерации _ Проблемы = TRUE THEN
{
Collect Исторические данные
Analyze Исторические данные
[ Create План корректирующих воздействий ]
Forecast Нужные данные / метрики
Monitor Нужные данные / метрики
}

Риск? – > История – > Прогноз – > Контроль Примеры: Итеративная разработка или типичные проекты – можно относительно несложно собирать данные о: разнице запланированных и реальных усилий, денег, времени. Цель – тренды по итерациям. Пользуемся баг трекерами – можно настроить отчетность о: на какой фазе сколько дефектов произведено; сколько дефектов обнаружил заказчик во время и / или после приемки. Цель – понять, спрогнозировать, улучшить процессы на проекте. Смена требований при сдаче – можно соотнести количество и / или качество требований при первичном обсуждении / утверждении и при сдаче. Цель – найти узкое место в «условиях жизни» проекта.

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

Рекомендации по анализу данных / метрик:
Анализируем не людей, а проблемы, процессы
Выявляем причины
Анализируем с конкретными целями (то, что действительно беспокоит)
Важно! Внедряем корректирующие воздействия / улучшения

Рекомендации по прогнозированию:
Основываем прогноз на нескольких типичных итерациях, проектах, проблемах
Важно! Устанавливаем ОЖИДАНИЯ – свои, менеджмента, заказчика на основании прогноза, таким образом снижая риск неопределенности или же превращая риск в факт
Проект А Проект B Проект C База знаний Проект D

Ну хорошо, мы умеем работать с рисками, и даже есть замечательный план:
Но об этом знает достаточно узкий круг лиц
Зачастую планы по борьбе с рисками вуалируются или игнорируются
Когда риск случается, то кто-то вместо благодарности за наличие плана реагирования получает по шапке
Риски это область где невозможно перекоммуницировать!

Ну хорошо, мы умеем работать с рисками, и даже есть замечательный план:
Но об этом знает достаточно узкий круг лиц
Зачастую планы по борьбе с рисками вуалируются или игнорируются
Когда риск случается, то кто-то вместо благодарности за наличие плана реагирования получает по шапке
Риски это область где невозможно перекоммуницировать!
/* IF THEN */
DEFINE Управление рисками = MUST BE
EDUCATE and INVOLVE Проектную команду и Менеджмент
EDUCATE Заказчика / Спонсора … там где это имеет смысл
COMMUNICATE Риски, Планы реагирования

Рекомендации:
Обучить проектную команду, и вовлекать ее в управление рисками
Донести до менеджмента о наличии такой дисциплины, как управление рисками, и о достоинствах ее применения
Дипломатично! донести до заказчика (возможно с помощью менеджмента) о наличии такой дисциплины, как управление рисками, и о достоинствах ее применения
Планы по реагированию на риски ДОЛЖНЫ быть включены в План проекта, который в свою очередь является средством коммуникации
Действия по управлению рисками
ДОЛЖНЫ быть одними из первых
на проекте, потому что:

Ошибки:
Невовлечение проектной команды, а также менеджмента и заказчика в процедуры управления рисками
Надежда на Авось – умалчивание, даже когда риски переходят в разряд фактов, а это значит ДОЛЖНЫ быть в плане проекта
Нежелание «расстраивать» заказчика, менеджмент наличием рисков
Отсутствие анализа исторических данных по типичным проектам, проблемам

Спасибо за внимание! Вопросы?

Контакт: [email_address]
Подробнее:
О проекте « ИТ Тюнинг » и тренингах http :// www.it-tuning.com
О себе http :// www . linkedin . com / in / sergiypovolyashko
Презентации http://www.slideshare.net/sergiyp1974
Тренинги
Risk Management (Управление Рисками). Оказывается ими можно управлять.
Scheduling (Планирование, Разработка расписания работ). Не так просто как кажется, структурируем очевидные вещи.
Software Measurements (Измерения в разработке ПО). Как, что и зачем измерять.
Полет по приборам: метрики проектных команд – управляемое движение.

Circum Risk Space. Whale Rider Conference. Moscow

by Sergiy Povolyashko on Dec 18, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 4

Statistics

Circum Risk Space. Whale Rider Conference. Moscow — Presentation Transcript