Вальсируя с медведями
Добавить в закладки К обложке
- Вступительное замечание авторов - Страница 1
- ПрологЭтика веры - Страница 2
- Часть IПочему? - Страница 4
- Глава 1Стремление к рискам - Страница 5
- Глава 2Управление рисками – это управление проектами для взрослых - Страница 8
- Глава 3Пересмотр истории международного аэропорта в Денвере - Страница 12
- Глава 4Доводы в пользу управления рисками - Страница 15
- Часть IIПочему бы и нет? - Страница 18
- Глава 5Доводы против управления рисками - Страница 19
- Глава 6Бремя ответственности за неопределенность - Страница 21
- Глава 7Удача - Страница 23
- Часть IIIКак? - Страница 25
- Глава 8Количественное определение неопределенности - Страница 26
- Глава 9Механика управления рисками - Страница 29
- Глава 10Правила управления рисками - Страница 34
- Глава 11Возвращение к основам - Страница 37
- Глава 12Инструменты и процедуры - Страница 41
- Глава 13Основные риски проекта по разработке программного обеспечения - Страница 44
- Глава 14Уточненный процесс обнаружения рисков - Страница 49
- Глава 15Динамика управления рисками - Страница 53
- Глава 16Инкрементный метод для ослабления рисков - Страница 55
- Глава 17Стратегия максимального ослабления рисков - Страница 59
- Часть IVСколько? - Страница 61
- Глава 18Количественная оценка ценности - Страница 62
- Глава 19Ценность – это тоже неопределенность - Страница 65
- Глава 20Анализ чувствительности - Страница 67
- Глава 21Выгоды возмещают риски - Страница 69
- Глава 22Уточнение правил управления рисками - Страница 70
- Часть VТак есть или нет? - Страница 72
- Глава 23Тест на управление риском - Страница 73
- Приложение АВильям Кингдон КлиффордЭтика веры, Часть 1 - Страница 75
- Приложение БШаблон для описания риска - Страница 79
- Ссылки - Страница 80

Здесь диапазон неопределенности представляется разумной долей от длительности с начала проекта до N.
Но предположим вместо этого, что ваша диаграмма риска выглядит так:

Совсем несимпатично в этой картинке то, что неопределенность слишком велика по сравнению с интервалом от начала проекта до N.
Если вы такой же, как и остальные из нас, руководителей проектов по созданию программного обеспечения, то вам комфортно при допуске порядка 10-15% времени от интервала с начала проекта до N и тревожно при любых больших значениях, то есть тревога возрастает по мере роста диапазона допуска свыше 15%.
Неудачи прежних проектов и их политики приучили нас к мысли, что подходящим диапазоном допуска является 10-15% от интервала с начала проекта до N. То, что больше, кажется неправильным, каким-то недисциплинированным. Многие руководители даже считают это признаком слабости управления.
Однако всё это не имеет никакого значения. Размер вашего допуска неопределенности является производным от того, сколь велик шум (отклонения) в процессах разработки, принятых в вашей организации, и не имеет никакого отношения к тому, что кому-то кажется подходящим.
Шум – источник отклонений от одного проекта к другому, объяснение того, почему некоторые проекты занимают больше времени, несмотря на все ваши усилия. До некоторой степени шум является количественной оценкой последствий прошлых рисков, величина шума может быть эмпирически определена для любой организации, которая ведет хотя бы элементарные записи деятельности. Эта цифра устанавливает, сколько неопределенности должно быть в вашем следующем проекте. Другими словами, ваша прежняя деятельность определяет размер диапазона допуска.
В целом для отрасли, производящей программное обеспечение, диапазон допуска составляет порядка 150-200% от интервала с начала проекта до N. Таким образом, у проекта с N, приходящимся на 25-е число какого-то месяца, дальний конец диапазона кривой неопределенности придется на 75-е число. От вас не требуется испытывать восторг по этому поводу. Просто так устроен мир. Бесполезно притворяться, что дело обстоит иначе.