Когда вы находитесь в Сиднее, поступайте так, как поступают жители этого города. Много лет назад, когда американские кафе с золотистыми сводами, входящие в сеть быстрого питания, впервые появились на Пит Стрит, в них предлагали гамбургеры австралийского типа, с маринованной свеклой сверху. Не так давно американские автопроизводители были обеспокоены тем, что японские покупатели приобретали мало американских машин, тогда как модели, произведенные в Японии, хорошо продавались в Америке. Конечно, машины, привезенные из Японии в Штаты, имели руль с левой стороны, чтобы соответствовать дорожной культуре, согласно которой автомобили ездят по правой стороне дороги. А Японии, небольшой островной стране с левосторонним движением, Детройт пытался продавать большие американские машины с неправильно расположенным рулем управления!

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

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

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

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

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

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

Первый важный вопрос: где находятся профессиональные ноу-хау организации? Хранятся главным образом в головах сотрудников? Являются частью коллективного фольклора — «здесь принято делать так»? Или же они формально закреплены в методах и процедурах? Другими словами, где «живет» практический опыт и кто им «владеет»? Сколько ноу-хау можно найти в корпоративных руководствах и инструкциях? Куда нужно пойти, чтобы узнать о ходе разработки программного обеспечения? Полагается ли ваша компания всегда и во всем на знания и умения ее блестящих и опытных сотрудников? Что можно узнать, околачиваясь в столовой или слушая разговоры в коридорах? Определяется ли «наилучший способ» на основе личных предпочтений? Или же «хорошее программирование» основано на неписаных законах о том, что работает и что не работает? Как происходит накопление знаний с каждым новым проектом — индивидуально, или распространяется по всей группе, или же эти знания добавляются в архивы и формальные инструкции, принятые в организации?

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

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

Если новые технологии и методы применяются неверно, то их внедрение будет затруднено, а шансы на успех — малы. Например, один из методов перехода к широкому применению объектно-ориентированного проектирования может заключаться в привлечении большой группы консультантов. Они придут со своим рациональным и унифицированным «Объектным методом для разработки гигантских приложений» (Object Method for Engineering Giant Applications, OMEGA) в комплекте с семью томами технологических руководств и предложат несколько ступеней обучения с применением интегрированного CASE-инструмента. Такая участь может ожидать группы, в которых традиционно применяется дисциплинированное проектирование, а полки заставлены замусоленными руководствами по стандартам. Однако группа свободно мыслящих программистов, работающих по своим собственным стандартам, будет увиливать от таких занятий, чтобы покодировать. Они не станут читать инструкции и не будут обращать внимание на всю эту «корпоративную чепуху». Их методы, так же как и их умения и способности, сугубо индивидуальны. Для того чтобы до них «достучаться», вам не нужно загонять их в большой класс на просмотр учебного видеофильма или отдавать в руки бездумного инструктора. Они привыкли на свой страх и риск определять, что стоит изучать, и самостоятельно доставать необходимые материалы, поэтому каждого из них нужно убеждать в отдельности, а затем обеспечивать их локальными ресурсами для индивидуального практического обучения.

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

Одни и те же инструменты разные группы могут применять по-разному. Групповое обеспечение (groupware) может подойти для организации, в которой принято тесно сотрудничать при проектировании и принятии решений. Однако группа разработчиков-одиночек, которые любят работать обособленно, вряд ли заинтересуется Lotus Notes. В компании кодирующих ковбоев сложное групповое обеспечение станет не более чем причудливым средством для дружеской переписки.

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

Кто-нибудь будет маринованную свеклу?

Из журнала Software Development, том 2, № 12, декабрь 1994 г.

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

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

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

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

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

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

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

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

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

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

Из журнала Software Development, том 3, № 1, январь 1995 г.

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

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

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

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

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

На этот вопрос ответить довольно легко. Например, одна-единственная ошибка во встроенном обеспечении одного из принтеров Hewlett-Packard может помешать этой компании достичь новых успехов. Если достаточно серьезная ошибка обнаруживается после выпуска продукта, то расходы на апгрейд ПЗУ будут больше, чем прибыль, полученная за весь период существования данной серии. Это серьезный стимул не допускать ошибок с самого начала. Так они и делают. Ни одна большая программа не бывает идеальной, однако некоторые программисты встроенных систем создают огромные программы с качеством, настолько близким к безупречному, насколько это вообще возможно. Дальнейшее снижение количества ошибок просто-напросто потребовало бы слишком больших затрат.

