Глава 6. Общение

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

В частности, для электронной почты опытные разработчики ПО с открытым кодом выработали следующие соглашения:

Посылайте сообщения только в формате простого текста, не в HTML, RichText, или других форматах, которые могут не увидеть почтовые программы, работающие только с простым текстом. Форматируйте строки так, чтобы они были примерно 72 символа в длину. Не заходите за 80-ю колонку, которая стала стандартом де-факто для ширины терминала (некоторые люди могут использовать более широкие терминалы, но никто не использует более узкие). Делая свои строки немногоменьше 80 символов, вы оставляете место для нескольких уровней символов цитирования, которые добавятся в ответах других людей, без необходимости переформатирования вашего текста.

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

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

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

Хорошо подумайте над темой нового сообщения. Это наиболее важная строка в вашем почтовом сообщении, потому что она позволяет любому другому человеку в проекте решить, читать его дальше или нет. Современные программы чтения почты собирают группы связанных сообщений в ветки, которые могут определяться не только общей темой, но и другими заголовками (которые иногда не отображаются). Отсюда следует, что если в ветке всплывает новая тема, вы можете—и должны —установить соответствующую тему при ответе. Целостность ветки будет сохранена, благодаря другим заголовкам, но новая тема поможет людям, просматривающим ветку, понять, что вопрос стал шире. И наоборот, если вы действительно хотите поднять новый вопрос, делайте это с помощью нового сообщения, а не отвечайте на существующее, изменив тему. В противном случае ваша почта всё ещё будет сгруппирована в ту же ветку, что и сообщение, на которое вы отвечаете, и тогда люди будут ошибочно полагать, что ваша почта относится к той теме а это не так. И в этом случае они не только потеряют свое время, но и доверие к вам, как к человеку который свободно владеет инструментами общения, будет подорвано.

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

Упрощайте доступ к информации своим читателям. Вокруг любого активного проекта ПО с открытым кодом витает масса информации, и нельзя полагаться на то, что читатели хорошо знают большую её часть,—вообще, нельзя полагаться, что они знают как её узнать. Вне зависимости от метода коммуникации ваше сообщение должно предоставлять информацию в форме, наиболее удобной для читателей. Если вы потратите две лишних минуты, чтобы откопать URL на конкретную ветку в архивах списка рассылки и тем самым избавите читателей от этого поиска,— оно того стоит! Если вам нужно потратить 5-10 минут на то чтобы подвести итоги, накопившиеся в разросшейся ветке, только для того, чтобы дать людям контекст, в рамках которого надо рассматривать ваше сообщение, сделайте это. Думайте об этом так: чем более успешен проект, тем большее количество читателей приходится на одного писателя на любом из форумов. Если каждое ваше сообщение видят N людей, то при росте Nценность затрат на дополнительные усилия, экономящие время этих людей, также растёт. И если люди видят, что вы сами следуете такому стандарту, они будут работать над тем, чтобы соответствовать ему в своих коммуникациях. В идеале, результатом является рост общей эффективности проекта: когда появляется выбор—тратить ли время всем или одному человеку, проекту выгоднее последнее.

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

То же мнение на самом деле становится сильнее, если выражено менее агрессивно:

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

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

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

Не могли бы вы более детально описать, с какой проблемой вы столкнулись,
	и т.п.?
	
	А также:
	
	Какую версию Slash вы используете? Я не смог понять из вашего первого
	сообщения.
	
	Как в точности вы собрали apache/mod_perl из исходников?
	
	Пробовали ли вы патч для Apache 2.0, о котором шла речь на 
	slashcode.com?
	
	Шейн

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

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

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

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

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

Давайте начнём с вещей, которые не являются грубостью:

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

Прямые, без прикрас вопросы, такие, как вопросы Шейна ко мне в процитированном выше сообщении, также не являются грубостью. Вопросы, которые в другом контексте могут казаться холодными, риторическими, и даже насмешкой, часто задаются серьёзно и не имеют скрытых намерений, кроме получения информации как можно быстрее. Классический пример - вопрос службы технической поддержки "Ваш компьютер включен в розетку?" Сотрудник службы поддержки действительно должен знать, включен ли компьютер в розетку, и, после первых нескольких дней работы, устаёт предварять свой вопрос вежливыми уговорами ("Я очень извиняюсь, но только хочу задать вам несколько простых вопросов, чтобы исключить некоторые возможные ситуации. Некоторые из них могут показаться весьма несущественными, но давайте их пройдём..."). Теперь он больше не беспокоится об этих "подстилках" и просто спрашивает прямо: включен ли компьютер или нет? В почтовых списках рассылки свободного ПО постоянно задаются одинаковые вопросы. Целью является не оскорбление адресата, а быстрое исключение наиболее очевидных (и, возможно, наиболее общих) объяснений. Адресаты, которые понимают это и реагируют соответственно, набирают очки, получая широкий отклик без дополнительных запросов. Но те, кто реагирует неправильно, также не должны страдать. Это просто коллизия культур, а не чей-то проступок. Дружелюбно объясните, что ваш вопрос (или критика) не имеет скрытых смыслов; он просто предназначен для получения (или передачи) информации наиболее эффективным способом, ничего больше.

