Стиль відповідей, які ви отримуєте на технічні питання, що задаються, залежить від способу завдання питань не менше, ніж від їх складності. Це керівництво навчить ставити запитання так, щоб збільшити ймовірність отримання задовільного відповіді.
Перш, ніж питати…
Перш ніж ставити технічне питання електронною поштою або в дискусійну групу, у чаті або на форумі, зробіть таке:
1. Спробуйте знайти відповідь за допомогою пошукової системи.
2. Спробуйте знайти відповідь за допомогою пошуку на форумі.
3. Спробуйте знайти відповідь у посібнику.
4. Спробуйте знайти відповідь у списку часто задаваних питань (ЧаВО).
5. Спробуйте знайти відповідь шляхом перевірок чи експериментів.
6. Запитайте досвідченого товариша.
7. Якщо ви – програміст, спробуйте знайти відповідь, аналізуючи вихідний код.
Коли запитуєте, вкажіть із самого початку, що ви все це вже зробили; це допоможе зрозуміти, що ви не який-небудь ледар, що тринькає чужий час. Ще краще покажіть, що ви дізналися в результаті своїх пошуків. Всім подобається відповідати людям, які продемонстрували свою здатність сприймати відповіді.
Використовуйте прийоми пошуку в Google за текстом отриманого повідомлення про помилку (пошукайте також у дискусійних групах – Google groups, а не тільки на Web-сторінках). Це може призвести безпосередньо до документації, присвяченої тому, як цю помилку усунути, або до дискусії у списку розсилки, в якій можна буде знайти відповідь. Навіть якщо відповідь і не знайдеться, фраза: ''Я пошукав у Google за наступним запитом, але нічого корисного не знайшов'' стане в нагоді при зверненні за допомогою електронною поштою або в дискусійну групу.
Підготуйте запитання. Продумайте його. На поверхневі запитання ви отримаєте поверхневі відповіді або взагалі відповідей не отримаєте. Чим більше ви зробите, щоб продемонструвати свої роздуми та зусилля щодо вирішення проблеми до того, як просити допомоги, тим вірогідніше, що ви цю допомогу отримаєте.
Не ставте неправильні запитання. Якщо питання будується на помилкових припущеннях, швидше за все, вам дадуть непотрібну буквальну відповідь, подумавши при цьому ''Дурне питання…'' і сподіваючись, що отримання того, про що ви просили, замість того, що дійсно потрібно, вас навчить.
Не думайте, що ви повинні відповісти. Вам ніхто нічого не винен; ви ж, зрештою, не платили за ці послуги. Ви отримаєте відповідь, якщо заслужите її, ставлячи суттєве, цікаве питання, яке наводить на роздуми – питання, що неявно дає спільноті новий досвід, а не просто пасивно вимагає від інших поділитися знаннями.
З іншого боку, непогано відразу ясно дати зрозуміти, що ви можете і хочете допомогти в виробленні рішення. На питання типу ''Чи може хтось підказати?'', ''Що не враховано в моєму прикладі?'' і ''А чи немає сайту, який варто на цю тему подивитися?'' більш ймовірно буде отримана відповідь, ніж на вимогу надіслати точну послідовність дій для вирішення проблеми, оскільки ви явно показали, що вирішите проблему.
Коли питаєте…
Правильно вибирайте форум.
Ретельно продумайте, де саме запитувати. Вас з великою ймовірністю проігнорують або спишуть як невдаху, якщо ви:
1. Надішліть питання у форум, що не відповідає за тематикою (off topic)
2. Надішліть найпростіше питання у форум, де обговорюються складні технічні питання, або навпаки.
3. Надішліть питання одночасно (cross-post) у безліч різних дискусійних груп.
4. Надішліть особисте повідомлення електронною поштою незнайомій людині, яка особисто не відповідає за вирішення ваших проблем.
Спершу треба знайти відповідний форум. У цьому вам знову допоможе пошукова система Google та інші засоби пошуку в Інтернеті. Використовуйте їх для пошуку сторінки проекту, що найбільш тісно пов'язане з обладнанням або програмним забезпеченням, з яким виникли труднощі. Зазвичай на цій сторінці будуть посилання на список питань (ЧаВО, FAQ – Frequently Asked Questions), списки розсилки проекту та їх архіви. Саме там і треба просити допомоги, якщо ваші власні зусилля (включаючи прочитання цих виявлених вами ЧаВО) не увінчалися успіхом. На сторінці проекту може бути описана процедура інформування про помилку або подано посилання на неї. У такому разі скористайтеся рекомендованою процедурою.
Посилання повідомлення людині або у форум, з яким ви не знайомі, – підприємство, як мінімум ризиковане. Наприклад, не думайте, що автор інформативної веб-сторінки хоче стати вашим безкоштовним консультантом. Не робіть оптимістичних припущень про те, що вашому питанню будуть раді – якщо не впевнені, надішліть його за іншою адресою або відмовтеся від його посилки взагалі.
При виборі форуму, дискусійної групи або списку розсилки не ухвалюйте рішення лише на основі імені; прочитайте список часто задаваних питань (FAQ) або правила, щоб переконатися, що питання відповідає тематиці. Прочитайте повідомлення деякий час, перш ніж надсилати питання, щоб відчути, як і що тут робиться. Насправді, перед відправкою питання не завадить пошукати за ключовими словами, пов'язаними з вашою проблемою, в архівах дискусійної групи або списку розсилки. В результаті можна знайти відповідь, а якщо ні, такий пошук допоможе сформулювати краще питання.
Загалом, ймовірність отримати відповіді на запитання у правильно вибраному загальнодоступному форумі вища, ніж у приватному. Причин цього кілька. Одна з них – кількість потенційних відповідальних. Інша – розмір аудиторії, яка дізнається відповідь. Наприклад: задати питання по автомобілю Jeep доцільніше на Джип форумі , ніж на форумі Школа життя .
Зрозуміло, що досвідчені програмісти та творці популярних програм і так уже отримують набагато більше питань, що не стосуються справи, ніж хотіли б. Збільшуючи цей потік, ви в деяких випадках можете стати останньою краплею – зрідка учасники популярних проектів припиняють їхню підтримку, тому що не виносять більше супутніх проблем у вигляді потоку марних повідомлень електронною поштою на їхні особисті адреси.
Ставте осмислені, конкретні теми повідомлень.
При надсиланні повідомлення до списку розсилки або дискусійної групи, тема повідомлення – чудова можливість привернути увагу кваліфікованих експертів рядком довжиною до 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, будь ласка”. Якщо у вас проблема з непрацюючим кодом, розумніше попроситиме пояснити, що в ньому не так, а не просити виправити помилки.
Далі буде…