Вальсируя с медведями - [8]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Требования к системе: Что именно должна делать система?

2. Обеспечение стандартов взаимодействия: Как будет система взаимодействовать с людьми-операторами и другими системами того же уровня?

3. Влияние изменяющейся среды: Как во время разработки будут изменяться потребности и цели?

4. Ресурсы: Какие ключевые навыки и знания исполнителей возможно будет (при необходимости) привлечь по мере продвижения работы над проектом?

5. Управление: Хватит ли у руководства таланта, чтобы создать эффективные команды, поддерживать боевой дух, обеспечивать низкую текучесть кадров и координировать сложные комплексы взаимосвязанных задач?

6. Сеть поставок: Будут ли другие участники проекта действовать так, как ожидалось?

7. Политика: Каков может быть результат использования политической силы для навязывания ограничений, несовместимых с успехом проекта?

8. Конфликты: Как различные участники проекта найдут компромисс между своими, зачастую несовместимыми, целями?

9. Инновации: Как уникальные для данного проекта технологии и методы влияют на возможный результат?

10. Масштаб: Как повлияет на осуществление проекта увеличение масштаба работ, если раньше у разработчика не было соответствующего опыта?

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

Управление рисками при строительстве ДМА

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

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