Может быть, в этом отчасти и состоит проблема компаний вроде Microsoft и IBM: нет достаточного стимула для того, чтобы делать все правильно, особенно когда покупатели согласны мириться с нелепым программным обеспечением, содержащим ошибки. Поставщики программного обеспечения всегда могут незаметно внести исправления в выпускаемые продукты, или просто выпустить исправленную версию 6.0а по цене CD-дис-ка, или же выложить ее в Интернете, чтобы каждый мог самостоятельно ее скачать.

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

Безошибочность части таких программ достигается с помощью насильно-го внедрения личной дисциплины, которая усмиряет даже самых воинственных маньяков, помешанных на стандартах. Некоторые компании, особенно в сфере телекоммуникаций и программ военного назначения, эффективно применяют «чистые» методы программирования. Согласно этим методам, сборка кода проводится очень тщательно, а программистам запрещено возвращаться к написанному коду. Другие компании достигают таких чудес, собирая системы из огромного количества компонентов повторного использования. Некоторые из случаев наиболее сложного и строгого применения объектно-ориентированной технологии относились к созданию встроенных приложений. В основном они написаны на С++, но Smalltalk также проявил себя с лучшей стороны.

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

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

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

Отчасти успех программирования встроенных систем связан с культурой и контекстом, а также, как я убедился, с применяемым подходом и профессиональной подготовкой. Многие годы я веду мастер-классы по высокопроизводительной командной работе и обучаю методам проектирования с учетом юзабилити на проводимой два раза в год Конференции по встроенным системам (Embedded Systems Conference). Когда я высказывался по поводу того, насколько быстро команды программистов встроенных систем находили действительно хорошие решения учебных задач, почти всегда кто-нибудь объяснял это тем, что большинство из них — инженеры.

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

Из журнала Software Development, том 3, № 7, июль 1995 г.

Культурным сердцем Тосканы является город великого искусства и великолепной еды. Для американцев это Флоренция, для итальянцев — Firen-ze. Колонны часто встречаются в архитектуре Firenze. При написании этой колонки[46] я черпал вдохновение в одном ресторане. На мой взгляд, он может служить образцом самых лучших методов работы, на котором мы все можем учиться.

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

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

Он был совершенным и идеальным. Его нель-зя было улучшить, не превратив во что-нибудь другое, чем он не должен быть и для чего не предназначался.

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

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

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

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

В том ресторане все было по-другому. Небольшое помещение, где каж/ дый, похоже, отвечает за все. Умберто Монтана (Umberto Montana) стоит у руля, но весь персонал действует так, словно ресторан принадлежит всем им.

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

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

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

Даже посетитель становится частью этой команды. Заказ напоминает обсуждение технических требований. Какое вино вы желаете? Может быть, после этого блюда на первое вам понравится рулет из мяса ягненкаil se-condo? Умберто может даже на месте придумать блюдо, которое подойдет под ваш вкус и будет сочетаться с выбранным вами вином. Он отходит к окошку небольшой кухни и говорит с шеф-поваром. Нет, она не может сделать это сегодня, но как насчет поджаренной на огне утки? Он возвращается к столу с новым предложением.

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

По-настоящему хорошая итальянская еда требует к себе хорошего вина — или даже более чем хорошего. Вино, которое прекрасно подходит для макарон или для блюда из рыбы, совершенно потеряет свой вкус с уткой, начиненной spinacci и апельсиновой коркой. Для Dolci, десертного блюда, подойдет бокал Malvasia spumante или, возможно, Brachetto. Не все могут посчитать это необходимым для получения полного удовольствия от еды, однако отдельные посетители закажут к обеду больше одного сорта вина.

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

В программном обеспечении хорошо разработанный пользовательский интерфейс не показывает пользователям все, что они когда-либо могут пожелать. Он просто показывает все то, что необходимо для текущей задачи. Хороший интерфейс является тонким компромиссом между желаниями пользователей и тем, что им действительно необходимо для работы. Именно в этом состоит разница между современными методами проектирования, ориентированными на использование (Constantine и Lockwood, 1999 [30]), и устаревающими методами типа «пользователь в центре внимания».

