Возможность получить максимальную отдачу от команды, разрабатывающей программное обеспечение, зависит от способности профессионалов, вовлеченных в проект, приходить к техническому консенсусу. Но почему же так важно, согласны ли вы и ваш коллега в том, как должна выглядеть форма для заполнения или как следует выдавать сообщения об ошибках? Технический консенсус не касается того, насколько хорошо вы ладите с собратьями-программистами или насколько вы близки с ними по духу (естественно, нет ничего плохого в том, чтобы ладить между со-бой или хорошо относиться друг к другу). Технический консенсус подра' зумевает максимальное использование способностей и опыта каждого участника команды. Речь идет о создании более совершенного программного обеспечения.

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

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

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

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

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

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

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

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

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

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

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

Ничто не может стать фактом просто потому, что вы это так назвали. Поэтому группам следует учиться пресекать пустословие и договориться не злоупотреблять средствами языка. В первые годы нашей совместной жизни моя первая жена научилась с подозрением относиться к любым утверждениям, которые я начинал с фразы наподобие: «Факты ясно свидетельствуют, что…». Это было сигналом, что далее, вероятно, последует глубоко личное мнение, не подкрепленное ни данными, ни доказательствами. После того как этот гамбит перестал действовать, за мной стали иногда замечать приверженность к другой тактике, которую мы назвали ходом «95 % всех ученых». Некоторые из вас, наверное, поняли, о чем идет речь. «Вы знаете, этот метод предпочитает большинство, уж точно более 95 % профессиональных программистов-разработчиков». Естественно, для того чтобы продолжать пользоваться этой уловкой, вам нужно варьировать проценты. «Почти 78 % пользователей WordPerfect знают, что лучшим способом является…» или «Если провести опрос, то более двух третей программистов, пишущих на С, согласятся, что…». Иногда кажется, что стоит только присмотреться, как увидишь легионы ученых, программистов-разработчиков или конечных пользователей, выстроившихся в ряд позади говорящего, чтобы лично поддержать его (или ее) точку зрения.

Но это только мое мнение.

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

Консенсуса нельзя достичь до тех пор, пока вы сами не признаете его наличие. Это значит, что в группах по разработке программного обеспечения, стремящихся к коллективным решениям, разумно заранее договориться о критериях, относительно которых будут решаться технические вопросы. Что является важным? Что имеет значение? Что «хорошо», а что «плохо» в рамках данного проекта?

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

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

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

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

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

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

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

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

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

Когда людям, отстаивающим свои позиции, не удается найти общий язык, поможет такой метод. Стороны меняются ролями и начинают защищать позиции, предложенные другими. Или же активным спорщикам можно поручить защиту технически интересных, но слабо отстаиваемых идей. «Послушай, Мэвис, твоя идея хороша, но сможешь ли ты убедить нас, что в идее Грега есть преимущества?» Еще один прием — предложить следующее: «Давайте применим те же аргументы в рассмотрении другого предложения».

К техническому консенсусу лучше приходить в диалоге и переговорах, чем в споре и препирательствах. Очень полезными могут быть сведения о переговорах, почерпнутые в других областях. Прежде всего, следует порекомендовать две великолепные книги, изданные в рамках «гарвардской программы по ведению переговоров»: Фишер (Fisher) и Юри (Ury) «Getting to Yes» (Как добиться согласия), 1981 [37] и Фишер и Браун (Brown) «Getting Together» (Как добиться единства), 1988 [38].

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

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

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

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

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

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

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