HPC.ru lite - Все форумы
Форум: Palm OS: Palm, Treo, Sony Clie и другие
Тема: предложение
Страницы: [1] 2
[Ответить]
lou [07.04.2004 11:46] предложение:
Ознакомился с чудесным топиком:
http://www.hpc.ru/pda/board/index.php?t=22611
и возникло у меня предложение. Согласен, девушек пользователей КПК немного и их надо беречь. Но почему же "недевушек" мы легко одной фразой козырно отправляем в поиск? Да если человек задает вопрос, то он ждет, что получит ответ на него, а не тыканье носом. И если ты так крут и знаешь, что тема недавно обсуждалась, помнишь, кто поднимал ее, или отвечал, ключевые слова, дату, и т.д., неважно то, очевидно, ты быстрее новичка найдешь ее и сможешь помочь ему ссылкой. Если ты не можешь этого сделать, не отвечай вообще. 
lou [09.04.2004 13:19] Не понятно:
2 maxus
, это ты меня на курсы отправляешь? Или тех неопытных пользователей, которые еще ни разу не сувались в нашу конфу и не знают, что надо пользоваться поиском, или, действительно, просто не умеют. Получается, чтобы получить информацию по какому то элементарному вопросу, надо сначала на курсы идти. А если нет, то можно вызвать раздражение. Позитиве, мне кажется, надо относиться к людям. Об этом хотелось сказать.
Lirik [09.04.2004 13:28] Re: Не понятно:
lou писал(а):
2 maxus
, это ты меня на курсы отправляешь? Или тех неопытных пользователей, которые еще ни разу не сувались в нашу конфу и не знают, что надо пользоваться поиском, или, действительно, просто не умеют. Получается, чтобы получить информацию по какому то элементарному вопросу, надо сначала на курсы идти. А если нет, то можно вызвать раздражение. Позитиве, мне кажется, надо относиться к людям. Об этом хотелось сказать.
ну не совсем так.
это же не чат, а конференция.
нахрена люди опытом делятся, когда вновь пришедшие, вместо того, чтоб прочитать уже написанное - вновь задают вопрос, который обсужден досканально?
а лень сюда приплетать не надо.
не хочешь искать - значит не нужна информация.
lou [09.04.2004 14:40] Не понятно:
А теперь вернемся к теме с которой все началось. Слово "поиск" не встречается. Все мягкие, пушистые… Принимают благодарности. Не так давно, какой то новичок задавал подобный вопрос и был отправлен в поиск. Не раздражает??? Получается, принципы на выборочной основе…
S1av_on [09.04.2004 14:44] Всё губит лень и невнимательность (c) Gnom, www.o45m.ru:
Меня раздражают вопросы подобного рода http://www.hpc.ru/pda/board/index.php?t=22998 данная тема поднимается с периодичностью один раз в месяц полтора. Уже и форуме обсуждали раз пять и в разделе софт подобные программы выделены в отдельный раздел, НЕТ лезут в форум и потом обижаются что их посылают в поиск!
S1av_on [10.04.2004 09:20] Может прилепить?:
Будь на мессте модераторов прилепил эту тему, повторяющихся вопросов сталоб гораздо меньше.
Ультрафиолетовый бегемот [11.04.2004 00:05] :
lou
С maxus'ом лучше не спорить. Он шибко это дело любит. Если интересно, могу в личке объяснить почему. Ей богу, пусть будет как он говорит, а то тема эта надолго затянется.
S1av_on [11.04.2004 00:20] Новый FAQ.:
Я полностью согласен с Максом, повторяющиеся вопросы начинают надоедать, Бегемот не наезжай!
Может не парится и FAQ составить взамен устаревшего? Предлагаю доверить подбор вопросов и ответов Lirik'у (если конечно согласится), он пишет грамотно, сосвоей стороны окажу посильную помощь, да и Макс думаю против не будет.
P.S. НАРОД КТО ВОЗЬМЁТСЯ ЗА НОВЫЙ FAQ!!!
S1av_on [11.04.2004 12:22] Новый FAQ.:
maxus [11.04.2004 01:32] :
всё равно читать никто не будет перед тем, как вопрос задавать.
<----->
Зато мы безобид будем отправлять не в поиск, а в FAQ
. Да если честно, понастоящему хорошего FAQ по Palm OS и нет
.
Кыс [11.04.2004 16:28] Как задавать вопросы правильно:
Был у линуксоидов замечательный текст на эту тему, http://www.catb.org/~esr/faqs/smart-questions.html
Если лениво читать на оригинал на английском, то вот перевод, но он адаптированный.
Создан: Nick A Norkin; VIT Server B 13.02.2003 18:17
Модифицирован: Nick A Norkin 13.02.2003 18:27
Папка:
00. Организационные вопросы Тип сообщения:
FAQ
--------------------------------------------------------------------------------
Сообщение:
Комментарий к переводу
При переводе была допущена одна вольность. Понятие хакер как-то слишком резало ухо (возможно, в свете последних дебатов Закона о языке
) ). Для той группы пользователей, на которую ориентировано, по нашему мнению, настоящее руководство, переводчик позволил себе использовать адаптированный вариант с заменой этого понятия на более нейтральные: технический специалист, компьютерный специалист, эксперт. (Николай Норкин)
Как задавать вопросы по-умному
Оригинал How To Ask Questions The Smart Way ( http://www.tuxedo.org/~esr/faqs/smart-questions.html )
Copyright © 2001 by Eric S. Raymond
Перевод Анны Зверевой © 2003
Содержание
Переводы
Введение
Перед тем, как спросить
Когда Вы спрашиваете
Как интерпретировать ответы
Не реагируйте как неудачник
Вопросы, которых не задают
Хорошие и плохие вопросы
Если Вы не можете получить ответ
Ссылки по теме
Переводы
Переводы этого документа доступны на французском.
Введение
В мире компьютерных спецов качество ответов, которые вы получите на свои технические вопросы, зависит от манеры, в которой вы их задаете, в той же степени, что и от трудности ответа. Это руководство научит вас тому, как задавать вопросы так, чтобы наверняка получить удовлетворяющий ответ.
Первая вещь, которую следует усвоить, состоит в том, что эксперты в действительности любят трудные проблемы и хорошие, требующие размышления вопросы. Если бы нам это не нравилось, мы бы не занимались тем, чем мы занимаемся. Если вы зададите нам вопрос, над которым стоит подумать, мы будем вам благодарны; хорошие вопросы – это хороший стимул и хороший подарок. Хорошие вопросы помогают развить нашу способность понимать других и часто раскрывают проблемы, которые мы могли бы не заметить или не додуматься до них. Среди экспертов восклицание “Хороший вопрос!” является сильным и искренним комплиментом.
Несмотря на это, компьютерные специалисты славятся враждебностью и раздражением по отношению к простым вопросам. Иногда создается впечатление, что мы рефлекторно грубы с новичками и невеждами. Но на самом деле это не правда.
Что есть на самом деле, так это непреклонная враждебность к тем людям, которые, кажется, не желают думать до того, как задать свой вопрос, надеясь, что их работу сделают за них. Общение с подобными людьми является напрасной тратой времени; они забирают его, ничего не давая взамен. Это время мы могли бы потратить на другой, более интересный, вопрос или более стоящего человека. Таких людей мы зовем неудачниками (losers). По историческим причинам мы иногда это пишем как "lusers".
Мы осознаем, что есть много людей, которые просто хотят использовать программное обеспечение, которое мы пишем, и им неинтересно изучение технических деталей. Для большинства людей компьютер является инструментом, конечным средством; у них есть более важные дела и другая жизнь. Мы признаем это, и не ожидаем, что каждый будет вникать в технические детали и поражать нас. Тем не менее, наш стиль ответов на вопросы настроен на тех людей, которые испытывают такой интерес и желают быть активными участниками процесса решения вопросов. Это не изменится в ближайшем будущем. Это не должно измениться; если бы это случилось, мы были бы менее эффективными в том, что мы делаем лучше всего.
Большей частью мы делаем эту работу добровольно. Мы отрываем время от наших занятий для ответов на вопросы и временами бываем перегружены ими. Поэтому мы фильтруем вопросы безжалостно. В особенности мы предпочитаем не общаться с людьми, которые кажутся нам неудачниками, для того, чтобы освободить время на других.
Если вы считаете это отношение несносным, снисходительным, оскорбительным, разберитесь со своими предположениями. Мы не просим вас преклонять перед нами колени; на самом деле, большинство из нас были бы счастливы быть с вами на равных и принять вас в нашу культуру, если бы вы приложили усилие для того, чтобы сделать это реальным. Но помогать тем, кто не хочет помочь себе сам - абсурд. Если вы не можете смириться с такой дискриминацией, мы предлагаем вам обратиться за коммерческой помощью вместо просьбы о персональной помощи.
Если вы решаетесь обратиться к нам за помощью, вы не захотите стать одним из неудачников. Также вы не захотите казаться одним из них. Лучший способ получить быстрый и нужный ответ - это задавать вопрос так, как бы это сделал технически грамотный специалист; как умный, уверенный в себе человек, которому просто понадобилась помощь по одной определенной проблеме.
Ваши предложения и замечания по этому руководству приветствуются. Вы можете посылать сообщения на esr@thyrsus.com. Но имейте в виду, что целью этого документа не является путеводитель по правилам хорошего тона работы в сети. И в основном, я буду отсеивать предложения, не касающиеся напрямую получения полезных ответов на вопросы в техническом форуме.
Перед тем, как спросить
Перед тем, как задать технический вопрос по электронной почте, в группе новостей или на доске объявлений в чате, сделайте следующее:
1. Попытайтесь найти ответ в руководстве пользователя.
2. Попытайтесь найти ответ в FAQ
3. Попытайтесь найти ответ в сети.
4. Попытайтесь найти ответ у продвинутого друга.
Когда вы задаете вопрос, покажите, что вы сперва сделали эти вещи. Это поможет удостовериться в том, что вы не лентяй, который тратит зря время остальных. Самым удачным будет показать то, что вы уяснили из этих действий. Нам нравится отвечать на вопросы тех людей, которые показывают, что они могут обучаться с помощью вопросов.
Подготовьте свой вопрос. Обдумайте его. Поспешные вопросы получают поспешные ответы или не получают их вовсе. Чем больше вы показываете, что приложили усилие обдумать решение вашей проблемы перед тем, как обратиться за помощью, тем больше у вас шансов получить эту помощь.
Остерегайтесь неправильных вопросов. Если вы зададите вопрос, который основывается на ложных предположениях, то г-н Случайный Эксперт наверняка отреагирует бесполезным ответом, думая про себя: “Какой тупой вопрос…” и надеясь, что опыт получения ответов на вопросы научит вас большему, чем сам ответ на вопрос.
Никогда не полагайте, что вы имеете право на ответ. Вы не имеете. Более того, вам нужно заплатить за услугу. Вы заработаете ответ содержательным, интересным, требующим размышления вопросом; вопросом, который подразумевает потребность в коллективном опыте, чем просто пассивную демонстрацию опыта других.
С другой стороны, проявление того, что вы способны и хотите помочь в процессе поиска решения, является очень хорошим началом. У вопросов типа “Кто-нибудь может дать мне намек, в каком направлении развиваться?” “Есть ли какой-нибудь сайт, который нужно было посетить?” больше шансов получить ответ, чем у “Пожалуйста, пришлите мне процедуру, которую я должен использовать” потому, что вы показываете, что вы на самом деле хотите завершить процесс, если кто-то укажет вам правильное направление.
Когда Вы спрашиваете
Тщательно выбирайте форум
Будьте внимательны к тому, куда вы посылаете вопрос. Скорее всего, вас проигнорируют или запишут в неудачники, если вы:
o Посылаете свой вопрос в форум, где данная тема не рассматривается
o Посылаете элементарные вопросы в форум, где ожидаются продвинутые технические вопросы или наоборот
o Делаете перекрестные рассылки в множество разных групп новостей
o Посылаете личное письмо по электронной почте кому-то, кто не является ни вашим знакомым, ни человеком, несущим ответственность за решение ваших проблем
Эксперты отбрасывают вопросы, которые не относятся к их компетенции, для того, чтобы не дать своим коммуникационным каналам утонуть в хламе. Вы бы тоже не хотели бы, чтобы это случилось с вами.
Посылка электронного письма незнакомцу или в форум, с которым вы незнакомы, как минимум рискованы. Например, не думайте, что автор информационной страницы в сети хочет быть вашим бесплатным консультантом. Не делайте оптимистических предположений о том, будет ли принят ваш вопрос. Если вы не уверены, пошлите его в какое-нибудь другое место или откажитесь от его посылки совсем.
При выборе группы новостей или списка почтовой рассылки, не доверяйте слишком просто имени; просмотрите часто задаваемые вопросы (FAQ) или карту сайта для того, чтобы убедиться, что ваш вопрос будет по теме. Почитайте сообщения, пришедшие в качестве обратной связи на этот сайт перед тем, как посылать свое. Тем самым вы поймете, как здесь обстоят дела.
Разберитесь с тем, что конкретно является вашей темой. Одна из классических ошибок состоит в том, что вопросы по программированию под Unix или Windows задаются в форуме, посвященном языку или библиотеке или инструменту, которые применимы и к тому и к другому. Если вы не понимаете, почему это является оплошностью, вам лучше вообще отказаться от задания вопросов до тех пор, пока вы не поймете этого.
В общем случае, вопросы в хорошо выбранном публичном форуме скорее получат полезный ответ, чем те же вопросы в частном форуме. Для этого есть много причин. Одна из них – количество потенциальных респондентов. Другая – охват аудитории; эксперты предпочитают отвечать на вопросы, которые обучат большое количество людей, чем те, которые нужны лишь нескольким.
Понятно, что квалифицированные эксперты и создатели популярного программного обеспечения уже получают огромное количество неправильно направленных сообщений. В общем потоке в экстремальных случаях вы можете стать той соломинкой, которая переломит спину верблюда – в некоторых случаях участники популярных проектов отказывали в помощи потому, что побочный ущерб в виде бесполезного трафика электронной почты становился непосильным для их счетов.
Насколько это возможно, используйте списки почтовой рассылки проекта
Если у проекта есть список почтовой рассылки разработчиков, пишите и рассылайте по этому списку, а не отдельным разработчикам даже если вы знаете, кто лучше всего ответит на ваш вопрос. Проверьте документацию проекта и его домашнюю страницу для того, чтобы найти список почтовой рассылки, и используйте его. Для такой стратегии есть несколько причин:
o Один вопрос, который хорош для ответа одному разработчику, будет полезен и для целой группы. И наоборот, если вы считаете свой вопрос слишком глупый для всего списка рассылки, то это не повод для того, чтобы беспокоить им отдельных разработчиков.
o Вопросы для всего списка помогают распределить нагрузку между разработчиками. Отдельный разработчик (особенно если он является руководителем проекта), может быть слишком занят для ответов на вопросы.
o Большинство листов рассылки заархивированы и архивы проиндексированы поисковыми механизмами. Кто-нибудь сможет найти ваш вопрос и ответ на него в сети вместо повторного запрашивания.
o Если видно, что некоторые вопросы задаются часто, то разработчики могут использовать их для улучшения документации к программному обеспечению. Но если эти же вопросы задаются в частном форуме, то никто не имеет полной картины того, какие вопросы задаются чаще всего.
Если вы не можете найти список почтовой рассылки проекта, а видите только адрес поддержки проекта, напишите туда. Но и тогда не думайте, что список рассылки не существует. Напишите в своем электронном письме, что вы пытались найти список рассылки и не нашли подходящего. Также укажите, что вы не возражаете против передачи вашего сообщения другим людям. (Многие люди считают, что частные электронные письма должны оставаться частными, даже если в них нет ничего секретного. Разрешая передавать ваше сообщение, вы предоставляете вашему корреспонденту право распоряжаться вашим сообщением)
Пишите ясным, грамматически и орфографически грамотным языком
Опытным путем установлено, что люди, которые являются небрежными и неряшливыми в письме, являются также небрежными и неряшливыми в размышлениях и в кодировании (хотя иногда на них можно положиться). Ответ на вопросы несобранных людей – неблагодарное занятие; мы бы лучше потратили время на что-нибудь еще.
Правильная постановка вопроса очень важна. Если вы не можете позаботиться о ней, то мы не можем заботиться о том, чтобы уделить вопросу внимание. Приложите усилия для того, чтобы отшлифовать свой язык. Он не должен быть натянутым или формальным, на самом деле культура компьютерных специалистов ценит неформальный, жаргонный язык с юмором, использованный в меру. Ваша речь должна обладать лаконичностью как признаком обдуманности и внимательности.
Орфография, пунктуация и заглавные буквы должны быть корректными. Не путайте "its" с "it's" или "loose" с "lose". Не пишите всеми заглавными буквами. Это выглядит кричаще и считается грубым. (Все прописные считаются чуть менее раздражительным, так как это трудно читать.)
В более общем случае, если вы пишете как полуграмотный дуралей, вас наверняка проигнорируют. Использование полуграмотного жаргона или тарабарщины гарантирует гробовую тишину (или, в лучшем случае, презрение и сарказм) в ответе.
Если задаете вопросы в форуме, который не поддерживает ваш родной язык, то вам будет позволено ограниченное количество описок и грамматических ошибок. Но никаких ошибок по причине вашей лени быть не должно. (Мы всегда видим отличия между ними) Если вы не знаете, на каком языке говорит респондент, пишите на английском. Занятые эксперты просто пропускают вопросы на языке, которого они не знают. Английский является рабочим языком в Интернете. Отправляя письмо на английском, вы уменьшаете шансы того, что ваше письмо будет отброшено непрочитанным.
Посылайте письма в форматах, которые легко понять
Если искусственно усложняете ваш вопрос, то ему предпочтут более простой, поэтому:
Посылайте простой текст, а не HTML. (не так уж трудно отказаться от HTML)
Как правило, хорошо проходят MIME – вложения. Но только если они имеют стоящее содержание (такое как вложенный файл ресурса или пакет), а не копия вашего сообщения, сгенерированная вашим почтовым клиентом.
Не посылайте письмо, в котором абзацы не разбиты на строки. (Очень трудно ответить на часть такого сообщения). Предположите, что ваш респондент будет просматривать текст при длине строки 80 символов. Отформатируйте ваш текст соответственно, чуть меньше, чем 80 символов в строке.
Тем не менее, не форматируйте такие данные, как записи логов, сессионные записи, в виде колонок фиксированной ширины. Данные должны быть включены как есть, чтобы у респондента была уверенность, что он видит то, что видели вы.
Не посылайте MIME Quoted-Printable кодировку в англоязычный форум. Эти кодировки могут быть необходимы, если вы посылаете сообщения на языках, на которые не распространяется таблица ASCII, но множество почтовых агентов просто не поддерживают эти кодировки.
Никогда не ожидайте того, что ваши респонденты будут читать документы закрытого лицензионного формата типа Microsoft Word. Большинство экспертов реагируют на них так, как вы бы реагировали на кучу свиного навоза, сброшенного у вашей двери.
Если вы отправляете письмо с платформы Windows, отключите дурацкую установку "Smart Quotes"(“Умные ссылки”). Это поможет избежать вам пересылку мусора своей электронной почтой.
Если вы используете почтовый клиент с графическим интерфейсом (Netscape Messenger, MS Outlook или их аналоги), то опасайтесь того, что эти правила могут быть нарушены, если использовать настройки по умолчанию. У многих клиентов есть команда меню "View Source" (“Просмотр источника”). Используйте её в папке для отправки почты, чтобы убедиться в том, что вы посылаете чистый текст без чего-либо ещё.
Используйте значимые, специфические заголовки
В почтовых списках или группах новостей, заголовок темы является вашей золотой возможностью привлечь с помощью 50 символов или менее внимание квалифицированных экспертов. Не тратьте его на ерунду типа “Помогите мне пожалуйста” (“ПОМОГИТЕ МНЕ ПОЖАЛУЙСТА!!!”; сообщения с такими темами отсеиваются рефлекторно). Не пытайтесь впечатлить нас глубиной своих мучений; лучше дайте суперкраткое изложение проблемы.
Хорошее соглашение для тематических заголовков, используемое многими организациями технической поддержки формулируется так: “объект-отклонение”. “Объект” – это вещь или группа, с которой есть проблемы. “Отклонение” – это описание проблемы, то есть отклонение от ожидаемого поведения.
Глупо:
Помогите! Видео не работает как надо на моем лаптопе!
Умно:
XFree86 4.1 деформирует курсор мыши , Fooware MV1005 vid. чипсет
Еще умнее:
XFree86 4.1 курсор мыши на чипсете Fooware MV1005 vid. Деформирован
Процесс построения описания по схеме “Объект-проблема” поможет организовать вам детальное размышление по проблеме. Что подвержено деформации? Только курсор мыши или другая графика тоже? Это специфично для версии 4.1? Это специфично для видеочипсетов Fooware? Модели MV1005? Эксперт, который видит такой результат, может моментально понять, в какой части ваша проблема и в чем она состоит.
Если вы задаете вопрос на ответ, измените строку темы так, чтобы было видно, что вы задаете вопрос. Строка темы, которая выглядит как “Повтор: тест” или “Повтор: новая шишка” вряд ли привлечет к себе много внимания. К тому же укороченные цитаты предыдущих сообщений мало скажут новым читателям.
Будьте кратки и информативны при изложении вашей проблемы
o Описывайте признаки вашей проблемы четко и тщательно
o Описывайте окружение, в котором она произошла (платформа, операционная система, приложение, другое)
o Опишите все исследования проблемы, которые вы проводили перед тем, как задать этот вопрос.
o Опишите те диагностические шаги, которые вы пытались предпринять перед тем, как задать этот вопрос
o Опишите все недавние аппаратные и программные изменения в вашем компьютере. Это может иметь значение.
Приложите все усилия для того, чтобы предугадать все вопросы, которые может задать эксперт, чтобы обдумать ответ на них заранее при обращении за помощью.
Симон Тахем написал отличное эссе “Как эффективно описать ошибку” (How to Report Bugs Effectively). Я настоятельно рекомендую прочитать её.
Краткость – сестра таланта
Вам нужно быть кратким и информативным. Не нужно скидывать кучи кода или данных в запрос о помощи. Если у вас сложный случай с тестированием программы, попытайтесь выделить проблему в наиболее кратком описании.
Это полезно, по меньшей мере, по трем причинам. Во-первых, замечено, что усилия по упрощению вопроса повышают шансы на ответ. Второе: усилия по упрощению вопроса повышают шансы на правильный ответ. Третье: в процессе совершенствования вопроса вы продолжаете сами искать решение проблемы
Описывайте симптомы проблемы, а не ваши догадки
Не очень полезно сообщать экспертам, что, на ваш взгляд, явилось причиной проблемы. (Если ваши диагностические теории так великолепны, то почему вы просите других о помощи?) Поэтому убедитесь, что вы даете им чистые симптомы проблемы, а не ваши теории и интерпретации. Оставьте диагностику на их долю.
Глупо:
Я натыкаюсь на SIG11-ошибки при компиляции ядра, подозреваю поломку одного из элементов материнской платы. Как лучше всего этот проверить?
Умно:
Мой K6/233 на материнской плате PA2007
(чипсет VIA Apollo VP2) с 256MB Corsair PC133 SDRAM выдает SIG11-ошибки через 20 минут после включения при компиляции ядра, но никогда в первые 20 минут. Перезагрузка не перезапускает часы. Выключение на ночь перезапускает часы. Смена всей памяти не помогает. Значимая часть журнала следующая.
Описывайте симптомы проблемы в хронологическом порядке
Самые верные ключи к пониманию того, что пошло не так, лежат в событиях, которые произошли непосредственно перед возникновением проблемы. Значит, ваш отчет должен четко описывать то, что вы делали, что делала машина до возникновения проблемы. Если у процесса есть журнал, то цитирование самых важных 20 строк будет очень полезным.
Если у программы, в которой начались проблемы, есть опции диагностики (такие как –v для verbose), подумайте тщательно о добавлении таких опций, которые добавят полезную информацию по отладке в транскрипт.
Если все-таки ваш отчет получается длинным (больше четырех абзацев), было бы полезно изложить саму проблему, а затем дать хронологический рассказ. Таким образом, эксперты будут знать, что искать в вашем отчете.
Не просите людей отвечать по личной электронной почте
Специалисты считают, что решение проблем должно быть публичным, прозрачным процессом, в течение которого первый ответивший может быть поправлен, если найдется более знающий человек, который заметит неполноту или некорректность ответа. К тому же они получают некое вознаграждение за роль респондента в виде пребывания знающим и компетентным в глазах своих коллег.
Когда вы просите частный ответ, вы нарушаете и процесс ответа, и вознаграждение за него. Это должен быть выбор респондента, отвечать ли ему по частной электронной почте. И если это происходит, то чаще потому, что вопрос плохо оформлен или слишком очевиден для того, чтобы быть интересным для других.
Есть одно ограниченное исключение из этого правила. Если вы думаете, что получите много однотипных вопросов, то очень кстати будут слова: “пришлите мне ответ по электронной почте и я обобщу ваши ответы для группы”. Это благородно попытаться сделать и спасти лист рассылки или группу новостей от потока однотипных посланий, но вы должны сдержать своё обещание и сделать обобщение.
Задавайте вопрос точно
Неясно сформулированные вопросы имеют тенденцию обсуждаться без конца. Большинство людей, которые могут дать вам дельный ответ являются людьми занятыми (хотя бы потому, что большую часть работы они берут на себя сами). У людей такого рода бывает аллергия на такие бездонные бочки, в которые утекает их время, поэтому у них аллергия на такие вопросы.
Вы скорее получите полезный ответ, если будете четко ставить вопрос о том, что вам нужно (указания, код, что-то еще). Это поможет сосредоточить им усилия и обозначить верхнюю границу того времени и энергии, которую они могут потратить на помощь вам. Это хорошо.
Чтобы понять тот мир, в котором вы ищете помощи, подумайте о компетенции как об обильном ресурсе, а о времени для ответа как о скудном ресурсе. Чем меньше времени вы просите, тем больше у вас шансов получить его у занятого и компетентного человека.
Таким образом, вам нужно сократить до минимума постановку своего вопроса; но это часто не одно и то же, что и упрощение вопроса. Например: “Можете ли вы указать, где можно найти хорошее объяснение Х?” обычно является более хорошим вопросом, чем: “Объясните мне пожалуйста Х.” Если у вас есть какой-то код, который не работает, умнее попросить совета о том, что там не правильно, чем попросить поправить его.
Не посылайте вопросы из учебников
Эксперты очень хорошо замечают вопросы из учебников; многие из них создавали эти вопросы сами.
Эти вопросы предназначены для вашей самостоятельной работы, для получения вами опыта. Нормально просить намеки, но не целые решения.
Отсекайте бессмысленные запросы
Избегайте соблазна закончить просьбу о помощи семантически нулевым вопросом типа: “Может мне кто-нибудь помочь?” или “существует ли ответ?” Во-первых, если вы описали свою проблему наполовину, то такое окончание вопроса как минимум излишне. Во-вторых, потому, что оно излишне, эксперты находят его раздражающим, и в ответ вы получите безупречные, но презрительные ответы: “Да, вам можно помочь” или “Нет, вам нельзя помочь”.
Не помечайте свои вопросы как “Срочно”. Даже если это срочно для вас
Это ваши проблемы, а не наши. Требование срочности приведет к обратному эффекту: Большинство экспертов просто удалят это сообщение как грубую и эгоистичную попытку привлечь к себе немедленное и специальное внимание.
Вежливость никогда не помешает
Будьте почтительны. Используйте “пожалуйста” и “спасибо заранее”. Давайте понять, что вы цените время тех людей, которые помогают вам бесплатно.
Честно, это не так важно (и не может заменить собой остального), как грамматическая ясность, краткость, полнота, отсутствие лицензионных форматов и так далее. В большинстве случаев эксперты предпочли бы получить что-нибудь свежее, технически точное, чем расплывчатую вежливость. (Если это озадачивает вас, вспомните, что мы ценим вопрос за то, что он учит нас)
Кстати, если вы изложите все свои технические проблемы, вежливость увеличит ваши шансы на получение полезного ответа.
(Следует заметить, что единственное серьёзное возражение мы получили от ветеранов по поводу фразы “Заранее благодарны”. Некоторые считают, что эта фраза содержит намерение не благодарить никого после. Наша рекомендация делать и то, и другое.)
Пошлите краткую заметку после получения ответа
Разошлите краткие благодарственные письма всем тем, кто помогал вам; сообщите им, что проблема урегулирована и поблагодарите их за помощь. Если проблема привлекла общее внимание почтового списка или группы новостей, напишите туда.
Ваше письмо не должно быть длинным: “Здравствуйте! Проблема заключалась в кабеле. Всем спасибо. Билл” будет лучше, чем ничего. Фактически, короткое и приятное резюме будет лучше, чем длинная диссертация, если только решение не имеет глубокой технической глубины. Назовите действие, которое привело к решению проблемы, но не стоит описывать всю их последовательность.
Помимо учтивости и информативности, такое заключение поможет другим найти в архиве почтового списка / группы новостей / форума конкретное решение, которое может помочь другим.
Последнее, но не менее важное. Такое заключение поможет всем тем, кто оказывал помощь, почувствовать компетентность и сопричастность к решению проблемы. Если вы сами не технарь, поверьте, что это чувство очень важно для технических специалистов, к которым вы обратились за помощью. Описание проблемы, которое канет в пустоту нерешенности разочаровывает. Эксперты жаждут видеть ее решенной. Удачная карма хорошего решения ещё поможет вам тогда, когда вы в следующий раз захотите задать вопрос.
Как интерпретировать ответы
RTFM и STFW: Как сказать, что вы влипли
Существует старая традиция: если вы получаете ответ, который звучит как RTFM, человек, который прислал его считает, что вы должны были Прочитать Чертово Руководство Пользователя (Read The Fucking Manual). Он абсолютно прав. Идите и читайте.
У RTFM есть младший родственник. Если вы получаете ответ STFW, человек, который прислал его, считает, что вам надо порыться в Web (Searched The Fucking Web). он абсолютно прав. Идите и ройтесь.
Часто человек, который посылает один из таких ответов, имеет руководство или страницу с той информацией, которая вам нужна, и он смотрит на них, пока печатает. Такой ответчик считает, что информация, которую вам нужно найти, легкодоступна, и вы поймете больше, если сами поищете ответ в источнике, чем если вас ткнут туда носом.
Вы не должны обижаться на это; по стандартам экспертов, он оказывает вам своего рода грубую форму уважения тем, что не игнорирует вас. Вместо обид вы должны благодарить его за материнскую доброту.
Если вы не понимаете…
Если вы не понимаете ответ, не стоит сразу требовать разъяснение. Используйте те же средства, что и при постановке первоначального вопроса (руководства, FAQ, Web, опытных друзей) для того, чтобы понять ответ. Затем, если вам все равно придется обратиться за объяснением, продемонстрируйте все, что вы усвоили.
Например, предположим, что я говорю вам: “Похоже у вас stuck zentry; вам нужно прояснить это.” Плохой вопрос для развития диалога: “Что такое stuck zentry (?)”
Вариант хорошего встречного вопроса: “Хорошо, я читал страницы, в которых zentries (?) просто упоминаются под буквами –z и –p. Нигде не сказано о zentries (?) подробно. Это что-то из этой области или я что-то упуcтил?”
Как относиться к грубости
Многое из того, что похоже на грубость, в кругах технических специалистов не направлено на то, чтобы обидеть вас. Более того, это результат прямого, отсекающего ерунду стиля общения, который присущ людям, более склонным к решению проблем, чем предоставления другим чувства комфорта и расслабленности.
Когда вы противостоите грубости, старайтесь реагировать спокойно. Если кто-то переходит рамки общепринятого, то, наверное, модератор укажет ему на это. Если этого не происходит, и вы теряете терпение, то наверняка этот человек вел себя в рамках норм, и его стиль общения будет считаться вашей виной.
С другой стороны, вы можете наткнуться на незаслуженную грубость и позерство. Другая сторона вышесказанного состоит в том, что есть общепринятая форма осаждения настоящих обидчиков - разбирать их поведение острым словесным скальпелем. Но будьте очень–очень уверены в своих основаниях перед тем, как попробовать такой стиль общения. Грань между корректированием неучтивости и бессмысленной перепалкой достаточно тонка и эксперты сами нечасто её переходят; если вы новичок или аутсайдер, ваши шансы избежать такой оплошности невелики. Если полученная информация вас удивляет, то лучше держаться подальше от клавиатуры, чем рисковать.
(Некоторые люди утверждают, что многие из компьютерщиков имеют мягкую форму аутизма или синдрома Аспергера, и на самом деле у них отсутствует какая-то мозговая схема, которая вырабатывает “нормальное” социальное взаимодействие между людьми. Это может быть правдой или неправдой. Если вы не являетесь экспертами сами, этот постулат поможет вам ужиться с нашей эксцентричностью, если вы думаете, что у нас с мозгами не все в порядке.) Идите прямо. Нам все равно; мы нравимся себе какими бы мы ни были и обычно скептически относимся к клиническим ярлыкам.
В следующем разделе мы поговорим о другой проблеме; виде грубости, которые вы встретите, если будете себя вести неправильно.
Не реагируйте как неудачник
Если вы влипните на подобных форумах несколько раз, способами, описанными в этой статье, то вам скажут об этом, по возможности во всех красках. Публично.
Если это случится, то самое худшее, что вы можете сделать, это сетовать на опыт, требовать письменного извинения, кричать, угрожать судебными исками, жаловаться работодателям и так далее. Вместо этого вам следует сделать следующее:
Переживите это. Это нормально. На самом деле это полезно и приемлемо.
Нормы общества живут не сами по себе: они поддерживаются людьми, активно применяющими их публично. Не думайте, что вся критика должна идти через частную почту: она перестанет работать. Не стоит настаивать на том, что вас оскорбили лично, когда кто-то сказал, что ваши требования некорректны или ваши взгляды отличаются. Это доводы неудачников.
Существовали форумы, на которых, из-за чувства ложной вежливости, участники форума были предупреждены о том, что им лучше ничего не говорить, если они не хотят помогать пользователю. В результате эти форумы скатывались к детскому лепету и теряли себя в качестве технического форума.
Преувеличенно дружелюбный или полезный. Выберите один.
Помните. Когда эксперт говорит вам, что вы влипли, скажите, что вы так больше не будете. Он руководствуется заботой о вас и об обществе. Ему было бы гораздо проще проигнорировать вас и выбросить из своей жизни. Если вы не можете побеспокоиться о том, чтобы быть благодарным, имейте хоть немного достоинства., не ругайтесь и не ждите, что к вам будут относиться как к хрупкой статуэтке только потому, что вы новичок с гиперчувствительной душой.
Вопросы, которые не задаются
Здесь даются некоторые классические дурацкие вопросы, и то, о чем думают эксперты, когда не отвечают на них.
Q: Где я могу найти программу Х?
A: В том же месте, где нашел бы её я, дурак. На другом конце поисковика. Боже, неужели кто-то ещё не умеет пользоваться Google ?
Q: Моя программа, конфигурация, SQL запрос не работают
A: Это не вопрос. И я не хочу играть в 20 вопросов для того, чтобы вытащить вопрос из вас. У меня есть занятия поинтереснее. При виде такого у меня обычно бывает следующая реакция:
· У вас есть ещё что-нибудь добавить?
· О, это очень плохо. Я надеюсь, вы справитесь.
· А какое это имеет отношение ко мне?
Q: У меня проблемы со своей машиной с Windows. Можете ли вы помочь?
A: Да, снесите этот майкрософтовский мусор и установите открытую систему типа Linux или BSD.
Q: У меня проблемы с установкой Linux или X. Можете ли вы помочь?
A: Нет, мне нужен прямой доступ к вашей машине для решения проблемы. Попросите помощи у вашей локальной группы пользователей. (Список групп пользователей вы можете найти здесь)
Q: Как я могу получить права на чтение чужой почты?
A: Вы низко поступаете, делая такие вещи, и слишком высоко обращаетесь, прося хакера об этом.
Плохие и хорошие вопросы
Наконец, я собираюсь проиллюстрировать, как по–умному задавать вопросы на примерах; пара вопросов по одной проблеме, один заданный по-дурацки, другой по-хорошему.
Глупо: Где я могу найти информацию о Foonly Flurbamatic?
Этот вопрос относится к категории STFW.
Умно:
Я использовал Google для того, чтобы найти информацию о "Foonly Flurbamatic 2600" в Web, но не нашел интересных моментов. Кто-нибудь знает, где я могу найти информацию по программированию с помощью этого средства.
Это уже обработано STFW и выглядит как реальная проблема.
Глупо: Я не могу достать код из проекта для компиляции. Почему он нарушен?
Он думает, что кто-то ещё хочет влипнуть. Глупо.
Умно: Не компилируется код из проекта Nulix версия 6.2. Я прочитал FAQ, но там ничего не говорится о проблемах, связанных с Nulix. Здесь транскрипт моих проблем с Nulix. Я что-нибудь не так сделал?
Он установил среду, он прочитал FAQ, он указал ошибку и он не перекладывает свои проблемы на кого-то ещё. Этот парень заслуживает внимания.
Глупо: У меня проблемы с моей материнской платой. Может кто-нибудь помочь?
Ответ Случайного Эксперта на это наверняка будет: “Хорошо. Вам нужна ещё соска и пеленка?” и последующий удар по клавише delete.
Умно: Я пробовал X, Y, и Z на материнской плате S2464. Когда это не сработало, я попробовал A, B, и C. Заметил странные симптомы, когда я попробовал С. Очевидно (…), но результаты не те, которые можно ожидать. Каковы обычные причины (...) на материнских платах Athlon MP? Кто-нибудь знает, какие тесты мне можно провести ещё для решения проблемы?
На первый взгляд, этот человек, кажется, достоин ответа. Он проявил способность к исследованию проблемы, а не пассивное ожидание ответа, который свалится на него сверху.
В последнем вопросе обратите внимание на тонкую разницу между требованием “Дайте мне ответ” и просьбой “Посоветуйте дополнительные диагностические средства”.
Фактически, форма того последнего вопроса тесно связана с реальным случаем, который произошел в августе 2001 на мейл-листе по ядру linux. Я (Эрик) наблюдал загадочные замыкания на материнской плате Tyan S2464. Участники списка предоставили критическую информацию, с которой мне надо было разобраться.
Путем задавания вопросов я давал людям пищу для размышления. Я сделал это простым и интересным для того, чтобы вовлечь их. Я демонстрировал уважение к их способностям и приглашал посоветоваться со мной как с членом той же группы. Так же я демонстрировал уважение к их времени путем рассказа о том, что я уже проделал.
После всего, когда я поблагодарил всех и отметил то, как плодотворно мы поработали, один из членов группы сказал, что все прошло удачно не столько по тому, что я “имя” в том списке, а потому, что я правильно задал вопрос.
В некотором смысле хакеры очень безжалостный народ. Я уверен в том, что он был прав и если бы я вел себя как неудачник, я был бы сожжен или проигнорирован, не важно кем бы я был. Его предложение описать этот случай как инструкцию для других привело прямо к написанию этого руководства.
Если вы не можете получить ответ
Если вы не можете получить ответ, не принимайте это так, как будто мы не хотим ответить лично вам. Иногда члены опрашиваемой группы могут просто не знать ответов. Отсутствие ответа ещё не означает игнорирование, хотя, надо признать, разницу извне увидеть трудно.
В общем случае повторять вопрос не стоит. Это будет выглядеть как раздражающая навязчивость.
Есть другие источники помощи, иногда даже более приспособленные для новичков.
Существует множество онлайновых и локальных групп пользователей, которые с энтузиазмом относятся к программному обеспечению, даже если сами его никогда не писали. Эти группы часто формируются так, что люди могут помогать друг другу и помогать новым пользователям.
Существует также несколько коммерческих компаний, которые могут заключить с вами контракт на оказание помощи, большой и маленькой. (Red Hat и Linuxcare – самые известные, существует также много других). Не смущайтесь от идеи платы за оказание помощи. В конце концов, если у вас сломалась машина, то скорее всего вы отвезете её в ремонт и заплатите за него. Даже если программное обеспечение вам ничего не стоило, не стоит рассчитывать на то, что обслуживание всегда будет бесплатным.
Для популярного программного обеспечения типа Linux, существует по крайней мере 10 000 пользователей на одного разработчика. Просто невозможно одному человеку поддерживать звонки 10 000 пользователей. Помните, что даже если вам нужно платить за помощь, то вы платите все же меньше, чем за покупку самого программного обеспечения (и поддержка закрытого программного обеспечения обычно более дорогая и менее компетентная, чем поддержка открытого программного обеспечения)
Ссылки по теме
Если вам нужны инструкции по основам работы персонального компьютера, Unix и Интернета, смотрите The Unix and Internet Fundamentals HOWTO.
Если вы выпускаете программное обеспечение или пишете пакеты для программного обеспечения, попытайтесь следовать правилам, описанным в Software Release Practice HOWTO.
[Ответить]
[Вперед >]