Меню в этом ristorante — сама простота. Вы выбираете из скромного списка главных блюд либо заказываете один из комплексов с фиксированной ценой и полностью полагаетесь на опыт и вкус Умберто и его персонала, которые создают для вас сюрпризы и радость.

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

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

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

Из журнала Software Development, том 3, № 8, август 1995 г.

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

По словам известного эксперта Эда Йордона (Ed Yourdon), наставничество стало признаком культуры компании Microsoft и краеугольным камнем ее подхода к улучшению программного обеспечения. В соответствии с этим подходом за новыми работниками закрепляется персональный наставник, который проверяет каждую строчку их кода. А «наставляемый» читает каждую строку кода, написанного наставником. Это, как нам говорят, является живым подтверждением стремления к качеству и совершенствованию рабочего процесса на большом ранчо в Редмонде.

Не желая ни славить, ни хоронить Цезаря, я воздержусь от общераспространенного бичевания Microsoft и вместо этого обращу больше внима-ния на то, чем является и чем не является наставничество. Во-первых, оно не ново. Несмотря на неологическое одеяние, представляющее наставничество как часть общего движения к совершенствованию качества и улучшению рабочего процесса, это старая идея. Наставничество — это модель «мастер-ученик» без узаконенного рабского служения. Это «переодетая» версия метода «сядь рядом с Нелли», который ранее применялся в разработке программного обеспечения. Эд Йордон и я даже писали об этой простой методике в первом издании «Structured Design» (Структурное проектирование) (Yourdon и Constantine, 1974 [70]). Новому программисту говорят: «Сядь рядом с Нелли. Она знает, как программировать». Как мы объяснили впоследствии, это симптом проблемы. Так как никто точно не знает, как Нелли удается хорошо программировать, и даже она сама не может толком это объяснить, то самый лучший способ поучиться у нее — это сесть рядом и смотреть, как она пишет код.

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

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

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

У меня были самые лучшие наставники. Удивительно, что нашлись умные тренеры, которые оказались достаточно смелыми и готовыми к тому, чтобы взять на обучение такого беспокойного молодого человека. Результаты тех лет все еще полезны. Я до сих пор стараюсь найти новые повороты в методиках, о которых я впервые узнал от Джека Креминса (Jack Сге-means), Кена Макензи (Ken Mackenzie), Дэйва Джаспера (Dave Jasper) и Бада Вайтофа (Bud Vitoff).

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

Это соответствие само по себе может стать первым небольшим шагом к повышению качества процесса проектирования. Согласованность — бабушка качества. Аксиома совершенствования рабочего процесса такова: перед началом улучшения процесса необходимо организовать его контроль — сделать его воспроизводимым. Пока процесс разработки программного обеспечения остается хаотичным, усилия — нерегулярными, а вы не знаете, будет ли продукт сдан в срок и в каком он будет виде, никакого систематичного совершенствования и последовательного улучшения не добиться. Надежность конечного продукта остается, главным образом, в руках Судьбы и легионов бета- и гамма-тестеров. Согласно Модели развития функциональных возможностей (Capability Maturity Model), представленной Институтом разработки программного обеспечения (Software Engineering Institute), первая ступень на лестнице качества, которая ведет к великим высотам 5-го уровня (другими словами, к работоспособному программному обеспечению), подразумевает уменьшение различий, то есть получение непротиворечивых результатов в ходе предсказуемых процессов. Конечно, это означает, что блестящие и необъяснимые успехи, равно как и неожиданные провалы, не будут распространяться. Таким образом, разработка будет вестись согласно «золотой середины» — в более стабильной, но менее эффектной среде.

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

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

Итак, слово «наставничество» является одним из ключевых — по крайней мере, сегодня. Однако язык продолжает преображаться прямо на глазах. Язык должен двигаться дальше и изменяться, иначе мы быстро к нему привыкнем или, что еще хуже, будем ограничены в своих действиях. Умные консультанты просто-напросто умеют называть все по-другому. Деньги на консультации и обучение можно выжать из бюджетов, но еще не все охотники за наживой открыли для себя тренировку и наставничество. Когда только это произойдет, появятся денежные ограничения на контракты по организации тренировок, а наставничество «окаменеет» на 13 страницах контрактных обязательств, компенсаций и договоренностей о неразглашении.

