Вальсируя с медведями
Добавить в закладки К обложке
- Вступительное замечание авторов - Страница 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
Ладно, посмотрим фактам в лицо: заставить заказчиков предсказывать выгоды – все равно, что удалять зубы. Это большой объем работы, открывающий дверь дополнительному уровню ответственности, причем усилия тех, кто подставляет себя под удар и занимается количественной оценкой, явно не окупятся. Если среди полезных функций затесались «прибамбасы», то люди, которые должны сделать количественную оценку, вполне могут оказаться теми, кто потеряет свои любимые игрушки. Можно ожидать практически от любого заказчика яростных возражений и уверений самым серьезным тоном, что «все это необходимо для поддержки основной функциональности, честное слово». Это та же самая старая и надоевшая песня про равномерно распределенную стоимость, но не рассчитывайте их в этом убедить.
Может быть, вам и не придется. Польза от частичных данных «выгоды/затраты» состоит в том, что они позволяют упорядочить компоненты для включения в версии. Получить точные оценки было бы отлично, но если их приобрести нельзя, то не устроит ли вас вместо этого упорядочение?
Сам факт, что вы собираетесь сдавать проект по частям, дает вам рычаг для получения инструкций по упорядочению даже от самых упрямых заказчиков. В конце концов, некоторые части системы обязательно придется внедрять после каких-то других. Одни части будут первыми, а другие – последними. Если вы отдадите это решение в руки своим заказчикам, они кинутся рассказывать вам о порядке осуществления. Все знают, что порой системы опаздывают и «первые» части могут оказаться готовыми к изначально определенному сроку, а вот «последние» еще не будут готовы. Редкий пользователь не сумеет воспользоваться преимуществами этого дополнительного уровня управления, несмотря на то, что использование этого является признанием неравномерной концентрации ценности в разных частях системы.