Ларри Константин - Человеческий фактор в программировании

• Название: Человеческий фактор в программировании
• Автор: Ларри Константин
• Жанр: Управление, подбор персонала

Хорошее программное обеспечение создается людьми. Так же как и плохое. Именно поэтому основная тема этой книги — не аппаратное и не программное обеспечение, а человеческий фактор в программировании (peopleware). Первое издание «Constantine on Peopleware» признано классическим трудом в области информационных технологий. Новая книга Ларри Константина включает все 52 легендарные статьи из предыдущей книги и 25 новых эссе.

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

Название оригинала на английском языке: The Peopleware Papers by Larry L. Constantine

---

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

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

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

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

6 Раздражающие прерывания

Очень раздражает, когда вас отвлекают. С другой стороны, в коде может быть ошибка, которую вы не замечаете, а идея, о которой вы не стали слушать, могла бы помочь найти решение. Эффективность взаимодействия людей в офисе или в команде может оказывать существенное влияние на производительность. Совместное использование офиса облегчает совместное использование информации. Иногда это является плюсом, иногда нет. Для интенсивных и сосредоточенных размышлений, необходимых для написания хорошего кода или для выискивания скрытых ошибок, требуется продолжительное и пристальное внимание. Когда слова статьи или строки кода просто вылетают из-под пальцев, то больше всего не хочется, чтобы кто-нибудь между прочим вставил свой комментарий по поводу того, что написал Роберт К. Крингли (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 не требуется.