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

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

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

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

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

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

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

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

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

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

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

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

Во многих сложных современных проектах по разработке программного обеспечения следует применять другие подходы, которые будут рассмотрены далее. Что касается компаний типа Nanomush Corporation и International Behemoth Management, Inc., то им придется плутать со своими хаотичными ковбоями среди мегапирамид.

Из журнала Software Development, том 1, № 5, май 1993 г.