Текст книги "Человеческий фактор в программировании"
Автор книги: Ларри Константин
сообщить о нарушении
Текущая страница: 3 (всего у книги 26 страниц) [доступный отрывок для чтения: 10 страниц]
Так что, пригласите писаря на ланч. Возможно, на следующей неделе г сарем станете вы.
Из журнала Computer Language Magazine, том 9, № 6, июнь 1992 г.
5
Официальное пространство
Ваш коллега в офисе жует жевательную резинку, проигрывает на персональном компьютере «Where-in-the-World-is-Carmen-San-Diego?», охает и задает глупые вопросы. А в это время вы пытаетесь разобраться с ка-ким-то непонятным багом. В этой компании вы работаете несколько лет и чувствуете, что пришла пора получить отдельный кабинет. Вы идете к начальнику и говорите, что вам нужно большее пространство и защита от отвлекающего шума и помех. Вы говорите, что это повысит эффективность работы. Дескать, если у вас появится больше пространства и вас будут меньше отвлекать, вы станете работать более продуктивно. Вы ссылаетесь на научные исследования, подтверждающие это. Вы считаете, что вам нужн, по крайней мере сто квадратных футов выделенного пространства и тридцать квадратных футов для рабочего стола. Окно вам тоже не помешает. В Дании даже есть закон, по которому вы должны сообщить об этом начальнику. В Дании начальник обязан предоставить вам окно.
Народная мудрость гласит, что чем больше свободного пространства, чем тише в офисе, чем меньше помех, тем выше продуктивность и меньше ошибок в программном обеспечении. Сто квадратных футов свободного пространства и тридцать квадратных футов рабочего места просят программисты во всем мире. Эти представления вошли в отраслевой фольклор благодаря Тому ДеМарко (Tom DeMarco), Тиму Листеру (Tim Lister) и их классическому произведению «Peopleware: Productive Projects and Teams», 1987 [ЗЗ]. Исследовав несколько источников (главным образом их собственный ежегодник о «военных играх по кодированию»), они пришли к следующему выводу: программисты, работающие в отдельной комнате и имеющие больше места для раскладывания своих диаграмм и распечаток, обладают большей производительностью.
Форма процесса
На работе, дома, в ресторане или в учебной аудитории физическое пространство определяет то, что происходит и может происходить между людьми. За длинным банкетным столом вы можете беседовать с сидящими по обе стороны от вас и еще с несколькими людьми, сидящими напротив. Однако вряд ли вы сможете пообщаться с теми, кто сидит на другом конце стола. Король Артур сделал свой стол круглым в знак равенства тех, кто за ним сидит. Кроме того, форма стола позволяла всем рыцарям легко говорить друг с другом.
Планировка и меблировка зданий или офисов может оказывать сильное влияние на общение людей и их совместную работу. Когда-то я два года прожил в квартирном доме и за все это время встретил лишь нескольких соседей. Вход в дом представлял собой маленький проем, едва достаточный для одного человека с сумкой продуктов. Коридоры были узкими, темными и пустынными. Там просто не было места для того, чтобы люди могли случайно встретиться друг с другом и поговорить.
Обычно офисы не страдают наличием узких проходов или темных коридоров, однако в офисах современных высокотехнологичных компаний есть другие архитектурные «изыски». В схемах компоновки современных офисов преобладает так называемая открытая планировка с гибким разделением помещений. Несмотря на такое привлекательное название эта система обычно не является ни «гибкой», ни «открытой».
Одна компьютерная компания размещается в зданиях с многомильными коридорами и кабинками крест-накрест, разделенных звуконепроницаемыми перегородками песочного цвета. Для того чтобы оглядеться, приходится вытягивать шею. Такие перегородки лишь сводят шум от разговоров к тому отвлекающему гулу, который слышен в оперном зале перед поднятием занавеса. Нет ни уединения, ни пресловутой открытости. Люди в офисах, отделенные в этом бежевом кроличьем садке более чем двадцатью футами, могут в течение многих лет не встречаться друг с другом. Посетителей в таких помещениях нужно сопровождать – не ради их безопасности, а просто для того, чтобы они не заблудились. Почтовые адреса там обозначаются наподобие KK14-HDQ:117NBB.R3 (тайные коды, сообщающие об этаже, колонке и ряде). Гибкость этой гибкой планировки офисов весьма иллюзорна. Перемещение любой перегородки означает необходимость выкорчевывания и прокладывания заново телекоммуника-ционных и сетевых кабелей, не говоря уже об исправлении почтовых адресов. Стены могут быть гибкими, но персонал отдела почтовой доставки – уж точно нет.
С точки зрения использования офисного пространства для повышения производительности разработчиков, эти негибкие «гибкие» системы обычно расставляются так плохо, как только можно себе представить. Они не дают возможности работать одному и работать вместе. Они не позволяют уединиться или встречаться мимоходом.
Влияние планировки офиса на производительность разработчиков определяется не только объемом свободного пространства и возможностью уединиться. В первую очередь можно упомянуть парадокс причины и следствия – старое пугало всех социологических исследований. Работники, проявившие высокую производительность в военных играх по кодированию, имели более просторные помещения и испытывали меньше помех именно потому, что они работали с высокой производительностью, а не наоборот. Либо их производительность способствовала тому, что компания смогла предоставить им более спокойные условия и более просторные помещения.
Еще более важно то, что результаты исследований, приведенные ДеМарко и Листером, касались кодирования и тестирования и не относились к процессу разработки программного обеспечения в целом. По условиям проводимых ими ежегодных соревнований каждый участник работал самостоятельно, а не в составе команды. Поэтому, как представляется, свободное пространство и тишина помогают обособленным кодерам. А как насчет командной работы?
Совместная работа и общение
Для эффективного сотрудничества командам действительно необходимо пространство: пространство для команды в целом и служебное пространство, необходимое для выполнения заданий. Исследования подтверждают, что для хорошей совместной работы нужны как открытые, так и изолированные помещения. Офис должен предоставлять возможности для интенсивной работы группам из двух-трех человек в течение коротких или длительных периодов. Кроме того, в офисе должно быть по крайней мере одно место, где все сотрудники, работающие в проекте, могут собираться вместе. Если в офисе нет места, где вся команда может спокойно собраться, то превратить команду в сплоченный рабочий коллектив намного труднее.
Один руководитель в области разработки программного обеспечения горячо поддерживал метод командной работы, но был разочарован резуль-татами совместного труда своих подчиненных. Этаж, на котором они работали, представлял собой сумасшедший лабиринт из узких коридоров и крохотных офисов со стеклянными стенами – отдельных, но не уединенных помещений. Лишь в некоторых офисах могли поместиться два человека, а в тех помещениях, которые были достаточно большими, часто размещались сотрудники, привлеченные к разным проектам. Однажды я наблюдал, как одна команда проводила собрание в самом большом зале на этом этаже. Одиннадцать разработчиков втиснулись в комнату, в которой стояли стол и шесть стульев, находящихся друг от друга на расстоянии семи дюймов. Между краем стола и небольшой доской на стене едва хватало места для того, чтобы руководитель собрания мог сделать пару шагов и повернуться. Нечего и говорить, что собрание было коротким.
Для командной работы крайне необходимо место для общих собраний в течение всего периода работы. Требуется место, которое может служить штаб-квартирой, «ситуационной комнатой», где может собраться вся команда. Нужна защищенная территория, где члены команды могут укрыться от шума и сосредоточиться. Плох вариант, когда зал для собраний используется совместно с другими командами.
Отдельная «ситуационная комната» достаточных размеров особенно важна для команд, которые ведут «архивирование системных документов» (Zahniser 1990 [71], 1993 [72]) и применяют другие методы группового анализа и разработки. Настенные доски командной штаб-квартиры становятся архивом групповой работы, ее видимой, внешней «групповой памятью», в которой хранятся важные элементы рабочего продукта и информация о процессе его создания. На стены командной штаб-квартиры можно поместить все, что угодно, начиная от командного флага и изложения целей проекта и заканчивая основными документами, связанными с разработкой. Само помещение и его оформление становятся частью командной культуры и способствуют тому, что каждая личность ощущает себя частью целого. Это помогает членам команды успешно и эффективно работать вместе.
Если члены команды находятся в разных зданиях, офисах или рассеяны по всему миру, то сотрудничать – и даже просто общаться – становится труднее и дороже. При прочих равных условиях размещение участников проекта по разным местам, даже в разных зданиях или на разных этажах, может привести к увеличению расходов на 50-100 %. Поскольку команда, которая рассредоточена в пространстве, почти всегда будет менее эффективна, чем группа, работающая в одном месте, такой команде нужны компенсационные механизмы. На помощь приходит электронная почта и телеконференции, но ничто не может заменить возможность хотя бы раз собраться вместе и увидеть друг друга.
В давние времена, когда разработка программного обеспечения только зарождалась, в Массачусетском технологическом институте были проведены исследования инженерных групп и групп НИОКР.[5]5
Научно-исследовательские и опытно-конструкторские работы.
[Закрыть] Выяснилось, что производительность возрастает при улучшении взаимодействия, а взаимодействие, в свою очередь, улучшается, когда группа работает в хороших условиях. Самые лучшие варианты компоновки предусматривали открытое пространство в центре помещения, что способствовало или даже вынуждало инженеров сталкиваться друг с другом. Здания с фиксированными стенами и руководство с ограниченным мышлением являются сдерживающими факторами, однако творческие компромиссы все же возможны. Райза Химэн (Risa Hyman) рассказывает об одной группе, которая проявила находчивость в использовании традиционного ряда офисов, выстроенных вдоль коридора (Hyman, 1993 [42]). Коридор был увешан настенными досками и стал главным местом для проведения общих собраний!
Правильная планировка способствует улучшению взаимодействия. Однако станут ли стены барьерами или мостами к более эффективной командной работе, зависит от членов группы и ее руководства.
Из журнала Software Development, том 1, № 12, декабрь 1993 г.
6
Раздражающие прерывания
Очень раздражает, когда вас отвлекают. С другой стороны, в коде может быть ошибка, которую вы не замечаете, а идея, о которой вы не стали слушать, могла бы помочь найти решение. Эффективность взаимодействия людей в офисе или в команде может оказывать существенное влияние на производительность. Совместное использование офиса облегчает совместное использование информации. Иногда это является плюсом, иногда нет. Для интенсивных и сосредоточенных размышлений, необходимых для написания хорошего кода или для выискивания скрытых ошибок, требуется продолжительное и пристальное внимание. Когда слова статьи или строки кода просто вылетают из-под пальцев, то больше всего не хочется, чтобы кто-нибудь между прочим вставил свой комментарий по поводу того, что написал Роберт К. Крингли (Robert X. Cringely). Однако бывает и так, что чья-либо случайная ремарка может помочь по-новому увидеть свою задачу. Иногда обсуждение проекта с внимательным слушателем может помочь увидеть недостатки или скрытые ошибки.
Для хорошей командной работы в офисе требуется возможность свободного, не вызывающего раздражение доступа друг к другу. Люди, которые работают вместе или делят одно рабочее пространство, имеют много разумных поводов для того, чтобы прерывать друг друга: просьбы о помощи, обсуждение идей, вопрос о состоянии дел и координирование текущей работы в целом. С другой стороны, очень важно, чтобы оставалось время для размышления и творчества, когда вам никто не помешает. Если вас кто-то не вовремя прервет, вы можете забыть ценную идею, потерять мимолетную мысль или полностью запутаться в сложном вопросе.
Эта проблема не является новой и не относится лишь к группам по разработке программного обеспечения. Однако разработчики могут получить пользу от более совершенных способов управления взаимодействием в группе. Естественно, компьютерщики любят решать социальные и организационные задачи с помощью компьютеров, и, вероятно, первое, что здесь приходит в голову, – это создание быстрой сети с какими-нибудь хитрыми почтовыми средствами. Но иногда даже очень простая система может сослужить хорошую службу. Может быть, все, что нужно, – это более удобный лексикон.
Вооружившись словом
Техническая терминология и обычная речь зачастую тесно взаимодействуют друг с другом. В компьютерный лексикон вошло много повседневных слов в качестве строгих технических терминов. Такие слова, как «объект» или «сущность», заимствованы для обозначения понятий, которые никак не связаны с окружающим нас физическим миром. Мы присвоили «метод» и «сообщение», «протокол» и «папку» (file[6]6
В отличие от английского языка, в котором слово «file» существует давно, в русский язык слово «файл» вошло сравнительно недавно (с-развитием информационных технологий). Слово «папка» вошло в компьютерный лексикон из обычной речи
[Закрыть]). Конечно, происходит и обратный процесс. Технические термины входят в обиходную речь в такой степени, что компьютерный жаргон теперь можно услышать даже в разговорах на улице.
Специалисты по компьютерам особенно любят переносить свой жаргон в обычный разговор, расширяя значение терминов таким образом, чтобы их можно было применять при общении. Они стараются произвести «пар-синг» (parsing) неразборчивого сообщения на автоответчике или маниакально «мультиплицируют» два разговора. Привычные поведенческие шаблоны таких специалистов «жестко запрограммированы в ПЗУ». Программисты «портируют» автомагнитолу с одной машины на другую, а не покупают новую деку. Для того чтобы написать черновик отчета о вчерашнем совещании, они осуществляют «дамп оперативной памяти». Все это может стать весьма утомительным и звучать ужасно глупо, однако порой техноболтовня обогащает обычный язык полезными и интересными новшествами.
Я помню свой первый опыт применения программной терминологии в устной речи. Наша группа занималась экспериментами, связанными с коммерческим использованием языка Lisp. Мы настолько увлеклись этим языком, что стали говорить списками и точечными парами. В на-ших разговорах то и дело встречались довольно своеобразные высказывания. Мы «cons» две идеи вместе, а также «саг» и «cdr» темы разговора. Такая беседа могла быть настолько «многопоточной», что в конце концов кто-нибудь жаловался на «переполнение стека» и просил о сборе мусора. Для тех, кто никогда не учился «шепелявить на ЛИШПе» (thpeak with а lithp),[7]7
Слово lisp в переводе с англ. означает «шепелявить». Именно это и обыгрывает автор (thpeak with a lithp нужно понимать как speak with lisp). Из-за особенностей синтаксиса LISP часто расшифровывают (в шутку, конечно) как Lots of Idiotic exceSsive Parentheses или Lots of Irritating Superfluous Parentheses, подразумевая, вероятно, что нормально «говорить» на подобном языке нельзя.
[Закрыть] скажу, что «саг» означает «первый элемент списка», или «левая часть», а под «cdr» (произносится «куд-эр») понимается «остальная часть списка», или «правая часть». Такие странные названия закрепились в Lisp несмотря на то, что они относятся к аппаратным регистрам давно исчезнувшей IBM 709/7090/7094 и буквально означают «содержимое адресного регистра» и «содержимое регистра декремента».
Наша вычурность продолжалась недолго. Вероятно, она казалась глупой и не была особенно полезной. Ну, разве что помогла нам изучить жаргон и лучше запомнить понятия языка Lisp. Уже много лет я не «cadadr»'jo какую-нибудь идею. Хотя если сегодня побродить по нашим офисам, то можно услышать не менее странные, а порой и более полезные идиоматические выражения.
Офисный протокол
Обычные способы прервать кого-либо, принятые в приличном обществе, могут быть слишком медленными и неудобными для эффективного взаимодействия. «Извините, вы не заняты? Надеюсь, не помешаю. У меня только один небольшой вопрос, на одну секунду.» На одну секунду? Это уже заняло 6,5 секунд! К этому моменту прерывание сталоfait accompli.[8]8
[Делом свершенным (фр.).
[Закрыть]К тому времени как ваш мозг разобрался и обработал весь этот шум и принял решение о том, что с этим делать, вы уже забыли, на какую строку кода смотрели и какой метод какого подкласса собирались задействовать.
Для рабочих групп нужен словарь прерываний, который был бы кратким, приятным и простым. То, что подходит для аппаратного обеспечения, подойдет и для людей, поэтому в наших офисах мы тоже IRQ, АСК и NAK.
IRQ – это сокращение от «interrupt request» (запрос прерывания, произносится «ирк»). Например, «Можномне «ирк» вас?». Впрочем, достаточной одного слова «Ирк?». Восходящая интонация делает высказывание более вежливым, а взрывной согласный звук в конце слова привносит оттенок настойчивости. Это слово звучит достаточно отчетливо, чтобы его можно было услышать среди шума вентиляторов и визга лазерных принтеров. В то же время, оно достаточно коротко, чтобы не сильно отвлекать от ментальных процессов. Возможные ответы: АСК[9]9
АСК (сокр. от англ. acknowledgement) – подтверждение приема.
[Закрыть] и NAK[10]10
NAK (сокр. от англ. negative acknowledge) – отсутствие подтверждения приема.
[Закрыть] (первое произносится «эк», второе – «эн-эк» или «нэк»), что означает «Ок, давайте!» и «Нет, не сейчас!» соответственно. Не нужно отрываться от ваших дел, чтобы пробурчать либо «эк», либо «нэк». Оба варианта ответа имеют характерное фонетическое звучание, что делает их различимыми при прерывании.
Протокол прерываний чрезвычайно прост. Тот, кто хочет прервать кого-нибудь, говорит «Ирк!» и ждет ответа. Тот, кого прерывают, может еще некоторое время продолжать свою работу, пока не подтверждено установление связи. Например, он может пометить место в тексте, заполнить поле заголовка или оставить себе короткую записку-напоминание. Когда сотрудник готов обслужить прерывание, он отвечает: «Эк». Ответ «Нэк» означает: «Нет, не отвлекайте меня сейчас». Это можно расценить как вежливый вариант высказывания «Уйди отсюда и не стой над душой». Все эти слова кажутся очень глупыми, но такая простая система может поразительным образом способствовать более гладкому взаимодействию в рабочей группе. Иногда в словарь может входить высказывание NMI[11]11
NMI (сокр. от англ. nonmaskable interrupt).
[Закрыть] (произносится «ними»), что означает «немаскируемое прерывание». По правилам этикета такое высказывание должно применяться лишь в критических случаях, требующих наибольшего приоритета обработки со стороны центральной нервной системы вашего бедного коллеги. Прежде чем начать говорить, лучше сделать короткую паузу, хотя дожидаться АСК или NAK не требуется.
Людей, которые слишком часто применяют IRQ, называют надоедливыми..[12]12
IRQsome, здесь обыгрывается англ. irksome – надоедливый, докучливый.
[Закрыть] С ними можно поступать на манер кота Билла, громко крича «Эк, нэк. Нэк! Эк!» и вырывая на себе волосы. Если в нужный момент вы сможете превратиться в пушистый клубок, то это будет еще более эффективно.
Конец прерывания.
Из журнала Software Development, том 2, № 6, июнь 1994 г.
II
Ковбои и ковгерлы
7
Кодеры-ковбои
Наступило новое тысячелетие, а вы даже не знаете об этом! Программное обеспечение наконец-то стало надежным. Как же был достигнут этот прорыв в области проектирования программного обеспечения? Вот цитата из 16-страничного рекламного буклета корпорации Nanomush Inc., который был разослан миллионам отсталых пользователей и разработчиков: «Одним из самых мощных дополнений к Blerbbleflox 3.1 является «проверка параметров» (parameter validation). Когда информация поступает из какого-либо приложения в операционную систему Blerbbleflox, система проверяет правильность полученных данных». Вот такая новая идея! Почему же вы об этом не думали, а? (Естественно, все поняли, что речь идет о Microsoft и Windows 3.1.)
Эта попытка самовосхваления открыла, что корпорация Nanomush, являющаяся одним из мировых лидеров в области разработки языков и операционных сред, в конечном счете стала применять самые элементарные приемы надежного проектирования программного обеспечения. Это настолько основополагающие приемы, что каждый человек, достойный имени программиста, знает и применяет их вскоре после того, как приобретает способность кодировать. Может ли это пролить хоть какой-то свет на недостатки в предыдущих версиях программного обеспечения? Однако нужно не придираться, а радоваться и хвалить всех начинающих разработчиков программного обеспечения за их усилия, а также поощрять их стремление к дальнейшему профессиональному развитию. Возможно, таким специалистам следует посоветовать книги о связывании и сцеплении или о том, как скрывать информацию от пользователя.
О том, почему компьютерный мир пришел к такому плачевному состоянию дел в области системного программного обеспечения, можно говорить долго. Но лучше пристальнее взглянуть на характер разработчиков, создавших некоторые из тех продуктов, от которых мы так сильно зависим. Мои коллеги, занимающиеся организационной динамикой, иногда называют их «ковбоями». Ковбоев, этих последних из грубых и диких индивидуалистов, можно встретить в разных местах, но в настоящее время многие из них пасут коров на силиконовых полях, причем эти коровы говорят на ассемблере. Кстати, обратите внимание на то, что прозвище «ковбои» заканчивается словом «мальчики» (boys), а не «мужчины» (men).
Весной 1992 года я участвовал в конференции по разработке программного обеспечения (Software Development Conference), организованной компанией Miller Freeman. Один из семинаров был посвящен такой скользкой теме, как «структурированное» и «неструктурированное» управление процессом разработки программного обеспечения. Я сидел рядом с одним из представителей компании Nanomush, отвечающим за разработки. Он был всецело на стороне ковбоев. Его позиция заключалась в том, что полному раскрытию потенциала разработчиков препятствуют руководители, которые стремятся ввести стандарты, ограничения или во всеуслышание заявляют об ожидаемых результатах. По его мнению, нужно просто отойти в сторону и не мешать программистам делать свое дело. Структурированные методы, регламентированная разработка, моделирование на бумаге и оценка программного обеспечения – все это неоправданно ограничивает возможности свободного творческого самовыражения наших блестящих ковбоев-программистов. Неудивительно, что продукты, поставляемые такими компаниями, так непредсказуемы в работе.
Почему нужно выпустить четыре релиза и задействовать 12000 сайтов бета-тестинга (это не шутка!) для того, чтобы выражение «необратимая ошибка в работе приложения, ок?» заменить на более понятное? Но ковбои не любят, когда их обуздывают с помощью особых критериев качества. Ковбоям не нравится заранее думать о том, какие функции продукта действительно необходимы. Нет, давайте лучше просто заскочим в старый добрый загон для разработки и настрочим какой-нибудь код – мы ковбои! Можно придумать симпатичный графический интерфейс и применить искусные методы кодирования – как-никак мы творческие ж гениальные личности. Но к черту юзабилити и надежность – для этого может потребоваться планирование или дисциплина (боже упаси).
Не стоит выделять какую-либо из компаний, разрабатывающих программное обеспечение. На рынке имеется бесчисленное множество примеров, подходящих для иллюстрации. Тем не менее очень редко в соответствующей литературе или на семинарах специалистов можно ветре-тить беспристрастную оценку зрелости разработчиков и качества методов программирования.
Зрелость индивидуалистов
Зрелость является центральным вопросом в разработке программного обеспечения. Методисты хотят знать, сколько времени должно пройти для того, чтобы проектирование программного обеспечения созрело как дисциплина. Менеджеры беспокоятся об уровне «зрелости процесса» в тех подходах к разработке, которые применяются в их организациях. Наконец, руководителей проектов интересует зрелость тех индивидуумов, руководить которыми их пригласили.
Одна большая корпорация провела исследования в своих группах, разрабатывающих программное обеспечение. Исследовалось, как часто и на каком уровне сложности эти группы применяют общепринятые систематические или строгие подходы к проектированию программного обеспечения. Оказалось, что наиболее эффективно методы проектирования использовались отделом администрирования информационных систем и отделом деловой информации. Средние результаты показали группы обеспечения проектирования. Как вы догадались, группы, разрабатывающие операционные системы, компиляторы и сервисное программное обеспечение, замыкали таблицу. Исследования о распространенности инструментов CASE дают ту же картину. Там, где дисциплине в проектировании и зрелости процесса не придается значения, разработка программного обеспечения напоминает шоу о Диком Западе, в котором главные роли играют кодирующие ковбои.
Наша культура превозносит гения-одиночку, который от начала и до конца разрабатывает какую-нибудь блестящую теорию, машину или программу. Однако на самом деле никто не делает это, полагаясь только на свои силы. Даже хакер-подросток, укрывшийся в своей спальне и взламывающий программу с помощью собранной им же самим машины, зависит от целой армии инженеров, которые спроектировали и создали чипы, и от целых легионов программистов, которые создали соответствующие инструменты. Для тех, кто следит за моим «показателем скрытой половой дискриминации» (LSI, Latent Sexism Index), скажу, что здесь я не случайно использую местоимение мужского рода. Большинство юных хакеров – мужского пола, а особый склад ума, связанный с желанием взламывать онлайновые компьютерные системы или запускать новых изощренных червей для того, чтобы полностью нарушить работу сетей, почти исключительно является предметом мужской психопатологии. Большинство актов вандализма также совершается подростками, и давайте признаем это. Сочинение вирусов, уничтожение файлов компаний или взламывание правительственных компьютеров является просто-напрос-то вандализмом и ничем иным. К сожалению, не за горами то время, когда такой компьютерный вандализм начнет приводить к потерям в людях, тем более, что уже несколько раз мы были близки к этому.
Совместное обучение
Итак, как же мы всего за несколько абзацев перешли от проектирования программного обеспечения и методологической зрелости к вопросам, связанным с полом? Суть состоит в том, что незрелое ковбойское мышление, отвергающее как дисциплину, так и сотрудничество, в значительной степени свойственно мужчинам.
На одной встрече группы планирования, проходящей в компании по разработке программного обеспечения, у собравшейся «команды» ушло 40 минут на конкурентные игры мужчин. Они спорили по поводу определений, старались занять выигрышную позицию, рисовались своими знаниями и эрудицией. В целом, каждый старался одержать верх над другими. Постепенно, один за другим, эти мужчины уходили с совещания под тем или иным предлогом. Чаще всего это было нечто «более важное», имеющее отношение к «реальной работе». Когда же остались только женщины, одна из них сказала: «Ну вот, сейчас мы можем что-то сделать». Они быстро и эффективно справились с задачей, получая удовольствие от самого процесса общения.
Конечно, это стереотип, но нам, парни, нужно признать, что женщины лучше понимают, что такое сотрудничество. Какие бы причины ни лежали в основе этого, маленькие мальчики стремятся состязаться, а маленькие девочки стремятся сотрудничать. Женщинам, как правило, намного лучше удается выстраивать отношения, поддерживать и поощрять друг друга. (Можно спросить, почему же в нашей отрасли они так редко бывают менеджерами и руководителями проектов. Задумайтесь об этом, руководители среднего и высшего ранга: при прочих равных условиях женщина может иметь явное преимущество над мужчиной в качестве лидера команды, даже если команда состоит из тех программистов-неандертальцев, которые утверждают, что не могут работать на женщину.)
В те годы, когда я был семейным терапевтом, я с неохотой пришел к выводу, что большинство современных мужчин знает очень мало о том, что такое воспитание детей или семейные отношения в целом. Это сказано не для того, чтобы принизить мужской пол, это всего лишь статистический факт. Мне посчастливилось встретить необыкновенных мужчин, которые хорошо разбирались в том, как устанавливать отношения. Также я встречал женщин, не способных к общению. Ни тот, ни другой пол не удерживает монополию ни на чувствительность, ни на способность уста-навливать отношения. Но говоря об умении ладить с людьми, нужно отметить, что по крайней мере в большинстве культур у женщин есть преимущество.
Думаю, сейчас я услышу, как кодирующие ковбои станут долго и настойчиво уверять в том, что суровый индивидуализм и независимость в сфере программирования есть единственная надежда американского бизнеса (или человечества – в зависимости от наивности мировоззрения). Именно они утверждают, что совместная работа ограничивает их в средствах, что приход к согласию низводит их до уровня наименьшего общего знаменателя, что необходимость проектировать до начала кодирования затормаживает их работу. Странно, что многие из них создают такие посредственные программы или даже системы, наделенные существенными недостатками.
По правде говоря, встречаются отдельные люди, как мужчины, так и женщины, которые настолько одарены, дальновидны, талантливы и способны к творчеству, что могут выполнять работу самостоятельно и создавать надежные, достойные похвалы продукты. Однако для большинства из нас возможность проявления нашего потенциала основана на умении соединять идеи каждого в творческом синтезе, когда результат превосходит то, что каждый из нас мог бы сделать в одиночку. Наша работа, скорее всего, будет лучше, чем моя работа либо ваша.
Поэтому растите, ковбои! Учитесь, как становиться на плечи друг друга, а не наступать на ноги. И пусть нам подадут руку помощи женщины, ведь нам нужно так многому научиться.
Из журнала Computer Language Magazine, том 9, № 8, август 1992 г.
