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

Автор книги: Фредерик Брукс

сообщить о нарушении

Текущая страница: 4 (всего у книги 16 страниц) [доступный отрывок для чтения: 6 страниц]

Глава 6 Донести слово

Он сядет здесь и будет распоряжаться: «Сделайте это! Сделайте то!» А дело и с места не сдвинется.

ГАРРИ С. ТРУМЕН. «О ПРЕЗИДЕНТСКОЙ ВЛАСТИ»[1]

Как менеджеру, имея опытных дисциплинированных архитекторов и достаточное число исполнителей, добиться того, чтобы все услышали, поняли и выполнили решения архитектора? Как группе из 10 архитекторов поддерживать концептуальную целостность системы, над которой трудится 1000 человек? Для достижения этого при осуществлении программы проектирования аппаратной части System/360 была разработана целая технология, которая в равной степени применима для проектов создания программного обеспечения.

Письменные спецификации – руководство

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

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

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

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

Единство «Принципов работы System/360» проистекает из того, что у них было лишь два автора: Джерри Блау и Андрис Падега. Авторами идей являются порядка десяти человек, но если требуется соблюсти согласованность описания и продукта, отливку решений в прозаические спецификации должны осуществлять не более двух человек. Для написания определения требуется принять массу мини-решений, которые не столь важны, чтобы выносить их на всеобщее обсуждение. Для System/360 примером служат подробности того, как после каждой операции устанавливается код условия. Однако задача всеобщей согласованности таких мини-решений не является тривиальной.

Думаю, что лучший виденный мной образец руководства – это написанное Блау приложение к «Принципам работы System/360». В нем тщательно и точно описаны границы совместимости System/360. Дано определение совместимости, предписывается, к чему нужно стремиться, и перечислены те области внешних проявлений, где архитектура намеренно молчит, и где результаты, полученные на разных моделях, могут отличаться между собой, где разные экземпляры одной модели могут дать различные результаты и даже один и тот же экземпляр может давать различия после конструктивных изменений. Это уровень точности, к которому стремятся составители руководств. Они должны одинаково описывать как то, что можно делать, так и то, что делать нельзя.

Формальные определения

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

Рассмотрим достоинства и слабости формальных определений. Как отмечалось, формальные определения являются точными. Они тяготеют к полноте: пробелы заметнее, а потому скорее восстанавливаются. Их недостаток – трудность понимания. На английском языке можно описать структурные принципы, очертить структуры по этапам или по уровням и привести примеры. Легко отметить исключения и подчеркнуть противоположности. Еще важнее, что можно объяснить причины. Предлагавшиеся до сих пор формальные определения вызывали восхищение своей элегантностью и уверенность в их точности. Но они требовали текстуальных пояснений для облегчения изучения своего содержания. По этой причине я полагаю, что в будущем спецификации будут состоять как из формальных, так и из текстовых описаний.

Древнее изречение предупреждает о том, что в море нельзя выходить с двумя хронометрами: нужно взять один или три. То же, очевидно, применимо и к текстовым и формальным определениям. Если имеются оба вида, то один должен быть стандартом, а другой – производным описанием, о чем должно быть прямо указано. Основным стандартом может быть любой из них. В Algol 68 в качестве стандарта выбрано формальное определение, а текстовые определения являются описательными. В PL/I стандартом является текст, а формальное определение – производным. В System/360 также в качестве стандарта принят текст, а производными являются формальные описания.

Есть много средств создания формальных определений. Для определения языков часто используется форма Бэкуса-Наура, по которой есть богатая литература.[3]В формальном описании PL/I используются новые обозначения абстрактного синтаксиса, надлежащим образом описанные.[3]APL Иверсона был использован для описания машин, в частности, IBM 7090[4]и System/360.[7]

Белл и Ньюэлл предложили новые нотации для описания как конфигураций, так и машин, и проиллюстрировали их на нескольких машинах, включая DEC PDP-8, [6] 7090 [6] и System/360. [7]

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

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

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

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

значительное количество недостатков. Реализация может переопределять даже внешние спецификации. Даже при ошибочном синтаксисе всегда получается некоторый результат; в контролируемой системе этот результат является указанием на ошибку и ничем больше. В неконтролируемой системе могут возникнуть любые побочные эффекты и быть использованы программистами. Когда мы, например, эмулировали IBM 1401 на System/360, выявилось 30 различных «курьезов» – побочных эффектов предположительно незаконных операций, которые широко использовались и должны были быть признаны частью определения. Реализация в качестве определения возобладала. Она не только говорила о том, что должна делать машина, но и многое сказала о том, как машина не должна была это делать.

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

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

Прямое включение

У архитекторов программных систем есть чудесный метод распространения и внедрения определений. Он особенно полезен при установлении если не семантики, то синтаксиса межмодульных интерфейсов. Этот прием состоит в создании объявлений передаваемых параметров или совместно используемой памяти и требовании включения этих объявлений при операциях времени компиляции (макрос или %INCLUDE в PL/I). Если, кроме того, все ссылки на интерфейс происходят только по символическим именам, объявления можно менять, добавляя или вставляя новые имена и лишь заново компилируя, но не изменяя использующую его программу.

Конференции и суды

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

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

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

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

Плодотворность этих совещаний обусловлена несколькими причинами:

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

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

3. При возникновении проблем решения ищутся как внутри, так и вне очевидных границ.

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

5. Открытое предоставление права принятия решения главному архитектору помогает избежать поиска компромиссов и задержек.

Со временем выясняется, что некоторые решения не в полной мере выполняются. Тот или иной из участников так и не принял всей душой какую-либо мелочь. Другие решения породили непредвиденные проблемы, и еженедельное совещание отказывается повторно их рассматривать. Так возникает хвост из мелких возражений, открытых тем или раздражения. Для их урегулирования мы проводим ежегодные "сессии верховного суда", обычно продолжающиеся две недели. (Если бы я проводил их сейчас, то делал бы это раз в полгода.)

Эти сессии проводились накануне важных дат окончательного принятия разделов руководства. Присутствовали не только представители программистов и проектировщиков по архитектуре, но и менеджеры программных, маркетинговых и реализационных проектов. Председательствовал менеджер проекта System/360. Повестка работы включала обычно около 200 пунктов, в основном мелких, перечисленных в развешанных по комнате списках. Заслушивались все стороны и принимались решения. Благодаря чуду компьютерной верстки (и превосходной работе сотрудников) каждое утро каждый участник обнаруживал на своем рабочем месте исправленное руководство, в которое были внесены решения, принятые накануне.

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

Множественные реализации

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

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

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

Журнал регистрации телефонных разговоров

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

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

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

Тестирование продукта

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

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

Глава 7 Почему не удалось построить Вавилонскую башню?

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

КНИГА БЫТИЯ 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 – определение интерфейсов между разными частями.

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

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

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