Наступило новое тысячелетие, а вы даже не знаете об этом! Программное обеспечение наконец-то стало надежным. Как же был достигнут этот прорыв в области проектирования программного обеспечения? Вот цитата из 16-страничного рекламного буклета корпорации Nanomush Inc., который был разослан миллионам отсталых пользователей и разработчиков: «Одним из самых мощных дополнений к Blerbbleflox 3.1 является «проверка параметров» (parameter validation). Когда информация поступает из какого-либо приложения в операционную систему Blerbbleflox, система проверяет правильность полученных данных». Вот такая новая идея! Почему же вы об этом не думали, а? (Естественно, все поняли, что речь идет о Microsoft и Windows 3.1.)

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

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

Весной 1992 года я участвовал в конференции по разработке программного обеспечения (Software Development Conference), организованной компанией Miller Freeman. Один из семинаров был посвящен такой скользкой теме, как «структурированное» и «неструктурированное» управление процессом разработки программного обеспечения. Я сидел рядом с одним из представителей компании Nanomush, отвечающим за разработки. Он был всецело на стороне ковбоев. Его позиция заключалась в том, что полному раскрытию потенциала разработчиков препятствуют руководители, которые стремятся ввести стандарты, ограничения или во всеуслышание заявляют об ожидаемых результатах. По его мнению, нужно просто отойти в сторону и не мешать программистам делать свое дело. Структурированные методы, регламентированная разработка, моделирование на бумаге и оценка программного обеспечения — все это неоправданно ограничивает возможности свободного творческого самовыражения наших блестящих ковбоев-программистов. Неудивительно, что продукты, поставляемые такими компаниями, так непредсказуемы в работе.

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

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

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

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

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

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

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

Конечно, это стереотип, но нам, парни, нужно признать, что женщины лучше понимают, что такое сотрудничество. Какие бы причины ни лежали в основе этого, маленькие мальчики стремятся состязаться, а маленькие девочки стремятся сотрудничать. Женщинам, как правило, намного лучше удается выстраивать отношения, поддерживать и поощрять друг друга. (Можно спросить, почему же в нашей отрасли они так редко бывают менеджерами и руководителями проектов. Задумайтесь об этом, руководители среднего и высшего ранга: при прочих равных условиях женщина может иметь явное преимущество над мужчиной в качестве лидера команды, даже если команда состоит из тех программистов-неандертальцев, которые утверждают, что не могут работать на женщину.)

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

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

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

Поэтому растите, ковбои! Учитесь, как становиться на плечи друг друга, а не наступать на ноги. И пусть нам подадут руку помощи женщины, ведь нам нужно так многому научиться.

Из журнала Computer Language Magazine, том 9, № 8, август 1992 г.

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

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

Речи на выпускных церемониях редко бывают запоминающимися. Обычно они либо ханжеские, либо банальные, либо политические; некоторые особенно ужасные варианты могут обладать всеми тремя характеристиками. Однако новый президент колледжа Уитон (Wheaton) уговорил свою предшественницу Корнел (Cornell) принять его помощь в проводах ее первого выпускного класса. Замечания Карла Сагана (Carl Sagan) были немногословны и полны остроумия и прозорливости. Вдохновленный выпускным классом, лишь вторым по счету, прошедшим четыре года совместного обучения в Уитоне, Саган начал с обсуждения взаимосвязи между полом и поведением. Он сосредоточился на женщинах, мужчинах и том мире, который они создают для себя. Сперва Саган обратил всеобщее внимание на шимпанзе. Безусловно, шимпанзе являются нашими генетическими братьями и сестрами — 99,6 % активных генов шимпанзе и человека совпадают. Естественно, поведение шимпанзе и человека определяется не только генетикой, но в то же время не все решает и обучение. Подобно тому как мы способны, взглянув на своих собственных родителей, рассказать о себе, мы можем узнать что-то о homo sapiense sapiense, если посмотрим на отражение своих родственников-приматов.

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

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

И я подумал, где же был Карл Саган в прошлом году, когда меня осаждали банды программистов-шимпанзе мужского пола за то, что я говорил то же самое. Наверное, им было тесновато от разговоров о совместном кодировании.

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

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

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

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

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

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

Увы, понимания бывает недостаточно. Как писала газета Wall Street Journal (от 26 мая 1993 г.), весь проект, казалось, был обречен на то, чтобы произвести колоссальный, чрезвычайно сложный и насыщенный ошибками программный продукт. Около 200 программистов неистово занимались написанием кода в соответствии с определяемыми на лету требованиями, отчего вся разработка проекта превратилась во всеобщую драку.

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

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

Однако подход может быть иным. Дисциплина бывает полезной. Вот что было сказано в докладе Эла Пиитресанта (А1 Pietresanta) на конференции по разработке программного обеспечения, проходившей в 1989 году в Бостоне: если применять «чистые» («clean room») методы кодирования и непрерывного технологического улучшения, то даже в очень больших системах может быть меньше одной ошибки на 10 ООО строк кода.

Зрелость окупается. Замечено, что если большие проекты осуществляются зрелыми организациями с помощью устоявшихся технологий, то расходы на разработку сокращаются в 20–30 раз по сравнению с применением более свободных методов «на скорую руку».

