Это – странный, но верный расчет как правило, гораздо важнее ограничивать уровень потерь в процессе разработки программного обеспечения, чем идти на все ради победы. У каждой организации в этой области бизнеса случаются неудачи. Те, кто сильнее пострадал от своего поражения (как ДМА) – неудачники, даже если они в некоторых других случаях одерживали победы.
Когда вы требуете от своих подчиненных работать без остановок и выполнить проект вовремя любой ценой (даже если сроки абсурдны), вы должны понимать, что укомплектовываете ключевые должности гонщиками NASCAR. Они пойдут на любой риск, пренебрегая всевозможными срывами, ради того, чтобы сохранить (по крайней мере, как можно дольше удержать) любой малейший шанс на победу.
Назовите это, как хотите, но это не является управлением рисками.
Часть III
Как?
• Как мы решаем проблему управления рисками?
• Раз неизвестные нам неизвестны, как мы можем их количественно оценить?
• Какие существуют инструменты для этого?
• Откуда берутся данные для управления рисками?
• Что такое резервы на управление рисками, и как их используют?
• Что можно сделать в отношении риска, кроме отслеживания его?
• Что такое повторяющиеся риски проектов по разработке программного обеспечения, и что о них известно?
• Как мы вообще обнаруживаем риски?
Глава 8
Количественное определение неопределенности
Разработка программного обеспечения – рискованный бизнес, поскольку весь процесс окутан неопределенностями. Все, что нужно предсказать относительно проекта, будет в какой-то мере неопределенным. Но насколько именно?
Можно, оглянувшись на какой-то проект, сказать о его руководителе: «Она действительно не знала, когда работа будет завершена». Но что это значит? Насколько она была неуверенна? Возможно, она была уверена, что проект будет сделан примерно 6-го числа, но немного сомневалась, будет ли это несколькими днями раньше или позже. Или, возможно, она совсем понятия не имела о сроке завершения. Ясно, что между этими двумя уровнями неопределенности колоссальная разница. Представьте это так: вы – руководитель проекта, и вы стремитесь завершить проект по графику к 30-му октября. У вас есть четкое ощущение, что 30-е октября – абсолютно нереально, но точнее вы ничего сказать не можете. Вы совершенно беспомощны. Ваши подчиненные также в полном неведении. Таким образом, примерно в середине лета, уже отставая от срока на четыре месяца, вы приглашаете консультанта. Выбранный вами консультант – лучший в данной области, способный правильно оценить проект даже во сне и определить его состояние. Через несколько дней погружения в технические условия и промежуточные результаты, а также встреч с исполнителями и акционерами, он заявляет напрямик:
«Слушай, шансов завершить до начала следующего года – никаких. Наиболее вероятная дата поставки приемлемого продукта – начало апреля в следующем году. Но и эта дата не абсолютно надежна. Возможно, лучше назначить срок сдачи не раньше чем на 1-е мая. По крайней мере, при дате 8 мая или позднее у вас шансы завершить проект выше, чем 50 на 50. Если нужно назначить дату, чтобы было практически невозможно не успеть к этому сроку, то стоит назначить конец декабря следующего года».
Вы пригласили консультанта, потому что были неуверенны относительно даты завершения проекта, но консультант и сам проявил некоторую неуверенность. Разница между вашей неопределенностью (полном отсутствием представления) и его (описанной в предыдущем абзаце) состоит в том, что его неопределенность заключена в четкие рамки.
Возьмем оценку, данную консультантом, и отобразим ее на графике. Поскольку все, что он сказал, относится к вероятностным суждениям («нет шанса завершить работу до начала следующего года», шансы выше, чем 50 на 50» и т.д.), график будет показывать уверенность/неуверенность как вероятность поставки готового продукта на любую рассматриваемую дату. Мы продлим график в обе стороны, чтобы он охватывал весь диапазон: от совершенно нереальных до полностью гарантированных сроков. Итак, отложим на вертикальной оси вероятность, а по горизонтали разместим даты. Вот пустой график, на котором отмечены только четыре даты, прямо упомянутые консультантом:
Консультант сказал, что вероятность завершения проекта равна нулю для всех дат до 1 января, но счел почти невероятным предположение, что после 31 декабря следующего года потребуется дополнительное время (поскольку был практически уверен, что проект будет к этому сроку завершен); наиболее вероятной датой завершения проекта он назвал 1 апреля. Исходя из этого, можно заполнить эти два полуинтервала и обозначить пик кривой. Поскольку на вертикальной оси пока не задан масштаб, можно поместить пик произвольно, не заботясь о его точном значении. Это выглядит так: