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

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

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

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

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

Блестящий и совершенно беспристрастный психолог Дэвид Кантор (David Kantor) одним из первых заметил, что в человеческих группах под внешней случайностью скрывается лежащая в ее основе сложно организованная логика (Kantor и Lehr, 1975 [45]). В этом отношении его работы предвосхитили последние исследования по применению теории хаоса в группах. Кантор выделил два варианта кажущейся случайности: одну он назвал творческой, а другую — хаотичной (в старом и более традиционном понимании слова «хаос»). Разница между «случайным творческим» и «случайным хаотичным» имеет решающее значение — это разница между успехом и провалом в достижении прорыва при разработке программного обеспечения.

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

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