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

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

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

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

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

По материалу из журнала American Programmer, июль 1993 г.

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

В этой главе начинается исследование вопросов организации и управления работой людей: как работа организована и как люди, работающие вместе, координируют свои действия (Constantine, 1990 [12], 1991 [15], 1003 [21]). Рассмотрим организацию как человеческий эквивалент архитектуры программного обеспечения, соотнося руководство с динамическим управлением программными компонентами. И снова мы придем к знакомым понятиям структуры и динамики систем управления. Когда вы хотите организовать новую компанию по разработке программного обеспечения или очередной программный проект, возникают все те же вопросы и проблемы.

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

Какой способ является правильным? Самое время вспомнить один из стандартных «ответов консультантов»: «Это как посмотреть!» Поиск правильного способа организации проекта похож на поиск правильного способа кодирования подпрограммы. Нужно исходить из того, что вы собираетесь получить в результате (Constantine, 1993 [21]).

Обычная работа по созданию еще одного набора драйверов для принтера или еще одного варианта традиционного генератора растровой развертки может потребовать совсем иной модели организации и руководства, чем работа над новейшим CASE-инструментом, поддерживающим процесс параллельного проектирования программного обеспечения и проектирование объектно-ориентированного ПО на основе консенсуса. В своей небольшой, но превосходной книге, посвященной командной работе, Jlap-сон и ЛаФасто (Larson и LaFasto, 1989 [47]) определили несколько основных вариантов такой работы, каждый из которых имеет свои преимущества. Здесь мы рассмотрим четыре отдельных и очень различных модели организации командной работы, их преимущества и недостатки.

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