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

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

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

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

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

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

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

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

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

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

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

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

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

Жизнь продолжается. Даже после того, как вас повысили в должности. Из журнала Computer Language Magazine, том 9, № 3, март 1992 г.

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

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

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

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

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

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

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

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

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

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

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

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

Ничто не может стать фактом просто потому, что вы это так назвали. Поэтому группам следует учиться пресекать пустословие и договориться не злоупотреблять средствами языка. В первые годы нашей совместной жизни моя первая жена научилась с подозрением относиться к любым утверждениям, которые я начинал с фразы наподобие: «Факты ясно свидетельствуют, что…». Это было сигналом, что далее, вероятно, последует глубоко личное мнение, не подкрепленное ни данными, ни доказательствами. После того как этот гамбит перестал действовать, за мной стали иногда замечать приверженность к другой тактике, которую мы назвали ходом «95 % всех ученых». Некоторые из вас, наверное, поняли, о чем идет речь. «Вы знаете, этот метод предпочитает большинство, уж точно более 95 % профессиональных программистов-разработчиков». Естественно, для того чтобы продолжать пользоваться этой уловкой, вам нужно варьировать проценты. «Почти 78 % пользователей WordPerfect знают, что лучшим способом является…» или «Если провести опрос, то более двух третей программистов, пишущих на С, согласятся, что…». Иногда кажется, что стоит только присмотреться, как увидишь легионы ученых, программистов-разработчиков или конечных пользователей, выстроившихся в ряд позади говорящего, чтобы лично поддержать его (или ее) точку зрения.

Но это только мое мнение.

Из журнала Computer Language Magazine, том 9, № 4, апрель 1992 г.

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

Часто, когда какая-нибудь группа застревает, проводя анализ или принимая проектное решение, а участники группы говорят: «Мы не знаем, как поступить», я спрашиваю их: «Как вы определяете, какой подход лучше?». Инжиниринг связан с поиском компромиссов — согласия на уступки в одном в обмен на уступки в другом. В любом проекте компромисс требует понимания ценности того, что приобретается или теряется при взаимных уступках.

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

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

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

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

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

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

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

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

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

К техническому консенсусу лучше приходить в диалоге и переговорах, чем в споре и препирательствах. Очень полезными могут быть сведения о переговорах, почерпнутые в других областях. Прежде всего, следует порекомендовать две великолепные книги, изданные в рамках «гарвардской программы по ведению переговоров»: Фишер (Fisher) и Юри (Ury) «Getting to Yes» (Как добиться согласия), 1981 [37] и Фишер и Браун (Brown) «Getting Together» (Как добиться единства), 1988 [38].

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

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

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

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

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

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

Из журнала Computer Language Magazine, том 9, № 5, май 1992 г.

Помните, как Боб Крэтчит (Bob Cratchit) трудился над книгами в солидной фирме Скруджа (Scrooge) и Марли (Marley), надев на руки перчатки без пальцев, чтобы они не замерзали, пока Боб перелистывал страницы? Я очень люблю «Рождественский гимн» (A Christmas Carol). Недавно мне подарили видеокассету с изумительной черно-белой экранизацией, где главную роль играет Алистэр Сим (Alistair Sim). Посмотрев этот фильм, я задумался о старом Бобе и других «клерках», которые на протяжении столетий вели учетные книги для множества предприятий. Эти писари были настоящими компьютерами своего времени. Без них предприятия пришли бы к банкротству, а целые отрасли были бы ввергнуты в хаос. Их реальная власть и влияние намного превосходили их скудные жалования или невысокий статус. Вообще говоря, продолжительный успех Скруджа и Марли был в большей мере связан с работой старого доброго Боба и его соотечественников, чем с тем, что привнес Эбенезер.

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

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

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

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

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

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

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

Входит скромный писарь. Звучат фанфары и приветствия!

В команде, разрабатывающей программное обеспечение, писарь или протоколист отвечает за коллективную память команды, в которой хранятся как рабочие продукты, так и описание процессов, давших результаты. Писарь ведет учетные книги. В модели командной работы с открытой структурой (Structured Open teamwork), которую независимо друг от друга разработали Роб Томсет (Rob Thomsett, 1990 [62]) и я (Constantine, 1989 [11], 1991 [13]), такая роль была обозначена как «информационный менеджер». Этот термин был введен для того, чтобы повысить статус этой роли, подобно тому как в объявлениях о вакансиях вместо «водитель мусоровоза» пишут «инженер санитарно-гигиенического транспорта».

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

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

