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

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

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

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

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

На случай каких-либо сомнений важно отметить, что я и сам являюсь одиночкой (по крайней мере, мне так говорили). На самом деле я был официально отнесен к типу одиночек Полом Вордом (Paul Ward) — методистом, ставшим историком, — в его истории структурного анализа (Ward, 1992 [64]). Он лично заверил меня, что это нужно воспринимать как комплимент. Конечно, большую часть моей профессиональной жизни я не был конформистом. Современная разработка программного обеспечения может охватывать многие основные принципы структурного проектирования. В качестве ортодоксальной технической иконографии могут применяться инструменты CASE, среды комплексной разработки, схемы потоков данных и блок-схемы, однако так было не всегда. В это трудно поверить, но все эти схемы когда-то считались отступлением от традиций и даже радикальным бредом индивидуалистов.

Я верю в индивидуалистов; многие из моих друзей — одиночки. И я верю в индивидуалистское воображение, в индивидуальное творчество как источник почти всех подлинных новшеств. Я также считаю, что индивидуализм — это истинная причина большинства глупых ошибок. На каждого

Эйнштейна находится целая толпа Великовских. Иногда нововведения и идиотизм даже исходят из одного и того же источника, как от Теслы (Tesla) или Вильгельма Рейха (Wilhelm Reich)². Так или иначе, индивидуалис-ты-одиночки обогатили нашу жизнь — если не всегда чем-то полезным, то хотя бы развлечениями.

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

Естественно, не каждый программист, который предпочитает работать самостоятельно, является кодером-ковбоем. Некоторые люди являются одиночками по своему темпераменту. Некоторых, наверное, можно охарактеризовать как отшельников, другие всего лишь любят составлять компанию самим себе, а многим просто кажется, что компания других людей отвлекает их или даже подавляет. Некоторые из моих лучших работ были сделаны, когда в комнате находились только я и мой верный компьютер.

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

Некоторые руководители являются сторонниками либерального стиля управления кодерами-ковбоями. По их мнению, дисциплина или навязывание стандартов только удерживает программистов от полного раскрытия их потенциала блестящих кодеров-ковбоев.

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

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

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

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

Когда работа выполняется в открытых группах, повышенная видимость помогает сократить ошибки и повысить качество (см. главы 26 и 33). Поэтому работа, выполненная в некоторой степени изолированности от остальной группы, требует большего внимания к соответствию внешним спецификациям и более пристального наблюдения за качеством продукта. Если приемочные испытания показывают, что код работает, то этого недостаточно; для обеспечения качества следует также изучить его с точки зрения соответствия стандартам ясности и надежности.

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

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

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

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

Меилир Пейдж-Джонс (Meilir Page-Jones) придумал очень практичную схему для определения эпохи зрелости, в которой пребывает процесс разработки программного обеспечения. Некоторые группы работают в эпоху анархии и разрабатывают программное обеспечение без помощи каких-либо системных подходов и даже не применяют систематизированные знания. Все опирается на индивидуальные умения. Эпоха фольклора характеризуется культурой коллективной мудрости, накопленного знания, которое часто воплощено в историях об успехе или неудаче или в эмпирических правилах, приобретенных в прошлом. Эпоха методов основана на использовании системных, не всегда формальных подходов к разработке программного обеспечения, которые выходят за пределы фольклора. Эпоха метрики базируется на проведении измерений для оценки качества и производительности и на организации обратной связи для улучшения процесса разработки, основанного на измерениях. И наконец, эпоха инжиниринга, в которую разработка программного обеспечения становится настоящей инженерной дисциплиной. В процессе непрерывного усовершенствования применяются методы, основанные не на фольклоре или догадках, а на теории, проверенной в исследованиях. Принимаемые решения и компромиссы являются системными и вырабатываются на основе моделей и измерений, вовлекая данные из растущего объема знаний.

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

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

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

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

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

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

Некоторые команды выигрывают от оппозиции, тогда как другие не могут перенести разногласий. Это зависит от основной модели, по которой организована команда (Constantine, 1993 [21]; Larson и LaFasto, 1989 [47]). Проектные команды, которые основаны на иерархическом типе руководства и назначении заданий или опираются на традиционные приказы и инструкции, или возглавляются властными лидерами, будут испытывать большие сложности с индивидуалистами и кодирующими ковбоями. Работа таких традиционных тактических команд (см. главу 11) может быть затруднена оппозицией, а подобный стиль управления может подтолкнуть индивидуалистов к противодействию.

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

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

Оппозицию и критицизм никогда не следует путать с нелояльностью. В действительности критическая оценка часто является самой ценной информацией, услышать которую важнее всего. Здоровый скептицизм и критический взгляд нужно поощрять, а не отвергать. Исследования выявили, что качество группового решения задач напрямую зависит от этой «негативной обратной связи». Группы оказываются более эффективными, если в них присутствует «резидентный критик», или «адвокат дьявола», или если в них лучше используются диалектические процессы противопоставления идей и активная критика (Constantine, 1989 [11]; Priem и Price, 1991 [59]).

Руководители должны помнить, что оппозиция сопротивляется контролю и власти в той мере, в какой власть старается контролировать оппозицию. Поэтому, вместо того чтобы контролировать, сотрудничайте! Один из способов эффективного сотрудничества с оппозицией — наделить ее законным статусом. В одном из подходов (Constantine, 1989 [11]; 1991 [13]) резидентный критик или «адвокат дьявола» рассматривается как ценный сотрудник, роль которого очень важна для успеха группы. Так же, как и «песчинка в устрице», критическое наблюдение за работой команды является необходимым раздражителем, формирующим базис для появления жемчужин в области программирования (Thomsett, 1990 [62]). Как член команды индивидуалист формально обязан критиковать решения, придерживаться альтернативных точек зрения, отмечать исключения, сложности и ограничения и следить за тем, чтобы группа рассматривала альтернативы и исследовала трудности, связанные с предложенными решениями.

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

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

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

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

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

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

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