Конференции и разбирательства

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

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

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

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

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

Подобные совещания очень плодотворны по нескольким причинам:

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

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

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

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

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

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

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

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

Совместные реализации

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

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

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

⇐ Предыдущая45678910111213Следующая ⇒

Поделиться: