Навчання користувачів писати гідні та корисні звіти про помилки

Хтось знає хороший спосіб змусити користувачів написати напівпристойний (читати: корисний ) звіт про помилки ?

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

Не працює, коли натискаю на синю кнопку! А-а-а, я просто втратив тиждень роботи ... змусив це працювати.

не дуже корисно, як це є.

Я почав розбиратись у списку, але думав перевірити у вас, хлопці, чи існує подібний метод.

Найефективніший спосіб змусити користувачів писати гідні та корисні звіти про помилки - це

1. щоб дозволити їм бачити свої звіти в Інтернеті ...
   ^{[Система] Дякуємо за повідомлення, ви можете знайти статус свого запиту тут: ...}
2. ... разом з оцінкою та коментарями призначеного інженера ...
   ^{[Інженер] Запит відхилений, оскільки такі деталі відсутні: ...}
3. ... з можливістю редагування / покращення звіту.
   ^{[Користувач] Запитані деталі додаються, будь ласка, переоцініть: ...}

Я б пішов так далеко, щоб стверджувати, що це єдиний ефективний спосіб.

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

Інтернет-звіти про помилки, які можна редагувати користувача, - це найефективніший спосіб навчити користувачів вдосконалюватися .

• ^{Альтернативні варіанти, наведені вище, - це 1) влаштувати навчальні сеанси віч-на-віч (так, звичайно, коли їх тисячі розповсюджуються по всьому світу). Або 2) поясніть їм речі по телефону ("подивіться, якби ви могли бачити лише лайно, яке ви написали у рядку 225 ..."). Що ще? О 3) електронною поштою, впевнено "у пошті, яку ви нам надіслали два місяці тому, ви згадали ... ні не той лист, ви надіслали нам сьогодні п'ять електронних листів, три з них були з темою Re: натисніть синю кнопку , подивіться на другий - той, на якому прикріплений 10-мегабайтний знімок екрана ... що? ви не можете його знайти? "}

На мою думку, найважливіше - це використання помилки для встановлення значимого постійного контакту з користувачем. Написання та розуміння звітів про помилки - це навичка, і моя порада полягатиме в тому, щоб якомога простіше зробити користувач першим контактом, а потім поступово робити зворотній зв'язок, що має більше значення.

Наприклад, просто отримайте електронну пошту користувача та надішліть їм звичайне текстове поле із наступним текстом:

"I did _____ , and expected ______ to happen, but ______ happened instead."

Після отримання електронної пошти зробіть автоматичну відповідь, щоб отримати подвійний вибір, щоб підтвердити, що вони подали помилку, ви отримали її, і подальше сповіщення про помилку нормально.

Ви можете розглянути кілька ідей від Mozilla та Sun на цю тему:

• Настанови щодо написання помилок - стаття Mozilla MDN
• Як правильно написати помилку - стаття Mozilla QMO
• Як написати корисний звіт про помилку - стаття Sun SDN

Зокрема (зі сторінки Mozilla "Як правильно написати помилку"):

Загальний контур звіту про помилки

Резюме : Як би ви описали помилку менш ніж за 60 символів? Він повинен швидко та унікально визначити звіт про помилку, а також пояснити проблему, а не запропоноване рішення.

Добре : "Скасування діалогового вікна" Копія файлу "завершує роботу файлового менеджера"

Погано : "Програми збою"

Погано : "Браузер повинен працювати з моїм веб-сайтом"

Компонент : У якій підрозділі програмного забезпечення воно існує? Це поле є обов'язковою для подання звітів про помилки. Клацніть слово "Компонент", щоб переглянути опис кожного компонента. Якщо жодне не здається підходящим, виділіть компонент «Загальні».

ОС : На якій операційній системі (ОС) ви її знайшли? (наприклад, Linux, Windows XP, Mac OS X.) Приклад: "Якщо ви знаєте, що помилка трапляється на більш ніж одному типі операційної системи, виберіть" Усі ". Якщо ваша ОС не вказана в списку, виберіть "Інше".

