Доклад Сергея Поволяшко рассматривает управление рисками в IT-проектах, акцентируя внимание на различиях между рисками и фактами, а также важности коммуникации в управлении рисками. Автор делится своими методами идентификации и анализа рисков, а также предоставляет рекомендации по взаимодействию с проектной командой и заказчиком. Основная цель документа - улучшить процесс управления рисками и повысить его эффективность за счет наличия четких планов и их коммуникации.

1. Около Рисковое Пространство Сергей Поволяшко, PMP

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

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

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

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

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

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

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

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

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

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

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

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

14. Риск ? – > Шаблон поведения – > Факт – > План Некоторые вещи воспринимаются нами как неожиданности, ассоциируемые с рисками: Вдруг выпал снег, снегоуборочная техника не готова Вдруг началась эпидемия гриппа, треть персонала заболела Верьте или нет, но эти вещи случаются с завидной регулярностью !

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

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

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

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

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

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

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

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

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

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

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

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

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

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

29. Контакт: [email_address] Тренинги: Risk Management (Управление Рисками). Оказывается ими можно управлять Scheduling (Планирование, Разработка расписания работ). Не так просто как кажется, структурируем очевидные вещи . Software Measurements (Измерения в разработке ПО). Как, что и зачем измерять. Полет по приборам: метрики проектных команд – управляемое движение. http://trn.work.ua/companies/1437/