Возможно, так и было задумано!

Из журнала Software Development, том 3, № 3, март 1995 г.

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

Неудовлетворенный моим ответом, человек подошел ко мне в перерыве. Что же ему делать? Его компания не поддерживает дальнейшее образование, расходы на обучение в бюджете не предусмотрены, книги и курсы слишком дороги для его скромного заработка, a COBOL — это все, что он знает.

Отраслевые стилисты уже не один год объявляют о том, что мэйнфреймы ушли в небытие, однако в тот момент, когда следователь уже собирается подписывать свидетельство о смерти, эти чертовы машины опять поднимают голову. Не оплакивайте старый добрый COBOL. Наверное, на планете наберется больше строк на COBOL, чем на всех других языках программирования, вместе взятых. (Этот досадный факт подтвердился, когда возникла «проблема 2000 года», напомнившая о старом пенсионере COBOL.) Как и все живые языки, COBOL продолжает развиваться. Теперь он стал объектно-ориентированным и когда-нибудь может получить настоящую поддержку.

Как и рок-н-ролл, COBOL будет жить вечно. Конечно, «вечность» — это относительное понятие в отрасли, где языки пятого поколения следуют за языками четвертого поколения уже через несколько лет после языков третьего поколения. Тем не менее языки программирования подчиняются Четвертому закону Константина: ни один язык программирования, на котором пишут значительное количество разработчиков, не может исчезнуть полностью. Изучать программирование я начал с Фортрана — одного из самых первых «высокоуровневых» языков. Фортран до сих пор применяется, до сих пор поддерживается своими партизанами, до сих пор жизнеспособен. Еще более удивительно то, что язык RPG, уже седой к моменту моей первой встречи с ним в начале 60-х, в середине 90-х все еще оставался в ходу.

Мой твердый совет этому несчастному программисту был обусловлен не пессимизмом или оптимизмом в отношении близкой кончины больших ЭВМ и «больших» языков, а реализмом относительно происходящего в этой профессии. Вопрос не в том, сможет ли этот кодирующий консерватор сохранить свою работу, а в том, что он будет делать в мире возникающих и исчезающих возможностей. В 80-х годах мой шурин вовремя оставил COBOL и мэйнфреймы, но это было тогда, а этот программист все еще стоял и спрашивал меня, как быть дальше.

И я ответил ему. На манер Дастина Хоффмана в сцене из фильма «Выпускник«(«The Graduate») я прошептал: «Объекты». Если вы не занимаетесь объектами, тогда займитесь ими. Иначе вы окажетесь среди тех, кто смотрит на проходящий через пески поток, который оставляет после себя высыхающую лужу возможностей. Я также говорил ему о визуальном проектировании. Я даже предложил изучить что-нибудь из программирования встроенных систем — я могу создавать трудности.

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

Трудно сказать, что делать. Ветры меняют свое направление, а прибой может унести вас в море. Вы можете заняться Java, изучить ActiveX или освоить межплатформенную библиотеку ГПИ, и все же вы будете смыты волной, когда производитель вашего любимого инструмента «отдаст концы», или продукт перестанет поддерживаться из-за поглощения компании, или Билл и Компания опять передумают и решат все сделать по-другому.

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

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

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

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

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

Это приводит нас к другой стороне более надежного будущего. Стоит изучать то, что является наиболее общим.

В Бостоне существует огромное количество колледжей и университетов, в которых предлагаются разнообразные подходы к образованию. Когда я пошел в колледж, в инженерной области все равнялись на Массачусет-ский технологический институт и Северо-восточный университет — две школы, которые так же отличаются друг от друга, как Smalltalk и COBOL. В районе Бэк-Бэй¹ располагался Северо-восточный университет, в котором упор делался на практику и на приобретение рабочего опыта в процессе совместного обучения. На кембриджской стороне реки² находился Тех, где правила наука, а акцент ставился на теорию, а не на практику — на фундаментальные принципы инжиниринга. Ходили слухи, что инженеры, прошедшие подготовку в Северо-восточном, могли эффективно работать уже в день своего выпуска, а выпускники Теха могли пять лет отрабатывать свое обучение. С другой стороны, еще через пять или десять лет бывшие студенты Северо-восточного сталкивались с устареванием своих знаний, а выпускники Теха по-прежнему были на высоте.

Теория не является бедной служанкой практики — она превосходит практику. Теория позволяет заглянуть в будущее. Когда Эйнштейн разработал формулу Е = тс², ядерных реакторов еще не было. Существование планеты Плутон было предсказано еще до того, как ее смогли увидеть; теоретически она должна была существовать, судя по параметрам орбиты Нептуна. В менее космическом масштабе: теория модульной сложности, на которой основано структурное проектирование, предсказала экспериментальные результаты, появившиеся спустя несколько лет. Кроме того, эта теория предвосхитила ключевые понятия объектно-ориентированного программирования, хотя при возникновении понятий связывания и сцепления методология ООП еще не существовала даже как идея.

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

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

Из журнала Software Development, том 3, № 4, апрель 1995 г.

Это был долгий год. Месяц за месяцем вы, как и другие программисты из вашей команды, тяжело работали, выполняя обязательства по проекту. Вы начинаете думать о премии в конце года. Это сезон подарков — зимнее солнцестояние, Ханука, Рождество, Кванза и обыкновенный Новый год — праздники идут один за другим. Что вы подарите вашим высокопроизводительным программистам, чтобы они поняли, как вы их цените? И вообще — как вы оцениваете, награждаете или стимулируете разработчиков приложений и программного обеспечения? По существу, именно в этом заключался вопрос, поднятый аудиторией на одном из лекционных туров, который я совершал по Австралии вместе с такими индустриальными светилами, как Роб Томсет и Эд Йордон. Это заставило всех нас задуматься о более творческих и эффективных методах поощрения разработчиков.

Это вечная проблема. Когда речь идет о стимулах, многие из нас склонны думать упрощенно. Несколько лет назад я работал с русскими и украинскими менеджерами из одной недавно приватизированной фирмы, которая раньше принадлежала советскому государству. В какой-то момент я понял, что вместе с ними оказался вовлечен в одну неувядаемую управленческую игру под названием «Почему бы вам не… — Да, но…». Я предлагал способы более эффективной работы, а они отвечали: «Да, но у нас нет надежных источников снабжения», «Да, но наши работники не готовы взять инициативу в свои руки», «Да, но мы не можем уволить работников и не можем изменить их зарплату. Мы не можем стимулировать сотрудников». Сначала эти блестящие и «мотивированные» менеджеры советской закалки не находили мотивацию для своих работников, но ког-да я предложил «мозговой штурм», они придумали десятки способов и средств мотивации, не прибегая к сокращению штатов или денежным поощрениям. Естественно, мы также способны найти эти возможности.

Многие из нас, чокнутых, любят технологические игрушки. Тест на родство со славным гранфаллоном довольно прост. Загораются ли ваши глаза при мысли о новом замечательном устройстве в ГПИ, или о SD-видео-карте к 21-дюймовому плоскоэкранному монитору, или о гигагерцовом лэптопе с диском в 20 Гбайт? Вы один из тех людей, которые не могут дождаться выхода бета-версии нового продукта? Вы раздираете целлофановую обертку для того, чтобы узнать, решены ли в релизе 2.0 проблемы релиза 1.1?

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

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

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

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

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

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

Быть в курсе событий, происходящих в области разработки программного обеспечения, довольно трудно. С другой стороны, это очень забавно — работать в такой быстро меняющейся технической сфере деятельности. Она никогда не бывает скучной. Посещение дополнительного практического семинара или билет на участие в очередной Конференции по про-граммированию встроенных систем (Embedded Systems Programming) или по разработке программного обеспечения может быть эффективным способом признания усердной работы. Книги и журнальные подписки — еще один недорогой метод поощрения.

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

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

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

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

Из журнала Software Development, том 3, № 12, декабрь 1995 г.

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

Все упали со смеху, когда я сказал, что получил отказ, — только Джеймсу Мартину[47] разрешили говорить оттуда.