Важнейшая функция сессионной памяти — хранение отчета о процессах, который отражает проведенные обсуждения и решения, принятые в группе (Дойл (Doyle) и Страус (Strauss), 1982 [35]). Наверное, идея о ведении записей в ходе процесса нова для большинства групп, разрабатывающих программное обеспечение, однако на различных собраниях это практиковалось десятилетиями. Ведя записи, начинающие писари часто допускают одну из двух ошибок. Они либо пытаются записывать все подряд, словно под диктовку, либо ждут, пока группа не придет к какому-то заключению, и просто записывают итог. Для технической работы, выполняемой командой, записи вида «он(а) сказа л (а)» не особенно подходят и не являются необходимыми. В хорошем протоколе отмечены ключевые события на пути к конечному результату, особенно рассмотренные альтернативы, принятые решения и представленные аргументы. Такие записи вносят наибольший вклад в групповое приобретение опыта. Они могут стать бесценными, когда необходимо оценить проект или когда проект вступает в фазу «post mortem».[4]

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

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

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

Как же определить того счастливчика, который станет выполнять роль писаря? Согласно некоторым методикам, таким как «Joint Application Design» (Совместная разработка приложений) Вуда (Wood) и Силвера (Silver), 1989 [69], специально подготовленные помощники и писари привлекаются со стороны. Это позволяет разгрузить участников проекта для того, чтобы они смогли сосредоточиться на создании программного обеспечения. В некоторых группах эти обязанности вменяются одному из членов команды (обычно младшему сотруднику или стажеру). Для большинства команд, разрабатывающих программное обеспечение, более эффективным является совмещение этих подходов. Информацией заведует вся команда в целом, а реальная ответственность может по очереди возлагаться на всех участников проектной команды. При таком подходе никто не освобождается от обязанности играть роль писаря, однако никто не играет ее слишком долго. В течение одного собрания обязанности сессионного протоколиста могут переходить от одного человека к другому или же такая работа может оставаться в одних умелых руках в течение всей сессии. Однако для сохранения рассудка и поддержания хорошей рабочей атмосферы обязанности писаря, возможно, должны передаваться по крайней мере на каждом новом собрании. Если собрания проходят довольно долго, то такая смена должна происходить не менее одного раза в час. Дело в том, что для хорошего выполнения обязанностей писаря требуется чрезвычайная концентрация внимания, и очень мало людей планете действительно получает удовольствие от этой роли.

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

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

Из журнала Computer Language Magazine, том 9, № 6, июнь 1992 г.

Ваш коллега в офисе жует жевательную резинку, проигрывает на персональном компьютере «Where-in-the-World-is-Carmen-San-Diego?», охает и задает глупые вопросы. А в это время вы пытаетесь разобраться с ка-ким-то непонятным багом. В этой компании вы работаете несколько лет и чувствуете, что пришла пора получить отдельный кабинет. Вы идете к начальнику и говорите, что вам нужно большее пространство и защита от отвлекающего шума и помех. Вы говорите, что это повысит эффективность работы. Дескать, если у вас появится больше пространства и вас будут меньше отвлекать, вы станете работать более продуктивно. Вы ссылаетесь на научные исследования, подтверждающие это. Вы считаете, что вам нужн, по крайней мере сто квадратных футов выделенного пространства и тридцать квадратных футов для рабочего стола. Окно вам тоже не помешает. В Дании даже есть закон, по которому вы должны сообщить об этом начальнику. В Дании начальник обязан предоставить вам окно.

Народная мудрость гласит, что чем больше свободного пространства, чем тише в офисе, чем меньше помех, тем выше продуктивность и меньше ошибок в программном обеспечении. Сто квадратных футов свободного пространства и тридцать квадратных футов рабочего места просят программисты во всем мире. Эти представления вошли в отраслевой фольклор благодаря Тому ДеМарко (Tom DeMarco), Тиму Листеру (Tim Lister) и их классическому произведению «Peopleware: Productive Projects and Teams», 1987 [ЗЗ]. Исследовав несколько источников (главным образом их собственный ежегодник о «военных играх по кодированию»), они пришли к следующему выводу: программисты, работающие в отдельной комнате и имеющие больше места для раскладывания своих диаграмм и распечаток, обладают большей производительностью.

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

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

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

Одна компьютерная компания размещается в зданиях с многомильными коридорами и кабинками крест-накрест, разделенных звуконепроницаемыми перегородками песочного цвета. Для того чтобы оглядеться, приходится вытягивать шею. Такие перегородки лишь сводят шум от разговоров к тому отвлекающему гулу, который слышен в оперном зале перед поднятием занавеса. Нет ни уединения, ни пресловутой открытости. Люди в офисах, отделенные в этом бежевом кроличьем садке более чем двадцатью футами, могут в течение многих лет не встречаться друг с другом. Посетителей в таких помещениях нужно сопровождать — не ради их безопасности, а просто для того, чтобы они не заблудились. Почтовые адреса там обозначаются наподобие KK14-HDQ:117N\BB.R3 (тайные коды, сообщающие об этаже, колонке и ряде). Гибкость этой гибкой планировки офисов весьма иллюзорна. Перемещение любой перегородки означает необходимость выкорчевывания и прокладывания заново телекоммуника-ционных и сетевых кабелей, не говоря уже об исправлении почтовых адресов. Стены могут быть гибкими, но персонал отдела почтовой доставки — уж точно нет.

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

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

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

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

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

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