Тогда что есть грубость?

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

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

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

Поэтому с психологической точки зрения интернет-сотрудничество необычно, поскольку оно подразумевает тесную кооперацию между людьми, которые почти никогда не идентифицируют друг друга наиболее естественными, интуитивными методами: прежде всего по лицам, по голосу, позе и т.д.Для компенсации этого эффекта старайтесь использовать один псевдоним повсюду. Он должен быть начальной частью вашего email-адреса (часть перед знаком @), вашим именем в IRC, именем пользователя в репозитории и баг-трекере и т.д. Это имя - ваше "сетевое лицо": короткая идентификационная строка, которая выполняет часть функций вашего реального лица, хотя, к сожалению, и не возбуждает то же самое "устройство" в мозгу.

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

From: "Karl Fogel" <kfogel@whateverdomain.com>

На самом деле, этот пример иллюстрирует две вещи. Как сказано выше, псевдоним интуитивно соответствует реальному имени, но и настоящее имя действительно реально. То есть, оно не является некоторым вымышленным именем, типа:

From: "Замечательный хакер" <wonderhacker@whateverdomain.com>

Известна знаменитая карикатура Поля Штейнера, появившаяся 5 июля 1993 вThe New Yorker, которая изображает собаку, зарегистрировавшуюся на компьютерном терминале, заговорщицки смотрящую и говорящую другой собаке: "В Интернете никто не знает, что ты собака." Такого рода рассуждения возможно и являются причиной существования большого числа самовозвышающих, задуманных-быть-крутыми сетевых идентификаторов, которые люди себе присваивают - как будто, если кто-то назовает себя "Изумительным Хакером, то люди сразу подумают, что так оно и есть. Однако, факт остаётся фактом: даже если никто не знает, что вы - собака, вы всё равно ей остаётесь. Фантастический сетевой идентификатор никогда не производит впечатления на читателей. Напротив, он заставляет их думать, что вы скорее воображаемое, чем реальное существо, или что вы просто ненадёжны. Используйте своё реальное имя для всех взаимодействий или, если по какой-то причине вы должны соблюдать анонимность, выдумайте имя, которое звучит как хорошее обычное реальное имя, и используйте его постоянно.

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

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

ВАЖНОЕ ЗАМЕЧАНИЕ

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

Данное сообщение послано из Deloitte & Touche LLP. Deloitte & Touche LLP
является товариществом с ограниченной ответственностью, зарегистрированным в
Англии и Уэльсе под регистрационным номером OC303675. Список членов для
ознакомления можно получить в Stonecutter Court, 1 Stonecutter Street, London
EC4A 4TR, United Kingdom, по месту регистрации и основной деятельности фирмы.
Deloitte & Touche LLP санкционировано и регулируется Financial Services
Authority.

Данное сообщение и любые приложения содержат информацию, которая является
конфиденциальной и также может быть привилегированной. Оно - для исключительного
использования получателем(ями), для которых предназначено. Если вы не являетесь
подразумеваемым получателем(ями), пожалуйста, обратите внимание, что любая форма
раскрытия, распространения, копирования или использования данного сообщения или
содержащейся в нём или в любых приложениях информации строго запрещена и может быть
незаконной. Если вы получили данное сообщение по ошибке, пожалуйста, верните его
с заголовком "получено по ошибке" по адресу IT.SECURITY.UK@deloitte.co.uk, а
затем удалите из почты и уничтожьте любые его копии.

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

Любые заключения или советы, содержащиеся в этом электронном сообщении или любых
приложениях, адресованные нашим клиентам, являются предметом условий и
обстоятельств, предусмотренных в основном письме обязательства Deloitte & Touche
LLP перед клиентом.

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

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

Если вы работаете в организации, которая настаивает на присоединении таких блоков подписи ко всем исходящим почтовым сообщениям, подумайте над получением бесплатной учётной записи, например, на gmail.google.com, www.hotmail.com, или www.yahoo.com, и используйте её в качестве своего адреса в проекте.