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

Дата теперь фиксирована, и неопределенность полностью относится к тому, что именно будут сдавать в этот день. Если ни один риск не наступит, могут быть сданы все версии от 1 до 24 (представленные как В24). Поскольку шансы избежать все риски крайне малы, это нанопроцентная функциональность – не то, чтобы невозможно, но исключительно неправдоподобно. Если судить по площади под кривой слева от В21, вероятность сдать все версии от 1 до 21 становится примерно 50%-ной к этой дате. Если участники проекта непреклонны в том, что для них не подойдет ничего, что будет меньше, чем В22, то диаграмма показывает, что вероятность предоставить им то, что они хотят, едва достигает 30%. Опять же, хотя это может оказаться неприятной новостью, скрывать ее – лишь отложить (и усугубить) день окончательной расплаты.
Здесь нужно сделать три предостережения: во-первых, этот подход осмыслен, только если заранее предполагается строго пошаговая разработка и вы заранее твердо определили, каким будет функционал каждой версии. Если вы собирались поставить всего две-три версии, полученная диаграмма неопределенности практически бессмысленна. А если вы откладываете решение того, какие функции будут включены в какую из версий, то пользователи не смогут определить, какие функции под угрозой риска.
Во-вторых, берегитесь проекта, который представлен как имеющий фиксированный срок сдачи, но на самом деле его не имеет: