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

Глава 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 млн. долларов дополнительного финансирования, могли быть отнесены к запаздыванию единственного ключевого элемента.

Тогда зададим себе несколько важнейших вопросов:

1. Почему нельзя было открыть аэропорт без этого программного обеспечения? Есть простой ответ: программное обеспечение для обработки багажа было на критическом пути этого проекта по открытию аэропорта. Это было настолько существенно для функционирования аэропорта, что члены управляющего совета считали, что без этой системы невозможно ни одного дня пропускать пассажиров через аэропорт.

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

3. Не было ли альтернативных способов обработки багажа? Разумеется, были. Например, проверенный временем способ привлечения дюжих парней для транспортировки багажа. Есть и привычный способ использования небольших грузовичков, тянущих соединенные в гирлянду тележки, загружаемые вручную.

4. Когда автоматизированная система оказалась не готова вовремя, почему нельзя было открыть ДМА, используя один из альтернативных способов транспортировки багажа? Ээээ… Хм. Туннели, предназначенные для обслуживания автоматизированной системой дистанционно управляемых тележек, были слишком низкими для людей и не могли вместить грузовички. Поэтому должна была работать автоматизированная система.

5. Нельзя было переделать туннели, чтобы управляемые людьми грузовички и тележки могли по ним двигаться? Можно, но не было времени. К моменту, когда стало понятно, что программное обеспечение запаздывает, туннели уже были построены. А времени на переделку потребовалось бы больше, чем на доведение программного обеспечения.

6. Нельзя ли было начать переоборудование туннелей раньше? Можно, но это не сочли подходящим решением. Если бы программное обеспечение было произведено вовремя, в чем заверяло тогда высшее руководство, то деньги и время на переделку туннелей оказались бы потраченными зря.

7. Рассматривалась ли задержка программного обеспечения для обработки багажа как потенциальный риск? Только после того, как это случилось. До этого программное обеспечение разрабатывалось по жесткому графику, и все было нацелено на его успешное выполнение.

8. Случались ли прежде задержки проектов по разработке программного обеспечения? Да, но на этот раз рассчитывали, что будет иначе.

9. Существовала ли история разработки подобных систем? Да. В аэропорту Франца-Иосифа Штрауса в Мюнхене была установлена пилотная автоматизированная система обработки багажа, разработанная по тому же типу.

10. Ознакомилась ли команда разработчиков ДМА с мюнхенским проектом, и, если да, то чему это ее научило? Разработчики программного обеспечения для обработки багажа в ДМА посетили Мюнхен. Разработчики мюнхенского программного обеспечения потратили полных два года на тестирование системы и шесть месяцев на окончательную отладку в режиме круглосуточного функционирования системы перед окончательной сдачей. Они советовали коллегам из ДМА отвести на это времени никак не меньше, а при возможности – даже больше.

11. Последовало ли руководство ДМА этому совету? Поскольку время для такого обширного тестирования и отладки не было запланировано, предпочли обойтись без этого.

12. Делала ли команда проекта достаточно внятные предупреждения об угрожающем запаздывании? Прежде всего, невидимая рука рынка сделала важный жест прямо в самом начале. Когда Совет управляющих ДМА первый раз объявил тендер на выполнение этой системы программного обеспечения, никто не хотел подавать заявку при указанной дате поставки готового продукта. Все подрядчики считали, что начинать проект при таком расписании было надежным способом навлечь на себя неизбежные неприятности.

В конце концов, аэропорт подрядил компанию «BAE Automated Systems» на выполнение этого проекта по принципу «наибольших усилий» (без гарантий). Почти с самого начала работы над проектом подрядчик начал регулярно уведомлять, что дата сдачи под угрозой и проект с каждым месяцем и каждым новым изменением все больше отстает от графика. Все участники были поставлены в известность, что делается попытка выполнить четырехлетний проект в два года и что подобные усилия редко увенчиваются своевременным результатом. Все это было проигнорировано.

Несоблюдение практики управления рисками

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

Анализ воздействия данного риска показал бы, что из-за того, что это программное обеспечение было на критическом пути, любая задержка отложит открытие аэропорта, приведя к финансовым штрафам по 33 млн. долларов в месяц (эту величину инвестиционных издержек легко было вычислить с самого начала). Из этого с очевидностью следовало, что главной стратегией ослабления риска является снятие разработки программного обеспечения с критического пути. Несколько миллионов долларов, потраченных в начале проекта на обеспечение возможных альтернативных систем обработки багажа, сберегли бы полмиллиарда долларов, в которые обошлась задержка разработки программного обеспечения.

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

Итак, чья же в этом вина?

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

В данном случае все издержки в конечном счете падали на головное агентство «Denver Airport System», которое было частью городского управления. Таким образом, городские власти Денвера несли ответственность за управление финансовыми рисками, к чему они не приложили ни малейших усилий.