Debunking Risk Management in Software (RUS)

Сеанс управления рисками с разоблачением

© Алексей Кузнецов ([email protected]), 2012

План доклада

2

1. Почему управление рисками интересует менеджеров?


3


2. Типичные глупости от тренеров по управлению рисками CHAOS report от Standish Group Обоснование эффективности

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


4


2. Типичные глупости от тренеров по управлению рисками

3. Известные методы, которые не работают в реальной жизни Оценка подверженности риску Связь оценки и риска PERT: обоснование и критика


5



3. Известные методы, которые не работают в реальной жизни

4. Сила простых методов Оптимизация = хрупкость Предположения (assumptions) Некоторые приемы


6




4. Сила простых методов5. Список литературы


7




4. Сила простых методов5. Список литературы6. Q&A

Project Manager: взгляд Эдварда Йордона

Все хотят выглядеть героями 8

Project Manager: типичный образ

Так выглядит менеджер вашего (моего) проекта9

Project Manager: суровая реальность

10PM несет за ответственность, но далеко не все в его силах

Второй слайд презентации типичного тренера по управлению рисками

11CHAOS Report (Standish Group). Зачем постоянно это показывают?

Что не следует из этого графика

12Даже некорректный отчет не показывает успеха управления рисками

Гипотетический эксперимент, проверки полезного эффекта управления рисками в ИТ

13

“Полезность управления рисками ещё никто не доказал, но по моим ощущениям она огромна” ©

1994 1998 2000 2002 2006 20080

10

20

30

40

50

60

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

Succeed Challenged Failed

1994 1998 2000 2002 2006 20080

10

20

30

40

50

60

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

Succeed Challenged Failed

Два вида неопределённости: метро и кокос

14

Вагон метрополитена

Подверженность риску: определение

Подверженность риску = затраты * вероятность

Вероятность — численная мера степени объективной возможности наступления случайного события.

Оценкой вероятности события может служить частота его наступления в длительной серии независимых повторений случайного эксперимента.

15И затраты и вероятность – величины весьма неопределенные

Подверженность риску: возможная погрешность

Если использовать подверженность риску как оценку необходимого резерва, то в зависимости от того, пессимист вы или оптимист, вам могут потребоваться суммы денег, отличающиеся друг от друга более чем в 5(!) раз. Сложно представить, как это будет работать если суммы большие.

16

Затраты Вероятность Подверженность риску

1000 р. 20% 200 р.(900/1000/1100) р. (15/20/25) % (135/200/275) р.(900/1000/1100) р. (1/2/3) % (9/20/33) р.

(700/1000/1300) р. (5/10/15) % (35/100/195) р.

Подверженность риску и абсурдные ситуации

17

Риск Затраты Вероятность Подверженность риску

Риск1 1000 р. 10% 100 р.Риск2 1000 р. 10% 100 р.Риск3 1000 р. 10% 100 р.

Риск4 1000 р. 10% 100 р.

Итак, подверженность риску составляет 400р., чего не хватит для покрытия ни одного из перечисленных рисков в случае их наступления.В целом, методику оценки подверженности риску следует уже давно признать алхимией. Хотя некоторые тренеры по УР со мной не согласятся.

Вместо этого предлагается выделять резерв по принципу «больше все равно не дадут». Ну и что что риски сработали? Больше все равно не дали бы денег/времени на их покрытие. Просто и понятно.

Связь оценки и риска

18

Оценка и риск – лед и вода, не одно и то же, однако одно перетекает в другое.

Заниженная оценка увеличивает шансы даже самых заурядных событий стать критическими рисками для вашего проекта.

Согласованная завышенная оценка имеет обратный эффект.

Почему мы не слишком завышаем оценки? Потому что на них смотрят

На риски не очень смотрят, потому что тут можно нафантазировать сколько угодно много. У вас слишком большая оценка! Окей: теперь у нас слишком большой риск.

Итак: вы хотите получить минимальную оценку и спать спокойно.

Оценки сроков по PERT

Техника PERT была разработана в 1958г. по заказу ВМС США для проекта создания ракетной системы Polaris.

19

Задачи О R P

Т1 1 2.5 7

Т2 2 5 10

Т3 4 9 16

Итого 7 16.5 33

Ei = (Oi+4*Ri+Pi)/6

3

5.33

9.33

E = 17.66

i = (Pi-Oi)/6

1

1.333333

2

4.333333

d = sqrt(1* 1 +..+ n*n) = 5.055T = E + = 17.66+5.055 ~ 22.7T2 = E + 2* = 17.66+10.11 ~ 27.8T3 = E + 3* = 17.66+15.165 ~ 32.8d ~ вероятность успеха 68%2 ~ вероятность успеха 95%3 ~ вероятность успеха 99%

Обоснование PERT

