41
LOGO Управление рисками hwdtech.com УК 03.006.02-2011

ук 03.006.02 2011

Embed Size (px)

Citation preview

Page 1: ук 03.006.02 2011

LOGO

Управление рисками

hwdtech.com УК 03.006.02-2011

Page 2: ук 03.006.02 2011

Организация управления рисками

Contents

Задачи из практики

Идентификация рисков

Планирование рисков

Понятие Управление рисками

Page 3: ук 03.006.02 2011

Делегирование

• Заказчики склонны требовать обещания - по срокам, по функциональным возможностям ПО, по качеству.

• Когда старший программист выполняет проект самостоятельно, ему в большинстве случаев легко пообещать что-то, зная что это будет выполнено, либо внести уточнения в пожелания заказчика.

• Если старший программист делегирует задачи младшему товарищу, то давать обещания намного сложнее. Даже в случае когда старший программист знает как нужно выполнить требуемое от начала и до конца.

• Если старший программист делегирует задачу и при этом в ней есть исследовательский элемент в котором он сам не уверен, то давать обещания по срокам и возможности выполнения очень сложно.

• Как научиться оценивать возможности своей команды?

Page 4: ук 03.006.02 2011

Продуктивность

• Для того чтобы начать решать задачу эффективно человеку нужно 15 минут. Это время уходит на “загрузку” информации в мозг. Если при этом каждые 30 минут отвлекаться на разговоры или сообщения в чате, то эффективного рабочего времени за день получится не 8 а 4 часа.

• Нужно научиться справляться с этим, но при этом работа не должна превратиться в каторжный труд. Общение с коллегами приятно и поднимает настроение.

• Как соблюсти баланс?

Page 5: ук 03.006.02 2011

Разминка

• Собрать фигуру по устному объяснению

Page 6: ук 03.006.02 2011

Chaos Report

Page 7: ук 03.006.02 2011

Почему?

• Одна из распространенных причин – неправильное управление рисками (или его отсутствие)

• Риск – опасность, возможность убытка, ущерба

Page 8: ук 03.006.02 2011

Разминка

Что Вы знаете об управлении рисками?

Page 9: ук 03.006.02 2011

Причем тут риски?

• Дилемма заключенного

• Равновесие Нэша. Тип решений игры двух и более игроков, в котором ни один участник не может увеличить выигрыш, изменив своё решение в одностороннем порядке, когда другие участники не меняют решения.

Page 10: ук 03.006.02 2011

Так все-таки причем тут

риски?

Неопределенность

Паралич

Сложность

Близорукость

Фактическая

последовательность работ

отличается от модели -

плана.

Только 30% из 60000

проектов выполняются во

время.

Неумение принимать решение в

условиях полной или частичной

неопределенности, неполноты,

неточности информации.

Направлять усилия на устранения

следствий (влияние от наступления

рисков), а не на причины (источники

возникновения рисков).

Риски

Page 11: ук 03.006.02 2011

Пример из жизни программистов

1

2

3

Если проект окончен в срок, то получаем 100%

оплаты

Если проект затянулся по срокам, то

получаем 60% оплаты

Если проект завершен раньше срока,

то получаем 150% оплаты

Проект скорее всего будет провален

Page 12: ук 03.006.02 2011

Почему так?

• Вероятность того, что проект будет закончен в срок – 30%, а раньше – гораздо меньше.

• Чтобы закончить раньше надо отказаться от каких-то активностей.

Page 13: ук 03.006.02 2011

Разминка

• Собрать фигуру под “непосредственным” присмотром

Page 14: ук 03.006.02 2011

Определение риска (PMBOK)

Риск проекта – это неопределенное событие или условие, которое будет иметь положительное или отрицательное воздействие как минимум на одну цель проекта (например, сроки, стоимость, содержание или качество), если оно произойдет

Негативные риски = угрозы

Позитивные риски = благоприятные возможности