Наша отрасль — это мир высоких технологий и твердолобых деловых людей, принимающих важнейшие корпоративные решения. Среди нас есть инженеры, ученые, аналитики, программисты. Мы тщательно и разумно анализируем продукты и процессы, а затем на основе их достоинств и недостатков делаем свой выбор. Однако под внешним налетом четкого здравомыслия и объективных данных лежит другой мир, в котором господствует культ личностей. Все дело в именах — в гуру, их последователях и со-ревнующихся лагерях, которые выступают под знаменами истинных верующих. Ура! Ура! Объекты выигрывают у функций 4:0 — подробности в следующем выпуске новостей.

У нас столько известных имен — от Коуда (Coad) и Йордона, Кодда (Codd) и Дэйта (Date) до Комафорда (Comaford), Крингли (Cringely) и Куртиса (Curtis); от Майерса (Myers) до Мейера (Meyer), Варда/Мелора (Ward/ Mellor), Вассермана (Wasserman) и Вайнберга (Weinberg). Все — начиная от новичков и восходящих звезд и заканчивая пантеоном, теми богами на вершине, чьи имена признаются каждым, кто пробыл в этой отрасли больше недели, — понимают, что это бизнес гуру и личностей настолько же, насколько бизнес технологий и чипов. Есть «глобальные» гуру и есть те, чья репутация связана с какими-то конкретными областями. Алан Грайвер (Y. Alan Griver) может легко заставить все сообщество Visual FoxPro слушать себя с раскрытым ртом, но среди мастеров по кодированию встроенных систем его речь вызовет только вопросы «Кто? Что-что?».

Большие звезды приобретают лояльных последователей и создают продукты, которые называют их именами. Уже есть Booch-граммы и Chen-нотации. При создании объектных моделей одни аналитики следовали Коуду/Йордону, а другие — Шлеру/Мелору (Shlaer/Mellor). В схемах потоков данных применялись либо кружки Йордона/ДеМарко (DeMarko), либо прямоугольники со скругленными углами, введенные Гейном/Сар-соном (Gane/Sarson). Было время, когда бизнес-аналитики могли из-за этого подраться. Может быть, вы все еще верите в системное проектирование по Джексону (Jackson). А может быть, вы все еще нормализуете свои определения до формы Бэкаса-Нора (Backus-Naur).

У нас есть множество звезд, а может быть, даже наберется с десяток суперзвезд, но в созвездии компьютерных светил Джеймс Мартин — самая яркая величина. По слухам, он зарабатывает $25 ООО в день. Что же нужно для того, чтобы достигнуть таких высот?

По мнению австралийского журналиста и обозревателя Грема Филипсона (Graeme Philipson), секрет заключается в особом сочетании стиля и содержания. Просто хорошее знание своего предмета и способность сказать нечто ценное не даст вам продвинуться дальше чтения лекций. Яркость и талант сами по себе работают лучше, по крайней мере хоть какое-то время, однако рано или поздно пустого болтуна раскусывают, и ему приходится либо кричать громче, либо прикусить язык.

Наличие характерной «изюминки» является необходимой частью игры. У Мартина есть смокинг, свое мультимедийное шоу и его безупречная, учтивая английская манера речи. У Пита Коуда есть гавайские рубашки и пластиковые гудки. Среди любимчиков Филипсона есть эксперт и аналитик Джеф Тэш (Jeff Tash), которого он описывает как «резкого и самоуверенного оратора, чей стиль — кричать на свою аудиторию». Как видите, есть немало способов произвести впечатление. Я сам известен своей ковбойской шляпой, которую я ношу на конференциях в качестве напоминания о своих тирадах по поводу кодирующих ковбоев (см. часть II).

По общему признанию, работа гуру программирования довольно приятна. На одной из бостонских Конференций по программным методам (Software Methods Conference) Меилир Пейдж-Джонс (Meilir Page-Jones), который сам считается гуру, закончил презентацию музыкальной пародией на хит Dire Straits «Money for Nothing». Вариант Меилира — это жалобная песнь работающего программиста, который изо дня в день лепит программы, а затем ему еще приходится высиживать на передвижных представлениях, устраиваемых «подиумными» демонстраторами. «Так не получится: деньги просто так и бесплатные путешествия».

На самом деле звезды в сфере программного обеспечения имеют двойственную природу. Немногие люди остаются «на сцене» так же долго, как Мартин и Йордон. Отчасти секрет выживания состоит в том, чтобы, как напоминает нам Меилир, не принимать все это всерьез. Полезно даже быть немного несведущим. Я понятия не имел о том, что сам могу быть гуру, до своей поездки в Бразилию с моей младшей дочерью в 1988 году. Наш хозяин, профессор компьютерных наук в одном из крупных университетов Рио, спросил Хивер, каково быть дочерью знаменитого отца. Она не поняла, о чем он говорил. Так же как и я.

