Как научить ваших пользователей / клиентов отправлять лучшие описания ошибок

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

• ОШИБКА!!!
• х не работает

без гораздо большей информации.

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

Как вы говорите своим пользователям / клиентам описывать проблемы более подробно, чтобы весь процесс мог быть проще для обеих сторон?

редактировать

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

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

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

Таким образом, первым ответом может быть что-то вроде: «Хорошо, я прочитал ваш отчет, но я не знаю, с чего начать. Можете ли вы сказать мне: произошло ли это однажды? Это повторяющийся феномен? Не могли бы вы попробовать X и сказать мне, что У как выглядит после этого? и так далее.

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

Да, это пошаговый процесс, и он не решит все проблемы со связью до завтрашнего утра, но, тем не менее, это начало.

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

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

Для вашего случая это может быть что-то вроде:

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, C, ... прежде чем говорить с нашими представителями». Это действительно будет зависеть от того, насколько вы контролируете приложение, поэтому оно может вообще не быть выполнимым. Это также не безошибочный путь, но, надеюсь, в голову клиента войдет мысль: «ERRORZ PLZ HLP !!!» недостаточно.

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

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

Другой вариант - использовать клиент удаленного рабочего стола, чтобы увидеть, что не так. В наши дни это так же просто, как позволить клиенту загрузить exe.

Вам придется задавать точечные вопросы и очень требовательно отвечать на них, чтобы дать вам ответы на все вопросы. Иногда их жалобы на проблему будут перемежаться с их планами на выходные, жалобами на других или погодой. Постарайтесь держать их на задании и спросите их: «Хорошо, когда вы делаете X, но не делаете Y, что происходит?» Аннотируйте их ответы, чтобы вы начали строить диаграмму последовательности событий, которую позже вы сможете вернуться и отладить.

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

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

-Направить билет пользователю и предоставить ему ссылку, чтобы он знал, что у него есть ошибка номер 1234 на www.yoursite.issues / 1234

- Спросите пользователя, чего он пытался достичь.

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

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