Отдельная «ситуационная комната» достаточных размеров особенно важна для команд, которые ведут «архивирование системных документов» (Zahniser 1990 [71], 1993 [72]) и применяют другие методы группового анализа и разработки. Настенные доски командной штаб-квартиры становятся архивом групповой работы, ее видимой, внешней «групповой памятью», в которой хранятся важные элементы рабочего продукта и информация о процессе его создания. На стены командной штаб-квартиры можно поместить все, что угодно, начиная от командного флага и изложения целей проекта и заканчивая основными документами, связанными с разработкой. Само помещение и его оформление становятся частью командной культуры и способствуют тому, что каждая личность ощущает себя частью целого. Это помогает членам команды успешно и эффективно работать вместе.

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

В давние времена, когда разработка программного обеспечения только зарождалась, в Массачусетском технологическом институте были проведены исследования инженерных групп и групп НИОКР.[5] Выяснилось, что производительность возрастает при улучшении взаимодействия, а взаимодействие, в свою очередь, улучшается, когда группа работает в хороших условиях. Самые лучшие варианты компоновки предусматривали открытое пространство в центре помещения, что способствовало или даже вынуждало инженеров сталкиваться друг с другом. Здания с фиксированными стенами и руководство с ограниченным мышлением являются сдерживающими факторами, однако творческие компромиссы все же возможны. Райза Химэн (Risa Hyman) рассказывает об одной группе, которая проявила находчивость в использовании традиционного ряда офисов, выстроенных вдоль коридора (Hyman, 1993 [42]). Коридор был увешан настенными досками и стал главным местом для проведения общих собраний!

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

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

Очень раздражает, когда вас отвлекают. С другой стороны, в коде может быть ошибка, которую вы не замечаете, а идея, о которой вы не стали слушать, могла бы помочь найти решение. Эффективность взаимодействия людей в офисе или в команде может оказывать существенное влияние на производительность. Совместное использование офиса облегчает совместное использование информации. Иногда это является плюсом, иногда нет. Для интенсивных и сосредоточенных размышлений, необходимых для написания хорошего кода или для выискивания скрытых ошибок, требуется продолжительное и пристальное внимание. Когда слова статьи или строки кода просто вылетают из-под пальцев, то больше всего не хочется, чтобы кто-нибудь между прочим вставил свой комментарий по поводу того, что написал Роберт К. Крингли (Robert X. Cringely). Однако бывает и так, что чья-либо случайная ремарка может помочь по-новому увидеть свою задачу. Иногда обсуждение проекта с внимательным слушателем может помочь увидеть недостатки или скрытые ошибки.

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

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

Техническая терминология и обычная речь зачастую тесно взаимодействуют друг с другом. В компьютерный лексикон вошло много повседневных слов в качестве строгих технических терминов. Такие слова, как «объект» или «сущность», заимствованы для обозначения понятий, которые никак не связаны с окружающим нас физическим миром. Мы присвоили «метод» и «сообщение», «протокол» и «папку» (file[6]). Конечно, происходит и обратный процесс. Технические термины входят в обиходную речь в такой степени, что компьютерный жаргон теперь можно услышать даже в разговорах на улице.

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

Я помню свой первый опыт применения программной терминологии в устной речи. Наша группа занималась экспериментами, связанными с коммерческим использованием языка Lisp. Мы настолько увлеклись этим языком, что стали говорить списками и точечными парами. В на-ших разговорах то и дело встречались довольно своеобразные высказывания. Мы «cons» две идеи вместе, а также «саг» и «cdr» темы разговора. Такая беседа могла быть настолько «многопоточной», что в конце концов кто-нибудь жаловался на «переполнение стека» и просил о сборе мусора. Для тех, кто никогда не учился «шепелявить на ЛИШПе» (thpeak with а lithp),[7] скажу, что «саг» означает «первый элемент списка», или «левая часть», а под «cdr» (произносится «куд-эр») понимается «остальная часть списка», или «правая часть». Такие странные названия закрепились в Lisp несмотря на то, что они относятся к аппаратным регистрам давно исчезнувшей IBM 709/7090/7094 и буквально означают «содержимое адресного регистра» и «содержимое регистра декремента».

