Як навчити своїх користувачів / клієнтів відправляти кращі описи помилок

Мені часто доводиться мати справу з клієнтами або користувачами, які повідомляють про помилки в додатках. Більшість випадків їх зміст є чимось марним

• ПОМИЛКА !!!
• х не працює

без значно більшої інформації.

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

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

редагувати

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

Нагороджуйте своїх користувачів за хороші звіти про помилки, карайте їх за поганих (ну хоча б трохи).

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

Отже, перша відповідь могла бути чимось на кшталт "Гаразд, я прочитав ваш звіт, але не знаю, з чого почати. ​​Чи можете ви сказати мені: чи трапилось це один раз? Це повторюваний феноменан? Чи можете ви спробувати" Х "і скажіть мені, що Y схожий після цього? " і так далі.

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

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

Одне, що я бачив у кількох проектах з відкритим кодом - це написати стандартну "форму" для звітів про помилки, з розділами для загально потрібної інформації.

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

Для вашого випадку це може бути щось на зразок:

URL where the error occurred:

What you did:

What you expected to happen:

What actually happened:

<Some other information you (ckeller & colleagues) often find useful>:

Any extra information you think might be relevant:

("Ви" тут стосуються клієнтів)

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

Зазвичай я прошу їх скріншот помилки щоразу, і врешті-решт вони починають надсилати мені скріншот зі своїм запитом про помилку, оскільки знають, що я його попрошу.

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

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

Песимістичний погляд: Ти не можеш. Це та ж ситуація, що і 40 років тому, за винятком того, що є більше користувачів, більше систем, більше додатків.

(Зауважте, песиміст - це просто оптиміст із досвідом.)

Зробити їх легко, або вони цього не роблять.

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

Зберігання детального файлу журналу та додавання його доповіді про помилку - це початок.

Закінчивши розмову із замовником, скажіть їм: «Наступного разу, будь ласка, підготуйте для мене пункт даних A, B, C тощо.» Звичайно, це працює лише в тому випадку, якщо це ті самі клієнти, які неодноразово телефонували. Я мав успіх у такому підході, коли користувачі дізналися деякі ключові речі, які: a) пришвидшити виклик; b) зробити загальну роздільну здатність набагато швидше.

Якщо більшість з них є одноразовими абонентами, можливо, найкраще оновити "ПОМИЛКА!" екран із текстом, на якому написано: "Ви повинні зібрати елементи даних A, B, C, ..., перш ніж говорити з нашими представниками". Це дійсно буде залежати від того, який контроль ви маєте над додатком, тому він може взагалі не зробити. Це не є надійним способом, але, сподіваємось, він отримає ідею в голову замовника, який кричить "ERRORZ PLZ HLP !!!" недостатньо.

Проблема з повідомленнями про помилки в сучасних програмах полягає в тому, що практично неможливо включити весь контекст, який може бути релевантним. Все, що стосується архітектури процесора до часу доби, може бути актуальним, саме тому і повідомлення про помилки, і поводження з помилками - це більше мистецтво, ніж наука. Такі системи apport-bugкорисні тим, що вони збирають відповідну інформацію та передають її вам. На жаль, до днів реплікаторів матерії, подорожей у часі та компенсаторів Гейзенберга, немає жодного способу бути впевненим, що отриманої інформації від користувачів буде достатньо для налагодження або навіть відтворення проблеми.

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

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

Вам доведеться задавати загострені запитання і бути дуже вимогливим до них, щоб дати вам усі відповіді. Іноді їх скарга на проблему буде переплітатися з їхніми планами на вихідні, скаргами на їх важливих інших чи на погоду. Спробуйте поставити їх на завдання і запитайте: "Гаразд, коли ви робите X, але не робите Y, що відбувається?" Анотуйте їхні відповіді, щоб ви почали будувати схему послідовностей подій, які згодом можна буде повернути назад та налагодити.

Ви можете вкласти деякий час і додати червону кнопку "Повідомити про помилку" у верхньому правому куті програми. Коли користувач натискає кнопку, спробуйте зробити знімок екрана, зібрати всі доступні журнали для сеансу, (можливо, варто) відкрити прямий загальний доступ до екрана користувача, показати йому просту форму та автоматично надіслати дані на ваш сервер.

- Спробуйте запитати у користувача якомога менше, якщо ваш додаток може отримати самі дані. Дозвіл екрану, версія ОС, ім’я користувача, логін, останні дії та журнали

-Зазначте квиток користувачеві та надайте йому посилання, щоб він знав, що у нього на сайті www.yoursite.isissue / 1234 він має номер помилки 1234

-Задати користувачеві те, чого він намагався досягти.

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

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