• анализ воздействия риска: количественная оценка каждого риска в терминах вероятности его наступления и потенциального ущерба.
• планирование реагирования на риски: что вы собираетесь делать, если и когда данный риск наступит.
• ослабление риска: меры, которые должны быть приняты предварительно, чтобы обеспечить возможность и эффективность проведения запланированных действий, если они потребуются.
• мониторинг и управление рисками: отслеживание рисков, выделенных в качестве объектов управления, выявление материализации рисков.
Первый пункт является действием общего характера, а остальные осуществляются по каждому из рисков.
Еще раз о том же
Управление рисками — то, чем большинство из нас занимается постоянно, причем везде, кроме своего рабочего места. В нашей личной жизни нам постоянно грозят болезни и ранняя смерть. Мы ослабляем риск, застраховав жизнь и здоровье и сделав распоряжения относительно того, кто позаботится о наших детях, если с нами что-то случится. Мы не притворяемся бессмертными и не делаем вид, что наша способность заработать себе на жизнь не может пострадать от какого-то несчастья. Каждый раз, когда мы взваливаем на себя новую ответственность (скажем, беря кредит под залог жилья), мы продумываем всякие возможные кошмары, которые могут приключиться, при этом надеясь, что ничего такого не произойдет, но заставляя себя продумать, что будет, если произойдет. Как мы увидим, управление рисками на рабочем месте включает несколько особых проблем.
Особая проблема немыслимых рисков
Некоторые риски, с которыми сталкивается проект, могут стать для него роковыми. Под этим мы понимаем крушение надежд и чаяний в первую очередь тех, кто дал жизнь этому проекту. Этими рисками особенно важно управлять, но разумное управление ими может привести к конфликту с установленными нормами корпоративной культуры. Ваш проект мог быть поставлен в жесткие временные рамки публичными, широко освещенными в прессе заявлениями первого лица компании о том, что продукт будет выпущен к определенной дате. Широко оповестив об этой дате, руководитель компании попытался сделать отставание от графика немыслимым.
Как известно, объявление нежелательного события немыслимым не делает его невозможным. Но это делает практически невозможным управление рисками. Рассмотрим пример в следующей главе…
Глава 3
Пересмотр истории международного аэропорта в Денвере
В городе Денвер (штат Колорадо) в 1988 году было принято решение построить новый аэропорт вместо существующего Стапльтонского аэропорта. Стапльтонский сочли неспособным к расширению, а в существующем виде он не отвечал потребностям растущего крупного города и способствовал все более очевидному загрязнению окружающей среды (а также был чрезмерно шумным). Новый аэропорт должен был стать более экономичным, покончить с загрязнением среды и задержкой рейсов и иметь возможности для необходимого роста. Новый Денверский международный аэропорт (ДМА) по графику собирались открыть 31 октября 1993 года. Так было запланировано.
Другая неприятность
Все было подогнано для того, чтобы поспеть к сроку: все шло отлично, но эти проклятые разработчики программного обеспечения опять подвели… 31 октября 1993 года весь огромный комплекс аэропорта был готов к пуску… по-честному готов. На самом деле. Можете поверить. Весь, кроме части программного обеспечения, и из-за нее аэропорт не мог открыться!
Точнее, не была готова вовремя злосчастная система автоматической обработки багажа. Аэропорт не мог открыться без работающего программного обеспечения для обработки багажа[11]. Поскольку строительство аэропорта связано с огромными вложениями капитала, то весь этот капитал был заморожен, пока эти программисты второпях пытались играть в догонялки. А время — деньги. Это был прямой удар по налогоплательщикам. Тут не нужны замысловатые рассуждения, все просто, как на картинке:
И все это по вине тех самых отвратительных разработчиков программного обеспечения.
Такое упрощенное видение (деньги прямиком летят в контейнер для мусора) было характерно для освещения в газетах и журналах проблем ДМА с первого признака задержки в начале 1993 года до частичного открытия в 1995 году. Столько клеймили команду разработчиков, что и сегодня слова «система автоматической обработки багажа ДМА» — узнаваемый символ некомпетентного проекта по разработке программного обеспечения.
Статья в журнале «Scientific American» открыто возлагала ответственность за разочарования, связанные с ДМА, на всю отрасль разработки программного обеспечения с ее нечеткими стандартами и практикой:
«В сфере производства программного обеспечения годами (возможно, десятилетиями) ощущается нехватка зрелой технологической дисциплины, соответствующей требованиям информационного общества»[12].
Статья утверждала, что все дело было в технологическом процессе. По мнению авторов этой статьи, задержки пуска ДМА можно было легко избежать, если бы в проекте были лучше прописаны процессы, чтобы включать:
1. более высокий уровень модели зрелости процессов (СММ).
2. большее использование формальных методов.
3. формализованные языки спецификации (типа В и VDM).
Но является ли это на самом деле проблемой технологических процессов?
То, что стоит за процессами.
Допустим, что у вас имеется абсолютно совершенный процесс разработки программного обеспечения. Устранит ли это всю неопределенность в нашем проекте? По сути, речь о том, является ли процесс разработки программного обеспечения хотя бы одним из главных источников неопределенности? Мы полагаем, что нет. Среди наиболее важных источников неопределенности можно назвать:
1. Требования к системе: Что именно должна делать система?
2. Обеспечение стандартов взаимодействия: Как будет система взаимодействовать с людьми-операторами и другими системами того же уровня?
3. Влияние изменяющейся среды: Как во время разработки будут изменяться потребности и цели?
4. Ресурсы: Какие ключевые навыки и знания исполнителей возможно будет (при необходимости) привлечь по мере продвижения работы над проектом?
5. Управление: Хватит ли у руководства таланта, чтобы создать эффективные команды, поддерживать боевой дух, обеспечивать низкую текучесть кадров и координировать сложные комплексы взаимосвязанных задач?
6. Сеть поставок: Будут ли другие участники проекта действовать так, как ожидалось?
7. Политика: Каков может быть результат использования политической силы для навязывания ограничений, несовместимых с успехом проекта?
8. Конфликты: Как различные участники проекта найдут компромисс между своими, зачастую несовместимыми, целями?
9. Инновации: Как уникальные для данного проекта технологии и методы влияют на возможный результат?
10. Масштаб: Как повлияет на осуществление проекта увеличение масштаба работ, если раньше у разработчика не было соответствующего опыта?
Даже самый совершенный процесс разработки не может полностью устранить неопределенность при осуществлении проектов по созданию сложных систем. А где есть неопределенность, там появляется риск. При наличии риска нужны осторожные и продуманные усилия, чтобы с ним справиться. Вместо того, чтобы спрашивать: «Как они справлялись с созданием программного обеспечения?», можно гораздо глубже понять, что произошло при строительстве ДМА, задав вопрос: «Как они справлялись с управлением имевшимися рисками?»
Управление рисками при строительстве ДМА
Кратко описав события строительства ДМА, мы просили принять на веру часто повторявшееся утверждение, что аэропорт был на 100% готов к открытию, за исключением программного обеспечения для обработки багажа, но что аэропорт нельзя было вообще открыть без этого программного обеспечения. Теперь давайте рассмотрим это утверждение подробнее.
Прежде всего, возможно, не было вполне правдивым утверждение, что все остальные части проекта были завершены. Возможно, система обработки багажа была не единственной оставшейся, а лишь наиболее заметной из незавершенных частей. Возможно, весь график был нереальным, и все запаздывали. Когда такое происходит, обычной уловкой для руководителей различных частей проекта является попытка изобразить полную готовность в надежде, что кто-то другой провалит дело первым. Когда кто-то, наконец, оказывается крайним, другие изображают негодование, а сами бешено спешат использовать дополнительное время, чтобы доделать свою часть работы. Возможно, именно это и происходило при строительстве ДМА. Но предположим в интересах нашего анализа, что было не так. Поверим остальным руководителям на слово и допустим, что аэропорт можно было бы открывать, если бы не задержка программного обеспечения для автоматизации обработки багажа. Обшие затраты, вызванные задержкой, составившие более 500 млн. долларов дополнительного финансирования, могли быть отнесены к запаздыванию единственного ключевого элемента.