Я вспомнил об этом, когда коллега по Сиднейскому технологическому университету представил меня как «икону отрасли». Я рассмеялся. У меня очень живое воображение, и я мгновенно представил панель инструментов, заполненную кнопками — одна из них содержала иконку¹ с изображением моего лица. Нажимаете кнопку с Йордоном и получаете предупреждение об офшорных программистах или ошибках 2000 г. Нажимаете кнопку с Гради, Айваром или Джимом — и на экране все унифицируется. Моя иконка может запускать хранитель экрана с кодирующими ковбоями, которые скачут галопом по монитору.

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

Некоторые шаги являются обязательными. Неважно, сколько систем вы построили, или сколько статей написали, или сколько провели семинаров. Никто не будет всерьез воспринимать вас как гуру до тех пор, пока вы не выпустите книгу или не станете регулярно печататься в какой-нибудь известной отраслевой газетенке. Желательно, чтобы эти заметки сопровождались вашей фотографией. Ваше имя на обложке книги должно идти первым среди соавторов. Все помнят, что метод ОМТ был разработан Рамбо (Rumbaugh), и каждый считает пользовательские ситуации неотъемлемой частью метода Джекобсона, но кто сейчас вспомнит имена других авторов, участвовавших в создании авторитетных трудов этих гуру?

Самый устойчивый и почитаемый гуру имеет нечто большее, чем стиль, — нечто, чему, вероятно, невозможно научить или научиться. Это харизма. Часто и неверно употребляемое слово «харизма» буквально означает дар богов. Этот дар наделяет некоторых людей способностью побуждать других идти на риск — создавать новое программное обеспечение, или стремиться к 5-му уровню в SEI, или заниматься неиспытанным языком программирования.

По-настоящему харизматические личности — те страстные истинные верующие, которые побуждают приверженцев следовать за собой в горы, в тюрьмы или в места похуже, — наверное, люди другого рода. Лен Оукс (Len Oakes), психолог из Мельбурна, изучающий психологию харизмы, утверждает, что, по сути, настоящие харизматичные гуру очень похожи друг на друга. Основополагающие идеи могут быть совершенно различными, но личности обладают сходным, чрезвычайно твердым центром. Кореш (Koresh), Жюре (Jouret), Раджниш (Rajneesh), Хаббард (Hubbard) — у харизматических лидеров подобного типа кроме всего прочего есть один общий изъян: непроницаемый эгоистичный взгляд на реальность, который может вызывать у других ощущение абсолютной, окончательной, непоколебимой достоверности. В мире, где преобладает двойственность и неоднозначность, достоверность может служить действенным эликсиром. Но, увы, достоверность такого рода основана на выдуманной реальности, которая не связана с реальным миром. Она поддерживается за счет непрерывных усилий по отгораживанию от новых идей, новых сведений и новых аргументов, которые могут поставить под сомнение абсолютную истинность личных представлений.

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

И в каждом змеиный жир?

Из журнала Software Development, том 3, № 2, февраль 1995 г.

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

Влияние и воздействие может принимать разные формы. Целая отрасль или профессия может измениться благодаря действиям или вкладу одного человека. Эдсгер Дейкстра (Edsger Dijkstra) применил теоретическую работу Бома (Bohm) и Джакопини (Jacopini) к стилю программирования. Своим историческим письмом к редактору под названием «GO ТО Statement Considered Harmful» (Оператор GO ТО считаю вредным) (Dijkstra, 1968 [34]) он вызвал спор, приведший к революции в практике программирования. Молодой Билл Гейтс совершил несколько правильных шагов в создании системного программного обеспечения для зарождающейся микрокомпьютерной индустрии, и наш бизнес радикально изменился. Докторская диссертация Алана Кэя (Alan Кауе) стала основой революционного языка, который помог превратить объекты в новую программную парадигму. В сущности, в основе современного компьютерного программирования лежит совсем немного базовых идей, которые были выдвинуты сравнительно небольшой группой новаторов.

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

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

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