Наша вычурность продолжалась недолго. Вероятно, она казалась глупой и не была особенно полезной. Ну, разве что помогла нам изучить жаргон и лучше запомнить понятия языка Lisp. Уже много лет я не «cadadr»'jo какую-нибудь идею. Хотя если сегодня побродить по нашим офисам, то можно услышать не менее странные, а порой и более полезные идиоматические выражения.

Обычные способы прервать кого-либо, принятые в приличном обществе, могут быть слишком медленными и неудобными для эффективного взаимодействия. «Извините, вы не заняты? Надеюсь, не помешаю. У меня только один небольшой вопрос, на одну секунду.» На одну секунду? Это уже заняло 6,5 секунд! К этому моменту прерывание сталоfait accompli.[8] К тому времени как ваш мозг разобрался и обработал весь этот шум и принял решение о том, что с этим делать, вы уже забыли, на какую строку кода смотрели и какой метод какого подкласса собирались задействовать.

Для рабочих групп нужен словарь прерываний, который был бы кратким, приятным и простым. То, что подходит для аппаратного обеспечения, подойдет и для людей, поэтому в наших офисах мы тоже IRQ, АСК и NAK.

IRQ — это сокращение от «interrupt request» (запрос прерывания, произносится «ирк»). Например, «Можномне «ирк» вас?». Впрочем, достаточной одного слова «Ирк?». Восходящая интонация делает высказывание более вежливым, а взрывной согласный звук в конце слова привносит оттенок настойчивости. Это слово звучит достаточно отчетливо, чтобы его можно было услышать среди шума вентиляторов и визга лазерных принтеров. В то же время, оно достаточно коротко, чтобы не сильно отвлекать от ментальных процессов. Возможные ответы: АСК[9] и NAK[10] (первое произносится «эк», второе — «эн-эк» или «нэк»), что означает «Ок, давайте!» и «Нет, не сейчас!» соответственно. Не нужно отрываться от ваших дел, чтобы пробурчать либо «эк», либо «нэк». Оба варианта ответа имеют характерное фонетическое звучание, что делает их различимыми при прерывании.

Протокол прерываний чрезвычайно прост. Тот, кто хочет прервать кого-нибудь, говорит «Ирк!» и ждет ответа. Тот, кого прерывают, может еще некоторое время продолжать свою работу, пока не подтверждено установление связи. Например, он может пометить место в тексте, заполнить поле заголовка или оставить себе короткую записку-напоминание. Когда сотрудник готов обслужить прерывание, он отвечает: «Эк». Ответ «Нэк» означает: «Нет, не отвлекайте меня сейчас». Это можно расценить как вежливый вариант высказывания «Уйди отсюда и не стой над душой». Все эти слова кажутся очень глупыми, но такая простая система может поразительным образом способствовать более гладкому взаимодействию в рабочей группе. Иногда в словарь может входить высказывание NMI[11] (произносится «ними»), что означает «немаскируемое прерывание». По правилам этикета такое высказывание должно применяться лишь в критических случаях, требующих наибольшего приоритета обработки со стороны центральной нервной системы вашего бедного коллеги. Прежде чем начать говорить, лучше сделать короткую паузу, хотя дожидаться АСК или NAK не требуется.

Людей, которые слишком часто применяют IRQ, называют надоедливыми..[12] С ними можно поступать на манер кота Билла, громко крича «Эк, нэк. Нэк! Эк!» и вырывая на себе волосы. Если в нужный момент вы сможете превратиться в пушистый клубок, то это будет еще более эффективно.

Конец прерывания.

Из журнала Software Development, том 2, № 6, июнь 1994 г.

Примечания:

1

CASE (computer-aided software engineering) — автоматизированное проектирование и создание программ. — Примеч. науч. ред.

4

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

5

Научно-исследовательские и опытно-конструкторские работы.

6

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

7

Слово lisp в переводе с англ. означает «шепелявить». Именно это и обыгрывает автор (thpeak with a lithp нужно понимать как speak with lisp). Из-за особенностей синтаксиса LISP часто расшифровывают (в шутку, конечно) как Lots of Idiotic exceSsive Parentheses или Lots of Irritating Superfluous Parentheses, подразумевая, вероятно, что нормально «говорить» на подобном языке нельзя.

8

[Делом свершенным (фр.).

9

АСК (сокр. от англ. acknowledgement) — подтверждение приема.

10

NAK (сокр. от англ. negative acknowledge) — отсутствие подтверждения приема.

11

NMI (сокр. от англ. nonmaskable interrupt).

12

IRQsome, здесь обыгрывается англ. irksome — надоедливый, докучливый.