Вальсируя с медведями
Добавить в закладки К обложке
- Вступительное замечание авторов - Страница 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
К несчастью, так редко бывает. Люди обязаны прийти к соглашению. Они обязаны сотрудничать. Когда существует глубокий конфликт, не позволяющий им это сделать, то часто результат маскируют. Проект продолжают с неправильными, двусмысленными целями, которые не радуют никого, но с которыми обе стороны готовы мириться, по крайней мере, до поры.
Пусть, например, конфликт возник по поводу того, кто из участников проекта должен управлять определенной ключевой порцией данных. Спецификации искусственно избегают определения того, где будут находиться данные, какие разрешения требуются для их изменения, какие сотрудники отслеживают эти данные, частью какого архива они должны стать, когда и как их могут замещать и т.д. Люди ворчат по поводу спецификаций, поскольку они не очень-то ясны. Но сохраняется то преимущество, что там не содержится ничего явно неприемлемого для какой-то из сторон. Проект переходит (или кажется переходящим) на стадию внутреннего конструирования и внедрения.
Замаскированная проблема уходит на время, но не навсегда. Хотя возможно описать (специфицировать) продукт двусмысленно, но невозможно создать продукт неоднозначным. В итоге приходится столкнуться с отложенными проблемами, и конфликт разгорается вновь. В худшем случае это происходит на очень поздней стадии проекта, когда потрачены почти все (или совсем все) отведенные на проект ресурсы (деньги и время). Проект очень уязвим в этой стадии, и отказ любой из сторон поддерживать его может привести к быстрому прекращению. Проект успешно уничтожен, без необходимости кому-то признаваться в том, что реальной проблемой было недостаточное согласование.
Нарушение спецификаций проявляется и по-другому. Например, в том, что гуру менеджмента Питер Кин (Peter Keen) называет контр-осуществлением, когда недовольные участники проекта перегружают проект все большим и большим количеством функций. Функции A-F используют для оправдания проекта. Но потом те, кто кажется энтузиастами-сторонниками проекта, добавляют функции G-Z. С таким объемом добавленных функций нет надежды на выгоду, превосходящую затраты. Такого рода «заваливание» обычно происходит в конце работы по анализу и приводит к невозможности договоренности по спецификациям.
Около седьмой части всех проектов в нашей базе данных были прекращены без поставки какого бы то ни было продукта. У других исследователей есть другие оценки доли прекращенных проектов, но большинство попадают в диапазон 10-15%. Мы взяли среднее значение от этого процентного диапазона прекращения проектов и рассматриваем его как фиксированный риск нарушения спецификаций. Для простоты мы предположили, что нарушение спецификаций – единственная причина прекращения проекта. (Возможно, вы сумеете найти где-то проект, прекращенный по причинам, не имеющим ничего общего с конфликтом сторон, но все же постарайтесь убедиться, что заявленная причина не является просто маскировкой глубинного отсутствия согласия между сторонами).
Проявление этого главного риска также уникально в своем роде. Мы предлагаем приписывать этот риск каждому новому проекту, пока не происходит четкого прекращения прений по поводу спецификаций. После чего риск можно убрать.
Для рассмотрения проблемы неоднозначности, используемой для сокрытия разногласий, определим прекращение прений по поводу спецификаций как то, что все стороны подписались под входными и выходными граничными условиями проекта и определениями данных, вплоть до данных элементарного уровня из всех входящих и исходящих потоков данных.
<…>
ными или функциям для создания данных. Хотя соглашение по потокам данных может быть только частью требуемого согласования, но это – ключевая часть. Поскольку описания данных менее склонны к неоднозначности, чем описания функций, мы смело заключаем, что отказ от претензий по входящим и исходящим потокам данных является хорошим показателем согласия. Когда такое согласие достигнуто, риск прекращения следует исключить из рассмотрения.
В этом есть некий псевдонаучный момент, который нельзя обойти вниманием. Мы проигнорировали дополнительные причины прекращения проекта и создали свой симулятор «RISKOLOGY» таким образом, что он вынуждает вас столкнуться с возможностью прекращения проекта, пока не пройдено контрольное событие, обозначающее окончание угрозы, после чего предполагается нулевой риск прекращения проекта. Это – весьма грубый подход к деликатному предмету прекращения проектов, оправданный лишь тем, что очень высока доля проектов, в конце концов прекращенных, для которых оказалось невозможным достичь соглашения, необходимого для наступления данного контрольного события.