«Ковбоизм» в кодировании может иметь много бастионов, но случай с ранчо Редмонд можно считать уникальным. Издание Journal приводит слова Митчела Дункана (Mitchell Duncan), главного конструктора проекта NT: «Все наши разработчики-ковбои строчат код просто как сумасшедшие».

И настрочили они 4,3 миллиона строк. Только смотрите внимательно, куда наступаете.

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

Что требуется для того, чтобы быть лидером? Какой вид лидерства ведет к эффективной командной работе и успешному решению задач? В конце 70-х годов английский колледж подготовки административных работников (Administrative Staff College) попросил британского консультанта по менеджменту Р. Мередита Белбина (R. Meredith Belbin, 1976 [3]) найти ответы на эти вопросы с помощью проведения формальных наблюдений и экспериментов.

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

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

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

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

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

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

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

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

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

Я думаю, что тема разнообразия в команде очень близка к теме этнического разнообразия. Особенно стоит отметить вклад этнических групп в богатство культуры и поваренное искусство. Мир был бы намного беднее без chiles rellenos, torn kah gai, szekely goulash, pesto sauce, lamb vindalo, coq au vin, strange-flavored beef, pasta primavera, paella и feijoada.[14] Если мы хотим узнать, как можно эффективно работать в разношерстных командах, нам нужно научиться ценить разнообразие в навыках, знаниях и стиле так же, как мы ценим разнообразие в питании.

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

Не всегда легко определить, когда разнообразие переходит в несовместимость. «Странная парочка» (The Odd Couple¹) часто приводится как классический пример принципиальной несовместимости, однако нужно отметить, что Феликс Ангер (Felix Unger) и Оскар Мэдисон (Oscar Madison) работали как раз очень слаженно, хотя и постоянно донимали друг друга. Наверное, в командной работе чье-то личное недовольство не так важно, как коллективная производительность.

Должно быть, именно на этом фоне важно отметить поступление волнующих свидетельств, подтверждающих, что программисты и другие профессионалы в области компьютеров в основном принадлежат к определенному типу личности. Австралийский консультант Роб Томсет (Rob Thomsett) обнаружил, что более 60 % людей, работающих в компьютерной индустрии, имеют одинаковый базовый тип личности. Эти люди практичны, склонны к логическому, реалистичному мышлению, основанному на фактах. Они способны сосредотачиваться и удерживать внимание на полезных предметах и практических вопросах. Они не очень общительны. Такому типу личности соответствует менее 20 % от общей численности людей. Типичные компьютерщики, принадлежащие этой группе, склонны играть лишь некоторые из описанных выше лидерских командных ролей. Чаще всего они становятся конструкторами, доводчиками, наставниками или бригадирами. Только немногие из них (если вообще кто-нибудь) выбирают роль координатора или помощника, незаменимых для четкого и эффективного общения в команде, или роль зачинателя, которая важна для творческого решения задач.

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

Джошуа Якобсон (Joshua Jacobson), дирижер бостонского хора «Zamir», а также один из моих любимых философов, на одной из репетиций сказал об этом так: «Если каждый станет петь одну и ту же ноту, вы не получите гармонии. Для достижения гармонии нужно, чтобы люди пели разные ноты, которые сочетаются друг с другом». Здесь он вторит другому моему любимому философу, Гераклиту Темному. «Темным» он был назван не потому, что его труднее понять, чем последующих греческих философов, а потому, что о нем почти ничего неизвестно кроме косвенных сведений и того, что ему приписывали другие. Возможно, это объясняет, почему он славится таким большим количеством мудрых и замечательных высказываний в поддержку столь разных позиций. Предположительно, он сказал следующее: «Е% two бшфероутсоу», что в переводе с греческого приблизительно означает: «Из разных песен рождается высшая гармония».

Аминь, Гераклит! Селах,[15] Якобсон!

Из журнала Computer Language Magazine, том 9, № 9, сентябрь 1992 г.

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

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

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

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

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

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

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

Эйнштейна находится целая толпа Великовских.[16] Иногда нововведения и идиотизм даже исходят из одного и того же источника, как от Теслы (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 г.

Примечания:

1

CASE (computer-aided software engineering) — автоматизированное проектирование и создание программ. — Примеч. науч. ред.

13

Trail boss (амер., устар. от trail — тропа и boss — начальник). На Диком Западе это старший группы ковбоев, ответственный за скот и погонщиков при перегоне табуна

14

Chiles rellenos — фаршированные перцы, Мексика; torn kah gai — суп из молока кокоса, Таиланд; szekely goulash — гуляш, Трансильвания; pesto sauce — соус из листьев базилика, Италия; lamb vindalo — баранина, приготовленная с острой приправой карри, Индия; coq au vin — курица в красном вине, Франция; strange-flavored beef — мясо с овощами, грибами и молодой кукурузой, Китай; pasta primavera — блюдо из макарон со свежими овощами, Италия; paella — блюдо из моллюсков и морепродуктов, Испания; feijoada — тушеное мясо с черными бобами, Бразилия.

15

Selah (древнеевр.) — слово неопределенного значения из книги Псалмов

16

Иммануил Великовский (1895–1979) — американский историк русского происхождения, успешно издавший ряд лженаучных работ по истории и астрономии