Мифический человеко-месяц или как создаются программные системы

      Не только формальное определение является реализацией, но и реализация может служить формальным определением. Когда были созданы первые совместимые компьютеры, использовалась именно эта технология. Новая машина должна была соответствовать имеющейся. Руководство туманно в некоторых местах? Задайте вопрос машине! Создавалась тестовая программа для выяснения поведения, и новая машина строилась так, чтобы достигалось соответствие.
      Программная модель аппаратной или программной системы может использоваться точно таким же образом. Это — реализация. Она работает. Поэтому все вопросы, связанные с определением, могут быть решены путем проверки.
      Использование реализации в качестве определения имеет некоторые преимущества. Все проблемы можно однозначно решить путем эксперимента. Дискуссий не требуется, поэтому ответ получается быстро. Ответ может быть сколь угодно точным и, по определению, всегда является правильным. С другой стороны, есть
      значительное количество недостатков. Реализация может переопределять даже внешние спецификации. Даже при ошибочном синтаксисе всегда получается некоторый результат; в контролируемой системе этот результат является указанием на ошибку и ничем больше. В неконтролируемой системе могут возникнуть любые побочные эффекты и быть использованы программистами. Когда мы, например, эмулировали IBM 1401 на System/360, выявилось 30 различных «курьезов» — побочных эффектов предположительно незаконных операций, которые широко использовались и должны были быть признаны частью определения. Реализация в качестве определения возобладала. Она не только говорила о том, что должна делать машина, но и многое сказала о том, как машина не должна была это делать.
      Кроме того, на проницательные вопросы реализация иногда дает неожиданные ответы, и определение де-факто часто оказывается неизящным в этих особых случаях потому, что над ними никогда не задумывались. Копирование этой неэлегантности в другой реализации часто оказывается замедляющим или дорогостоящим. Например, в некоторых машинах в регистре множимого после умножения остается мусор. Точная природа этого мусора становится частью определения де-факто, однако его копирование может помешать использованию более быстрого алгоритма умножения.
      Наконец, использование реализации в качестве формального определения может создать неясность, какое из описаний — текстовое или формальное — в действительности является стандартом. Это относится особенно к программным моделям. Следует также воздерживаться от внесения изменений в реализацию, пока она служит в качестве стандарта.
       Прямое включение
      У архитекторов программных систем есть чудесный метод распространения и внедрения определений. Он особенно полезен при установлении если не семантики, то синтаксиса межмодульных интерфейсов. Этот прием состоит в создании объявлений передаваемых параметров или совместно используемой памяти и требовании включения этих объявлений при операциях времени компиляции (макрос или %INCLUDE в PL/I). Если, кроме того, все ссылки на интерфейс происходят только по символическим именам, объявления можно менять, добавляя или вставляя новые имена и лишь заново компилируя, но не изменяя использующую его программу.
       Конференции и суды
      Нет нужды говорить о том, что совещания необходимы. Сотни частных консультаций должны дополняться крупными и более формальными собраниями. Мы признали полезными два уровня таких собраний. Первый – это еженедельная конференция всех архитекторов вместе с официальными представителями разработчиков аппаратной и программной части и сотрудниками маркетинга продолжительностью в половину рабочего дня под председательством главного архитектора системы.
      Предлагать задачи и изменения можно всем, но обычно предложения распространяются в письменном виде до совещания. Обычно новая задача некоторое время обсуждается. Упор делается на творческой стороне, а не просто на принятии решения. Группа пытается предложить несколько решений проблемы, затем ряд предложенных решений передается одному или нескольким архитекторам для разработки подробных и точно сформулированных предложений по внесению изменений в руководство.
      Подробные предложения об изменениях затем выносятся для принятия решения. Предложения тщательно изучаются исполнителями и пользователями, и выясняются все "за" и "против". Если возникает всеобщее согласие, все в порядке. В противном случае решение принимает главный архитектор. Ведется протокол, и решения формально, оперативно и широко распространяются.
      Решения еженедельных конференций дают быстрые результаты и позволяют продолжить работу. Если кто-то очень недоволен, допускается немедленная апелляция к менеджеру проекта, но это происходит очень редко.
      Плодотворность этих совещаний обусловлена несколькими причинами:
      1. Одна и та же группа – архитекторы, разработчики и исполнители – на протяжении месяцев встречаются между собой каждую неделю. Не требуется времени, чтобы ввести людей в курс дела.
      2. Группа состоит из предприимчивых, способных, хорошо осведомленных в вопросах и глубоко заинтересованных в конечном результате людей. Никто не участвует с "совещательным" голосом. Все уполномочены принимать на себя обязательства.
      3. При возникновении проблем решения ищутся как внутри, так и вне очевидных границ.
      4. Благодаря формализму письменных предложений сосредоточивается внимание, требуется принятие решения и устраняется несогласованность, свойственная черновым решениям комиссий.
      5. Открытое предоставление права принятия решения главному архитектору помогает избежать поиска компромиссов и задержек.
      Со временем выясняется, что некоторые решения не в полной мере выполняются. Тот или иной из участников так и не принял всей душой какую-либо мелочь. Другие решения породили непредвиденные проблемы, и еженедельное совещание отказывается повторно их рассматривать. Так возникает хвост из мелких возражений, открытых тем или раздражения. Для их урегулирования мы проводим ежегодные "сессии верховного суда", обычно продолжающиеся две недели. (Если бы я проводил их сейчас, то делал бы это раз в полгода.)
      Эти сессии проводились накануне важных дат окончательного принятия разделов руководства. Присутствовали не только представители программистов и проектировщиков по архитектуре, но и менеджеры программных, маркетинговых и реализационных проектов. Председательствовал менеджер проекта System/360. Повестка работы включала обычно около 200 пунктов, в основном мелких, перечисленных в развешанных по комнате списках. Заслушивались все стороны и принимались решения. Благодаря чуду компьютерной верстки (и превосходной работе сотрудников) каждое утро каждый участник обнаруживал на своем рабочем месте исправленное руководство, в которое были внесены решения, принятые накануне.
      Эти "осенние фестивали" были полезны не только для пересмотра решений, но и для того, чтобы они были приняты. Каждый был услышан, каждый принимал участие, каждый лучше понимал сложные ограничения и взаимосвязи между решениями.
       Множественные реализации
      У архитекторов System/360 было два почти беспрецедентных преимущества: достаточно времени для тщательной работы и такое же политическое влияние, как у проектировщиков. Наличие времени было обеспечено графиком по новой технологии; политическое равенство происходило благодаря одновременному созданию нескольких реализаций. Необходимость их строгой совместимости лучше всего способствовала исполнению спецификаций.
      В большинстве компьютерных проектов наступает день, когда оказывается, что машина и руководство по ее использованию не согласуются. В последующем конфликте обычно проигрывает руководство, поскольку его можно изменить значительно быстрее и меньшей ценой, чем машину. Однако это не так, если существует несколько реализаций. Тогда временные и финансовые издержки, связанные с исправлением машины с ошибками, могут быть ниже, чем связанные с переделкой машин, верно следовавших руководству.
      Это замечание можно с пользой применить при определении языка программирования. Можно с уверенностью утверждать, что рано или поздно потребуется создать несколько интерпретаторов или компиляторов для разных целей. Определение будет яснее, а дисциплина более крепкой, если изначально строятся как минимум две реализации.
       Журнал регистрации телефонных разговоров
      Какими бы точными не были спецификации, по ходу проектирования возникает несчетное множество вопросов касательно интерпретации архитектуры. Очевидно, многие из этих вопросов требуют более ясного изложения в тексте. Прочие просто отражают неправильное понимание.
      Важно, чтобы озадаченные исполнители звонили ответственным архитекторам и задавали вопросы, а не продолжали работу на основании догадок. Важно также понимать, что ответы на такие вопросы являются авторитетными заявлениями архитекторов и должны доводиться до всех.
      Полезным механизмом является ведение архитектором журнала регистрации телефонных разговоров, в который им заносятся все вопросы и ответы. Каждую неделю журналы нескольких архитекторов объединяются воедино, размножаются и распределяются среди пользователей и исполнителей. Несмотря на свою неформальность, такой механизм является и быстрым, и понятным.
       Тестирование продукта
      Лучший друг менеджера проекта — его постоянный противник, независимая организация, тестирующая продукт. Группа проверяет соответствие машин и продуктов спецификациям и выступает пособником дьявола, указывая на все замеченные дефекты и несоответствия. Каждой организации, ведущей разработки, нужна такая независимая группа технического аудита, которая должна быть неподкупна.
      Последний анализ в качестве независимого аудитора осуществляет покупатель. В безжалостном свете практического применения станет виден каждый огрех. Группа тестирования продукта как раз заменяет покупателя, настроенного на поиск ошибок. Время от времени тщательная проверка продукта обнаруживает места, где не услышали указание, где проектные решения поняли неправильно или выполнили неточно. Поэтому такая группа проверяющих является необходимым звеном в цепочке, по которой доходит слово проектировщика, звеном, которое должно начать действовать рано и одновременно с проектированием.

      На всей земле был один язык и одно наречие. Двинувшись с востока, они нашли в земле Сеннаар равнину и поселились там. И сказали друг другу: наделаем кирпичей и обожжем огнем. И стали у них кирпичи вместо камней, а земляная смола вместо извести. И сказали они: построим себе город и башню, высотою до небес, и сделаем себе имя прежде, нежели рассеемся по лицу всей земли. И сошел Господь посмотреть город и башню, которые строили сыны человеческие. И сказал Господь: вот, один народ, и один у всех язык; и вот что они начали делать, и не отстанут они от того, что задумали делать; сойдем же и смешаем там язык их, так чтобы один не понимал речи другого. И рассеял их Господь оттуда по всей земле; и они перестали строить город
      КНИГА БЫТИЯ 11:1-8

       Аудит менеджмента Вавилонского проекта
      Согласно Книге бытия, Вавилонская башня была вторым крупным инженерным предприятием человека после Ноева ковчега. Вавилонская башня стала первым инженерным фиаско.
      Эта история глубока и поучительна в нескольких отношениях. Давайте, однако, рассмотрим ее как чисто технический проект и посмотрим, какие уроки администрирования можно из нее извлечь. Насколько хорошо проект был обеспечен необходимыми составляющими успеха? Имелись ли:
      1. Ясность цели? Да, хотя и наивно недостижимой. Проект провалился задолго до того, как столкнулся с эти принципиальным ограничением.
      2. Человеческие ресурсы? В большом числе.
      3. Материалы? Глина и битум в изобилии имеются в Месопотамии.
      4. Достаточно времени? Да, нет никаких указаний на ограничения по времени.
      5. Адекватные технологии? Да, пирамидальной или конической структуре присуща устойчивость и хорошее распределение нагрузки сжатия. Очевидно, свойства каменной кладки были хорошо известны. Проект провалился до того, как вышел за пределы технологических ограничений.
      Так почему же провалился проект, если все это у них было? Чего у них не хватало? Двух вещей — обмена информацией и вытекающей из него организации. Они не могли разговаривать друг с другом и, как следствие, согласовывать усилия. Когда отказала координация, работа встала. Читая между строк, мы обнаруживаем, что отсутствие обмена информацией привело к спорам, дурному настроению и взаимной ревности. Вскоре кланы начали расходиться, предпочтя обособленность спорам.
       Обмен информацией в большом программном проекте
      В наше время происходит тоже самое. Отставание от графика, несоответствие функциональности, системные ошибки — все это из-за того, что левая рука не знает, что творит правая. По ходу работы участвующие в ней несколько бригад понемногу изменяют функции, размер, быстродействие своих программ, явно или косвенно меняют допущения относительно входных данных и использования выходных.
      Например, исполнитель функции, осуществляющей оверлейную загрузку программ, может столкнуться с проблемами и снизить быстродействие, основываясь на статистических данных, указывающих на редкость использования этой функции в прикладных программах. В то же время его сосед может разрабатывать важную часть супервизора таким образом, что она крайне зависит от скорости выполнения этой функции. Это изменение скорости выполнения, в сущности, становится значительным изменением спецификаций, о нем нужно широко объявить и оценить с точки зрения системы.
      Как же должны бригады обмениваться между собой информацией? Всеми возможными способами:
      • Неформально. Хорошая телефонная связь и ясное определение взаимозависимостей между бригадами должны способствовать многочисленным телефонным переговорам, от которых зависит единая интерпретация печатных документов.
      • Совещания. Нельзя переоценить значение регулярных совещаний участников проекта с поочередным заслушиванием технических отчетов бригад. Таким путем устраняются сотни мелких непониманий.
      • Рабочая тетрадь. В самом начале нужно завести рабочую тетрадь учета проделанной работы. Эта тема заслуживает отдельного раздела.
       Рабочая тетрадь проекта
      Что. Рабочая тетрадь проекта является не столько отдельным документом, сколько структурой, налагаемой на все документы, которые будут созданы во время выполнения проекта.
      Все документы проекта должны входить в эту структуру, включая цели, внешние спецификации, спецификации интерфейсов, технические стандарты, внутренние спецификации и административные записки.
      Почему. Технологический документ практически вечен. Если исследовать генеалогию руководства пользователя по какому-нибудь аппаратному или программному продукту, можно проследить не только идеи, но и множество отдельных предложений и параграфов, вплоть до первой памятной записки, предлагающей продукт или поясняющей первый проект. Для составителя документации ножницы и клей — такая же важная вещь, как перо.
      Раз это так, и завтрашние руководства для готового продукта развиваются из сегодняшних памятных записок, очень важно правильно определить структуру документации. Разработка рабочей тетради проекта на ранних этапах обеспечивает продуманную, а не случайную структуру документации. Более того, задание структуры позволяет составленные позднее документы оформить в виде отрывков, которые вписываются в эту структуру.
      Второй причиной для ведения рабочей тетради является необходимость управления процессом распространения информации. Задача состоит не в ограничении доступа к информации, а в том, чтобы соответствующая информация достигла всех, кому она может понадобиться.
      Первым делом следует пронумеровать все памятные записки, так чтобы имелись упорядоченные списки названий, и каждый работник мог убедиться в наличии необходимых ему материалов. Организация рабочей тетради идет значительно дальше, устанавливая древовидную структуру памятных записок. Древовидная структура позволяет, если нужно, организовать доставку информации соответственно поддеревьям.
      Механика. Как и во многих задачах управления программными проектами, проблема технических меморандумов усложняется нелинейным образом по мере увеличения объема данных. Если в работе участвуют 10 человек, документы можно просто пронумеровать. Если участвуют 100 человек, часто достаточно нескольких линейных последовательностей. Для 1000 сотрудников, неизбежно разбросанных по нескольким площадкам, возрастает потребность в структурированной рабочей тетради, и, следовательно, возрастает ее объем. Как поступать в этом случае?
      Я думаю, мы правильно поступили при работе над проектом OS/360. На необходимости хорошо структурированной рабочей тетради особенно настаивал О. С. Локен, который убедился в ее эффективности при работе над своим предыдущим проектом, — операционной системой 1410-7010.
      Мы быстро приняли решение, что каждый программист должен иметь возможность видеть весь материал, т.е. должен иметь экземпляр рабочей тетради в своем офисе.
      Решающее значение имеет своевременное обновление. Рабочая тетрадь должна отражать текущее состояние проекта. Это очень трудно осуществить, когда для внесения обновлений нужно перепечатывать целые документы. Однако в тетради с вынимающимися листами достаточно заменить отдельные страницы. У нас имелась компьютерная система редактирования текста, оказавшаяся бесценной для своевременного обновления. Офсетные формы изготавливались непосредственно на принтере, и цикл обработки составлял меньше одного дня. Перед получателем всех этих обновленных страниц встает, однако, проблема усвоения. Когда он впервые получает обновленную страницу, то ему нужно знать, что было изменено. Когда он позже обращается к ней, то ему нужно знать, какое определение действительно на текущий день.
      Последнюю потребность удовлетворяет непрерывность обновления документации. Чтобы выделить изменения, требуются другие меры. Во-первых, нужно отметить на странице измененный текст, например, с помощью вертикальной линии на полях рядом с каждой измененной строчкой. Во-вторых, необходимо вместе с измененными страницами распространять краткую отдельную сводку с перечислением изменений и характеристикой их значения.
      Наш проект не перешел и шестимесячного рубежа, когда мы столкнулись с другой проблемой. Толщина рабочей тетради составила около полутора метров! Если бы мы сложили в одну стопку требующиеся программистам 100 экземпляров в своих помещениях здания Time-Life в Манхеттене, она бы превысила по высоте само здание. Кроме того, ежедневные исправления имели толщину больше пяти сантиметров и насчитывали около 150 страниц, которые надо было заменить. Поддержка рабочей тетради стала занимать значительную часть ежедневного рабочего времени.
      С этого времени мы перешли на микрофиши, что сберегло миллион долларов даже с учетом стоимости устройств для чтения микрофишей в каждом офисе. Мы смогли достичь отличной продолжительности цикла производства микрофишей. Рабочая тетрадь уменьшилась в объеме с 90 дм [3] до 5 дм [3] и, что более важно, обновления выпускались порциями по сотне страниц, стократно уменьшая сложность замены листов.
      Микрофиши имеют свои недостатки. С точки зрения менеджера, неудобство замены бумажных страниц гарантировало, что их прочтут, для чего и велась рабочая тетрадь. Микрофиши слишком облегчили задачу ведения рабочей тетради, если только они не сопровождались печатным документом с перечислением изменений.
      Кроме того, микрофиши не позволяют читателю легко делать выделения, пометки и комментарии. Документы, с которыми читатель работал, приносят больше пользы автору и читателю. Взвешивая все, я полагаю, что микрофиши являются очень удачной технологией, и для очень крупных проектов я бы отдал им предпочтение перед бумажной рабочей тетрадью.
      Как можно осуществить это сегодня? Сегодняшние системные технологии, я думаю, делают предпочтительнее ведение рабочей тетради в файле прямого доступа с полосками, помечающими измененные части, и датами внесения изменений. Любой пользователь может обратиться к журналу с дисплейного терминала. Сводка изменений, готовящаяся ежедневно, должна храниться в виде стека (LIFO) с установленной точкой доступа. Программист может ежедневно ее читать, но если он пропустил один день, ему придется дольше читать на следующий день. Прочтя об изменениях, он может прерваться и прочесть сам измененный текст.
      Обратите внимание, что сама рабочая тетрадь остается неизменной. Она по-прежнему остается собранием всей проектной документации, тщательно организованной. Единственное изменение — механизм распределения доступа. Д. С. Энглебарт с коллегами создали такую систему в Стэнфордском исследовательском институте и используют ее для ведения документации по сети ARPA.
      Д. Л. Пранас и Университета Карнеги-Мелона предложил еще более радикальное решение. [1] Он полагает, что производительность программиста выше всего, когда он огражден от подробностей конструкции тех частей системы, над которыми он не работает. Это предполагает, что все интерфейсы полностью и точно заданы. Такой проект определенно хорош, но если полагаться на его идеальное осуществление, это приведет к катастрофе. Хорошая информационная система не только должна выявлять ошибки в интерфейсах, но и способствовать их исправлению.
       Организация крупного программного проекта
      Если над проектом работает n человек, то существует (n [2] –n)/2 интерфейсов, через которые может происходить обмен данными, и потенциально существует почти 2 nгрупп, внутри которых должно происходить согласование. Цель организации работы состоит в сокращении необходимого объема обмена информацией и согласования. Поэтому создание правильной организационной структуры является решающим направлением решения проблем информационного обмена, рассматривавшихся выше.
      Способы, которыми сокращается обмен информацией, — разделение труда и специализация функций. Древовидная организационная структура отражает уменьшение потребности в подробном обмене информацией при использовании разделения труда и специализации.
      В действительности, организация в виде дерева возникает как структуризация полномочий и ответственности. Принцип, что никто не может быть слугой двух господ, требует, чтобы структура полномочий была древовидной. Однако структура обмена информацией не столь ограничена, и дерево является мало пригодным приближением структуры общения, которая является сетью. Неадекватность приближения деревом служит причиной возникновения бригад, целевых групп, комиссий и даже организаций матричного типа, существующих во многих инженерных лабораториях.
      Рассмотрим древовидную организацию программистов и исследуем существенные характеристики, которыми должны обладать поддеревья, чтобы быть эффективными. Таковыми являются:
      1 — задание,
      2 — продюсер,
      3 — технический директор или архитектор,
      4 — график работ,
      5 — разделение труда,
      6 — определение интерфейсов между разными частями.
      Все перечисленное очевидно и обычно, исключая различие между продюсером и техническим директором. Сначала рассмотрим сами эти две функции, а затем их взаимоотношения.
      В чем назначение продюсера? Он собирает бригаду, распределяет работу и устанавливает график ее выполнения. Он занимается приобретением необходимых ресурсов. Это означает, что большая часть его функций состоит в общении, которое направлено вне бригады, — вверх и в стороны. Он устанавливает схему связи и предоставления отчетности внутри бригады. Наконец, он обеспечивает выполнение графика, осуществляя маневр ресурсами и меняя организацию в соответствии с новыми обстоятельствами.
      А что же технический директор? Он постигает проект, который должен быть реализован, выявляет его составляющие, определяет, как он будет выглядеть внешне, и делает эскиз внутренней структуры. Он обеспечивает единство и концептуальную целостность проекта в целом и таким образом способствует ограничению сложности системы. При возникновении технических проблем он изыскивает их решения или при необходимости изменяет системный проект. Он, согласно прелестному выражению Ала Каппа, является «своим человеком в паршивых делах». Общение его происходит преимущественно внутри команды. Его работа почти исключительно техническая.
      Теперь видно, что для этих двух функций требуются совершенно разные способности. Способности встречаются в разных сочетаниях, и отношения между продюсером и директором должны определяться теми конкретными сочетаниями, которыми они обладают. Не люди должны быть втиснуты в чисто теоретические организационные формы, а организация должна строиться вокруг тех людей, которые есть.
      Возможны три типа отношений, и все они с успехом встречаются на практике.
      Одно и то же лицо может быть продюсером и техническим директором. Это вполне оправдано в маленьких командах, насчитывающих от трех до шести программистов. В более крупных проектах это очень редко осуществимо по двум причинам. Во-первых, редко встречаются люди, сочетающие в себе большие административные и технические способности. Мыслители встречаются редко, практики еще реже, но реже всего — мыслители-практики.
      Во-вторых, в больших проектах выполнение каждой из функций требует полного рабочего дня или даже больше. Продюсеру трудно передать кому-либо достаточную часть своих обязанностей, чтобы высвободить время для технической работы. Директору невозможно передать свои обязанности, не нанося ущерба концептуальной целостности проекта.
      Продюсер может быть начальником, а директор — его правой рукой. Сложность здесь состоит в том, чтобы определить полномочия директора при принятии технических решений, с тем чтобы он не тратил свое время, участвуя в административной цепочке.
      Очевидно, продюсер должен объявить о полномочиях директора в технической области и в высшей степени укреплять их в возникающих спорных ситуациях. Чтобы это было возможно, продюсер и директор должны иметь схожие взгляды по основным техническим вопросам. Они должны частным образом согласовывать основные технические проблемы, прежде чем они встанут на повестку дня. Продюсер должен также с большим уважением относиться к техническому мастерству директора.
      Что менее очевидно, продюсер может с помощью символов статуса (таких как размер кабинета, ковровое покрытие, мебель, рассылка вторых экземпляров документов и т.п.) подчеркивать, что директор, находясь вне административной цепочки, обладает, тем не менее, властью в принятии решений.
      Это может действовать очень успешно. К несчастью, к этому редко прибегают. Что хуже всего получается у менеджеров проектов, — так это использование технического гения людей, не очень сильных в администрировании.
      Директор может быть начальником, а продюсер — его правой рукой. Роберт Хайнлайн ярко описывает такую организацию в «Человеке, продавшем Луну».
      Костер закрыл лицо руками, затем взглянул вверх:
      — Я разбираюсь в этом. Я знаю, что нужно делать, но всякий раз, когда я пытаюсь заняться технической проблемой, какой-нибудь болван хочет, чтобы я принял решение по поводу грузовиков, или телефонов, или еще какой-нибудь ерунды. Простите, мистер Гарриман. Мне казалось, я справлюсь со всем этим.
      Гарриман очень мягко сказал:
      — Не отчаивайся, Боб. Ты ведь недосыпал последнее время, правда? Вот что я скажу: мы перехитрим Фергюсона. Я возьму твой стол на несколько дней и построю организацию, которая оградит тебя от таких вещей. Я хочу, чтобы твои мозги были заняты векторами реакции, эффективностью топлива и сложностями проекта, а не контрактами по грузовикам. — Гарриман подошел к двери, выглянул наружу и заметил человека, который был, возможно, старшим клерком. — Эй, вы! Подойдите сюда!
      Человек показался озадаченным, встал и, подойдя к двери, спросил:
      — Да?
      — Я хочу, чтобы этот стол в углу и все, что на нем, были перенесены в пустую комнату на этом этаже, и немедленно.
      Он проследил, как Костер и второй его стол переехали в другую комнату, убедился, что телефон в новом помещении отключен, и, подумав, заставил перенести туда диван.
      — Мы поставим проектор, чертежную доску, книжные шкафы и все такое прочее сегодня вечером, — сказал он Костеру. — Просто составь список всего необходимого, чтобы заниматься делом. — Он вернулся в официальный кабинет главного инженера и с радостью взялся за работу, пытаясь выяснить, каково положение дел, и что не ладится.
      Часа через три он позвал Баркли, чтобы познакомить его с Костером. Главный инженер спал, сидя за столом, положив голову на руки. Гарриман хотел выйти, но Костер проснулся.
      — Прошу прощения, — сказал он, краснея, — я, наверное, задремал.
      — Для этого я притащил тебе диван, — сказал Гарриман, — на нем удобнее. Боб, познакомься с Джоком Беркли. Это твой новый раб. Ты остаешься главным инженером и неоспоримым начальником. Джок будет Главным лордом Все Остальное. С этого момента тебе абсолютно не о чем беспокоиться — исключая такую мелочь, как лунный корабль.
      Они пожали руки.
      — Хочу просить об одной вещи, мистер Костер, — сказал Беркли с серьезностью, — передавайте мне все, что сочтете необходимым — ваша сторона техническая, — но Бога ради, записывайте все, чтобы я был в курсе. Я хочу, чтобы вам на стол поставили выключатель, который будет управлять опечатанным магнитофоном на моем столе.
      — Отлично! — Гарриману показалось, что Костер помолодел.
      — И если вам понадобится что-либо, не относящееся к технике, не занимайтесь этим сами. Нажмите выключатель и свистните. Все будет сделано. — Беркли взглянул на Гарримана. — Хозяин говорит, что собирается поговорить с вами о настоящей работе. Я вас покину и займусь делами. — Он вышел.
      Гарриман сел. Костер последовал его примеру и сказал:
      — Уф!
      — Так лучше?
      — Мне понравился этот Беркли.
      — Это хорошо. Теперь это твой двойник. Не беспокойся: он работал у меня раньше. Ты почувствуешь себя, как в хорошей больнице. [2]