Все лучшие методы работы уходят корнями в 70-е годы, когда ведущие разработчики программных методов стали посещать Австралию. Поскольку эта страна так мала, а область информационных технологий — еще меньше, то на удивление много австралийских профессионалов-программистов прошли подготовку непосредственно у этих первопроходцев, которые были создателями и основными защитниками современных методов и подходов. Многие из тех студентов, которые рано испытали на себе влияние Константина, ДеМарко (DeMarco), Вайнберга (Weinberg) или Йордона (Yourdon), заняли руководящие позиции или стали независимыми консультантами и профессиональными лидерами, в свою очередь оказывая влияние на современную практику разработки программного обеспечения и приложений.

Формирующую роль в этом процессе культурного изменения сыграли один человек и крошечная организация, проводившая курсы по повышению квалификации. Оба персонажа — человек и организация — мало кому известны за пределами Австралии. Компания называлась DP Education Proprietary Limited, а Деннис Дэви (Dennis Davie) был веселым импресарио, который первым завлек Эда Йордона и Ларри Константина на континент, чтобы научить австралийцев своим новым методам. В то время когда мало кто в Соединенных Штатах даже слышал о структурных методах, а рукопись книги «Structured Design» (Структурное проектирование), известной как «Orange book», еще только предполагалось отдать в печать, австралийцы уже получали этот материал из первых рук. С Дэви было очень приятно сотрудничать, и за эти годы он сумел привлечь к работе в Австралии значительную группу квалифицированных преподавателей и новаторски мыслящих людей. Оставаясь человеком небогатым и малоизвестным, Дэви тихо и счастливо ушел на пенсию и перебрался на Золотое побережье Австралии. Иногда он проводил одно-два занятия в своей компании, которую возглавил его сын. Знал ли он об этом или нет, но Дэви, который умер в начале 1998 года, изменил жизнь многих людей.

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

Важная часть его одаренности — способность привлекать талантливых людей и ценить талант в человеке. Он не только сумел правильно распознать зарождение новых направлений, но и собрать вокруг себя самых лучших и самых ярких на то время мыслителей и преподавателей. В своем апогее компания Yourdon Inc., возглавляемая Эдом и его женой Тони Нэш (Toni Nash), была очень привлекательным местом. Почти каждый, у кого было что сказать и было желание сказать это, хотел там работать. Удивительно, как много современных самых влиятельных лидеров отрасли так или иначе начинали у Эда Йордона.

Импресарио интересны не только с исторической точки зрения; их роль сегодня так же важна, как и всегда. Например, Джордж Шассел (George Schussel) из Digital Consulting выражает себя именно в этой роли. Помимо всего прочего, он способствовал тому, что сопротивляющийся Ларри Константин вернулся на передовую линию в области разработки программного обеспечения. Шассел и еще один импресарио Рик Фридман (Rick Friedman) сыграли важную роль в привлечении внимания широкой аудитории к объектной технологии. Одни из самых удачных конференций в данной области были организованы Коэн Тинджли Викорен (Ко-Ann Tingley Vikoren), impresaria, которая раньше занималась организацией Software Development Conferences и пригласила меня на самую первую конференцию в 1988 году.

Кстати говоря, в стране, которая дала нам это слово, есть свой импресарио информационных технологий. Джованни Модика (Giovanni Modica) не только великолепный повар итальянской кухни. Он всеми силами способствует тому, чтобы Италия стала мировым лидером в разработке информационных систем. Средством здесь должен стать перенос технологий (technology transfer), что отражено и в названии его компании. Приглашая самых лучших, самых ярких людей со всего мира, он надеется сделать будущее итальянских методов разработки более светлым. И похоже, он своего доьется. Благодаря своему упорству и искренности он сумел собрать группу специалистов мирового класса, которые теперь регулярно останавливаются в Милане и Риме, чтобы передать итальянским разработчикам новейшие эффективные методы и инструменты.

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

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

Возможно, это вы.

Из журнала Software Development, том 3, № 9, сентябрь 1995 г.

Примечания:

4

После смерти (лат.).

45

Небоскреб в Сан-Франциско.

46

Слово column (англ.) может переводиться и как газетная или журнальная колонка, и как архитектурная колонна.

47

Джеймс Мартин (James Martin) считается отцом CASE-технологии.