В конце концов Гери и Тойота добились того, что время реверберации[22]
стало равным 2,2 секунды для пустого зала и 2 секунды – для полного, что считается оптимальным для оркестровой музыки. Когда зал на 2265 мест был построен, Филармоническому оркестру Лос-Анджелеса предоставили четыре месяца, чтобы привыкнуть к его новой площадке. Оркестранты были очень довольны новым помещением. «Самое прекрасное в этом зале – натуральность звука», – заявил в интервью PBS дирижер оркестра Еса-Пекка Салонен. До этого коллектив выступал в павильоне Чандлера, расположенном напротив. Акустика Дисней-холла позволила Салонену расширить репертуар оркестра, включив в него «Песни Гурре» Шёнберга. «Я просто обожаю наш новый концертный зал, и это правда, – не переставал радоваться Салонен. – У нас не только взлетели продажи билетов. Отныне жители Лос-Анджелеса и туристы смогут познакомиться с новой музыкой и получить незабываемые впечатления».Во время работы над проектом здания Гери и его команда постоянно проверяли его на соответствие требованиям. Один из способов такой проверки заключался в использовании электронной ручки для сканирования и оцифровки каждой модели и перевода данных в компьютер с помощью специального программного обеспечения, которое называется Digital Project. Сканирование производилось вручную. Это программное обеспечение, изначально разработанное для предприятий, занимающихся проектированием космических летательных аппаратов, впоследствии стало использоваться при работе с картами и в промышленном дизайне. С помощью этой программы можно на стадии проектирования проверять соответствие проекта требованиям, в том числе высчитывать общую площадь, объем и площадь облицовки здания. Гери специально подчеркивает, что точность этого программного обеспечения – семь знаков после запятой.
То, что во время работы над проектом можно учитывать его соответствие конкретным требованиям, постоянно получая представление об особенностях его структуры, не означает, что все так просто; на самом деле этот процесс может очень сильно изматывать. После оцифровки макета и внесения его параметров в компьютер часто оказывается, что параметры здания превышают заданные, и коллег Гери это не сильно вдохновляет. «В таких случаях я говорю им: “Бог мой, дизайн здания выглядит отлично, но, видимо, нам действительно придется отнять тут десять процентов”». Такой подход крайне важен и позволяет проектировщикам с подъемом исправлять проект. Архитектурные планы разрабатываются с учетом требований заказчика, учитывая все подробности до мелочей – где будут находиться титановые панели, а где каменные блоки. Эти требования помогают Гери решить, что именно ему надо делать и чего делать не надо.
Учет заданных параметров предусматривает действие. В некоторых областях, как, например, в архитектуре, требования к проекту, как правило, выдвигаются заказчиком. Бывает и так, что количество возможных вариантов не ограничено, например в случае «чистого листа». И тогда использование ограничительных условий, определенных самостоятельно, особенно эффективно. Суть этого метода заключается в том, что весь проект или основная задача разбиваются на более мелкие блоки и ограничения накладываются на каждый в отдельности, затем, по мере его решения, на следующий и так далее.
Такая стратегия, когда проект разбивают на составляющие, на относительно несложные задачи, с которыми проще справиться, и есть то, что Бинг Гордон, сооснователь и бывший креативный директор компании по разработке видеоигр Electronic Arts, называет
Сегодня подобная практика дробления проблем в Кремниевой долине общепринята, и большинство директоров называют ее одним из важнейших новых веяний в индустрии программного обеспечения – методом гибкой разработки программного обеспечения. Этот метод был предложен в 2001 году Кентом Беком, Алистером Кокбёрном и Джефом Сазерлендом при участии четырнадцати других разработчиков. Они считали, что процесс разработки должен разбиваться на мелкие составные части, в ходе его должны определяться приоритеты, а окончательные варианты выпускаемых программных продуктов должны отвечать запросам пользователей. Вместо стандартного процесса или заблаговременного планирования они стали формировать небольшие команды разработчиков, способные быстро реагировать на изменения в проекте. По их мнению, единственным критерием прогресса в проекте могут быть только законченные, функциональные программы.