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