| Лебединая песнь Digital.
Опыт ведения проекта DEC Alpha AXP
15 лет назад в специализированном журнале Digital Technical Journal корпорации DEC вышла статья Питера Конклина, главного конструктора Alpha AXP – одного из крупнейших проектов в ИТ-индустрии. Эта статья попала мне в руки в конце 1994 г. (благодаря сотрудничеству МАИ и DEC по созданию центра компетенции). В 1995 г. решил её издать в альманахе "e;Технология программирования"e; (первом отечественном периодическом 200-страничном издании с CD-диском, посвящённом программированию). При подготовке к старту проекта новой ОС в середине 2006 г. я обратил внимание на эту статью и нашёл там немало полезного в плане организации работ в будущем проекте новой отечественной ОС. Наряду с проектом МАРС и IBM AS/400 (рассказы о которых ещё впереди) он был взят на вооружение. Настало время познакомить с этими материалами и широкие круги общественности.
Биографическая справка. Питер Конклин (Peter Conklin). В 1963 г. закончил Гарвардский университет (Harvard University) с дипломом математика. В корпорации Digital (DEC) с 1969 г. Был первым инженером по программному обеспечению в рамках проекта VMS. Входил в состав группы VAX A вместе с Уильямом Стрекером (William Strecker, архитектор VAX), Гордоном Беллом (Gordon Bell, архитектор PDP-11) и Дэйвом Катлером (Dave Cutler, будущий архитектор Windows NT и Windows 2000). Руководил группой, занимавшейся разработкой архитектуры VAX, принимал активное участие в проработке ключевых аспектов архитектуры и набора программных средств для VAX/VMS. В ранге директора возглавлял Центр разработки систем Alpha AXP (Alpha AXP Systems Development).
Давайте познакомимся с выдержками из статьи Питера Конклина, которые я сделал сквозь призму предстоящего изложения наших подходов к организации работ над проектом новой отечественной ОС.
Peter Conklin "e;Enrollment Management, Managing the Alpha AXP Program"e; // Digital Technical Journal, 1992, Vol.4, No.4.
Питер Конклин "e;Стратегия вовлечения: руководство программой Alpha AXP"e; // Технология программирования, 01/1995. (Перевод Александра Китаева)
Питер Конклин пишет:
==>
Программа по разработке систем Alpha AXP была наиболее масштабной в истории корпорации Digital и одной из крупнейших в компьютерной индустрии в целом. В ходе работы над проектом Центр управления программы Alpha (Alpha AXP Program Office) разработал модель, обеспечивающую необходимый инструментарий для управления программой. Может показаться, что руководители программы начали с разработки инструментов, а уж затем в чистом виде применили их на практике. На самом же деле в основе этих подходов лежит многолетний опыт и созданные экспертами методики управления; мы тоже изучали и применяли эти уроки по мере работы над программой. Разумеется, такие показатели, как своевременное выполнение заданий и высокое качество особенно важны при выполнении масштабных программ. Тем не менее, Digital успешно применяла наши методы управления и в сравнительно небольших проектах... Опыт автора говорит о том, что нашу модель управления можно применять в проектах практически любого масштаба. <…>
Программа Alpha AXP корпорации Digital охватывала проектирование микропроцессорного набора мирового уровня, новой архитектуры, основанной на 64-разрядной системе, множества систем аппаратного обеспечения (от персональных компьютеров до мэйнфреймов), большого числа операционных систем и сотен видов программных продуктов, работающих под управлением этих систем. Разработка продуктов первого поколения длилась несколько лет, и в пик работ в проекте участвовало свыше 2 тыс. инженеров – специалистов в области аппаратного и программного обеспечения, а также системной инженерии. Корпорация Digital осуществляла общее руководство программой через Центр управления (Program Office), где было занято 8 специалистов.
В работах по программе Alpha AXP на предприятиях Digital, разбросанных по всему миру, участвовало свыше 22 групп инженеров по программному обеспечению и 10 групп инженеров по аппаратным средствам. Последние включали группу по разработке полупроводниковых систем и по одной группе на каждую из платформ систем аппаратного обеспечения. В разработках программного обеспечения участвовали 4 группы по операционным системам, а также группы по разработке средств миграции, сетевых систем, компиляторов, баз данных, сред интеграции и приложений. Число инженеров-разработчиков в некоторых группах доходило до 150 – и это не считая персонала поддержки. Многие из них также заключали контракты с поставщиками как внутри Digital, так и вне ее.
Организация столь масштабной и сложной программы связана не только с техническими, но и с управленческими проблемами. Поэтому Центр управления рассмотрел и отверг ряд традиционных организационных подходов. В соответствии с классической организационной моделью создается иерархическая или линейная организация, содержащая всех главных исполнителей. Когда речь идет о большой программе, этот подход имеет тот недостаток, что для создания организации требуется слишком много времени. Формирование рабочих групп и установление операционных процедур занимает больше времени, чем позволяет рыночное окно и имеющаяся технология. Итог – грандиозные планы, и ... выполнение проекта на несколько лет позже, чем запланировано. К тому же по окончании работ по программе "e;временные"e; организации надо опять реорганизовывать и приводить "e;в исходное состояние"e; <...> Один из альтернативных подходов состоит в том, что создаются небольшие, работающие на свой страх и риск группы специалистов, перед которыми ставится задача любой ценой добиться поставленных целей. Так можно работать в рамках небольших проектов, т.н. skunk works. Кстати говоря, именно по этой схеме проводилась первоначальная работа по проектированию программы Alpha. Но когда такой подход применяется в крупных программах, специалисты часто "e;перегорают"e;, не укладываясь в поставленные перед ними сжатые сроки. А это вызывает бурную реакцию руководства, которое набирает новых людей и продолжает ту же линию – и с теми же результатами.
Центр формировал программу Alpha AXP как совокупность проектных бригад, которые остаются внутри существующих линейных организаций. Так, каждый проект по разработке программного и аппаратного обеспечения реализовывался внутри своей функциональной группы (полупроводниковые средства, серверы, OpenVMS, UNIX, компиляторы, базы данных, разработка процессоров, сети и т.д.). Работу отдельных проектных бригад координировал Центр управления программой. Такая схема обеспечивала ей гибкость в случае реорганизации функциональных групп.
Модель управления через вовлечение. Эта модель в программе Alpha состоит из четырех стадий:
1) уяснение (vision) - вовлечение (enrollment)
2) обязательства (commitment) – делегирование (delegation)
3) контроль (inspection) – поддержка (support)
4) признание (acknowledgement) – изучение (learning).
Модель в такой форме была разработана автором статьи (главным конструктором Alpha AXP Питером Конклином – прим. Р.Б.). Некоторые элементы ее были предложены на семинарах по управлению или позаимствованы из рекомендаций консультантов. Конкретные формы, применяемые на стадиях уяснения, обязательств и признания возникли в ходе работы по программе Alpha. Стадия "e;контроль – поддержка"e; разрабатывалась автором в течение многих лет руководства проектами и ведения надзора. Две концепции являются ключевыми для реализации этой модели в крупных программах. Во-первых, уже упоминавшийся Центр управления. Он обеспечивает необходимую связь, единое понимание концепции программы и структуру контроля, позволяя в то же время специалистам и ресурсам оставаться в их "e;родных"e; организациях. Более того, Центр обеспечивает согласованность действий на всем пространстве программы и соблюдение каждой участвующей в работе группой взятых на себя обязательств. Важно подчеркнуть, что небольшой Центр управления программой Alpha, состоящий из менеджеров по различным группам продуктов и по операциям, не имел никакой формальной власти (даже в области распределения средств), поэтому его влияние осуществлялось лишь с помощью методичного вовлечения и делегирования, обозначенных в модели управления. Вторая ключевая концепция – это концепция "e;переломов"e; (cusp) в ходе проекта, что означает критическое событие, стимулирующее перемены. <...>
Уяснение – вовлечение. Стадия уяснения участниками программы ее общей концепции использовалась Центром для того чтобы представить цели программы как общее дело всех соответствующих рабочих групп. Так, уяснение может состоять в осознании коммерческих целей руководства и потребностей клиентов. Для починенных проектов уяснение может включать цели более общего проекта. В любом случае, вовлечение происходит только тогда, когда цели поставлены в понятном для аудитории (проектной бригады) контексте. Центр управления добивается наилучших результатов тогда, когда он выражает концепцию программы языком и понятиями той группы, которая в данный момент вовлекается. Уяснение должно быть достаточно широким, чтобы включать в себя все требуемые обязательства и конечные результаты.
Обязательства – делегирование. Разрабатывая планы, менеджер проекта делегирует задачи подгруппам и получает от них конкретные обязательства, касающие содержания работы и сроков ее выполнения. Поскольку эти обязательства даются в контексте более широкой концепции – программы в целом, участники подпроекта получают вполне достаточную мотивацию для их выполнения. Ключевым элементом в процессе делегирования является явная спецификация результатов с тем, чтобы они были измеримы и идентифицируемы и имелся бы конкретный ответственный. <...>
Контроль – поддержка. Менеджер проекта полагается на принятые обязательства и постоянно контролирует состояние дел в проекте для обеспечения соблюдения графика<...> Как только возникает опасность невыполнения взятых обязательств, менеджер проекта объявляет о том, что в работе по проекту наступил "e;перелом"e;. Термин "e;перелом"e; (cusp), позаимствованный у Гляйка (J.Gleick "e;CHAOS: Making a New Science"e;, 1987), означает потенциальные поворотные пункты или имеющие решающее значение события в ходе работы над проектом. (Для их обозначения часто используются другие слова: gotchas, неудачи, кризисы, поворотные пункты, срывы проекта и "e;призывы к действию"e;. При работе над программой наши менеджеры использовали и эти термины. Но для наших целей мы принимаем термин "e;перелом"e; как эмоционально нейтральный. Суть в том, чтобы на любой стадии проекта применялся такой термин, который как бы открывает возможности действовать иначе, продвигать проект вперед.) В момент перелома все готовы принять перемены, поскольку это приближает достижение общих целей программы. <...>
Признание – изучение. На каждой стадии проекта Центр управления программой выражает – как в личных контактах, так и публично – признательность участникам, добившимся заметных успехов. И каждый раз в таких случаях руководство программы неоднократно задает вопрос: какие уроки были извлечены и как менеджеры и команда могут в следующий раз добиться еще более высоких результатов. Для достижения более высоких результатов группы часто проходят методическую подготовку.
Применение модели. Когда Центр управления приступил к ведению полномасштабной программы, мы начали формализовывать эту методологию. По ходу развития событий мы постоянно учились. Нам удалось найти несколько учебников, полезных в деле эффективной организации столь масштабной программы. Но значительную часть своего инструментария Центр управления разработал "e;на месте"e;, набираясь опыта по ходу развития проекта<...> Большинство менеджеров проекта следовали модели управления через вовлечение, руководствуясь интуицией (опытом) или чьим-то примером. В нескольких случаях они официально проходили подготовку по управлению проектами такого уровня сложности в сторонних организациях. В зависимости от масштаба проекта или подпроекта менеджеры применяли данную модель с большей или меньшей степенью строгости. Так, в крупных проектах и в рамках программы в целом применялись официальные собрания, посвященные контролю работ. Менеджеры подчиненных проектов могли сами выбирать форму контроля – официальную или неофициальную. А чтобы в сфере управления не появлялось неприятных сюрпризов, руководство программы следило за организацией контроля в каждой группе.
Как указывалось выше, переломы – это решающие события в ходе развития проекта, или кризисы. Цель традиционного управления проектом состоит в том, чтобы избежать таких кризисов с помощью жесткого планирования. Центр управления программой принял противоположный подход: мы стремились вникнуть в суть критических событий и использовать эти переломы для наращивания темпов работы над проектом<...> Каждый раз, когда проект приближался к очередному перелому, Центр управления быстро принимал меры к тому, чтобы проект продолжал двигаться в нужном направлении. Иными словами, план был нужен руководителям не для "e;галочки"e;. Его главные пункты и другие события использовались как средство управления скоростью проекта, который следовало неустанно направлять в сторону намеченной цели. Часто мы сами создавали ситуацию перелома для ускорения необходимых перемен (например, провоцируя кризис в соблюдении графика). <...> Когда руководители научились конструктивно использовать переломы проекта, Центр управления приступил к активному провоцированию новых переломов. В итоге создавался "e;эффект бумеранга"e;, скорость выполнения работ и темп выполнения программы повышались. <...> По мере того как руководство признавало все новые и новые достижения, темп реализации программы возрастал от очень низкого до среднего и, наконец, она, образно говоря, переключалась на высокую передачу. <...>
Программа Alpha AXP выросла из компьютерных исследований, точнее – из исследований по технологиям и преимуществам различных RISC-архитектур, а также из передовых разработок в области создания компиляторов, проектирования СБИС и производства полупроводниковых систем. В 1988 г. руководство корпорации Digital поставило перед инженерным департаментом задачу разработать систему, которая бы удовлетворяла потребность клиентов в плане первоклассных эксплуатационных характеристик во всех вычислительных средах корпорации Digital. Инженерный департамент из представителей разных подразделений сформировал рабочую группу, которая разработала необходимую системную архитектуру и проектную документацию. <...> Руководство Digital одобрило программу Alpha AXP в октябре 1988 г. К концу 1989 г. Digital завершила упомянутые разработки, а также работу с документацией по архитектуре и предварительному проектированию. В ходе широкой проверки в январе 1990 г. высшее руководство потребовало, чтобы работы по программе были ускорены и завершены в пределах "e;рыночного окна"e; для новой технологии. <...>
Когда программа Alpha AXP была одобрена, Центр управления начал проводить ежеквартальные обзорные собрания. На этих форумах группы докладывали о планах и о ходе работы для широкой аудитории, состоящей из специалистов разного профилей. Сначала эта аудитория состояла из групп инженеров, производственных и сервисных групп. По мере того как программа набирала темпы, в работу включились другие специалисты – по маркетингу и сбыту; они тоже начали сообщать о ходе своей работы. Эти форумы помогли установить доверие и упрочить принцип вовлечения. Они также помогли Центру выявлять проблемные участки до назревания кризиса. Мы добились понимания всеми участниками программы важности массового выпуска продукции в 1992 г.
После того как ключевые менеджеры проектов усвоили общую концепцию программы, нам предстояло сделать следующий шаг – создать рабочий план и обеспечить обязательство каждой группы выполнить свою задачу в установленные сроки. <...> Необходимость одновременной разработки многочисленных аппаратных и программных систем осложняла задачу координации. Центр управления решал эту проблему комплексной координации по двум направлениям: в плане технического менеджмента и менеджмента проекта. По техническому направлению Центр сформировал команду технических руководителей из основных инженерных групп, известную как EJST (EVAX Joint Systems Team; EVAX – первоначальное название программы Alpha AXP – прим. Р.Б.). <...> Эта группа на еженедельных заседаниях вырабатывала директивы по вопросам технического проектирования и стратегическим вопросам, касающимся сразу нескольких групп. Поскольку в компетенцию этой группы входило решение проблем и обеспечение выполнения решений, EJST превратилась в орган, куда работники представляли технические проблемы для их разрешения.
В области управления проектами менеджер программы сформировал команду менеджеров проектов. Каждый член этой команды был уполномочен соответствующей группой инженерной разработки брать обязательства и отвечать за их выполнение. Эта команда была известна как ASPM (Alpha AXP System Project Managers). Масштабность генеральной задачи и сложность понимания всех деталей взаимозависимостей в ходе работы привели к тому, что менеджерам проекта сам проект, как правило, представлялся невероятно сложным. Поэтому на уровне программы проблема состояла в том, чтобы создать генеральный общий план Alpha AXP. Но этот план создавался значительно медленнее, чем мы ожидали. Неспособность администраторов создать генеральный план привела к возникновению кризиса доверия. Менеджеры проектов грозили мятежом (или уходом в другие проекты). Технические руководители разрабатывали все более масштабную проектную документацию. Менеджеры групп инженерной разработки заявили, что Центр управления программой стоит на пороге кризиса. Нам нужно было создать рабочий план для всей программы, из которого следовало бы, в каком порядке каждый подпроект должен представить результаты своего труда (выполнить свою задачу).
Как координировать работу, не имея плана? Менеджер программы Alpha AXP постоянно требовал от отдельных групп предоставления их планов. От чего зависит ваша работа? Какое время она займет? Какие средства вам потребуются? Каковы основные этапы или параметры вашей работы? Постоянным ответом было: "e;Не знаю – мне же неизвестно, что делают остальные и когда они закончат свою часть"e;. К этому времени мы уже создали состоящую из опытных менеджеров проектов многофункциональную команду ASPM, в которой было представлено большинство групп разработчиков. И эта команда не имела возможности составить планы работы подразделений, поскольку у нее не было генерального плана.
Выбор стратегии. Для разработки общих параметров плана программы Alpha AXP менеджеры инженерных групп разработки собрались на заседание, которое длилось целый день. Сначала они установили коммерческие цели и исследовали различные технические ограничения. Критерием для включения в план того или иного компонента был ответ на вопрос: "e;Имеет ли она решающее значение для достижения коммерческого успеха программы Alpha AXP"e;? Такая постановка обеспечила серьезный подход к содержанию генерального плана, причем решение о включении или невключении того или иного компонента оставалось за ответственной группой разработки. Затем эта группа определяла организационные аспекты такого рабочего плана. Члены группы рассматривали коммерческие, технологические и организационные аспекты для определения приоритетов и порядка работы. Мы дали этой группе статус Совета директоров по разработке систем Alpha AXP (ASBOD – Alpha AXP System Board of Directors; в результате общая структура управления проектом Alpha AXP включала в себя Центр управления проектом, группу технических директоров EJST, группу менеджеров проектов ASPM и все инженерные группы, находящиеся под контролем ASBOD – прим. Р.Б.).
Представление плана. Когда были установлены важнейшие приоритеты и ограничения программы, менеджер программы Alpha AXP приступил к составлению генерального плана. Чтобы дать возможность каждой группе видеть свое место в общей работе, он решил ограничить генеральный план одной страницей текста. Он определил содержание плана в рамках интенсивного периода, в ходе которого просил участников описать свои посылки и задачи и показать, как вписывается в общий план вклад каждой из участвующих групп. Одностраничный формат плана заставил команду управленцев (группу управления) отбирать в него лишь самое важное и позволил участникам увидеть свои участки работы, не перегруженные конкретными сложностями работы данной группы. Далее, на обзорных совещаниях всем участникам было легко видеть картину в одном и том же свете, в котором результаты можно видеть, обсуждать и приходить к общему согласию относительно стоящих проблем. Когда группа управления составила план, он был рекомендован менеджерами проектов (ASPM) и одобрен менеджерами группы инженерных разработок (ASBOD). Теперь члены группы знали, что их цели не будут меняться без явно указанных причин. К тому же другие могут начать составлять свои планы на основе согласованного набора предпосылок. Возникшая в результате страница текста стала точкой отсчета для установления и усиления постоянства целей. Мы назвали ее "e;соломенная лошадка"e; – Straw Horse Plan. <...> Позднее мы повысили ранг этого плана, назвав его "e;оловянной лошадкой"e; (Tin Horse) и подчеркивая тем самым повысившуюся надежность лежащих в его основе планов и обязательств. Мы пришли к согласию относительно генерального плана размером в одну страницу, исходя из которого бригады (teams) могли создавать собственные планы. <...>
Еще в начале 1980-х годов один из вице-президентов нашей корпорации любил повторять: "e;Не полагайтесь на обещанию. Результат определяют проверки"e;. <...> В прошлом проверки, проводимые линейным руководством, как правило, вели к тому, что подчиненные утаивали недостатки до тех пор, пока те не превращались в трудноразрешимые проблемы. У нас же менеджер программы, действующий в рамках концепции Центра управления, не был наделен административной властью, и ежемесячные оперативные проверки проходили в открытой и доброжелательной атмосфере. Отчитывались ответственные менеджеры проектов, представлявшие каждую группу разработчиков. При этом Центр призывал всех участников сообщать о своих трудностях и проблемах до того, как ситуация выйдет из-под контроля. И здесь мы использовали документы одностраничного формата. В верхней части такого документа в простой, наглядной форме представлялся ход решения важнейших задач, позволяющий легко проследить повторяющиеся задержки по срокам. Упор делался на событиях критического пути, завершенных в прошлом месяце и тех, что предстояли в следующем месяце. В нижней части документа перечислялись как решенные, так и новые задачи с четким указанием ответственного и срока выполнения. <...>
Центр управления ввел в практику ежемесячные проверки, информация о которых фиксировалась в документах единого образца объемом в одну страницу. <...>
После уяснения общей концепции программы и составления планов мы все оказались во власти эйфории. Но вскоре на смену ей пришло отчаяние, вызванное пониманием огромной сложности предстоящей работы. Главной проблемой в тот момент было сдвинуть программу с мертовй точки. Модель управления через вовлечение подразумевает тесную связь между наращиванием темпов (стадия признания -- изучения) и стадией контроля. Иными словами, события, установленные в ходе проверки, помогли нам раскручивать маховик всей программы. Центр управления активизировал усилия по разъяснению ее общей концепции, и когда исполнители все активнее стали браться за дело, у них уже не было времени предаваться унынию перед лицом предстоящей работы. Размах нашей программы был поистине колоссальным, и неудивительно, что у многих участников стали опускаться руки. По коридорам пошли разговоры о том, что всю работу не переделаешь, что график будет постоянно срываться и всем придется работать сверхурочно. Этот синдром типичен для любого крупного проекта, особенно если его участники вынуждены брать на себя обязательства, связанные с серьезным риском. В этих условиях руководство программы приняло решение информировать участников даже о небольших успехах. Широко распространяя соответствующие сообщения по сети электронной почты корпорации Digital, мы начали вселять уверенность в своих людей. Этой уверенностью заражались другие группы, и они тоже добивались успеха. Словно волна прокатилась по всем подразделениям, участвовавшим в программе: все новые группы приходили к выводу, что предстоящая работа им под силу; и вот уже каждый коллектив стремится к тому, чтобы его достижения получили огласку. Программа стала набирать обороты.
Центр управления программой убедился в том, что простая благодарность, выраженная в форме публичного признанияи достижений участников проекта, высоко оценивается ими и может служить серьезным стимулирующим фактором. Этот вывод противоречит установке традиционной теории управления, согласно которой мотивировать людей к труду следует с помощью частых денежных вознаграждений. Спору нет, от премии никто не откажется, но все же самый мощный стимул для профессионала – благодарность за хорошую и нужную работу. Надо отметить, что курс на признание заслуг принес еще один положительный эффект – увереннее стали чувствовать себя менеджеры проектов. <...>
На дальнейших этапах реализации программы Alpha AXP Центр управления программой развернул активную работу с другими фирмами и покупателями. Поэтому мы все время знали, что думают о нашей программе другие. <...>
Все рабочие группы программы Alpha AXP уделяли первостепенное внимание качеству своей работы. Менеджеры неоднократно убеждались в справедливости афоризма Фила Кросби -- "e;качество бесплатно"e; (P.Crosby "e;Quality Is Free: The Art of Making Quality Certain"e;, 1979). Анализ работы различных групп неизменно свидетельствовал: там, где с самого начала качеству уделяют неослабное внимание, задание выполняется в срок или даже досрочно. Однако, руководство программы обратило внимание на то, что мы не занимаемся проверкой работы по повышению качества на уровне систем, а ведь клиента интересует лишь качество конечного продукта. И вот, когда различные проекты начали выстраиваться в единую систему, Центр управления создал независимую группу контроля качества уже на уровне всей программы. <...>
Результаты и уроки. Несмотря на многочисленные трудности корпорация Digital с точностью до месяца (речь идет о сроках серийных поставок) выдержала общий график работ. Система Alpha AXP соответствует проектным рабочим характеристикам при отличном качестве конечных продуктов. Совет директоров Digital утвердил бизнес-план программы Alpha AXP в полном объеме и выделил средства, необходимые для коммерческой реализации семейства машин Alpha AXP. <...>
Полностью себя оправдали и концепция Центра управления, и связанная с ней модель управления через вовлечение. <...> Надежным инструментом повышения эффективности работы оказалось творческое использование переломов в ходе проекта. С помощью введения общего графика работ и дисциплины, поддерживаемой регулярными проверками, мы добились того, что график стал своеобразным инструментом утверждения разделяемой всеми концепции программы. Между тем, обычно график воспринимается как некое дополнительное бремя. В результате большинство групп вовремя справилось с весьма масштабными заданиями. А несколько групп, решавших чрезвычайно сложные задачи, перекрыли график. <...> Разумеется, один из важных уроков состоял в том, что перед собой надо ставить четкие задачи и не отступать от них, но в то же время постоянно учиться и корректировать подробные планы. Ключевую роль в поддержании единства целей играет их компактное изложение на одной странице текста и общий план программы.
Что нужно было сделать по-другому. Если смотреть с позиций дня сегодняшнего, следовало бы изменить наш подход к программе в двух отношениях. Во-первых, было бы полезно познакомить руководителей проектов с методологией управления в большем объеме и на более ранней стадии. Дело в том, что несколько проектов были завершены со значительным опозданием, и это создало ненужные осложнения для других групп. Центру управления следовало бы быстрее и энергичнее пропагандировать методологию Ляфлера (R.LaFleur "e;A Seminar in Project Management"e;, 1990). Мы же не начинали эту работу, пока не убеждались, что группа осознала ее необходимость. Некоторым группам, в том числе группе разработки OpenVMS для Alpha AXP, методологию излагали на ранних этапах их деятельности. Но другие группы так и не усвоили эту дисциплину (ни тогда, ни теперь).
Во-вторых, Центр должен был шире практиковать проверки состояния дел в отдельных проектах. Некоторые группы слишком долго готовили графики и планы, которые Центр управления был в состоянии понять. <...>
Программа Alpha AXP – самое сложное предприятие такого рода в истории корпорации Digital – была реализована в срок и с высоким качеством. Для организации коллективной работы, без чего было бы невозможно совершение этого прорыва, Центр управления программы применял жесткую методологию управления.
<==
Важно отметить тех, чей вклад был во многом определяющим в этом масштабном проекте. Гордон Белл (Gordon Bell) занимался проработкой архитектуры. Кен Ольсен (Ken Olsen) настойчиво продвигал идею одностраничных планов. Джеф Калб (Jeff Kalb) ввёл принцип состязательности. Боб Сапник (Bob Supnik) проработал идею создания и принципы работы Центра управления программой.
Проект DEC Alpha AXP (1988-1992). Лебединая песня некогда могущественной корпорации DEC (Digital Equipment Corp.), которая в 1970-1990-х годах была главным конкурентом IBM в области разработки компьютерных систем. Цель – создание единой 64-разрядной платформы нового поколения для всего спектра систем: от микро- до суперкомпьютеров и сопутствующей инфраструктуры (соответствующие ОС, инструментальные средства и др.). Поддержка собственных ОС OpenVMS, Tru64 UNIX (ранее -- DEC OSF/1 AXP, Digital UNIX ), а также Linux, BSD-семейство UNIX, Windows NT. Проект ставил целью осуществить постепенный переход с CISC-архитектуры VAX на RISC-архитектуру Alpha AXP (ранее -- EVAX). Проект был реализован в рекордно короткие сроки. К концу 2000 г. в мире было продано свыше 500 тыс. систем на базе процессоров Alpha. В середине 2003 г. (через 5 лет после исчезновения Digital) фактически снятый с производства процессор Alpha был основой самых производительных суперкомпьютеров!
Предпосылки к началу проекта Alpha AXP были заложены в ходе работ над PRISM (Parallel Reduced Instruction Set Machine, 1985-1989) – 32-разрядным экспериментальным RISC-процессором корпорации Digital c операционной системой Emerald и программируемым микрокодом Epicode (прообразом Alpha PALcode – уровнем абстрагирования от аппаратуры). Проект PRISM был во многом инициирован в стенах DEC энтузиастом RISC-архитектуры Дэвидом Катлером (проект CASCADE, 1984), будущим главным конструктором Microsoft Windows NT и Windows 2000. Главный конструктор PRISM Рик Витек (Rich Witek) первоначально закладывал в проект 64-разрядную архитектуру.
Первые экземпляры процессора Alpha AXP были продемонстрированы в феврале 1991 г. и произвели огромное впечатление на руководство Apple. Джон Скулли (John Scully), тогда возглавлявший Apple, пригласил на званный обед основателя и президента DEC Keна Ольсена (Kenneth Olsen), чтобы сделать предложение о стратегическом партнерстве – использовать Alpha AXP в новых моделях компьютеров Apple. Ольсен отклонил предложение. Как впоследствии вспоминал Уильям Деммер (William R. Demmer), бывший вице-президент Digital, отвечавший за бизнес Alpha AXP и VAX, "e;Кен не хотел, чтобы будущее корпорации зависело от Alpha"e;. Через несколько месяцев Apple заключила альянс с IBM и Motorola по использованию процессоров PowerPC в качестве основных движков своих компьютеров. Через год Ольсен ушел с поста президента. Еще одним ударом по Digital был уход в 1991 г. из компании легендарного Гордона Белла (Gordon Bell), архитектора PDP-4, PDP-5, PDP-6, PDP-11, VAX-11, Alpha AXP. С 1991 по 1995 гг. Белл совмещал работу в своей новой компании с должностью советника в Microsoft, а после 1995 г. стал штатным сотрудником Microsoft Research и полностью отдал себя исследованиям.
Через 7 лет после упомянутой выше встречи руководства двух компаний Digital была похоронена компанией Compaq, сумевший в рекордно короткий срок при участии Intel и Microsoft уничтожить все следы некогда существовавшей могущественной корпорации. А потом и сама Compaq сдалась на милость победителю в лице HP.
Дополнительная информация
Richard Sites "e;Alpha AXP Architecture"e; // Communications of the ACM, February 1993.
Richard Sites, Anton Chernoff, Matthew Kirk, Maurice Marks, Scott Robinson "e;Binary Translation"e; // Communications of the ACM, February 1993.
Nancy Kronenberg, Thomas Benson, Wayne Cardoza, Ravindran Jagannathan, Benjamin Thomas "e;Porting OpenVMS from VAX to Alpha AXP"e; // Communications of the ACM, February 1993.
Matt Reilly "e;Designing an Alpha Microprocessor"e; // IEEE Computer, July 1999.
М.Рэйли "e;Как рождается микропроцессор Alpha"e; // Открытые системы, #07-08/1999.
Л.Черняк "e;Памяти Digital Equipment Corporation (1957 — 1998)"e; // Открытые системы, #03/2002.
Л.Черняк "e;От VAX до Alpha"e; // Computerworld Россия, #08/2005.
Дж. Виджаян "e;Digital открывает перед процессорами Alpha новые перспективы"e; // Computerworld Россия, #02/1997.
Д. де Во "e;Нелегкие времена Digital"e; // Computerworld Россия, #12/1997.
Р.Богатырев "e;Даст ли Oberon новый импульс развитию платформы Digital Alpha"e; // СomputerWeek-Moscow, #40/1997.
Р.Богатырев "e;Compaq и Digital: шок сменяется прозрением"e; // СomputerWeekly, #05/1998.
Р.Богатырев "e;Эволюция UNIX"e; // СomputerWeekly, #05/1998.
Д.Грей, Л.Род "e;Alpha на двоих. Compaq передает Intel секреты своего процессора"e; // Computerworld Россия, #25/2001.
Д.Грей "e;Технологии Alpha на службе у Intel"e; // Computerworld Россия, #33/2001.
Дж.Николаи "e;Будущее расставание с Alpha"e; // Computerworld Россия, #48/2002.
М.Кузьминский "e;За явным преимуществом. Alpha 21164 и 21264"e; // Computerworld Россия, #29/1997.
М.Кузьминский "e;Микроархитектура DEC Alpha 21264"e; // Открытые системы, #01/1998.
М.Кузьминский "e;Вперед под флагом параллелизма. Микропроцессоры Alpha 21364"e; // Computerworld Россия, #32/1999.
М.Кузьминский "e;Многонитевая архитектура микропроцессоров. Compaq Alpha 21464, Intel Xeon MP и Itanium Processor Family"e; // Открытые системы, #01/2002.
М.Кузьминский "e;RISC сдается, но не умирает. СMP, SMT, EPIC — три перспективных подхода к развитию архитектур высокопроизводительных микропроцессоров"e; // Computerworld Россия, #06/2002.
Ю.Долбнев "e;Операционная система Digital Unix"e; // Открытые системы, #03/1997.
С.Брик, К.Вахрамеев "e;OpenVMS сегодня и завтра"e; // Открытые системы #05-06/2000.
Л.Левин "e;Itanium — третья платформа OpenVMS"e; // PC Week, #41/2007.
Л.Черняк "e;От VAX до лезвий. Операционной системе OpenVMS исполнилось 30 лет, но ее ресурс далеко не исчерпан"e; // Computerworld Россия, #40/2007.
|