Про позитивные риски часто забывают или пускают на самотек

Page 15: ук 03.006.02 2011

Цель управления рисками

• Риск может быть вызван одной или несколькими причинами и в случае возникновения может оказывать влияние на один или несколько факторов

• Цели управления рисками – повышение вероятности возникновения и воздействия благоприятных событий и снижения вероятности возникновения и воздействия неблагоприятных для проекта событий.

• Управление рисками = управление проектом ???

Page 16: ук 03.006.02 2011

Недостаток времени.

Сопротивление управлению рисками.

Нежелание брать на себя ответственность.

Неприятие термина риск.

Трудности внедрения

Убежденность в отсутствии необходимости управлению рисками.

Непрофессионализм.

Page 17: ук 03.006.02 2011

5. Неприятие термина риск

• Руководство

– Говорят о рисках – значит пытаются увильнуть от работы и снять с себя ответственность

– Отход от “Мы это обязательно сделаем”

– Потребуют времени и денег на управление рисками

• PM

– Реализация выявленного риска будет рассматриваться как ошибка PM

• Исполнители

– Гонца принесшего дурную весть …

– Если риски не реализуются, пропадает необходимость в подвигах

Page 18: ук 03.006.02 2011

Цикл Деминга-Шухарта

Page 19: ук 03.006.02 2011

Процесс управления рисками

Цикл

управления

Контроль

Анализ

Монито-

ринг

Идентификация

Планиро-

вание

Фазы

Процесс управления рисками

начинается с:

• сбор первичной информации,

• выработка подходов к управлению.

Идентификация - выявление рисков

Анализ – оценка вероятности, степень влияния

Планирование – планы работы с рисками Мониторинг - отслеживание статуса риска

Контроль – анализ эффективности мероприятий по управлению рисками

Page 20: ук 03.006.02 2011

Идентификация

Причинно-следственная

модель

Условие – событие, которое уже произошло или произойдет с высокой вероятностью Следствие - связанное с условием событие, которое может произойти в будущем

Причина – источник риска

Негативный эффект – результат влияния следствия на результаты проекта.

•причин и следствий может быть много,

•каждое следствие может иметь несколько причин

Page 21: ук 03.006.02 2011

Упражнение

Работа в группах

Продуктивность

Page 22: ук 03.006.02 2011

Вариант решения

• Придумать какое-либо занятие, которое будет интересно нескольким людям

• Это занятие будет нерабочим временем

Page 23: ук 03.006.02 2011

Выявление причинно-

следственной связи

• Как правило очевиден только негативный эффект

– Нет прогресса на проекте

– Требования часто меняются

– Срочные задачи

• Чаще всего воздействуем на негативный эффект, вместо устранения причины

– Делать любую задачу за 1-2 дня

– Не торопиться что-либо сделать. Все равно скоро отменят.

– Запретить менять требования.

• Практика ставить задачи в виде конкретных действий

– Сделать вот эту кнопочку. Завтра будет?

– Надо прописать в договоре: ТЗ менять нельзя.

Page 24: ук 03.006.02 2011

Правило 5 почему?

• Чтобы добраться до первопричины надо задать 5 вопросов Почему?

• Низкая мотивация персонала

– Почему? Нет смысла торопиться что делать.

– Почему? Семь пятниц на неделе. Требования меняются настолько часто, что мы не успеваем что-то сделать, как это уже никому не нужно.

– Почему? Все время появляются новые идеи, которые просят реализовать.

– Почему? Есть какая-то потребность у заказчика, которую он пытается реализовать посредством разных идей.

– Почему? Потребность не выявлена нами.

Page 25: ук 03.006.02 2011

TOP-10 рисков по Б. Боэуму

• Дефицит специалистов.

• Нереалистичные сроки и бюджет.

• Реализация несоответствующей функциональности.

• Разработка неправильного пользовательского интерфейса.

• «Золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание деталей.

