КаталогИндекс раздела
НазадОглавлениеВперед


VII. ПОЧЕМУ ОБРУШИЛАСЬ ВАВИЛОНСКАЯ БАШНЯ

"На всей земле был один язык и одно наречие. Двинувшись с Востока, они нашли в земле Сенаар равнину и поселились там. И сказали друг другу: наделаем кирпичей и обожжем огнем. И стали у них кирпичи вместо камней, а земляная смола вместо извести.
И сказали они: -построим себе город и башню, высотою до небес; и сделаем себе имя, прежде нежели рассеемся но лицу всей земли.
И сошел Господь посмотреть город и башню, которые строили сыны человеческие.
И сказал Господь: вот, один народ, и один у всех язык. и вот что начали они делать, и не отстанут они от того, что задумали делать. Сойдем же, и смешаем там язык их так, чтобы один не понимал речи другого.
И рассеял их Господь оттуда по всей земле; и они перестали строить город".
(Бытие 11.1-8)

Анализ Вавилонского проекта с точки зрения административного управления

Как считает библия, Вавилонская башня была вторым важнейшим техническим предприятием человечества после Ноева ковчега, и Вавилон был первым техническим провалом.

История о Вавилонской башне имеет глубокий смысл и очень поучительна во многих отношениях. Давайте, однако, рассмотрим ее как чисто технический проект и выясним, какие административные уроки можно из него извлечь. Были ли созданы все предпосылки для успеха? Имели ли строители:

  1. Ясную цель? - Да, хотя достичь ее абсолютно невозможно. Однако проект провалился задолго до того, как он столкнулся с этим фундаментальным ограничением.
  2. Рабочую силу? - Сколько угодно.
  3. Материалы? - Глина и битум имеются в Месопотамии в избытке.
  4. Достаточно времени? - Да, не было и речи ни о каких ограничениях на время.
  5. Соответствующую технологию? - Да, пирамидальные или конические конструкции очень просты и хорошо выдерживают нагрузку. С каменной кладкой строители были прекрасно знакомы. Проект потерпел крах до того, как он наткнулся на чисто технические трудности.

    Итак, если у них все это было, то почему же проект провалился? Чего же не хватало строителям? У них не было, во-первых, связи, и, как следствие, - организации. Они не смогли говорить друг с другом и, следовательно, не смогли координировать свои действия. Как только прекратилась связь, застопорилась и работа. Читая между строк, мы угадываем, что отсутствие связи привело к спорам, недоброжелательству, соперничеству между группами. Короче говоря, люди начали разбредаться в разные стороны, предпочитая изоляцию ссорам и пререканиям.

    Связь в больших программистских проектах

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

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

    Как отдельные группы должны поддерживать связь друг с другом? - Всеми возможными путями.

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

    Рабочий документ проекта

    Что. Рабочий документ проекта - это не столько отдельный документ, сколько структура, накладываемая на документы, выпускаемые проектом.

    Все документы проекта должны входить в эту структуру. Сюда относятся цели и задачи, внешние спецификации, спецификации сопряжении, технические стандарты, внутренние спецификации и административные меморандумы.

    Зачем. Техническая проза почти бессмертна. Рассматривая генеалогию технического руководства по какой-то части оборудования или математического обеспечения, можно проследить, что не только идеи, но одни и те же предложения и даже абзацы сохраняются с самого первого меморандума, предлагающего продукт или поясняющего начальный проект. Ножницы и клей нужны создателю технического документа не менее, чем авторучка.

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

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

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

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

    Я думаю, что в проекте OS/360 это вполне удалось. На необходимости хорошо структурированных рабочих документов особенно настаивал О. С. Локен, который убедился в их эффективности на примере своего предыдущего проекта, операционной системы IBM 1410- 7010.

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

    Однако человек, получивший все эти новые варианты страниц, оказывался перед проблемой сравнения. Когда ему впервые попадает страница с изменениями, он хочет знать: "Что изменилось?". Когда же он позже обращается к ней, ему нужно знать: "А как это определяется сегодня?".

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

    Нашему проекту не исполнилось еще и полугода, как мы столкнулись с другой проблемой. Рабочие документы уже стали около 1,5 м толщиной! Если бы сложить друг на друга все 100 экземпляров, которыми пользовались наши программисты в своем здании на Манхэттене, то получилась бы башня выше самого дома. И далее, ежедневно распространялись изменения толщиной в 5 см, т. е. приблизительно 150 страниц вновь подшивалось в документ. Ведение рабочих документов стало занимать значительную часть каждого дня.

    В этот момент мы переключились на микрофиши, что сэкономило нам миллион долларов, учитывая даже стоимость проекторов для чтения с микрофиш. Мы смогли прекрасно организовать производство микрофиш, объем рабочих документов сократился с 1,7 м3 до 0,004 м3 и, что важнее всего, изменения сразу вносились в куски по 100 страниц, тем самым в 100 раз облегчилась проблема организации документов.

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

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

    Тем не менее, учитывая все вышесказанное, я считаю, что микрофиши были удачной находкой, и я мог бы их рекомендовать для очень больших проектов.

    Как поступать сегодня? Я считаю, что, располагая сегодняшней системной техникой, имеет смысл хранить рабочие документы в файле с непосредственным доступом и отмечать в нем все изменения и их даты, каждый пользователь сможет обращаться к нему с графического терминала (телетайпы слишком медленны). Ежедневно подготавливаемый обзор всех изменений будет храниться по принципу "вошедший последним выходит первым" в некоторой фиксированной точке обращения. Программист может читать его ежедневно, но если он и пропустит день, то назавтра ему просто придется прочесть больший текст. По мере чтения обзора всех изменений, он может прерываться и обращаться к самому тексту, в который они внесены.

    Отметим, что сам рабочий документ при этом не изменяется. Он остается объединением всей документации по проекту и имеет тщательно разработанную структуру. Изменения претерпевают только механизм его распространения и работа с ним. Д. Энгельбарт вместе со своими коллегами из Стэнфордского исследовательского института создали такую систему и использовали ее при разработке и ведении документации по проекту создания сети ARPA.

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

    Организация в больших программистских проектах

    Если в проекте занято n работников, то существует (n2 - n)/2 сопряжений, по которым в принципе возможна связь, и почти 2n коллективов, внутри которых должна иметь место координация. Задача организации заключается в том, чтобы максимально уменьшить требуемый объем затрат на установление связи и координацию, следовательно, организация представляется радикальным решением вышеупомянутых проблем.

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

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

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

    1. Цели и задачи.
    2. Продюсер.
    3. Технический директор или архитектор.
    4. График работ.
    5. Разделение труда.
    6. Определение сопряжении между отдельными частями.

    Все это очевидно и общепринято, за исключением разницы между продюсером и техническим директором. Рассмотрим сначала две эти роли, а затем - связь между ними.

    Какова роль продюсера? Он набирает бригаду, распределяет работу и устанавливает график. Он обеспечивает коллектив всеми необходимыми ресурсами и следит за их пополнением. Это означает, что его основные обязанности заключаются в установлении связей за пределами бригады, вверх и в стороны. Он устанавливает структуру связей и отчетности внутри коллектива. И, наконец, он обеспечивает выполнение графика, приводя ресурсы и организацию в соответствие с изменяющимися обстоятельствами.

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

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

    Существуют три возможных типа отношений, и каждый из них вполне оправдывает себя на практике.

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

    Продюсер может быть начальником, а директор - его правой рукой. Трудность здесь заключается в представлении директору права принимать технические решения, не загружая его в то же время административными проблемами.

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

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

    Тем самым можно сделать работу очень эффективной. К сожалению, все это практикуется редко. Хуже всего, когда руководители проекта используют в качестве продюсера талантливого специалиста, который не силен в проблемах управления.

    Директор может быть начальником, а продюсер - его правой рукой. В книге "Человек, продавший луну", Роберт Хайнлайн выразительно описывает такую организацию.

    Костер уронил голову на руки, потом вдруг поднял ее:

    "Я в этом разбираюсь. Я знаю, что нужно сделать - но каждый раз, когда я пытаюсь заняться технической проблемой, какой-нибудь идиот требует, чтобы я принял решение насчет грузовиков или телефонов, или другой такой же чертовщины. Простите, мистер Гарриман. Я думал, что смогу справиться со всем этим".

    Гарриман сказал очень мягко: "Не принимайте все это так близко к сердцу, Боб! Вы, наверное, не высыпаетесь последнее время? Вот что я вам скажу - мы перехитрим Фергюсона. Я заберу ваш стол на пару дней и построю вам такую баррикаду, за которой никакие грузовики не страшны. Я хочу, чтобы вы могли спокойно думать о направлении реакции, КПД горячего топлива, об узких местах в проекте и не заботиться о контрактах на грузовики". Гарримап подошел к двери, выглянул в коридор и позвал какого-то человека, по виду напоминавшего старшего клерка. "Эй, Вы! Идите-ка сюда!".

    Человек удивленно огляделся, подошел к двери и спросил:

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

    Часа четыре спустя он пригласил Беркли, чтобы представить его Костеру. Главный инженер спал за столом, положив голову на руки. Гарриман собирался уже уйти, но Костер проснулся. "Простите, - покраснел он, - я, наверное, задремал". "Для этого я и принес вам диван, - сказал Гарриман - на нем удобнее отдыхать. Вот, познакомьтесь с Джеком Беркли. Он ваш новый раб. Вы остаетесь главным инженером и верховным начальником, приказ которого не обсуждается. Джек - это Его Превосходительство Все Что Хотите. Отныне вам абсолютно не о чем беспокоиться - разве, что о такой малости, как создание лунного корабля".

    Они пожали друг другу руки. "Я только об одном вас попрошу, г-н Костер,- сказал Беркли серьезным тоном, - переправляйте ко мне все, что хотите - в конце концов, вам командовать техническим парадом - но, ради бога, записывайте все, чтобы я был в курсе дела. У вас будет кнопка, включающая мой диктофон".

    "Отлично" - Костер, как показалось Гарриману, молодел на глазах.

    "А если вам понадобится что-нибудь, что не имеет отношения к проблеме, не делайте этого сами. Нажмите на кнопку и свистните - и все будет сделано". Беркли взглянул на Гарримапа. "Босс говорит, что хочет обсудить с вами настоящее дело. Так что я вас покину". Он вышел.

    Гарриман уселся. Костер последовал его примеру и вздохнул: "Уф!".

    - Ну как, легче?

    - Мне этот парень сразу понравился.

    - Ну вот и хорошо, теперь он - ваша тень. Не беспокойтесь, он у меня и раньше работал. Вам покажется, что вы живете в хорошем пансионате.2

    Этот отрывок вряд ли нуждается в комментариях. Для эффективной работы такая организация вполне приемлема.

    Я считаю, что этот последний метод организации более всего пригоден для маленьких коллективов, таких, как обсуждаются в гл. III "Хирургическая бригада", в то время как продюсер в качестве верховного руководителя - это наиболее приемлемая форма организации для больших поддеревьев действительно крупного проекта.

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


    НазадОглавлениеВперед
    КаталогИндекс раздела