Вальсируя с медведями

Управление рисками – то, чем большинство из нас занимается постоянно, причем везде, кроме своего рабочего места. В нашей личной жизни нам постоянно грозят болезни и ранняя смерть. Мы ослабляем риск, застраховав жизнь и здоровье и сделав распоряжения относительно того, кто позаботится о наших детях, если с нами что-то случится. Мы не притворяемся бессмертными и не делаем вид, что наша способность заработать себе на жизнь не может пострадать от какого-то несчастья. Каждый раз, когда мы взваливаем на себя новую ответственность (скажем, беря кредит под залог жилья), мы продумываем всякие возможные кошмары, которые могут приключиться, при этом надеясь, что ничего такого не произойдет, но заставляя себя продумать, что будет, если произойдет. Как мы увидим, управление рисками на рабочем месте включает несколько особых проблем.

Особая проблема немыслимых рисков

Некоторые риски, с которыми сталкивается проект, могут стать для него роковыми. Под этим мы понимаем крушение надежд и чаяний в первую очередь тех, кто дал жизнь этому проекту. Этими рисками особенно важно управлять, но разумное управление ими может привести к конфликту с установленными нормами корпоративной культуры. Ваш проект мог быть поставлен в жесткие временные рамки публичными, широко освещенными в прессе заявлениями первого лица компании о том, что продукт будет выпущен к определенной дате. Широко оповестив об этой дате, руководитель компании попытался сделать отставание от графика немыслимым.

Как известно, объявление нежелательного события немыслимым не делает его невозможным. Но это делает практически невозможным управление рисками. Рассмотрим пример в следующей главе…

Глава 3Пересмотр истории международного аэропорта в Денвере

В городе Денвер (штат Колорадо) в 1988 году было принято решение построить новый аэропорт вместо существующего Стапльтонского аэропорта. Стапльтонский сочли неспособным к расширению, а в существующем виде он не отвечал потребностям растущего крупного города и способствовал все более очевидному загрязнению окружающей среды (а также был чрезмерно шумным). Новый аэропорт должен был стать более экономичным, покончить с загрязнением среды и задержкой рейсов и иметь возможности для необходимого роста. Новый Денверский международный аэропорт (ДМА) по графику собирались открыть 31 октября 1993 года. Так было запланировано.

Другая неприятность

Все было подогнано для того, чтобы поспеть к сроку: все шло отлично, но эти проклятые разработчики программного обеспечения опять подвели… 31 октября 1993 года весь огромный комплекс аэропорта был готов к пуску… по-честному готов. На самом деле. Можете поверить. Весь, кроме части программного обеспечения, и из-за нее аэропорт не мог открыться!

Точнее, не была готова вовремя злосчастная система автоматической обработки багажа. Аэропорт не мог открыться без работающего программного обеспечения для обработки багажа[11]. Поскольку строительство аэропорта связано с огромными вложениями капитала, то весь этот капитал был заморожен, пока эти программисты второпях пытались играть в догонялки. А время – деньги. Это был прямой удар по налогоплательщикам. Тут не нужны замысловатые рассуждения, все просто, как на картинке:

И все это по вине тех самых отвратительных разработчиков программного обеспечения.

Такое упрощенное видение (деньги прямиком летят в контейнер для мусора) было характерно для освещения в газетах и журналах проблем ДМА с первого признака задержки в начале 1993 года до частичного открытия в 1995 году. Столько клеймили команду разработчиков, что и сегодня слова «система автоматической обработки багажа ДМА» – узнаваемый символ некомпетентного проекта по разработке программного обеспечения.

Статья в журнале «Scientific American» открыто возлагала ответственность за разочарования, связанные с ДМА, на всю отрасль разработки программного обеспечения с ее нечеткими стандартами и практикой:

«В сфере производства программного обеспечения годами (возможно, десятилетиями) ощущается нехватка зрелой технологической дисциплины, соответствующей требованиям информационного общества»[12].

Статья утверждала, что все дело было в технологическом процессе. По мнению авторов этой статьи, задержки пуска ДМА можно было легко избежать, если бы в проекте были лучше прописаны процессы, чтобы включать:

1. более высокий уровень модели зрелости процессов (СММ).

2. большее использование формальных методов.

3. формализованные языки спецификации (типа В и VDM).

Но является ли это на самом деле проблемой технологических процессов?

То, что стоит за процессами.