• Непрекращающийся поток изменений.

• Нехватка информации о внешних компонентах, определяющих окружение системы или вовлечённых в интеграцию.

• Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.

• Недостаточная производительность получаемой системы.

• «Разрыв» в квалификации специалистов разных областей знаний.

Page 26: ук 03.006.02 2011

Цепочка событий и

последовательность рисков

• В модели “условие-следствие” рассматривается последовательность из 4-х рисков

• В реальности события выстраиваются в более длинные цепочки зависимостей

Page 27: ук 03.006.02 2011

Пример цепочки рисков

Page 28: ук 03.006.02 2011

Прошедшие риски

Page 29: ук 03.006.02 2011

Актуальные риски

Page 30: ук 03.006.02 2011

Потенциальные риски

Page 31: ук 03.006.02 2011

Планирование

Page 32: ук 03.006.02 2011

Стратегии реагирования на

риски

• Уклонение Последовательность работ выстроена таким образом, что устраняет

возникновение риска

• Передача Негативные последствия передаются другой стороне без устранения

самого риска

• Снижение Планирование действий по снижению вероятности возникновения

самого риска и/или снижению негативного эффекта

• Принятие – Пассивное принятие – ничего не делаем вообще

– Активное принятие – создается резерв

Бывают неустранимые риски

Page 33: ук 03.006.02 2011

Активное принятие

• Резервы – запасы ресурсов (время, сотрудники, финансы), добавляемые к плану проекта для эффективной работы с рисками

• Наличие резервов – необходимое условие для выполнения планов

• Виды резервов – Страховой резерв (для известных, главным образом,

неустранимых рисков)

– Резерв управления (для неизвестных рисков

Page 34: ук 03.006.02 2011

Примеры работы с рисками

• План предотвращения – Перенос сроков обновления ПО на время после сдачи фазы

проекта

– Аналитика

– Прототипирование

• План смягчения – Автоматизированное тестирование

– Руководство пользователя

– Методологии управления проектами

• План реагирования – Выделение времени на поддержку проектов

– Коэффициент оптимистичности

Page 35: ук 03.006.02 2011

Упражнение

Работа в группах

Делегирование

Page 36: ук 03.006.02 2011

Вариант решения

• Предложить план решения задачи и объяснить причины такого решения

• Убедиться, что с предложенным вариантом “подопечный” согласен

• Расставить контрольные точки (мониторинг + контроль)

• План “Б” (кто-то кто может сделать эту задачу)

Page 37: ук 03.006.02 2011

Как организовать

управление рисками

• Принцип ПДД

• Пирамида степени автоматизации действий

• Общее хранилище рисков

• Форма описания (паттерн)

• Выявлять риски в произошедших инцидентах

• Периодически проводить обучение менеджеров на предмет новых выявленных рисков

• Общие риски вводить в нормативные документы

Page 38: ук 03.006.02 2011

Упражнение

Работа в группах

Список рисков

Page 39: ук 03.006.02 2011

Риски

• Во время работы над проектом Заказчик был доволен, но после сдачи проекта он резко меняет свое мнение

• Программист затянул по срокам, потому что не знал как решить задачу

• Мы не сможем реализовать задачу в принципе

• Неожиданно закончились задачи

• Заказчику не нравится результат нашей работы

• У студентов “неожиданно” началась сессия

• “Отличники”

• Со своим уставом в чужой монастырь

Page 40: ук 03.006.02 2011

• Работа почасовая – сколько хочу - столько и работаю

• Слишком большой объем работы

• Недопонимания в чатах

• Слишком много чатов одновременно

• “Антикомандное” поведение – Участники проекта могут “подставить” друг друга

– Заказчику будут выданы противоречивые обещания от разных участников проекта

– Повышение собственной значимости за счет занижения самооценки других

• Синдром долгосрочного проекта

• Синдром одного заказчика

Page 41: ук 03.006.02 2011

LOGO hwdtech.com