Современная электроника №5/2025

СОВРЕМЕННЫЕ ТЕХНОЛОГИИ 43 WWW.CTA.RU СОВРЕМЕННАЯ ЭЛЕКТРОНИКА • № 5 / 2025 последние годы, они, вероятно, были той командой, которая лучше всего понима- ла, что могут собой представлять «неиз- вестные» этого проекта, и как с ними справляться, когда они возникнут. Партнёрство с Honeywell В разработке и производстве IMP команда BBN сильно полагалась на Севе- ро Орнстайна. Орнстайн ранее работал с Фрэнком Хертом и другими над раз- личными компьютерными проекта- ми в Лаборатории Линкольна, сотруд- ничал с Уэсом Кларком по созданию малых компьютеров вWUSTL (Универ- ситет Вашингтона в Сент-Луисе) и затем вернулся в Кембридж, чтобы работать в BBN и читать лекции в Гарварде. До начала работы над проектом ARPAnet Орнстайн занимался проектами, связан- ными с использованием компьютеров в образовании. Его интерес к запросу ARPAnet заставил его посвятить боль- ше времени работе в BBN. Во время разработки IMP в процес- се подготовки предложения Орнстайн оценил, что «мытогда сделали 90%раз- работки» . Однако, чтобы компьютеры были построены, даже после того как BBN выиграла предложение, Орнстайн продолжал тратить значительные уси- лия на работу с Honeywell. Орнстайн вспоминает: «Человек из Honeywell, которому было поручено создавать интерфейсы по моим чертежам, плохо их понял и не был достаточно внимателен. Мы в итоге вынуждены были переделать бо́льшую часть его работы». Многое из взаимодействия BBN с Honeywell может поставить под сомне- ние, что промышленный подрядчик справился бы с этим контрактом так же эффективно, как это сделала коман- да BBN. Один из примеров, описанных Орнстайном, иллюстрирует, как коман- да BBN решала запутанную проблему, и помогает понять, почему это так. Исто- рия освещает характер работ, которы- ми занимались сотрудники BBN до эта- па реализации, и как Honeywell решала возникающие проблемы. Орнстайн объ- ясняет: «Они не привыкли делать некоторые из тех вещей, которые делали мы… Например, мы обнаружили дефекты в конструкции машины. Одна из при- чин, почему мы выбрали Honeywell 516, заключалась в том, что мы счи- тали, что это зрелая машина, кото- рая не доставит нам проблем. Ну, мы ошиблись. Мы сильно нагружали её… и обнаружили баг, в который они едва ли поверили – проблему синхронизатора… Проблемы с синхронизатором очень, очень тонкие. Мы должны были копать- ся в этом, и наконец из их чулана появил- ся действительно умный парень – они, конечно, имеют пару таких, но было очень трудно его найти. Мы наконец нашли его…Когда он пришёл, имы сели, я, наконец, нашёл кого-то, с кемможно было поговорить, кто понял быменя и поверил мне. Это была тонкая пробле- ма. Программа прекрасно работала на машине несколько дней подряд, но в кон- це третьего или четвёртого дня вдруг машина просто “умирала” без объясне- ния причин. Это был очень, очень ред- кий сбой, настолько редкий, что ты не мог увидеть его на осциллографе, толь- ко последствия. Нампришлось разрабо- тать специальное оборудование, кото- рое бы “било” по проблемному месту гораздо быстрее, чем обычно. И толь- котогда, когда в комнате были выклю- чены все огни, мы смогли увидеть на осциллографе редкие сбои. Тогда люди из Honeywell наконец поверили, что это реальная проблема…Мы посоветовали им тривиальное исправление, которое они могли бы внести в машину…» Итак, их специалисты не были абсо- лютного топ-уровня, но тем не менее они были квалифицированными инже- нерами, в отличие от чисто исследова- тельских специалистов. Конечно, в те времена существовали и промышленные операции с рядом исследовательских специалистов, таких как Bell Labs, бывшее место работыКана, которые имели достаточно «исследова- тельских» людей. Однако неясно, как компании вроде Raytheon справились бы с такими проблемами. Смогли бы они их решить? Если да, то как быстро? Мы видим, что команда Honeywell отлично справлялась с повторным созданием машин после того, как уже была изготовлена одна. Но определён- ные принципы и навыки компьютер- ной инженерии, использовавшиеся в проекте, были намного более знакомы таким командам, как та, что работала в Lincoln Lab и с Wes Clark вWUSTL, чем большинству других групп. Это было огромным преимуществом BBN. Несмотря на это, команда инженеров, бывших сотрудниками университетов, всё же воспринимала проект как скорее новаторскую инженерную задачу, чем исследовательскуюпроблему. Дэйв Уол- ден, один из двух основных инженеров- программистов проекта, позже ставший генеральным директором BBN, описал, как команда воспринимала задачу, сле- дующим образом: «Моё мнение таково, что в основ- номмы занимались очень прагматич- ной инженерией. Мы должны были пере- дать биты по проводам: как добавить заголовок, как добавить хвост. Теория заключалась в том, как наложить коды для исправления ошибок. Роберт Кан знал эту теорию и объяснил нам, что она собой представляет. Были некото- рые ограничения: вот как должно про- исходить подключение к 303 (или 301, или кактамназываетсямодемBell), но после этого всё было довольно прагма- тично. Теории много не было». Управление командой Прежде чем погрузиться в детали реа- лизации однолетнего контракта, стоит сначала понять, как в BBN была орга- низована работа команды. Во-первых, команда была гораздо меньше, чеммож- но было бы ожидать. В течение первого года работы коман- да оставалась небольшой – всего около восьми человек. Именно так предпочи- тал работать Фрэнк Херт. По его мне- нию, для успешной реализации проек- та достаточно было небольшой группы талантливых специалистов в соответ- ствующих областях. Он подробнее опи- сал стиль работы на проекте, сказав: «Я считаю, что важные вещи лучше всего делаютмаленькие группы людей, которые знают всё о проекте. Вте вре- мена все программисты что-то зна- ли о железе, а все аппаратчики умели программировать. Это была не груп- па незнакомых людей, а команда, где каждый знал многое о работе в целом. Я считаю это важным в любых круп- ных проектах. Так что, если это мож- но назвать стилем управления, то это то, что я бы сказал. Я также считаю, что это была очень, очень талант- ливая группа. Я думаю, что дела идут лучше всего, когда над ними работают маленькие группы очень, очень хороших людей – если вы можете это организо- вать. Не всегда это удаётся. Так что, если хотите, можете назвать это сти- лем управления – собрать лучших людей в небольшомколичестве, чтобы все зна- ли, что делает каждый» (рис. 4). Херт был категорически против того, чтобы команда разрослась до такого раз- мера, что коммуникация стала бы осу- ществляться только через документы. Он предпочитал стиль работы с «очень, очень частыми взаимодействиями по