Техника PERT является следствием центральной предельной теоремы:

20

Сумма большого количества слабо зависимых случайных величин имеет распределение, близкоек нормальному.

График плотности вероятности.Вероятность – это площадь под графиком

PERT: проблемы

• Случайные величины скорее всего зависимы

• Количество случайных величин мало (≤100)

• Слагаемые могут иметь разный порядок величин

• Вы (наверняка) не подрядчик Пентагона

21

PERT: проблемы

22

Если вы думаете, что ваши дела действительно плохи после

изложенного выше, то продолжайте слушать.

На самом деле все ещё хуже.

Характер ошибок прогнозирования:физическая реальность

23Проект по разработке ПО не принадлежит физическому миру

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

Она не масштабируема, т.к. чем старше мы становимся, тем меньше у нас шансов жить дальше. В развитой стране таблицы страховых компаний предсказывают новорождённой девочке смерть в 79 лет.

Когда она справит 79-й день рождения, ожидаемая продолжительность ее жизни в типичном случае будет составлять 10 лет. В возрасте 90 лет она сможет рассчитывать на 4.7 года. В 100 лет -- на 2.5 года. По мере того, как она пересекает очередные пороги, количество дополнительных лет уменьшается.

Характер ошибок прогнозирования:проекты

24Чем дольше вы ждёте, тем дольше вам предстоит ждать

С человеческими планами и проектами дело обстоит по-другому. Они часто масштабируемы, а в случае с масштабируемыми переменными вы получите ровно противоположный эффект.

Скажем, предполагается, что проект будет завершен за 79 дней (берем ту же цифру, что в примере с возрастом женщины). Если на 79-й день проект не завершен, нужно будет отвести на него ещё 25 дней.

На 90-й день -- ещё около 58. На 100-й -- 89. На 119-й -- 149. Если проект не завершен в день номер 600, то на него понадобится 1590 дополнительных дней.

Способы снижения рисков при разработке ПО

1. Добавление в контракт условий, при которых обязательства сторон пересматриваются.

2. Добавление избыточности самого разного рода.

3. Отказ от проекта до его старта.

25Третий способ -- для настоящих мужиков

Практические приемы (банально, но зато работает)

26

• Оговорите рамки и цели проекта, определите что обязательно должно войти в очередную поставку, а что может подождать

• Наймите дополнительного разработчика в самом начале проекта• Пересекайте области ответственности и экспертизы внутри команды• Заплатите за более квалифицированных кандидатов• Не полагайтесь на оценки типа «aggressive & ambitious». Чем крупнее

клиент, тем больший запас закладывайте (бюрократы своё возьмут)• Убедитесь, что у заказчика есть деньги• Разделите большой проект на несколько фаз (в последующих фазах

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

• Оговорите факторы, не зависящие от вас (готовность инфраструктуры, порядок приемки, доступность ключевых лиц, сетевой доступ…)

Как дать небольшую оценку, скрыть риск и сдать проект вовремя (fake it till you make it)

27

• Постарайтесь с самого начала работать с реальными данными, а не с синтетическими тестовыми примерами (которые не верны)

• Сфокусируйтесь на том, что пользователь видит, оставляйте на потом то, что пользователю не видно или надежно спрятано от него

• Показывайте случайные цифры или нули там, где должны быть вычисления, но нет реализации (ваш продукт будет выглядеть живым с первой недели)

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

• Ставьте везде заглушки. Вы не знаете mapping? Вы не знаете какое значение нужно задать для этого параметра? Задавайте любое, лишь бы сработало (разбирайтесь в фоне). Главное чтобы был видимый результат как можно быстрее

Почему исправить потом легче чем сразу сделать сразу всё «правильно»

28

Нас учат, что ошибка на стадии сбора требований дешево правится. Так вот, это не всегда так:• У заказчика есть только образ в голове, ему не на что посмотреть.

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

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

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

Избыточность в других областях

1. Страховой бизнес.

2. Ваши сбережения.

3. Управление стратегическими вооружениями.

4. Самолёты, корабли и подлодки.

5. Деньги в ваших водительских правах.

6. Пожарная лестница в офисе

29

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

Список литературы

30

Nassim Nicholas Taleb

Список литературы: The Black Swan

31

Taleb, Nassim Nicholas

The Black Swan: The Impact of the Highly Improbable

New York: Random House, 2007.ISBN 978-1-4000-6351-5.

Список литературы: Dance with Chance

32

Spyros G. Makridakis, Robin M. Hogarth, Anil Gaba

Dance with Chance: Making Luck Work for You

Oxford: Oneworld Publications, 2009ISBN: 978-1-85168-679-7

Вопросы и ответы

33

Debunking Risk Management in Software (RUS)

Technology

Transcript of Debunking Risk Management in Software (RUS)