Как избежать распространенных ошибок?

Не посылайте сообщения без цели

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

  1. Сообщения, предлагающие нечто нетривиальное.

  2. Сообщения, выражающие поддержку или несогласие с чем-то, что сказал кто-то ещё.

  3. Обобщающие сообщения.

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

Два хороших повода добавить свой голос в тему это а) когда вы видите недостаток в предложении и полагаете, что вы единственный, кто видит это, и б) когда вы видите, что между другими возникает недопонимание, и знаете, что можете восстановить его разъясняющим сообщением. Также, нет ничего плохого в том, чтобы послать сообщение, просто поблагодарив кого-то за что-то, или сказать "Я тоже", поскольку получатель может чётко определить, что такое сообщение не требует ответа или дальнейших действий и, следовательно, не будет размышлять о нем больше чем надо. Но даже в этих случаях подумайте дважды, прежде чем что-то сказать; всегда лучше, чтобы у людей оставалось желание, чтобы вы писали больше, чем желание, чтобы вы писали меньше. (Смотрите вторую часть Приложение C, Why Should I Care What Color the Bikeshed Is? . Там есть несколько мыслей, о том как вести себя в оживлённом списке рассылки.

Продуктивные и непродуктивные темы

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

Чтобы понять, как это делается, давайте рассмотрим контекст, в котором это происходит. Каковы отличительные признаки непродуктивной темы?

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

  • Люди начинают говорить чаще и используя все большие преувеличения, обсуждая все меньшую и меньшую пользу для проекта.

  • Большинство комментариев приходят от людей, которые делают мало или ничего,в то время как люди, старающиеся доводить дела до конца, молчат.

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

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

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

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

А вот это хорошо:

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

Почувствуйте разницу между первым и вторым подходом. Во втором случае не проводится линия между вами и остальными, и они не обвиняются в том, что они ходят кругами. Говорится "мы", и это важно независимо от того, принимали вы участие в теме до этого или нет, поскольку это напоминает каждому, что даже те, кто до сих пор молчал, вносят вклад в результат темы. Здесь описывается, почему тема идёт в никуда, но это делается без уничижения и осуждения - просто беспристрастно констатируются некоторые факты. Наиболее важно то, что предложено позитивное направление действий, так что люди чувствуют себя не так, будто дискуссию закрывают (ограничение, которое может только подтолкнуть к сопротивлению), а так, будто им предлагают способ перевести разговор на более конструктивный уровень. Это - то поведение, которого и ждут люди.

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

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

Чем шире вопрос, тем длиннее споры

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

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

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

Это длинная история, или, скорее, старая история, но на самом деле достаточно короткая. В середине 1960-х Сирил Норткот Паркинсон написал книгу под названием "Законы Паркинсона", которая рассматривает многие движущие силы управления.

[...]

В конкретном примере с навесом для велосипедов второй существенный компонент - атомная электростанция, я полагаю, это подчёркивает возраст книги.

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

Паркинсон объясняет это тем, что атомная станция настолько громадна, так дорога и сложна, что люди не могут этого охватить, и вместо того, чтобы попытаться, они полагаются на то, что кто-то другой уже проверил все детали. Ричард Фейнман в своих книгах даёт массу интересных, и очень подходящих, примеров, связанных с Лос-Аламосом.

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

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

(Его полное сообщение также очень полезно почитать. Смотрите Приложение C, Why Should I Care What Color the Bikeshed Is?; и http://bikeshed.com.)

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

Как избежать религиозных войн?

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

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

Обычный, но неудовлетворительный, способ, которым люди пытаются прекратить религиозную войну - сказать "Мы уже потратили намного больше времени и энергии, обсуждая это, чем следовало! Не могли бы мы просто прекратить это?" Здесь есть две проблемы. Первая в том, что время и энергия уже потрачены и их не вернуть - теперь единственный вопрос, сколько будет истрачено ещё? Если некоторые люди видят, что ещё немного споров и проблема решится, то всё ещё имеет смысл (с их точки зрения) продолжать.

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

Но тогда как же ыы должны управлять религиозными войнами?

Первый совет такой - постарайтесь устраивать всё так, чтобы они не возникали. Это не так безнадёжно, как кажется:

Вы можете предвидеть некоторые стандартные религиозные войны: они имеют тенденцию возникать вокруг языков программирования, лицензирования (смотрите «The GPL and License Compatibility» in Глава 9, Licenses, Copyrights, and Patents), reply-to munging (see «The Great Reply-to Debate» в Глава 3, Техническое обеспечение)и некоторых других вопросов. В каждом проекте обычно есть одна-две собственные религиозные войны, с которыми постоянные разработчики очень быстро осваиваются. Техники для остановки религиозных войн или, по крайней мере, снижения ущерба от них везде одни и те же. Даже если вы уверены, что правда на вашей стороне, попытайтесь найти какой-то способ выразить сочувствие и понимание утверждений противоположной стороны. Часто проблема в религиозной войне состоит в том, что каждая сторона строит свои стенки такими высокими, как только может, и даёт ясно понять, что любое другое мнение это явная глупость, поэтому акт уступки или изменения чьих-либо представлений становится психологически непереносимым: это было бы не просто признанием своей неправоты, но того, что ты выражал уверенность, будучи неправ. Вы можете сделать такое признание приемлемым для противоположной стороны, выказав некоторую собственную неуверенность - особенно показывая, что вы понимаете приведённые ими аргументы и находите их по крайней мере разумными, если и не до конца убедительными. Сделайте жест, который оставляет место для ответного жеста, и обычно ситуация улучшится. Это ни больше и не меньше продвигает к техническому результату, которого вы ожидаете, но, по меньшей мере, вы можете избежать ненужных второстепенных опасностей для боевого духа проекта.

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

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

Более подробную историю религиозных войн смотрите на http://catb.org/~esr/jargon/html/H/holy-wars.html, а работа Дэнни Коэна (Danny Cohen) ввела термин в упортребление, http://www.ietf.org/rfc/ien/ien137.txt.

Эффект "шумящего меньшинства"

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

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

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