Effective Forum Questioning.

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

Прежде чем задать вопрос…

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

1. Попытайтесь найти ответ, используя поисковую систему.

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

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

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

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

6. Спросите у опытного друга.

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

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

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

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

Не задавайте неправильные вопросы. Если ваш вопрос основан на ошибочных предположениях, вам, скорее всего, дадут бесполезный, буквальный ответ, подумав: “Какой глупый вопрос…”, и надеясь, что, получив то, о чем вы просили, а не то, что вам действительно нужно, вы чему-то научитесь.

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

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

Когда вы задаете вопрос…

Выбирайте форум с умом.

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

1. Публикуете вопрос на форуме, не соответствующем теме.

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

3. Перекрестно публикуете свой вопрос в нескольких разных дискуссионных группах.

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

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

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

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

В общем, вероятность получения ответов на ваши вопросы выше на хорошо выбранном публичном форуме, чем на частном. Этому есть несколько причин. Одна из них — количество потенциальных респондентов. Другая — размер аудитории, которая получит ответ. Например, задать вопрос о Jeep эффективнее на форуме Jeep, чем на форуме School of Life.

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

Делайте темы ваших сообщений содержательными и конкретными.

При публикации в списке рассылки или дискуссионной группе строка темы — это отличная возможность привлечь внимание квалифицированных экспертов, используя до 50 символов. Не тратьте их на пустую болтовню, например, “Пожалуйста, помогите мне!” (не говоря уже о темах “ПОЖАЛУЙСТА, ПОМОГИТЕ МНЕ!!!!”; сообщения с такими темами отбрасываются рефлекторно). Не пытайтесь произвести на нас впечатление глубиной своих страданий; вместо этого используйте отведенное место, чтобы как можно короче описать проблему.

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

Например:

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

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

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

Написание строки темы с использованием шаблона “объект – отклонение” поможет вам более подробно понять проблему. Когда пользователь получает сообщение с такой темой, он сможет в общих чертах понять, что именно вы испытывали и что это за проблема.

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

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

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

Завершение вопроса фразой ”Пожалуйста, отправьте свой ответ на…”, крайне маловероятно, что вы получите ответ.

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

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

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

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

Пожалуйста, соблюдайте правила синтаксиса, пунктуации и капитализации.

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

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

Если вы отправляете вопрос не на форум, а на адрес электронной почты службы поддержки или “гуру”, которого вы знаете, пожалуйста, отправляйте свои вопросы в формате, который всем понятен.

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

1. Отправляйте свои сообщения в виде простого текста, а не HTML.

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

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

Если вы используете почтовый клиент с графическим интерфейсом (например, Netscape Messenger, MS Outlook и подобные программы), имейте в виду, что он может нарушать эти правила при использовании настроек по умолчанию. У большинства таких клиентов есть команда меню, например “Просмотреть источник”. Используйте ее, чтобы убедиться, что отправляемое сообщение представляет собой простой текст, без какого-либо ненужного спама.

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

Опишите проблему точно и подробно.

1. Тщательно и четко опишите симптомы проблемы или ошибки, которую вы обнаружили.

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

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

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

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

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

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

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

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

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

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

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

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

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

Некоторые, осознав, что им не следует быть грубыми или высокомерными, требуя ответа, выбирают противоположную крайность — самоуничижение. “Я знаю, что я новичок, неудачник и полный нуб, но…” Это отвлекает от сути и не служит никакой цели, особенно в сочетании с расплывчатостью в описании фактической проблемы.

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

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

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

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

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

Опишите цель точно и подробно, а не отдельный шаг.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Продолжение следует…

No votes yet.
Please wait...

Leave a Reply

Your email address will not be published. Required fields are marked *