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

Прежде, чем спрашивать...

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

1. Попытайтесь найти ответ с помощью поисковой системы.

2. Попытайтесь найти ответ с помощью поиска на форуме.

3. Попытайтесь найти ответ в руководстве.

4. Попытайтесь найти ответ в списке часто задаваемых вопросов (ЧаВО).

5. Попытайтесь найти ответ путем проверок или экспериментов.

6. Спросите опытного товарища.

7. Если вы - программист, попытайтесь найти ответ, анализируя исходный код.

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

Используйте приемы типа поиска в Google по тексту полученного сообщения об ошибке (поищите также в дискуссионных группах - Google groups, а не только на Web-страницах). Это может привести либо непосредственно к документации, посвященной тому, как эту ошибку устранить, либо к дискуссии в списке рассылки, в которой можно будет найти ответ. Даже если ответ и не найдется, фраза: "Я поискал в Google по следующему запросу, но ничего полезного не нашел" пригодится при обращении за помощью по электронной почте или в дискуссионную группу.

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

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

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

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

Когда спрашиваете...

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

1. Пошлете вопрос в форум, не соответствующий по тематике (off topic)

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

3. Пошлете вопрос одновременно (cross-post) во множество различных дискуссионных групп.

4. Пошлете личное сообщение по электронной почте незнакомому человеку, лично не отвечающему за решение ваших проблем.

Сначала надо найти соответствующий форум. В этом вам снова поможет поисковая система Google и другие средства поиска в Web. Используйте их для поиска страницы проекта, наиболее тесно связанного с оборудованием или программным обеспечением, с которым возникли трудности. Обычно на этой странице будут ссылки на список часто задаваемых вопросов (ЧаВО, FAQ - Frequently Asked Questions), списки рассылки проекта и их архивы. Именно там и надо просить помощи, если ваши собственные усилия (включая прочтение этих, обнаруженных вами, ЧаВО) не увенчались успехом. На странице проекта может быть также описана процедура информирования об ошибке или представлена ссылка на нее. В таком случае, воспользуйтесь рекомендованной процедурой.

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

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

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

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

Задавайте осмысленные, конкретные темы сообщений.

При посылке сообщения в список рассылки или в дискуссионную группу, тема сообщения - прекрасная возможность привлечь внимание квалифицированных экспертов строкой длиной до 50 символов. Не тратьте их на лепет типа "Помогите мне, пожалуйста" (не говоря уже про темы "PLEASE HELP ME!!!!"; сообщения с такими темами выбрасываются рефлекторно). Не пытайтесь поразить нас глубиной своих страданий; лучше используйте отведенное место для максимально краткого описания проблемы.

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

Например:

Глупо писать: Помогите, у меня не отображаются русские буквы

Лучше: Проблема с кириллическими шрифтами в Windows XP SP2

Еще лучше: Шрифты в Windows XP SP2 - неправильное отображение

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

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

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

Упростите посылку ответа.

Завершение вопроса фразой "Ответ, пожалуйста, направляйте по адресу... " делает получение ответа весьма маловероятным.

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

Пишите понятным языком, соблюдая правила грамматики и лексики.

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

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

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

Не ПИШИТЕ ВСЕ В ВЕРХНЕМ РЕГИСТРЕ, - это воспринимается как крик и считается грубостью. Если все написано в нижнем регистре, - не многим лучше, поскольку так сложно читать.

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

Если вы посылаете вопрос не на форум, а на е-мэйл службы поддержки или знакомому «гуру», посылайте вопросы во всем понятных форматах.

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

1. Посылайте сообщение в виде обычного текста, а не в формате HTML.

2. MIME-приложения обычно вполне допустимы, но только если они имеют реальное содержание (например, прилагается исходный текст или файл исправлений), а не просто автоматически генерируются почтовым клиентом (представляя собой, например, еще одну копию письма, но в формате HTML).

3. Постарайтесь не отсылать документы в закрытых, патентованных форматах типа Microsoft Word или Excel. Многих возмущает необходимость возиться с ними.

При использовании почтового клиента с графическим интерфейсом, (например, Netscape Messenger, MS Outlook и им подобных) помните, что он может нарушать эти правила при использовании стандартных установок. В большинстве таких клиентов в меню есть команда типа "View Source". Проверьте с ее помощью по одному из отправленных сообщений, что посылается обычный текст, без лишнего мусора.

Точно и детально опишите проблему.

1. Внимательно и четко опишите симптомы обнаруженной проблемы или ошибки.

2. Опишите среду, в которой она возникает (машина, ОС, приложение и т.д.) Укажите дистрибутив и релиз.

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

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

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

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

Объем еще не значит точность.

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

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

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

Помните, что множество других пользователей с такой проблемой не сталкивались. Иначе вы бы уже узнали об этом при чтении документации или при поиске в Web (вы же сделали это, прежде чем делать подобные утверждения, не так ли?). Это означает, что, скорее всего, именно вы что-то делаете неправильно, а не программное обеспечение.

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

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

Публичное самоунижение не заменяет выполнение домашних заданий.

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

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

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

Описывайте симптомы проблемы в хронологическом порядке.

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

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

Точно и детально описывайте цель, а не отдельный шаг.

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

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

Глупо: Как заставить диалог выбора цвета в программе FooDraw воспринимать шестнадцатеричное RGB-значение?

Разумно: Я пытаюсь заменить таблицу цветов в изображении нужными мне значениями. Сейчас я вижу только один способ сделать это - редактируя каждый слот таблицы, но я не могу задать шестнадцатеричное RGB-значение в диалоге выбора цвета программы FooDraw.

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

Не просите отвечать на личный адрес электронной почты.

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

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

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

Задавайте ясные и четкие вопросы.

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

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

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

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