Чтение онлайн

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

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

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

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

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

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

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

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

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

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

1. Цели и задачи.

2. Продюсер.

3. Технический директор или архитектор.

4. График работ.

5. Разделение труда.

6. Определение сопряжении между отдельными частями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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