Опис : подробиці звіту про проблему, включаючи:

- Огляд : Це більш детальний перегляд резюме. Прикладом може бути: «Перетягнення-вибір будь-якої сторінки вибиває з ладу Mac, побудований у функції NSGetFactory».

- Ідентифікатор збірки : Щоб знайти це, перейдіть на сторінку "про:" через рядок розташування або, якщо у вас є розширення MozQA Nightly Tester Tools, перейдіть до Інструменти | Щомісячні інструменти тестера та виберіть параметр, який містить вихід ID збірки. Це має виглядати приблизно так: “Mozilla / 5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: 1.9.1b3) Gecko / 20090305 Firefox / 3.1b3 ″.

- Додаткові збірки та платформи : Помилка має місце на інших платформах (або у браузерах, якщо це застосовується). Це має виглядати приблизно так: “Не відбувається в Mozilla / 5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: 1.9.1b3) Gecko / 20081107 Firefox / 3.1b2 ″.

Кроки до відтворення : мінімізовані, прості в виконанні кроки, які спровокують помилку. Якщо вони необхідні, обов'язково включіть будь-які спеціальні кроки налаштування. Добрий приклад цього виглядає наступним чином: 1) Перегляд будь-якої веб-сторінки. (Я використовував типову зразок сторінки за замовчуванням, http://www.google.com/ ). 2) Перетягніть-виберіть сторінку. Зокрема, утримуючи кнопку миші, перетягніть курсор миші вниз від будь-якої точки області вмісту браузера до нижньої частини вмісту браузера.

Фактичні результати : Що програма зробила після виконання вищезазначених кроків. Прикладом може бути: Програма перервана.

Очікувані результати : те, що мала зробити програма, не було помилки. Наприклад, таке: Вікно повинно прокручуватися вниз. Виберіть прокручений вміст. Або, принаймні, додаток не повинен виходити з ладу.

Є як ефективно повідомляти про помилки Саймон Татем. Це добре пояснює речі, щоб зробити їх зрозумітими для менш досвідчених користувачів. Однак недоліком є ​​те, що це зовсім небагато тексту. Коли у вас є користувач, який намагається повідомити про проблему, але не в змозі пояснити це, ви зазвичай не зможете переконати його прочитати все це.

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

Наприклад, "Якою була ваша остання дія перед цією помилкою?", "Чи намагалися ви ... безпосередньо перед цією помилкою?".

Жоден користувач не напише вам звіт про помилку на зразок: "Мій відеодрайвер не оновлено. Ваша графічна бібліотека може бути не сумісна зі старими графічними драйверами."

Припустимо, що база користувачів - це кінцеві користувачі, які мали проблеми з написаним вами програмним забезпеченням ....

Це не ваша робота користувачів, щоб стати досвідченим інженером програмного забезпечення або професіоналом тестування, і ви не повинні сподіватися на це. Ваші користувачі - це середньостатистичні люди, які справедливо очікують, що програмне забезпечення "просто працює". Коли цього не відбувається, вони повідомлять про все, що вони думають, що вони прислухаються, щоб привернути вашу увагу. Ви не можете цього змінити і цього не слід робити. Будь-яка спроба наполягати на типі звітів, які, як очікується, зробить професіонал, призведе до втрати звіту про помилку, а клієнт - «У мене виникли проблеми з цим програмним забезпеченням, але замість того, щоб допомогти мені, вони змусили заповнити все види непотрібних форм, які нічого не значать і не мають для мене ніякого значення. Я піду знайти програмне забезпечення, яке насправді працює. "

тобто це не їхня робота .....

Якщо ви хочете отримати хороші звіти про помилки, найдіть своїх фахівців, щоб знайти ваші помилки. Якщо ви, як розробник програмного забезпечення, не можете турбуватися з клієнтами, найміть когось, хто зможе.